security.txt: Nur 1,8 Prozent der Websites in Deutschland haben sie

Wenn ein Sicherheitsforscher oder ein CERT auf Ihrer Website eine kritische Schwachstelle findet, wohin schickt er die Meldung? Bei den allermeisten deutschen Unternehmen: nirgendwohin, weil es keine erkennbare Adresse dafür gibt. Laut einer Erhebung des Bundesamts für Sicherheit in der Informationstechnik (BSI) (öffnet in neuem Tab) stellen nur 1,8 Prozent der Webseitenbetreiber in Deutschland eine sogenannte security.txt bereit – eine Standarddatei, die genau diesen Kontakt liefert. Über 98 Prozent haben demnach keinen etablierten Kanal für Sicherheitsmeldungen, wie heise online (öffnet in neuem Tab) zur selben Erhebung berichtet.

Das wäre für sich genommen schon ein Grund, die Datei einzurichten – der Aufwand ist gering. Interessanter für Unternehmen, die selbst Software entwickeln oder vertreiben, ist der zweite Teil der Meldung: Seit dem 11. September 2026 gelten im Rahmen des Cyber Resilience Act (CRA) gesetzliche Meldepflichten für Schwachstellen, die über die freiwillige security.txt weit hinausgehen – und seit demselben Tag ist auch die dafür zuständige zentrale Meldeplattform der ENISA live. Dieser Beitrag trennt beide Themen, weil sie oft in einen Topf geworfen werden, aber unterschiedliche Adressaten und unterschiedliche Verbindlichkeit haben.

Was security.txt ist – und was nicht

security.txt ist nach RFC 9116 (öffnet in neuem Tab) eine einfache Textdatei, die unter dem festen Pfad /.well-known/security.txt auf einem Webserver liegt. Sie ist eine freiwillige Empfehlung der IETF, kein Gesetz und keine CRA-Pflicht – das BSI ruft lediglich dazu auf, sie umzusetzen, weil sie eine der niedrigschwelligsten IT-Sicherheitsmaßnahmen überhaupt ist.

Der Standard kennt zwei Pflichtfelder:

Contact – ein Kontaktweg für Sicherheitsmeldungen, etwa eine E-Mail-Adresse oder eine Kontaktseite. Dieses Feld muss laut RFC immer vorhanden sein.
Expires – ein Ablaufdatum, ab dem die Angaben als veraltet gelten. Auch dieses Feld ist verpflichtend und darf nur einmal vorkommen.

Alles andere – ein Verweis auf eine Offenlegungsrichtlinie (Policy), einen Verschlüsselungsschlüssel (Encryption) oder bevorzugte Sprachen (Preferred-Languages) – ist laut RFC optional. Eine minimale, gültige Datei kann also so aussehen:

# Sicherheitskontakt für example.de
Contact: mailto:security@example.de
Expires: 2027-08-17T00:00:00z

Das BSI ordnet die Datei in sein Cyberdome-Projekt (öffnet in neuem Tab) ein: Websites werden automatisiert gescannt, und Erkenntnisse zu Schwachstellen sollen über die security.txt direkt beim richtigen Ansprechpartner landen – statt im allgemeinen Support-Postfach zu versickern.

Wer mehr Aufwand investieren will, kann laut RFC 9116 zusätzliche Felder ergänzen: Policy verweist auf eine ausführliche Offenlegungsrichtlinie, Encryption auf einen öffentlichen PGP-Schlüssel für verschlüsselte Meldungen, Preferred-Languages gibt an, in welchen Sprachen Meldungen erwünscht sind. Der RFC empfiehlt zudem, die Datei digital mit einer OpenPGP-Signatur zu versehen, damit Forschende die Echtheit prüfen können – verpflichtend ist das aber nicht. Für den Einstieg reichen die beiden Pflichtfelder.

Für eine Nuxt- oder sonstige serverseitig gerenderte Website ist das eine reine Konfigurationsaufgabe

Technisch bedeutet die Umsetzung nur: eine Textdatei im öffentlichen Verzeichnis der Website ablegen, sodass sie unter /.well-known/security.txt erreichbar ist. Bei einem Nuxt-Projekt liegt sie im public/-Verzeichnis unter public/.well-known/security.txt – kein Build-Schritt, keine Serverkonfiguration, kein Redirect nötig. Bei klassischem Apache- oder Nginx-Hosting genügt es, die Datei in das entsprechende Wurzelverzeichnis zu kopieren. Der Aufwand liegt bei Minuten, nicht bei Tagen – was die niedrige Verbreitung von 1,8 Prozent umso auffälliger macht.

