security.txt nach RFC 9116 und Coordinated Vulnerability Disclosure – Pflichtangaben, Fundort und rechtlicher Rahmen

Kurzantwort

Eine security.txt ist eine reine Textdatei, die den Sicherheitskontakt einer Organisation maschinenlesbar hinterlegt. Nach RFC 9116 muss sie bei webbasierten Diensten unter dem Pfad /.well-known/security.txt liegen (RFC 9116, Abschnitt 3), und genau zwei Felder sind zwingend: Contact (RFC 9116, Abschnitt 2.5.3) und Expires (RFC 9116, Abschnitt 2.5.5). Für gewöhnliche Webseitenbetreiber in Deutschland besteht keine gesetzliche Pflicht, eine security.txt bereitzustellen – BSI und Allianz für Cyber-Sicherheit empfehlen sie; nach BSI-Messungen im Cyberdome-Projekt stellen bislang nur 1,8 Prozent der Webseitenbetreiber in Deutschland eine security.txt bereit (BSI-Pressemitteilung vom 06.08.2026). Gesetzlich verankert ist dagegen der Rahmen der koordinierten Schwachstellenoffenlegung: Nach § 5 Absatz 1 Satz 2 BSIG ist das Bundesamt für Sicherheit in der Informationstechnik „der nationale Koordinator für die Zwecke einer koordinierten Offenlegung von Schwachstellen nach Artikel 12 Absatz 1 der NIS-2-Richtlinie". Für Hersteller von Produkten mit digitalen Elementen verlangt die Technische Richtlinie BSI TR-03183-3 eine security.txt nach RFC 9116 („MUST", Abschnitt 4.2); die Richtlinie selbst begründet allerdings keine Rechtspflicht – verbindlich sind die Anforderungen des Cyber Resilience Act.

Kernfakten

Geltungsbereich

Zu unterscheiden sind drei Ebenen:

1. Webseitenbetreiber allgemein (Unternehmen, Vereine, Behörden mit eigener Website): Für sie ist die security.txt eine freiwillige Maßnahme. BSI und Allianz für Cyber-Sicherheit rufen zur Umsetzung auf, weil Hinweise auf Sicherheitslücken ohne auffindbaren Kontakt „häufig verzögert, an der falschen Stelle oder gar nicht" eingehen (BSI-Pressemitteilung vom 06.08.2026).
2. Hersteller von Produkten mit digitalen Elementen im Sinne des Cyber Resilience Act: Für sie stellt die BSI TR-03183-3 verbindliche technische Anforderungen an security.txt und CVD-Policy auf (Abschnitte 4.2 bis 4.5). Die Technische Richtlinie ist keine harmonisierte Norm und begründet für sich genommen keine Rechtspflicht; die rechtlichen Meldepflichten folgen aus dem CRA – die dreistufigen Fristen des Art. 14 CRA (24 Stunden / 72 Stunden / 14 Tage bzw. ein Monat) gelten ab dem 11. September 2026 (siehe eigene Themenseite zu CRA Art. 14).
3. Das BSI selbst als nationale Koordinierungsstelle: § 5 BSIG regelt Entgegennahme, Auswertung und Weitergabe von Schwachstellenmeldungen sowie den Schutz der meldenden Person.

Die beiden Pflichtfelder im Detail

Contact (RFC 9116, Abschnitt 2.5.3) benennt den Weg, über den Sicherheitsforschende eine Schwachstelle melden sollen. Der Wert muss der URI-Syntax nach RFC 3986 folgen – E-Mail-Adressen also als mailto:, Telefonnummern als tel:. Verweist das Feld auf eine Webseite, muss die URI mit https:// beginnen. Mehrere Kontaktwege sind zulässig und sollen in absteigender Präferenz angegeben werden.

