CVD-Policy und security.txt in 30 Minuten

Inhalt in Kürze

• Der CRA verlangt drei Dinge: eine Strategie zur koordinierten Offenlegung (Anhang I Teil II Nr. 5), eine Kontaktadresse für Schwachstellenmeldungen (Nr. 6) und eine zentrale Anlaufstelle, die nicht auf automatisierte Kanäle beschränkt sein darf (Art. 13 Abs. 17).
• security.txt steht nicht in der Verordnung. Es ist ein guter Weg, die Anforderungen zu erfüllen — keine Rechtspflicht.
• Die Strategie ist aufzustellen und umzusetzen. Ein PDF im Intranet erfüllt den zweiten Teil nicht.
• Dazu kommt eine oft übersehene Advisory-Pflicht: Nach Bereitstellung einer Sicherheitsaktualisierung sind Informationen über die behobene Schwachstelle zu teilen und zu veröffentlichen (Anhang I Teil II Nr. 4).

Von allen CRA-Pflichten ist diese die günstigste. Sie kostet keine notifizierte Stelle, keine Zertifizierung und kein Werkzeug — nur eine halbe Stunde und die Bereitschaft, danach auch zu antworten. Den Rahmen liefert der Überblick zu den CRA-Pflichten für Hersteller.

Was die Verordnung verlangt — im Wortlaut

Anhang I Teil II Nummer 5. Hersteller müssen

„eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen”.

Dasselbe steht noch einmal in Artikel 13 Absatz 8 Unterabsatz 6: Die Hersteller haben geeignete Strategien und Verfahren, darunter eine Strategie für die koordinierte Offenlegung von Schwachstellen gemäß Anhang I Teil II Nummer 5.

Anhang I Teil II Nummer 6. Hersteller müssen

„Maßnahmen ergreifen, um den Austausch von Informationen über mögliche Schwachstellen … zu erleichtern, und dazu u. a. eine Kontaktadresse für die Meldung der in dem Produkt mit digitalen Elementen entdeckten Schwachstellen angeben”.

Artikel 13 Absatz 17. Hersteller benennen eine zentrale Anlaufstelle, die es den Nutzern ermöglicht, direkt und schnell mit ihnen zu kommunizieren, auch um die Meldung von Schwachstellen zu erleichtern. Und der Satz, der die meisten Umsetzungen kippt:

„Die zentrale Anlaufstelle ermöglicht es den Nutzern, ihr bevorzugtes Kommunikationsmittel zu wählen, wobei diese Mittel nicht auf automatisierte Instrumente beschränkt werden dürfen.”

Anhang II Nummer 2 schließt den Kreis: Den Nutzern ist die zentrale Kontaktstelle mitzuteilen, bei der Informationen über Schwachstellen gemeldet und entgegengenommen werden und das Konzept für die koordinierte Offenlegung von Schwachstellen zu finden ist.

Was security.txt damit zu tun hat — und was nicht

Der Begriff kommt in der Verordnung nicht vor. Ebenso wenig „PSIRT”. Eine security.txt nach RFC 9116 ist eine Textdatei unter /.well-known/security.txt, die maschinen- und menschenlesbar sagt, wohin eine Schwachstellenmeldung geht. Sie ist ein bewährtes Mittel, Anhang I Teil II Nummer 6 und Anhang II Nummer 2 umzusetzen — nicht mehr und nicht weniger.

Der Vorteil ist praktisch: Sicherheitsforscher suchen dort zuerst. Wer keine hat, bekommt die Meldung im besten Fall über das allgemeine Kontaktformular, im schlechteren gar nicht — und im schlechtesten erfährt er von der Schwachstelle aus einem Blogbeitrag.

Ein Minimalbeispiel:

Contact: mailto:security@example.com
Contact: https://www.example.com/sicherheit/schwachstelle-melden
Contact: tel:+49-40-0000000
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: de, en
Policy: https://www.example.com/sicherheit/cvd-policy
Canonical: https://www.example.com/.well-known/security.txt

