security.txt nach RFC 9116 und BSI TR-03183-3: Anleitung für Hersteller

Eine security.txt ist eine kleine Textdatei unter /.well-known/security.txt auf der Webseite des Herstellers. Sie sagt Sicherheitsforschern, Kunden und Behörden, wohin sie eine Schwachstelle melden sollen. Die Verordnung (EU) 2024/2847 verlangt in Anhang I Teil II Nummer 6 eine solche Kontaktadresse und in Artikel 13 Absatz 17 eine zentrale Anlaufstelle, schreibt aber kein Format vor. Die BSI TR-03183-3 füllt diese Lücke: security.txt nach RFC 9116 als Mindestanforderung, dazu OpenPGP-Signatur, ein Ablaufdatum von höchstens einem Jahr und zwei Funktionspostfächer, psirt@ für Produkte und csirt@ für die eigene IT.

Was verlangt die Verordnung, und ab wann?

Drei Stellen der Verordnung betreffen die Meldeadresse. Anhang I Teil II Nummer 6 verpflichtet Hersteller, eine Kontaktadresse für die Meldung entdeckter Schwachstellen anzugeben. Anhang I Teil II Nummer 5 verlangt eine Strategie für die koordinierte Offenlegung, auf die die security.txt verweist. Artikel 13 Absatz 17 fordert eine zentrale Anlaufstelle, über die Nutzer "direkt und schnell" mit dem Hersteller kommunizieren können, auch um Schwachstellen zu melden. Sie muss leicht zu finden sein, in den Nutzerinformationen nach Anhang II stehen, und Nutzer müssen ihr Kommunikationsmittel wählen können.

Die Pflichten aus Anhang I Teil II gelten nach der Kommissionsleitlinie C(2026) 5252 (Randnummer 210) für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden. Trotzdem ist die Meldeadresse heute schon wichtig: Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026 und beginnt mit der Kenntnis des Herstellers. Wer keine funktionierende Adresse hat, erfährt von einer Schwachstelle später als nötig. Das Format legt die Verordnung nicht fest. In Deutschland ist die BSI TR-03183-3 "Vulnerability Reports and Notifications" (Version 1.0.0, 20. August 2025) der Maßstab. Sie ist freiwillig, eine harmonisierte Norm (prEN 40000-1-3) ist noch nicht im Amtsblatt, und ob die Marktüberwachung die TR als Maßstab anlegen wird, ist nicht belegt. Sie ist aber die einzige behördliche Beschreibung, und wer sie erfüllt, erfüllt auch RFC 9116.

Was ist security.txt und wo liegt die Datei?

RFC 9116 ist ein Standard der IETF aus dem April 2022. Er legt fest, wie eine Webseite ihre Sicherheitskontakte maschinenlesbar bekannt gibt: in einer Klartextdatei im Format "Feldname: Wert", eine Angabe je Zeile, Kommentare mit Rautezeichen. Die Datei liegt unter /.well-known/security.txt und wird über HTTPS ausgeliefert; Werkzeuge von Sicherheitsforschern und Behörden lesen sie automatisch. Die TR verlangt zusätzlich (Abschnitt 4.2.1) Klartext in ASCII oder UTF-8 mit dem MIME-Typ text/plain; charset=utf-8 und nach Abschnitt 4.2.11, dass Firewall und DDoS-Schutz den Abruf durch Prüfdienste nicht blockieren.

Die TR verlangt in Abschnitt 4.5 zusätzlich eine Meldeseite, von der Startseite verlinkt, ohne JavaScript und Login nutzbar. Die security.txt zeigt dorthin.

Welche Felder gehören hinein?

RFC 9116 kennt acht Felder, von denen zwei Pflicht sind. Die TR hebt vier weitere auf Pflicht, verlangt zusätzlich eine Signatur und ergänzt ein Feld aus dem CSAF-Standard, dem Format für maschinenlesbare Sicherheitshinweise. Die Tabelle zeigt beide Stufen.

Die Signatur

RFC 9116 empfiehlt in Abschnitt 2.3, die Datei mit OpenPGP zu signieren (Clearsign: die lesbare Datei mit angehängter Signatur). Die TR macht das in Abschnitt 4.2.10 zur Pflicht: nach RFC 9580, mit einem eigenen Schlüssel, höchstens fünf Jahre gültig. Die Signatur beweist, dass die Datei vom Hersteller stammt und nicht von einem Angreifer, der Meldungen umleiten will.

Welche Rollen und Fristen stehen hinter der Adresse?

Eine security.txt ist nur so gut wie das Postfach dahinter. Die TR beschreibt in Abschnitt 4.3 und 4.4, was den Betrieb ausmacht.