Expires (RFC 9116, Abschnitt 2.5.5) gibt Datum und Uhrzeit an, ab denen die Angaben als veraltet gelten und nicht mehr verwendet werden sollen. Das Format folgt RFC 3339 (ISO-8601-Profil). Der Wert soll weniger als ein Jahr in der Zukunft liegen. Das Feld darf genau einmal vorkommen.

Rechtsrahmen in Deutschland: § 5 BSIG

Das BSI-Gesetz vom 2. Dezember 2025 (BGBl. 2025 I Nr. 301, in Kraft seit 06.12.2025) regelt die koordinierte Schwachstellenoffenlegung in § 5:

• Absatz 1: Das Bundesamt nimmt als zentrale Stelle Meldungen Dritter über Sicherheitsrisiken entgegen und wertet sie aus. Satz 2 bestimmt ausdrücklich: „Das Bundesamt ist dabei der nationale Koordinator für die Zwecke einer koordinierten Offenlegung von Schwachstellen nach Artikel 12 Absatz 1 der NIS-2-Richtlinie."
• Absatz 2: Entgegengenommen werden Informationen zu Schwachstellen, Schadprogrammen, erfolgten oder versuchten Angriffen, Sicherheitsvorfällen, Cyberbedrohungen und Beinahevorfällen. Meldungen können anonym erfolgen. Erfolgt die Meldung nicht anonym, kann die meldende Person verlangen, dass ihre personenbezogenen Daten nur anonymisiert weitergegeben werden.
• Absatz 3 Satz 1: Das Bundesamt gibt Informationen zu gemeldeten Schwachstellen unverzüglich an den verantwortlichen Hersteller oder Produktverantwortlichen weiter, sofern die Schwachstelle nicht bereits öffentlich bekannt ist.
• Absatz 4: Die Weitergabe unterbleibt, soweit Betriebs- und Geschäftsgeheimnisse Dritter betroffen sind und die Maßnahme nicht ohne deren Bekanntgabe möglich ist, oder soweit Vereinbarungen des Bundesamtes mit Dritten entgegenstehen.
• Absatz 6: Das Bundesamt veröffentlicht am 6. Dezember 2026 eine Verfahrensbeschreibung zur Durchführung der Absätze 1 bis 3.

Reagiert ein Hersteller nicht, kann das BSI nach § 13 BSIG vor einem Produkt warnen. Die zugrunde liegende CVD-Leitlinie des BSI (Version 1.0 vom 01.12.2022) verweist an dieser Stelle noch auf § 7 BSIG in der bis 05.12.2025 geltenden Fassung; die Warnbefugnis findet sich seit dem 06.12.2025 in § 13 BSIG.

Der CVD-Prozess beim BSI

Nach der CVD-Leitlinie des BSI (Version 1.0 vom 01.12.2022) läuft der Prozess in vier Schritten: Schwachstellenmeldung, Schwachstellenbewertung, Kontaktaufnahme und Koordination, koordinierte Offenlegung. Zeitliche Eckpunkte:

• Wird das BSI um Kontaktaufnahme mit dem Hersteller gebeten, erwartet es eine Eingangsbestätigung des Herstellers innerhalb von drei Werktagen (telefonisch oder per E-Mail). Bleibt sie aus, unternimmt das BSI einen zweiten Kontaktversuch; reagiert der Hersteller erneut nicht innerhalb von spätestens drei Werktagen, stimmt das BSI das weitere Vorgehen mit den Sicherheitsforschenden ab.
• Zur Schließung der Schwachstelle räumt das BSI eine Frist ein, die sich „innerhalb der international üblichen 45 bis 90 Tage" bewegt und mit den Sicherheitsforschenden abzustimmen ist. Abhängig von Kritikalität und Komplexität – bei Hardware-Schwachstellen ausdrücklich auch deutlich – kann davon abgewichen werden; Abweichungen sind zu begründen.
• Vom Hersteller wird erwartet, valide Schwachstellen einschließlich CVE-Nummer selbst zu veröffentlichen, spätestens wenn sie behoben sind. Das BSI empfiehlt dafür den maschinenverarbeitbaren CSAF-Standard.
• Als Anerkennung bietet das BSI eine Nennung (Name oder Alias) auf seiner Danksagungsseite an; eine finanzielle Kompensation zahlt das BSI im Rahmen eines CVD-Prozesses derzeit nicht.

