Kernpunkte & Schnellleser-Modus
- Standardisierter Kontaktweg: Die security.txt (RFC 9116) ermöglicht Sicherheitsforschern das schnelle und strukturierte Melden von Schwachstellen.
- Rechtliche Relevanz: Indirekt durch Art. 32 DSGVO (TOMs) gefordert und künftig durch den EU Cyber Resilience Act verpflichtend für digitale Produkte.
- Geringer Aufwand, hoher Nutzen: Mit zwei Pflichtangaben (Contact & Expires) lässt sich ein klares Signal für digitale Verantwortung setzen.
Zusammenfassung Wenn Sicherheitsforscher eine Schwachstelle auf einer Website entdecken, fehlt oft die richtige Kontaktadresse. Der Standard RFC 9116 löst dieses Problem mit der
security.txt. Erfahren Sie, warum die unscheinbare Textdatei für Website-Betreiber, Datenschutz und den Cyber Resilience Act unverzichtbar ist und wie das BSI die Umsetzung empfiehlt.
Ein Einbrecher entdeckt eine offene Terrassentür. Er will es dem Eigentümer sagen. Doch am Haus hängt kein Klingelschild, kein Name, keine Nummer. Also lässt er es bleiben – oder postet den Fund im Internet.
Genau das passiert täglich mit Webseiten. Sicherheitsforscher finden eine Schwachstelle. Sie wollen sie melden. Sie finden aber kein Kontaktfeld, keinen Ansprechpartner, keinen Weg. Die Meldung versandet in einem allgemeinen Postfach – oder sie versandet gar nicht erst.
Für dieses Problem gibt es seit April 2022 einen Standard: die security.txt, festgelegt in RFC 9116. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt sie jeder Organisation mit eigener Website.
Was die Datei leistet
Die security.txt ist keine Software und kein Sicherheitssystem. Sie ist eine einfache Textdatei, abgelegt unter /.well-known/security.txt auf dem eigenen Server. Sie beantwortet eine einzige Frage, maschinen- wie menschenlesbar: Wen erreiche ich, wenn ich hier eine Schwachstelle finde?
Zwei Angaben sind laut RFC 9116 Pflicht:
- Contact – eine E-Mail-Adresse, eine URL oder eine Telefonnummer für sicherheitsrelevante Meldungen.
- Expires – ein Ablaufdatum, das zeigt: Diese Angabe ist noch aktuell.
Alles Weitere ist Kür, aber sinnvoll: ein Verweis auf den öffentlichen PGP-Schlüssel für verschlüsselte Meldungen, eine Seite mit der eigenen Offenlegungsrichtlinie (Coordinated Vulnerability Disclosure) oder eine kanonische URI, die den Fundort der Datei selbst bestätigt.
Warum das mehr ist als eine Fleißaufgabe
Drei Gründe sprechen dafür, die security.txt ernst zu nehmen – nicht nur technisch, sondern auch aus Sicht des Datenschutzes und der Unternehmensführung:
- 1. Die Zahlen sind eindeutig: Nur ein Bruchteil der deutschen Webseiten hält heute einen standardisierten Sicherheitskontakt vor. Wer eine security.txt einrichtet, gehört noch immer zu einer kleinen Gruppe – und genau diese Sichtbarkeit ist der Punkt.
- 2. Die DSGVO verlangt es indirekt bereits: Artikel 32 DSGVO fordert angemessene technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten – dazu gehört auch, dass Meldungen über Sicherheitslücken die Organisation überhaupt erreichen können. Eine security.txt ist kein explizites DSGVO-Pflichtfeld, aber ein naheliegender Baustein, um dieser Pflicht nachzukommen.
- 3. Der Cyber Resilience Act macht ernst: Für Hersteller von Produkten mit digitalen Elementen wird eine Kontaktmöglichkeit für Schwachstellenmeldungen EU-weit gesetzlich verpflichtend. Wer die security.txt heute einrichtet, hat morgen eine regulatorische Anforderung bereits proaktiv erledigt.
Was die Einrichtung wirklich kostet – Best Practices des BSI
Wenig. Das ist der eigentliche Charme der Empfehlung. Eine Textdatei, zwei Pflichtfelder, ein fester Speicherort – mehr braucht es im Kern nicht. Das BSI empfiehlt in seiner Praxisempfehlung dennoch, ein paar Punkte sauber aufzusetzen:
- Kontakte trennen: Eine Adresse für Produkte (
psirt@oderproductcert@), eine für die Infrastruktur (security@,cert@odercsirt@) – gerade in größeren Organisationen findet die Meldung so schneller ihren Platz. - Ablaufdatum im Blick behalten: Ein Wert, der weniger als ein Jahr in der Zukunft liegt, zwingt zur regelmäßigen Prüfung. Eine veraltete security.txt ist schlimmer als keine.
- Signieren, wenn möglich: Eine digitale Signatur per OpenPGP schützt davor, dass jemand die Datei manipuliert und Melder auf eine falsche Adresse lenkt.
- Auffindbar bleiben: Firewall- und DDoS-Regeln dürfen Web-Crawler nicht aussperren, die gezielt nach dieser Datei suchen – sonst läuft die Implementierung ins Leere.
Eine Datei, ein Signal für digitale Verantwortung
Die security.txt löst kein einziges technisches Sicherheitsproblem von selbst. Sie öffnet nur eine Tür – die Tür, durch die eine Warnung überhaupt erst hereinkommen kann. Genau das ist ihr Wert: Sie macht aus einem stillen Risiko ein meldbares.
Für Unternehmen, Vereine und Kommunen, die ich als externer Datenschutzbeauftragter begleite, gehört die security.txt inzwischen zur Grundausstattung jeder neuen Website – neben Impressum und Datenschutzerklärung ein drittes, oft übersehenes Pflichtfeld für digitale Verantwortung.
Wer prüfen möchte, ob die eigene Website bereits erreichbar ist, findet unter securitytxt.org ein Werkzeug zum Erstellen der Datei. Die vollständige Empfehlung des BSI mit allen Feldern und Beispielen steht als BSI-CS 149 zum Download bereit.
Über den Autor
Achim Weidner ist zertifizierter Social Media Manager (IHK) und Absolvent des Zertifizierungsprogramms „Rechtliche Aspekte der IT- und Internet-Compliance“ an der Carl von Ossietzky Universität Oldenburg mit Datenschutzrecht, Internetrecht und Computerstrafrecht. Seit 2017 befasst er sich mit der Thematik der „Künstlichen Intelligenz“.
Achim Weidner
Haßlocher Straße 73
65428 Rüsselsheim am Main
E-Mail: post@achim-weidner.de
Telefon: 06142 796066
LinkedIn: achimweidner

LinkedIn | WhatsApp Kanal | Google Profil | Kontakt
#securitytxt #cybersecurity #datenschutz #compliance