Ein Punkt, der in der Praxis oft übersehen wird: Das Expires-Datum ist keine Formalie. Der RFC empfiehlt ausdrücklich, es auf weniger als ein Jahr in der Zukunft zu setzen, damit die Angaben nicht veralten – wer die Datei einmal anlegt und dann vergisst, hat nach Ablauf des Datums formal wieder keinen gültigen Kontakt hinterlegt. Ein jährlicher Kalendereintrag zur Erneuerung gehört deshalb zur Umsetzung dazu.

Die andere Frist: CRA-Meldepflicht ab 11. September 2026

Während security.txt freiwillig bleibt, wird eine verwandte, aber deutlich schärfere Pflicht in wenigen Wochen verbindlich. Der Cyber Resilience Act (öffnet in neuem Tab) verpflichtet Hersteller von „Produkten mit digitalen Elementen" zu einem gestaffelten Melderegime für Schwachstellen und Sicherheitsvorfälle. Laut BSI müssen Betroffene bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen:

innerhalb von 24 Stunden eine erste Meldung (Frühwarnung) abgeben,
innerhalb von 72 Stunden weitere verfügbare Informationen nachreichen,
und spätestens 14 Tage nach einem Sicherheitsupdate oder Workaround einen Abschlussbericht vorlegen.

Diese Meldepflichten gelten laut BSI bereits ab dem 11. September 2026 – 21 Monate nach Inkrafttreten der Verordnung. Die Meldungen laufen über eine neue zentrale Plattform, die die europäische Sicherheitsbehörde ENISA dafür einrichtet. Alle übrigen CRA-Anforderungen – etwa die vollständige Konformitätsbewertung nach CE-Kennzeichnung – greifen laut BSI-FAQ erst zum 11. Dezember 2027.

Wen betrifft das – und wen nicht

Hier liegt der Punkt, an dem Verwechslung teuer werden kann: Die CRA-Meldepflicht trifft Hersteller von Produkten mit digitalen Elementen, nicht jeden Betreiber einer Unternehmenswebsite. Laut BSI zählt dazu ausdrücklich auch B2B-Software – etwa Buchhaltungssoftware oder andere Anwendungen, die ein Unternehmen als Produkt an Dritte verkauft oder bereitstellt. Wer dagegen „nur" eine eigene Website oder interne Software betreibt, ohne sie als Produkt in Verkehr zu bringen, fällt nicht automatisch unter diese Meldepflicht.

Für kleine und mittlere Unternehmen sieht der CRA laut BSI eigene Erleichterungen vor: vereinfachte technische Dokumentation, Helpdesks für Meldefragen und Regulatory Sandboxes zur Überprüfung von Produkten. Wer unsicher ist, ob ein selbst entwickeltes oder vertriebenes Produkt unter den CRA fällt, sollte das frühzeitig klären – die 24-Stunden-Frist ab dem 11. September 2026 lässt keinen Spielraum für nachträgliche Einordnung im Ernstfall.

Die meisten Produkte, für die der CRA überhaupt relevant ist, fallen laut BSI in die Kategorie „Standardprodukte" – dazu zählt regulär vertriebene B2B-Software ebenso wie vernetzte Geräte. Nur eine kleinere Gruppe von „wichtigen" oder „kritischen" Produkten, etwa Passwortmanager, Firewalls oder Smart-Meter-Gateways, unterliegt schärferen Konformitätsbewertungsverfahren durch eine externe Prüfstelle. Für die Meldepflicht selbst spielt diese Einordnung aber keine Rolle: Sie gilt laut BSI-FAQ für alle Produktkategorien gleichermaßen, unabhängig vom Preis oder der Zielgruppe.

Zwei Maßnahmen, zwei Zeithorizonte

Weil beide Themen in denselben Meldungen auftauchen, lohnt sich die klare Trennung, bevor Prioritäten verwechselt werden:

security.txt – für praktisch jedes Unternehmen mit eigener Website sinnvoll, unabhängig davon, ob es Software als Produkt vertreibt. Freiwillig, in Minuten umsetzbar, ohne Rechtsrisiko bei Unterlassung. Der Nutzen: Sicherheitsforscher und CERTs finden einen Ansprechpartner, bevor eine Lücke ausgenutzt wird.