Zusatzanforderungen der BSI TR-03183-3 für Hersteller

Die Technische Richtlinie BSI TR-03183-3 „Vulnerability Reports and Notifications", Version 1.0.0, konkretisiert für Hersteller unter anderem:

Beispiel

Eine minimale, RFC-9116-konforme Datei unter https://example.com/.well-known/security.txt besteht aus den beiden Pflichtfeldern:

Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59Z

Ergänzt um die praxisüblichen optionalen Felder:

# Our security addresses
Contact: mailto:security@example.com
Contact: https://example.com/sicherheit
# Our security policy
Policy: https://example.com/cvd-policy
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Expires: 2027-06-30T23:59:59Z

Häufige Fehler / Missverständnisse

• „Eine security.txt ist gesetzlich vorgeschrieben." Für gewöhnliche Webseitenbetreiber in Deutschland gibt es keine solche Pflicht. BSI und Allianz für Cyber-Sicherheit sprechen einen Aufruf aus (BSI-PM vom 06.08.2026). Eine „MUST"-Anforderung besteht nach BSI TR-03183-3 nur für Hersteller, die diese Technische Richtlinie anwenden – und die Richtlinie selbst ist keine Rechtsnorm.
• „Die Datei kann im Wurzelverzeichnis liegen." RFC 9116 Abschnitt 3 verlangt den Pfad /.well-known/. Eine Datei im Wurzelverzeichnis ist nur aus Kompatibilitätsgründen geduldet; liegt sie an beiden Orten, ist die Datei unter /.well-known/ maßgeblich.
• „Expires ist optional." Nein – Expires ist neben Contact das zweite zwingende Feld und darf nur genau einmal vorkommen (RFC 9116, Abschn. 2.5.5). Eine abgelaufene security.txt gilt als veraltet und soll nicht mehr verwendet werden.
• „Eine security.txt erlaubt Sicherheitstests." RFC 9116 stellt in Abschnitt 5.5 ausdrücklich klar, dass aus der Datei keine stillschweigende Erlaubnis für Sicherheitstests folgt („No Implied Permission for Testing").
• „Wer eine security.txt hat, braucht keine CVD-Policy." Beides erfüllt unterschiedliche Zwecke: Die security.txt macht den Kontakt auffindbar, die CVD-Policy beschreibt die Bearbeitung der Meldung. Die TR-03183-3 verlangt in Abschnitt 4.2.7 gerade die Verlinkung der CVD-Policy aus der security.txt heraus.
• „Die Meldung an das BSI ersetzt die CRA-Meldung." Nein. § 5 BSIG regelt die freiwillige Meldung Dritter an das BSI; die Meldepflichten des Herstellers nach Art. 14 CRA ab 11.09.2026 bestehen davon unabhängig. Ebenso unberührt bleibt die Meldepflicht nach Art. 33 DSGVO, wenn eine Schwachstelle zu einer Verletzung des Schutzes personenbezogener Daten geführt hat.
• „Anonyme Meldungen sind beim BSI nicht möglich." Doch – § 5 Abs. 2 Satz 3 BSIG stellt das ausdrücklich klar; zusätzlich kann eine nicht anonyme meldende Person die anonymisierte Weitergabe ihrer Daten verlangen (§ 5 Abs. 2 Satz 4 BSIG).

Quellen