• Zwei Rollen. Ein PSIRT (Product Security Incident Response Team) für Schwachstellen in Produkten, ein CSIRT (Computer Security Incident Response Team) für die eigene Infrastruktur. Beide bekommen Funktionspostfächer psirt@ und csirt@ und je einen eigenen OpenPGP-Schlüssel. Außer bei Kleinstunternehmen sollen das nicht dieselben Personen sein. Meldungen werden mindestens auf Englisch bearbeitet.
• Webformular. Nach Abschnitt 4.3.3 muss ein Formular vorhanden sein, über das auch anonym gemeldet werden kann. Es ergänzt die E-Mail, es ersetzt sie nicht.
• Tägliche Prüfung. Die TR empfiehlt, Postfächer und Formular täglich mit einer automatischen Testnachricht zu prüfen.
• Reaktionsfristen. Nach Abschnitt 4.4.8 bekommt ein Meldender binnen 5 Werktagen eine Antwort, die nicht automatisch erzeugt ist. Binnen 10 Werktagen folgt eine Detailantwort: Bestätigung oder Ablehnung, Rückfragen oder eine Begründung der Verzögerung mit Zusage eines weiteren Updates in 10 Werktagen. Bei anonymen Meldungen entfällt das.
• Vier-Augen-Prinzip. Nach Abschnitt 4.4.7 darf kein Analyst eine Meldung allein schließen.
• Offenlegung. Nach Abschnitt 4.4.10 wird eine bestätigte Schwachstelle binnen 90 Tagen veröffentlicht, einmal um 90 Tage verlängerbar in Abstimmung mit dem nationalen CSIRT, in Deutschland CERT-Bund.

Diese Fristen stammen allein aus der TR; Verordnung und Kommissionsleitlinie nennen keine Reaktionszeiten für Meldeadressen. Davon zu trennen ist Artikel 14: Bei einer aktiv ausgenutzten Schwachstelle läuft ab Kenntnis die 24-Stunden-Frist, unabhängig von Werktagen (siehe Kenntnis und Fristbeginn).

Wie sieht eine vollständige Datei aus?

Das folgende Beispiel für einen fiktiven Hersteller erfüllt die Pflicht- und Soll-Felder der TR. Es fehlt nur die Signatur, die beim Signieren mit OpenPGP um die Datei gelegt wird.

# Our canonical URI
Canonical: https://www.beispiel-maschinen.de/.well-known/security.txt

# Our security addresses
Contact: mailto:psirt@beispiel-maschinen.de
Contact: mailto:csirt@beispiel-maschinen.de
Contact: https://www.beispiel-maschinen.de/security-contact

# Our OpenPGP keys
Encryption: https://www.beispiel-maschinen.de/.well-known/psirt-beispiel-maschinen.asc
Encryption: https://www.beispiel-maschinen.de/.well-known/csirt-beispiel-maschinen.asc

# Our preferred languages
Preferred-Languages: de, en

# Our security policy
Policy: https://www.beispiel-maschinen.de/security-policy

# Our security advisories
CSAF: https://www.beispiel-maschinen.de/.well-known/csaf/provider-metadata.json

# Hall of Fame
Acknowledgments: https://www.beispiel-maschinen.de/security-acknowledgments

Expires: 2027-10-01T00:00:00.000Z

Die Kommentare folgen der Vorgabe der TR, die PSIRT-Adresse steht vor der CSIRT-Adresse, jedes Encryption-Feld zeigt auf eine Schlüsseldatei, und Expires liegt weniger als ein Jahr in der Zukunft.

Wie prüfen Sie Ihre Datei?

1. Abruf prüfenDer Aufruf von https://ihre-domain.de/.well-known/security.txt muss Status 200 und den Inhaltstyp text/plain liefern, ohne Weiterleitung. Auf der Kommandozeile: curl -sI https://ihre-domain.de/.well-known/security.txt.
2. Felder und Datum lesenAlle Pflichtfelder der TR vorhanden, Contact in der richtigen Reihenfolge, Canonical identisch mit dem Fundort, Expires in der Zukunft und höchstens ein Jahr entfernt? Einen Prüftermin je Quartal in den Kalender eintragen.
3. Signatur prüfenMit gpg --verify gegen den veröffentlichten Schlüssel. Der Schlüssel muss unter der Encryption-Adresse abrufbar sein, der Fingerabdruck auf der Meldeseite stehen.
4. Prüfdienste nutzenDie TR nennt findsecuritycontacts.com und internet.nl als Crawler, die die Datei erreichen können müssen. Beide zeigen formale Fehler an.
5. Postfächer und Formular testenTestnachrichten an psirt@, csirt@ und über das Formular schicken; kommen sie bei einer Person an, die sie liest? Die TR empfiehlt das täglich und automatisiert.

