security.txt nach RFC 9116 erstellen

Eine Anleitung zum Selbermachen: die zwei Pflichtfelder, ein vollständiges Beispiel zum Übernehmen, der richtige Ablageort und die fünf Fehler, die in der Praxis am häufigsten vorkommen. Wer diese Schritte abarbeitet, braucht dafür keinen Dienstleister.

Was die Datei ist

Eine security.txt ist eine Klartextdatei an einem fest vereinbarten Ort Ihrer Website. Sie sagt jedem, der eine Schwachstelle in Ihrem Produkt oder Ihrem Auftritt findet, an wen er sich wenden kann — mit Kontaktadresse, Schlüssel und Spielregeln. Ihr Aufbau ist in RFC 9116 genormt, damit Mensch und Maschine die Datei ohne Raten finden und lesen können.

Ab dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act: Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden an die Behörden melden. Diese Frist beginnt mit der eigenen Kenntnis — wer für Finder nicht erreichbar ist, erfährt von Lücken im eigenen Produkt womöglich zuletzt. Eine Kontaktadresse für Schwachstellenmeldungen schreibt der CRA ab dem 11. Dezember 2027 vor; die security.txt ist der Standardweg dafür, aber nicht wörtlich vorgeschrieben.

Schritt 1

Die Felder: zwei Pflicht, vier sinnvoll

Contact — Pflichtfeld

Wohin eine Meldung gehen soll. Erlaubt sind eine E-Mail-Adresse (mailto:), eine Telefonnummer (tel:) oder eine HTTPS-Adresse, etwa ein Meldeformular. Mehrere Contact-Zeilen sind zulässig; die Reihenfolge ist die Reihenfolge Ihrer Präferenz. Die Adresse muss funktionieren und gelesen werden — dazu unten mehr, es ist der fünfte der fünf Fehler.

Expires — Pflichtfeld

Das Datum, bis zu dem die Angaben gelten, im ISO-8601-Format mit Zeitzone — genau einmal in der Datei. RFC 9116 empfiehlt, das Datum weniger als ein Jahr in die Zukunft zu legen: Die Datei soll regelmäßig angefasst und geprüft werden, nicht einmal geschrieben und vergessen.

Vier Felder, die sich lohnen

Encryption — die Adresse Ihres öffentlichen OpenPGP-Schlüssels, damit eine Meldung verschlüsselt werden kann. Eine Schwachstellenbeschreibung im Klartext per Mail ist selbst ein Risiko.
Policy — die Adresse Ihrer veröffentlichten Regel, wie Sie mit Meldungen umgehen (Coordinated Vulnerability Disclosure): was ein Finder melden soll, was er von Ihnen erwarten kann und in welcher Zeit.
Canonical — die maßgebliche Adresse der Datei selbst. Damit ist belegt, welche Fassung gilt, wenn die Datei mehrfach oder in Kopien auftaucht.
Preferred-Languages — die Sprachen, in denen Sie Meldungen entgegennehmen können, etwa de, en.

Ein vollständiges Beispiel 200 OK — text/plain

Contact: mailto:security@ihre-firma.example
Expires: 2027-09-01T06:00:00.000Z
Encryption: https://ihre-firma.example/pgp-schluessel.txt
Policy: https://ihre-firma.example/cvd-policy
Canonical: https://ihre-firma.example/.well-known/security.txt
Preferred-Languages: de, en

ihre-firma.example ersetzen Sie durch Ihre Domain, das Expires-Datum durch eines, das höchstens ein Jahr entfernt liegt. Mehr braucht die Datei nicht: Es gibt keine Vorschrift zur Reihenfolge der Felder, Kommentarzeilen beginnen mit #. RFC 9116 sieht zusätzlich vor, dass die Datei mit OpenPGP signiert werden kann — das ist empfohlen, aber keine Pflicht.

Schritt 2

Wohin die Datei gehört

Der Ort ist Teil der Norm: https://ihre-domain/.well-known/security.txt. Der Ordner /.well-known/ ist der in RFC 8615 festgelegte Platz für solche wohlbekannten Adressen — dort suchen Menschen und Werkzeuge zuerst.