• § 5 BSIG (Allgemeine Meldestelle für die Sicherheit in der Informationstechnik), amtlicher Volltext: https://www.gesetze-im-internet.de/bsig_2025/__5.html A
• § 3 BSIG (Aufgaben des Bundesamtes), amtlicher Volltext: https://www.gesetze-im-internet.de/bsig_2025/__3.html A
• § 13 BSIG (Warnungen), amtlicher Volltext: https://www.gesetze-im-internet.de/bsig_2025/__13.html A
• BSI-Gesetz vom 2. Dezember 2025 (BGBl. 2025 I Nr. 301), Gesamtfassung als PDF inkl. Ausfertigungsdatum und Inkrafttreten: https://www.gesetze-im-internet.de/bsig_2025/BSIG.pdf A
• RFC 9116, „A File Format to Aid in Security Vulnerability Disclosure" (IETF, April 2022) – Abschnitte 2.5.3, 2.5.5, 2.5.7, 3 und 5.5: https://www.rfc-editor.org/rfc/rfc9116.html D
• BSI, Pressemitteilung „Nur 1,8 Prozent der Webseitenbetreiber nutzen security.txt – BSI und ACS raten zur Umsetzung" vom 06.08.2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260806_security_txt.html D
• BSI, „Leitlinie des BSI zum Coordinated Vulnerability Disclosure (CVD)-Prozess", Version 1.0 vom 01.12.2022 (PDF): https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/CVD/CVD-Leitlinie.pdf?__blob=publicationFile&v=4 D
• BSI, CVD-Richtlinie und Meldewege für Sicherheitsforschende: https://www.bsi.bund.de/dok/CVD-Richtlinie D
• BSI TR-03183-3 „Cyber Resilience Requirements for Manufacturers and Products – Part 3: Vulnerability Reports and Notifications", Version 1.0.0 (PDF): https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-3_v1_0_0.pdf?__blob=publicationFile&v=4 D
• BSI/Allianz für Cyber-Sicherheit, Empfehlung BSI-CS 149 „Sicherheitskontakte mit Hilfe einer security.txt nach RFC 9116 angeben": https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/BSI-CS_149.html D
• BSI, FAQ für Hersteller zum Umgang mit Schwachstellenmeldungen: https://www.bsi.bund.de/DE/IT-Sicherheitsvorfall/IT-Schwachstellen/FAQ_Hersteller/FAQ_Hersteller_node.html D

Änderungsverlauf

• 2026-08-20: Erstveröffentlichung. Wortlaut von § 5 BSIG (Absätze 1 bis 6) sowie Ausfertigungsdatum, Fundstelle (BGBl. 2025 I Nr. 301) und Inkrafttreten (06.12.2025) gegen den amtlichen Volltext auf gesetze-im-internet.de geprüft. Pflichtfelder, Ablageort und Formatvorgaben wörtlich gegen RFC 9116 (Abschn. 2.5.3, 2.5.5, 3, 5.5) verifiziert. Verbreitungszahl 1,8 Prozent und Mindestumsetzung aus der BSI-Pressemitteilung vom 06.08.2026 übernommen; Prozessfristen (drei Werktage, 45–90 Tage) aus der BSI-CVD-Leitlinie v1.0; Hersteller-Anforderungen aus BSI TR-03183-3 v1.0.0. Hinweis: EUR-Lex war in diesem Lauf nicht erreichbar (HTTP 202 mit leerem Body auf ELI-, CELEX- und PDF-Pfad); CRA-Fundstellen sind deshalb nicht direkt verlinkt, sondern über die bestehende Themenseite zu CRA Art. 14 nachgewiesen. | change_type=initial_publication field="topic_lifecycle" new="published" reviewed_by="Andreas Warkentin"

Stand

• Stand: 2026-08-20
• Gültig ab: 2025-12-06 (Inkrafttreten des BSIG vom 02.12.2025)
• Status: aktuell
• Quellenautorität: A (gesetze-im-internet.de, BSIG), ergänzt um B (RFC Editor, BSI)
• Lizenz: CC BY 4.0