Das Wichtigste in Kürze
- Das BSI hat gemessen: 1,8 Prozent der Webseitenbetreiber in Deutschland stellen eine security.txt bereit. Die Zahl stammt aus dem Cyberdome-Projekt, veröffentlicht am 6. August 2026.
- Die Datei liegt unter
/.well-known/security.txtund braucht laut RFC 9116 genau zwei Pflichtfelder:ContactundExpires. Alles andere ist optional. - Der Zweck ist eng: Wer eine Schwachstelle an deiner Website findet, sieht sofort, wohin die Meldung geht. Ohne diesen Eintrag landet der Hinweis im allgemeinen Kontaktformular oder gar nicht.
- Der Standard warnt vor der eigenen Alterung. RFC 9116 empfiehlt ein Ablaufdatum unter einem Jahr. Eine abgelaufene Datei ist kein Meldeweg, sondern ein Briefkasten ohne Leerung.
- Zur Einordnung, weil das gerade durcheinandergeht: Die CRA-Meldepflicht ab 11. September 2026 trifft Hersteller vernetzter Produkte. Wer ausschließlich eine Firmenwebsite betreibt, richtet die Datei aus praktischen Gründen ein, nicht wegen dieser Frist.
Angenommen, jemand entdeckt eine Lücke in eurem Bewerberportal. Kein Angreifer, sondern jemand aus der Sicherheitsforschung, der sie melden will. Diese Person sucht dann nach einer Adresse. Sie findet ein Kontaktformular für Anfragen, eine Telefonnummer der Zentrale und ein Impressum mit der Geschäftsführung.
Was sie nicht findet, ist eine Stelle, die mit dem Hinweis etwas anfangen kann.
Genau dafür gibt es seit April 2022 einen Standard. Er heißt RFC 9116, das Ergebnis ist eine Textdatei, und in Deutschland nutzen ihn 1,8 Prozent der Webseitenbetreiber.
Was das BSI gemessen hat
Das Bundesamt für Sicherheit in der Informationstechnik hat die Zahl am 6. August 2026 veröffentlicht. Sie stammt aus Messungen im Cyberdome-Projekt, mit dem das BSI Webseiten scannt und erkannte Mängel an die Betreiber weitergibt.
Das BSI beschreibt in derselben Mitteilung, warum die Datei mehr ist als Formalie. Wörtlich:
"Fehlt dieser Kontakt, gehen Hinweise auf Sicherheitslücken häufig verzögert, an der falschen Stelle oder gar nicht ein."
Das BSI und die Allianz für Cyber-Sicherheit rufen deshalb dazu auf, eine security.txt einzurichten. Der Aufwand steht in keinem Verhältnis zum Nutzen: eine Textdatei, zwei Pflichtangaben, ein fester Pfad.
Eine Einschränkung gehört dazu, und wir schreiben sie hin, weil sie sonst untergeht. Das BSI nennt keine Aufschlüsselung, wie viele dieser 1,8 Prozent formal gültig sind. Die Zahl beschreibt Vorhandensein, nicht Qualität. Wer aus ihr eine Aussage über den Zustand der deutschen Websites ableitet, geht einen Schritt zu weit.
Was in der Datei stehen muss, und was nicht
RFC 9116 ist ungewöhnlich schlank. Zwei Felder sind Pflicht.
Contact. Der Weg, über den eine Meldung eingeht. Der Standard sagt dazu: "This field MUST always be present in a security.txt file." Erlaubt sind eine Mail-Adresse als mailto:, eine Telefonnummer als tel: oder eine Webseite mit https://. Mehrere Einträge sind zulässig. Laut Standard ist der erste Eintrag der bevorzugte Kontaktweg.
Expires. Datum und Uhrzeit, ab wann die Angaben als veraltet gelten. Auch dazu ist der Standard eindeutig: "This field MUST always be present and MUST NOT appear more than once." Und weiter: "It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness."
Alles andere ist freiwillig. Policy verlinkt eure Regeln für Meldungen, Preferred-Languages nennt die Sprachen, Encryption verweist auf einen Schlüssel für verschlüsselte Zuschriften, Acknowledgments auf eine Danksagungsseite.
Eine vollständige, standardkonforme Datei sieht so aus:
`` # Meldungen zu Sicherheitsluecken Contact: security(at)beispiel-gmbh(dot)de Contact: tel:+49-751-0000000 Expires: 2027-06-30T12:00:00z Preferred-Languages: de, en Policy: beispiel-gmbh.de/sicherheit ``
Das z am Ende der Zeitangabe steht für UTC. Fünf Zeilen, zwei davon sind Pflicht.
Wie kommt die Datei in TYPO3, WordPress und beim Hoster an die richtige Stelle?
Der Standard macht auch beim Ablegen klare Vorgaben. Die Datei gehört unter /.well-known/security.txt. Sie wird über https ausgeliefert. Und sie kommt mit dem Content-Type text/plain und charset=utf-8 zurück, nicht als HTML-Seite.
TYPO3. Im Composer-Setup legst du die Datei unter public/.well-known/security.txt ab. Der Webserver liefert sie direkt aus, TYPO3 startet dafür gar nicht erst. Bei mehreren Sites in einer Instanz führt der Weg über die statischen Routen in der Site-Konfiguration, mit denen sich schon robots.txt pro Site steuern lässt. Das ist derselbe Mechanismus, nur ein anderer Pfad (TYPO3-Dokumentation zu Static Routes).
WordPress. Lege den Ordner .well-known im Web-Root an, also dort, wo auch wp-config.php liegt, und darin die Datei. WordPress leitet nur Anfragen um, für die keine echte Datei existiert. Eine vorhandene Datei geht also am CMS vorbei.
Beim Hoster nachsehen. Manche Panels und Sicherheits-Plugins sperren /.well-known/ bis auf den Pfad, den Let's Encrypt für Zertifikate braucht. Das fällt erst auf, wenn du die URL im Browser aufrufst und einen 403 oder eine Weiterleitung auf die Startseite bekommst.
Prüf es so:
- Ruf
deine-domain.de/.well-known/security.txtim Browser auf. Der Inhalt muss als reiner Text erscheinen, nicht im Seitenlayout. - Sieh dir in den Entwicklerwerkzeugen unter Netzwerk den Response-Header an. Dort muss
Content-Type: text/plain; charset=utf-8stehen. Fehlt der Zusatz mit dem Zeichensatz, ist das ein Fall für die Server-Konfiguration. - Trag das Datum aus
Expiresin den Kalender ein, mit Erinnerung vier Wochen vorher.
Vier Stellen, an denen es in der Praxis klemmt
| Stolperstelle | Was passiert | Was hilft |
|---|---|---|
| Das Ablaufdatum läuft ab | Nach dem Expires-Datum gilt die Datei als veraltet. Sie steht noch da und leistet nichts mehr. | Datum unter einem Jahr setzen, Erinnerung vier Wochen vorher |
| Die Adresse hängt an einer Person | m.mustermann(at)... funktioniert nur, solange diese Person da ist. | Rollenpostfach wie security@, das Urlaub und Kündigung übersteht |
| Subdomains fehlen | Die Datei gilt nur für den Hostnamen, über den sie abgerufen wurde. | Eine Datei je Hostname, der Inhalt darf gleich sein |
| Die Datei kommt als HTML zurück | Werkzeuge lesen Text, kein Seitenlayout. | Reine Textdatei ausliefern, die Sicherheitsseite ins Feld Policy |
Der Standard verlangt Expires genau deshalb, weil eine Kontaktangabe altert: Menschen wechseln die Firma, Verteiler werden abgeschaltet.
Den Punkt mit den Subdomains übersehen viele. RFC 9116 sagt dazu: "A security.txt file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains." Wer also firma.de, shop.firma.de und portal.firma.de betreibt, braucht drei Dateien.
Der Teil zum Cyber Resilience Act, den viele falsch lesen
Das BSI verweist in seiner Mitteilung auf den Cyber Resilience Act. Daraus wird in der Berichterstattung schnell eine Frist für alle. Das stimmt so nicht, und die Entwarnung ist für die meisten Leser die wichtigere Nachricht.
Der Zeitplan des BSI zum Cyber Resilience Act nennt für den 11. September 2026 wörtlich: "Die Hersteller von vernetzten Produkten unterliegen der Meldepflicht für Schwachstellen und Vorfälle." Betroffen sind Hersteller von Produkten mit digitalen Elementen, die diese auf dem EU-Markt bereitstellen. Gemeint sind vernetzte Maschinen, Steuerungen, Geräte und Softwareprodukte.
Die Fristen dafür stehen im Verordnungstext selbst, in Artikel 14 des CRA. Das BSI fasst sie in seinem FAQ zusammen: Frühwarnung innerhalb von 24 Stunden, weitere Angaben innerhalb von 72 Stunden, Abschlussbericht spätestens 14 Tage nach einem Sicherheitsupdate oder Workaround. Ab 11. Dezember 2027 gelten dann alle Anforderungen des CRA.
Ein Maschinenbauer aus dem Bodenseeraum, der vernetzte Anlagen ausliefert, hat hier also eine Aufgabe. Ein Steuerberatungsbüro mit einer Firmenwebsite hat sie nicht.
Und trotzdem lohnt die Datei auch im zweiten Fall. Der Grund liegt im Alltag: Der Hinweis auf eine Lücke kommt an einer Stelle an, die ihn versteht.
Für die erste Gruppe kommt ein Punkt dazu. Wer ab September meldepflichtig ist, braucht ohnehin einen funktionierenden Eingang für Schwachstellen-Meldungen. Die security.txt ist der billigste Baustein davon.
Was das für deine Website heißt
Ohne festen Eingang landet ein Hinweis im allgemeinen Kontaktformular, bei jemandem, der ihn nicht einordnen kann, oder gar nicht. Mit der Datei weiß die meldende Person, wohin sie schreiben soll, und ihr wisst, wer die Meldung liest.
Drei Fälle, sortiert nach Aufwand.
Ihr habt keine security.txt. Das ist der Regelfall. Lege ein Rollenpostfach an, schreibe zwei Zeilen, lade die Datei hoch, setze eine Kalender-Erinnerung. Rechne mit einer halben Stunde, den Abstimmungsweg für das Postfach eingerechnet.
Ihr habt eine, aber sie ist alt. Prüf zuerst das Expires-Datum, dann ob die Adresse dahinter noch jemand liest. Schick testweise eine Mail dorthin und sieh nach, ob eine Antwort kommt. Ein Postfach ohne Zuständigen ist schlechter als keine Angabe, weil es Verlässlichkeit vortäuscht.
Ihr betreibt mehrere Domains und Subdomains. Erstelle eine Liste aller Hostnamen, die von außen erreichbar sind. Shop, Portal, Bewerbungsseite, Landingpages aus alten Kampagnen. Jeder Hostname braucht seine eigene Datei.
Nächster Schritt
Die Datei selbst ist in einer halben Stunde erledigt. Die Frage dahinter ist größer: Wo landet eigentlich ein Hinweis auf ein Sicherheitsproblem in eurem Haus, und wer sieht ihn?
Wenn du das für deine Domains einmal sauber durchgehen willst, schauen wir es uns gemeinsam an. Für TYPO3-Installationen gehört das zur TYPO3-Betreuung, für WordPress zur Wartung und Updates der WordPress-Installation. Wir prüfen, welche Hostnamen erreichbar sind, ob der Meldeweg technisch korrekt ausgeliefert wird und wer intern zuständig ist.
Das Erstgespräch dauert 15 Minuten und kostet nichts: Meldeweg und Sicherheits-Setup prüfen lassen.
Häufige Fragen
Brauchen wir eine security.txt, wenn wir gar keine Software verkaufen?
Pflicht ist sie nicht. Sinnvoll bleibt sie trotzdem, weil jede öffentlich erreichbare Website Angriffsfläche hat. Der Aufwand liegt bei einer Textdatei mit zwei Pflichtfeldern.
Welche Angaben sind wirklich vorgeschrieben?
Genau zwei. Contact mit dem Meldeweg und Expires mit dem Ablaufdatum. RFC 9116 verlangt beide Felder ausdrücklich. Alles Weitere ist optional.
Wie lange darf das Ablaufdatum in der Zukunft liegen?
Der Standard empfiehlt weniger als ein Jahr, um Veraltung zu vermeiden. Ein festes Maximum nennt er nicht. In der Praxis funktioniert ein jährlicher Termin, der zusammen mit anderen Routinen läuft.
Reicht eine Datei für alle unsere Subdomains?
Nein. RFC 9116 begrenzt den Geltungsbereich auf genau die Domain, über die die Datei abgerufen wurde. Subdomains und übergeordnete Domains sind nicht mit abgedeckt. Der Inhalt darf aber überall gleich sein.
Gilt die CRA-Meldepflicht ab September 2026 auch für uns?
Das hängt daran, ob ihr ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt. Der BSI-Zeitplan nennt für den 11. September 2026 die Hersteller vernetzter Produkte. Wer nur eine eigene Firmenwebsite betreibt, fällt nicht darunter. Das ist eine Einordnung, keine Rechtsberatung: Im Zweifel prüft das eure Rechtsabteilung am Verordnungstext.
Ziehen wir mit der Datei nicht erst Angreifer an?
Wer eure Website angreifen will, braucht keine Kontaktdatei dafür. Die security.txt richtet sich an Leute, die einen Fund melden wollen, und macht diesen Weg kurz. --- ## Quellen - BSI, Pressemitteilung: Nur 1,8 Prozent der Webseitenbetreiber nutzen security.txt, 06.08.2026: www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260806_security_txt.html - BSI und Allianz für Cyber-Sicherheit, Flyer zur security.txt nach RFC 9116 (PDF): www.bsi.bund.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/Flyer_security_txt.pdf - IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, April 2022: www.rfc-editor.org/info/rfc9116/ - BSI, Cyber Resilience Act, Zeitplan und FAQ zu den Meldefristen, abgerufen am 18.08.2026: www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/cyber_resilience_act_node.html - Europäische Kommission, Cyber Resilience Act, Berichtspflichten nach Artikel 14: digital-strategy.ec.europa.eu/de/policies/cra-reporting - Verordnung (EU) 2024/2847 (Cyber Resilience Act), Volltext auf EUR-Lex: eur-lex.europa.eu/eli/reg/2024/2847/oj - TYPO3 Documentation, Static routes im Site Handling, Version 13.4: docs.typo3.org/m/typo3/reference-coreapi/13.4/en-us/ApiOverview/SiteHandling/StaticRoutes.html ---
Quellen
- BSI, Pressemitteilung: Nur 1,8 Prozent der Webseitenbetreiber nutzen security.txt, 06.08.2026. bsi.bund.de
- BSI und Allianz für Cyber-Sicherheit, Flyer zur security.txt nach RFC 9116. bsi.bund.de
- IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, April 2022. rfc-editor.org
- BSI, Themenseite und FAQ zum Cyber Resilience Act. bsi.bund.de
- Europäische Kommission, CRA-Berichtspflichten nach Artikel 14. digital-strategy.ec.europa.eu
- Verordnung 2024/2847, EUR-Lex. eur-lex.europa.eu
- TYPO3 Documentation, Static routes, Version 13.4. docs.typo3.org