Drei Bedingungen gelten für die Auslieferung: über HTTPS erreichbar, als Klartext mit dem Medientyp text/plain, im Zeichensatz UTF-8. Zusätzlich darf die Datei unter /security.txt im Wurzelordner liegen; maßgeblich ist die Adresse unter /.well-known/.

Praktisch heißt das: Bei einem statischen Auftritt legen Sie im Webroot den Ordner .well-known an und die Datei hinein. Bei einem CMS oder Shopsystem hinterlegen Sie sie als statische Datei oder eigene Route — manche Systeme filtern Pfade, die mit einem Punkt beginnen, und brauchen dafür eine Ausnahme.

Bevor Sie es abhaken

Die fünf häufigsten Fehler

Abgelaufenes Expires. Die Datei liegt da, das Datum ist vorbei — damit gilt sie nach RFC 9116 als ungültig. Die Erneuerung gehört in den Kalender, nicht ins Gedächtnis.
Eine HTML-Fehlerseite mit Status 200. Viele Systeme beantworten unbekannte Pfade mit einer gestalteten Fehlerseite und melden trotzdem „200 OK". Ein Werkzeug sieht „vorhanden", ein Finder sieht nichts. Unter der Adresse muss die Datei selbst liegen.
Kein Klartext. Das System verpackt die Datei in eine HTML-Seite oder liefert sie mit falschem Medientyp aus. Vorgeschrieben ist text/plain — was ein Browser als schmucklosen Text anzeigt, ist hier richtig.
Fehlendes Canonical. Ohne das Feld bleibt offen, welche Adresse die maßgebliche Fassung trägt. Spätestens wenn die Datei signiert wird, fehlt damit der Bezugspunkt der Signatur.
Ein Postfach, das niemand liest. Die Datei ist Mittel, nicht Zweck. Endet die Contact-Adresse in einem Sammelpostfach ohne Zuständigen, kommt die Meldung an und bewirkt nichts — der Vorsprung, den die Datei bringen sollte, ist verschenkt.

Schritt 3

Selbst prüfen — eine Minute

Öffnen Sie ein Browserfenster, tippen Sie Ihre Domain in die Adresszeile und hängen Sie /.well-known/security.txt an. Was erscheinen soll: die Datei selbst, als schlichter Text mit Ihren Feldern — keine gestaltete Seite, keine Fehlermeldung.

Erscheint reiner Text mit den Feldern aus dieser Anleitung?
Liegt das Expires-Datum in der Zukunft — und höchstens ein Jahr voraus?
Funktioniert die Contact-Adresse? Eine Testnachricht schicken und messen, wann jemand antwortet — das prüft den Teil, den keine Datei ersetzen kann.

Auf unserer CRA-Seite steht eine Sofort-Prüfung, die die öffentliche Datei einer Domain auf dieselben Punkte abklopft.

Wer es lieber abgibt

Alles oben Beschriebene können Sie selbst umsetzen — dafür ist dieser Text da. Wer die Meldestelle lieber in einem Stück eingerichtet bekommt: Oberflow richtet sie zum Festpreis von 490 € ein — security.txt nach RFC 9116, psirt@-Postfach mit eigenem OpenPGP-Schlüssel, veröffentlichte CVD-Policy und ein Übergabeprotokoll auf einer Seite: was eingerichtet wurde, wo es liegt, wann was zu erneuern ist. Fünf Arbeitstage.

Die Einrichtung ist eine technische Leistung, keine Rechtsberatung. Ob Ihr Produkt unter den Cyber Resilience Act fällt, klärt im Zweifel Ihr Anwalt.

Zur CRA-Meldestelle 0179 1565405

Einordnung

Einordnung: Dieser Text ist eine technische Anleitung und allgemeine Information, keine Rechtsberatung und keine Bewertung eines Einzelfalls. Oberflow erbringt technische Leistungen und keine Rechtsdienstleistungen. Der Standard ist im Wortlaut unter RFC 9116 bei rfc-editor.org nachzulesen. Stand: 10. September 2026.