Typische Fehler

Eine Auswertung der eine Million meistbesuchten Domains durch uriports vom 24. Januar 2025 zeigt, wie selten die Datei korrekt ist: Nur 1,25 Prozent der Domains hatten eine security.txt, davon entsprachen nur 44 Prozent dem RFC. Bei 45 Prozent fehlte Expires, bei 13 Prozent war es abgelaufen, bei 20 Prozent lag es zu weit in der Zukunft. Bei 26 Prozent stimmte Canonical nicht mit dem Fundort überein. Nur 11 Prozent waren signiert, die Hälfte davon ungültig.

• Falscher Ort. Die Datei liegt nur unter /security.txt, nicht unter /.well-known/.
• Nur http oder Weiterleitung. Die Datei ist nur unverschlüsselt erreichbar oder leitet auf eine HTML-Seite weiter. Dann lesen Werkzeuge nichts.
• Abgelaufenes Expires. Einmal angelegt und vergessen. Ab dem Ablaufdatum gilt der Inhalt als unzuverlässig. Dazu Kleinbuchstaben "t" und "z" im Datum, die TR verlangt Großbuchstaben.
• Canonical zeigt woandershin. Etwa auf die Domain ohne www, während die Datei unter www liegt.
• Encryption zeigt auf eine Seite statt auf den Schlüssel. Die TR verlangt den direkten Download der .asc-Datei.
• Postfach existiert, wird aber nicht gelesen. Der folgenreichste Fehler: Wer eine Meldung drei Wochen liegen lässt, hat ein Erklärungsproblem.

Wie machen es große Hersteller?

Drei öffentlich abrufbare Dateien, Stand 7. Oktober 2026, zeigen die Bandbreite. Siemens trennt die Rollen wie die TR (productcert@ für Produkte, cert@ für die Infrastruktur), mit zwei Schlüsseln, Canonical, Policy, CSAF-Eintrag und Hall of Thanks, aber ohne sichtbare Signatur. Bosch liefert die Datei signiert aus, mit Kommentaren im Wortlaut der TR, Contact als Formularadresse, Hall of Fame, Policy und Hiring. SAP beschränkt sich auf Contact und Expires: RFC-konform, aber ohne Canonical, Policy, Sprache und Signatur, das Ablaufdatum mehr als ein Jahr entfernt. Für einen Mittelständler ist die Bosch-Datei das brauchbarste Vorbild.

Was das praktisch heißt

Die Datei selbst ist in einer Stunde geschrieben. Die Arbeit steckt im Betrieb: zwei Postfächer, die jemand liest, ein Formular, das funktioniert, ein Ablaufdatum, das jemand verlängert, und eine Antwort binnen 5 Werktagen, die eine Person schreibt. Für einen Hersteller mit 80 Beschäftigten ohne Sicherheitsabteilung heißt das: Rollen benennen, Vertretung regeln, Prüftermine in den Kalender. CRA Response Center richtet security.txt, Postfach und Meldeformular ein, prüft jede eingehende Meldung und weckt die Rufkette des Herstellers, wenn eine Meldung nach aktiver Ausnutzung aussieht. Bewertung und Meldung bleiben beim Hersteller.

Häufige Fragen

Weiterlesen

• Richtlinie zur koordinierten OffenlegungDas Dokument, auf das das Feld Policy zeigt: Was hineingehört und was Meldende erwarten.
• PSIRT im MittelstandWer die Postfächer liest, wer bewertet, wer antwortet, und wie das mit wenigen Leuten geht.
• Die ersten 24 StundenWas passiert, wenn über die Meldeadresse eine aktiv ausgenutzte Schwachstelle hereinkommt.

Quellen

• Verordnung (EU) 2024/2847, Artikel 13 Absatz 8 und 17, Anhang I Teil II, Amt für Veröffentlichungen der EU, 20. November 2024.
• BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, Bundesamt für Sicherheit in der Informationstechnik, 20. August 2025.
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, IETF, April 2022.
• OASIS CSAF 2.0, Requirement 8: security.txt, OASIS, 2022.
• Leitlinien der Kommission C(2026) 5252, Annex, Randnummer 210, Europäische Kommission, 27. Juli 2026.
• security.txt in 2025, Auswertung der Top-1-Million-Domains, uriports, 24. Januar 2025.
• security.txt von Siemens, Bosch und SAP, abgerufen am 7. Oktober 2026.