Zwei Details, an denen es in der Praxis hakt: Expires ist Pflicht und läuft ab — eine abgelaufene Datei ist schlechter als keine, weil sie Aktualität vortäuscht. Und die Datei gehört unter /.well-known/, nicht ins Wurzelverzeichnis.

Die dritte Contact-Zeile im Beispiel ist kein Zierrat: Sie ist der nicht automatisierte Weg, den Artikel 13 Absatz 17 verlangt.

Die CVD-Seite: was hineingehört

Die Strategie muss aufgestellt und umgesetzt werden. Umsetzen heißt: Es gibt eine öffentlich erreichbare Seite, die sagt, woran Meldende sich halten können — und intern jemanden, der sich daran hält.

• Geltungsbereich. Welche Produkte, Versionen und Dienste sind gemeint, welche ausdrücklich nicht.
• Meldewege. Adresse, Formular, Telefon — und mindestens einer davon nicht automatisiert. Optional ein Schlüssel für verschlüsselte Meldungen.
• Was Sie zusagen. Eingangsbestätigung binnen X Werktagen, erste inhaltliche Rückmeldung binnen Y. Nennen Sie Zeiträume, die Sie halten können — eine gerissene Zusage ist schlimmer als keine.
• Wie Sie mit Meldenden umgehen. Keine rechtlichen Schritte bei gutgläubiger Forschung im beschriebenen Rahmen. Das ist der Punkt, der über die Qualität der eingehenden Meldungen entscheidet.
• Veröffentlichung. Wann Sie ein Advisory herausgeben und wie Sie es mit dem Meldenden abstimmen.
• Was Sie nicht anbieten. Ein Bug-Bounty-Programm verlangt der CRA nicht. Wenn Sie keines haben, schreiben Sie das hin — sonst kommt die Frage in jeder zweiten Meldung.

Die Advisory-Pflicht, die fast überall fehlt

Anhang I Teil II Nummer 4 verlangt, nach Bereitstellung einer Sicherheitsaktualisierung Informationen über die behobene Schwachstelle zu teilen und zu veröffentlichen: Beschreibung der Schwachstelle, Angaben, mit denen Nutzer ihre Betroffenheit erkennen können, Auswirkungen und Schwere sowie Hinweise zur Behebung.

Die Verordnung räumt dabei ausdrücklich einen Aufschub ein: Die Veröffentlichung darf in hinreichend begründeten Fällen so lange aufgeschoben werden, bis den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden.

Das ist nicht dasselbe wie die Nutzerinformation nach Artikel 14 Absatz 8 — die betrifft aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, gilt bereits seit dem 11. September 2026 und richtet sich an die betroffenen Nutzer. Die Advisory-Pflicht aus Anhang I gilt ab dem 11. Dezember 2027 und betrifft jede behobene Schwachstelle. Wer nur eines von beiden aufsetzt, hat eine Lücke.

Die 30 Minuten

1. Postfach anlegen und einem Menschen zuweisen (10 Min.). security@ihre-domain.de, mit benannter Vertretung. Ohne das ist der Rest Kosmetik.
2. CVD-Seite veröffentlichen (10 Min.). Geltungsbereich, Meldewege, Reaktionszeiten, Umgang mit Meldenden, Veröffentlichungspraxis. Eine Seite reicht.
3. security.txt ablegen (5 Min.). Unter /.well-known/security.txt, mit Expires und einem Verweis auf die CVD-Seite im Policy-Feld.
4. In die Produktinformation aufnehmen (5 Min.). Anhang II Nummer 2 verlangt, dass Nutzer die zentrale Kontaktstelle und den Fundort der Strategie erfahren — also in die Produktdokumentation, nicht nur auf die Website.

Danach steht eine Wiedervorlage an: Expires erneuern, bevor es abläuft, und einmal im Jahr prüfen, ob die genannten Reaktionszeiten noch stimmen.