CRA-Meldepflicht – nur relevant, wenn ein Unternehmen Produkte mit digitalen Elementen herstellt oder vertreibt, dafür aber verbindlich und mit engen Fristen ab dem 11. September 2026. Hier braucht es vorher geklärte interne Prozesse: Wer erkennt eine aktiv ausgenutzte Schwachstelle, wer meldet sie fristgerecht über die ENISA-Plattform, und wer verantwortet den Abschlussbericht?

Ein Beispiel, wie beides zusammenhängt: Ein Unternehmen, das eine SaaS-Lösung für Kunden betreibt, sollte nicht nur die eigene Website mit einer security.txt versehen, sondern für das Produkt selbst prüfen, ob und ab wann die CRA-Meldepflicht greift – und ob interne Verantwortlichkeiten für den Ernstfall bereits feststehen. Beides lässt sich unabhängig voneinander angehen, aber beides gehört in dieselbe Bestandsaufnahme.

Die Meldeplattform ist live: So läuft die Registrierung ab

Mit dem 11. September 2026 hat die ENISA die CRA Single Reporting Platform (SRP) (öffnet in neuem Tab) unter portal.cra-srp.enisa.europa.eu in Betrieb genommen – die 24-Stunden-Frist ist damit keine theoretische Pflicht mehr, sondern hat ein konkretes technisches Gegenstück. Laut der ENISA-FAQ zur SRP (öffnet in neuem Tab) funktioniert die Registrierung so:

Ein Hersteller braucht mindestens einen „Assigned Representative" (AR) mit einem persönlichen EU-Login-Konto und aktivierter Mehr-Faktor-Authentifizierung. Das Konto lässt sich vorab unter ecas.ec.europa.eu anlegen.
Der erste AR registriert sich als Primary AR, wählt das zuständige CSIRT Designated as Coordinator (CDaC) – in der Regel das des Landes, in dem das Unternehmen seinen Hauptsitz hat – und hinterlegt die Herstellerangaben. Bis zu 20 weitere Secondary ARs lassen sich danach per Einladung hinzufügen.
Die Verknüpfung zwischen AR und Hersteller muss vom zuständigen CSIRT bestätigt werden. Das läuft laut ENISA parallel zum eigentlichen Meldeprozess: Ein Unternehmen kann laut FAQ bereits vor abgeschlossener Verifizierung bis zu 20 Meldungen einreichen – die Bestätigung blockiert die erste Meldung im Ernstfall also nicht.
Für eine gegebene Schwachstelle oder einen Vorfall reicht eine einzige Meldung über die Plattform, auch wenn ein Hersteller mehrere Niederlassungen in der EU hat oder die Konzernmutter außerhalb der EU sitzt – die interne Koordination, wer meldet, bleibt aber Aufgabe des Unternehmens selbst.

Für die Praxis heißt das: Wer erst im Ernstfall anfängt, ein EU-Login-Konto anzulegen und das zuständige CSIRT herauszufinden, verliert einen Teil der ohnehin knappen 24-Stunden-Frist mit reiner Verwaltungsarbeit. ENISA empfiehlt zwar, sich „erst bei Bedarf" zu registrieren, um die Prüflast bei den CSIRTs gering zu halten – das entbindet aber nicht davon, vorher zu klären, wer im Unternehmen die Rolle des Primary AR übernimmt und wie schnell diese Person im Ernstfall handlungsfähig ist.

Was jetzt zu tun ist

Für die security.txt reicht ein kurzer interner Auftrag: Kontakt- und Ablaufdatum festlegen, Datei anlegen, unter /.well-known/security.txt veröffentlichen. Das lässt sich in einer Umsetzung von unter einer Stunde erledigen und ändert nichts an bestehenden Prozessen.

Für die CRA-Meldepflicht braucht es mehr Vorlauf, wenn ein Unternehmen betroffen ist: eine Klärung, ob die eigenen Produkte unter den CRA-Anwendungsbereich fallen, eine benannte Person als künftiger Primary AR, ein vorbereitetes EU-Login-Konto und ein Testlauf, wie eine Meldung innerhalb von 24 Stunden über die SRP praktisch aussehen würde – nicht erst, wenn der Ernstfall eintritt. Die Meldepflicht selbst ist seit dem 11. September 2026 scharf; wer die interne Zuständigkeit dafür jetzt noch nicht geklärt hat, klärt sie im ungünstigsten Moment.