Ab wann das gilt

Die Pflichten aus Artikel 13 und Anhang I gelten ab dem 11. Dezember 2027 (Art. 71 Abs. 2). Für Produkte, die vor diesem Tag in Verkehr gebracht wurden, greifen sie erst mit der nächsten wesentlichen Änderung (Art. 69 Abs. 2). Die Meldepflicht des Artikels 14 gilt dagegen bereits seit dem 11. September 2026 — und zwar auch für den Altbestand (Art. 69 Abs. 3).

Das spricht trotzdem nicht dafür, mit der CVD-Seite zu warten. Sie ist die einzige CRA-Pflicht, die sich an einem Nachmittag erledigen lässt — und sie ist der Kanal, über den Sie von einer aktiv ausgenutzten Schwachstelle möglicherweise überhaupt erst erfahren. Die 24-Stunden-Uhr aus Artikel 14 läuft ab dem Moment, in dem Sie es wissen; ob Sie es früh oder spät wissen, entscheidet dieser Kanal.

Ob der CRA für Sie gilt, klärt der kostenlose Hersteller-Check. Wie die Meldung an CSIRT und ENISA abläuft, steht im Beitrag zur CRA-Meldepflicht in 24 und 72 Stunden — und die Grundlage dafür, überhaupt zu wissen, was in Ihrem Produkt steckt, liefert die Software-Stückliste.

Häufige Fragen (FAQ)

Verlangt der Cyber Resilience Act eine security.txt?

Nein. Die Verordnung verlangt eine Kontaktadresse für die Meldung entdeckter Schwachstellen (Anhang I Teil II Nummer 6) und eine zentrale Anlaufstelle, die den Nutzern die Wahl des Kommunikationswegs lässt (Artikel 13 Absatz 17). Der Begriff security.txt kommt im Verordnungstext nicht vor. Eine security.txt nach RFC 9116 ist ein bewährter Weg, diese Anforderungen umzusetzen — mehr nicht.

Was ist eine CVD-Policy?

Eine Strategie für die koordinierte Offenlegung von Schwachstellen. Anhang I Teil II Nummer 5 verlangt, sie aufzustellen und umzusetzen. Sie legt fest, wie Meldende Sie erreichen, wie schnell Sie antworten, wie Sie mit der Behebung umgehen und wann Sie veröffentlichen. Anhang II Nummer 2 verlangt zusätzlich, dass Nutzer erfahren, wo die Strategie zu finden ist.

Reicht eine security@-Adresse mit Autoresponder?

Für die Kontaktadresse nach Anhang I Teil II Nummer 6 ja, für die zentrale Anlaufstelle nach Artikel 13 Absatz 17 nicht. Diese muss es den Nutzern ermöglichen, ihr bevorzugtes Kommunikationsmittel zu wählen, und darf ausdrücklich nicht auf automatisierte Instrumente beschränkt werden. Es braucht also mindestens einen nicht automatisierten Weg.

Müssen wir jede behobene Schwachstelle veröffentlichen?

Nach Anhang I Teil II Nummer 4 sind Informationen über behobene Schwachstellen nach Bereitstellung einer Sicherheitsaktualisierung zu teilen und zu veröffentlichen — mit Beschreibung, Angaben zur Betroffenheitserkennung, zu Auswirkungen und Schwere sowie Hinweisen zur Behebung. Die Veröffentlichung darf in hinreichend begründeten Fällen so lange aufgeschoben werden, bis Nutzer den Patch anwenden konnten.

Ab wann gilt das?

Die Pflichten aus Artikel 13 und Anhang I gelten ab dem 11. Dezember 2027 (Artikel 71 Absatz 2). Für Produkte, die vor diesem Tag in Verkehr gebracht wurden, greifen sie erst mit der nächsten wesentlichen Änderung (Artikel 69 Absatz 2). Die Meldepflicht des Artikels 14 gilt dagegen bereits seit dem 11. September 2026.