CVD-Policy für Maschinen: Was die ENISA-Vorlage offenlässt

Die ENISA hat im Oktober 2026 den Entwurf eines „Technical Advisory on security.txt, CVD Policies and Security Advisories“ veröffentlicht, Untertitel „SME Vulnerability Kit“. Die Vorlagen für security.txt, CVD-Policy und Security Advisory sind für kleine Hersteller brauchbar. Sie tragen aber nur einen Teil von Anhang I Teil II CRA, und der CVD-Policy fehlt eine Regel, die Maschinen- und Anlagenbauer brauchen.

Eine CVD-Policy (Coordinated Vulnerability Disclosure, koordinierte Offenlegung von Schwachstellen) legt fest, wie Dritte Schwachstellen melden, wie der Hersteller reagiert und wann er veröffentlicht. Nach Anhang I Teil II CRA müssen Hersteller eine solche Policy einführen und durchsetzen. Der ENISA-Entwurf gibt laut rechtlichem Hinweis nur die Sicht der Agentur wieder. Er begründet keine Pflicht und ersetzt nach eigener Aussage keine offiziellen Leitlinien zum CRA.

Inhalt

1. Die ENISA legt drei Vorlagen für KMU zur Konsultation vor
2. security.txt und Security Advisory erfassen auch Weboberfläche und Cloud-App
3. Drei der acht Pflichten aus Anhang I Teil II deckt das Paket nicht ab
4. Die CVD-Vorlage schließt Tests an laufenden Maschinen nicht ausdrücklich aus
5. Bei Meldewegen und Fristen bleibt der Entwurf ungenau
6. Für Maschinen und Anlagen zählen vor allem die OT-Hinweise

Die ENISA legt drei Vorlagen für KMU zur Konsultation vor

Das Paket richtet sich an Hersteller von Produkten mit digitalen Elementen, vor allem an Kleinst-, kleine und mittlere Unternehmen mit wenig Personal für Recht und Compliance. Es enthält eine security.txt nach RFC 9116, eine CVD-Policy mit zehn Nummern und eine Vorlage für Security Advisories. Bezugspunkte sind die Anforderungen des CRA an das Schwachstellenmanagement und der Normentwurf prEN 40000-1-3. Wie diese Normenreihe aufgebaut ist, zeigt unser Überblick über die harmonisierten Normen zum CRA.

Nicht abgedeckt sind sichere Entwicklung, interne Behebungsabläufe, Incident Response und das Schwachstellenmanagement von Zulieferern. Den Entwurf als PDF stellt die ENISA auf ihrer Website bereit. Die Angabe „Mandatory“ in der Feldtabelle zur security.txt bezieht sich laut Fußnote 5 auf RFC 9116 und begründet keine Rechtspflicht.

security.txt und Security Advisory erfassen auch Weboberfläche und Cloud-App

Als Beispiel dient eine Maschinensteuerung mit Embedded-Webserver als HMI, zu der der Hersteller eine Cloud-Begleit-App anbietet. Die security.txt liegt nach dem Entwurf mindestens unter /.well-known/security.txt, wird nur per HTTPS ausgeliefert, und das Feld Expires reicht höchstens zwölf Monate in die Zukunft. Sie gehört auf die Hauptdomain des Herstellers und auf jede Domain, die zum Produkt gehört. Im Beispiel braucht also auch die Domain der App eine eigene Datei.

Für den Embedded-Webserver sieht der Entwurf zwei Wege vor. Entweder verweisen Weboberfläche oder Produktdokumentation auf die Offenlegungsinformationen des Herstellers, oder das Gerät bekommt eine eigene security.txt mit klarem Scope und aktuellem Kontakt. Die zentrale Anlaufstelle muss nach Anhang II Nummer 2 CRA zusätzlich in den Informationen für Nutzer stehen.

Die Advisory-Vorlage sieht Kennungen nach CVE oder EUVD vor, eine CVSS-Bewertung mit Vektor, ein optionales Feld „Safety impact“ und die Zielgruppe, etwa Betreiber, Integratoren oder Servicepartner. Einen öffentlichen Index aller Advisories wertet die ENISA als Beleg laufender Compliance. Als maschinenlesbares Format empfiehlt sie CSAF und verweist auf Artikel 14 Absatz 8 CRA, der die Information der Nutzer, wo angebracht, in strukturierter und maschinenlesbarer Form vorsieht. Wir lesen die Vorlage als Zusammenführung von Anhang I Teil II und Normentwurf. Den Index verlangt die Verordnung nicht ausdrücklich; die ENISA macht ihn zum Nachweis.

Drei der acht Pflichten aus Anhang I Teil II deckt das Paket nicht ab

Die ENISA schreibt in Annex A.1 selbst, dass die Vorlagen die Pflichten nicht allein erfüllen und die zugehörigen Prozesse gelebt werden müssen. Unsere Zuordnung auf Grundlage dieses Anhangs:

Anforderung (Anhang I Teil II)	Unterstützt durch	Grad laut ENISA	Was beim Hersteller bleibt
Nr. 1 Schwachstellen und Komponenten erfassen, SBOM	keine Vorlage	nicht	Komponentenliste aufbauen und pflegen
Nr. 2 Schwachstellen unverzüglich beheben	CVD-Policy (Ziele für Reaktion und Behebung)	unterstützt	Behebung selbst, Fristen festlegen
Nr. 3 Testen und überprüfen	keine Vorlage	nicht	interner Entwicklungsprozess
Nr. 4 Behobene Schwachstellen offenlegen	CVD-Policy, Advisory	unterstützt	Advisory je Schwachstelle, Index pflegen
Nr. 5 CVD-Policy einführen und durchsetzen	CVD-Policy	unterstützt	Anpassung, Zuständigkeiten, Ressourcen
Nr. 6 Informationsaustausch, Kontaktadresse	security.txt, CVD-Policy	unterstützt	Kanäle verfügbar halten und überwachen
Nr. 7 Updates sicher verteilen	keine Vorlage	nicht	Update-Mechanismus
Nr. 8 Updates unverzüglich und kostenlos mit Hinweisen verteilen	Advisory	teilweise	Verteilung und Hinweise an Nutzer

Die Vorlagen regeln damit vor allem, was nach außen sichtbar ist. Komponentenliste, Tests und sichere Update-Verteilung bleiben ohne Vorlage, und dort steckt nach unserer Einschätzung der größere Teil des Aufwands. Wie weit die Pflicht zur Komponentenliste reicht, beschreibt unser Beitrag zur SBOM nach dem CRA.

Die CVD-Vorlage schließt Tests an laufenden Maschinen nicht ausdrücklich aus

Nummer 2 der CVD-Vorlage nimmt Tests an Systemen, Diensten und Infrastruktur aus, die der Hersteller weder besitzt noch kontrolliert („not owned or controlled by“). Die Testregeln in Nummer 4 verbieten Denial-of-Service-Tests und Beeinträchtigungen der Systeme des Herstellers. Zu Safety und laufendem Betrieb sagen sie nichts.

Im Beispiel erreicht ein Forscher die HMI einer Steuerung, die beim Kunden in der Produktion läuft. Ob diese Anlage als „controlled by“ gilt, etwa weil der Hersteller sie per Fernwartung betreut, beantwortet die Vorlage nicht.

Den Kern benennt der Entwurf erst in den Umsetzungshinweisen zur CVD-Policy. Ein Safe Harbour kann danach nur Tests an den eigenen Systemen des Herstellers freigeben und keine Tests an Systemen Dritter. Die Rechtslage unterscheidet sich außerdem zwischen den Mitgliedstaaten. Wir halten diesen Hinweis in der Vorlage selbst für nötig. Veröffentlicht wird der Vorlagentext, die Umsetzungshinweise bleiben im ENISA-Dokument.

Bei Meldewegen und Fristen bleibt der Entwurf ungenau

Nach dem Absatz zur NIS-2 genügen eine security.txt und ein überwachter Meldekanal für beide Rechtsakte. Die Policy soll aber klären, ob eine Meldung Produkte betrifft, gemeldet nach Artikel 14 CRA, oder die eigenen Netze, gemeldet nach Artikel 23 NIS-2. Das liest sich, als müsse jede Meldung an eine Behörde weitergehen. Meldepflichtig sind nach Artikel 14 CRA aber nur aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, nach Artikel 23 NIS-2 nur erhebliche Sicherheitsvorfälle. Eine gewöhnliche Forschermeldung zu Ihrer Steuerung löst keine der beiden Meldungen aus. Welche Fälle darunter fallen, ordnet unser Beitrag Schwachstellen nach CRA: was gemeldet werden muss ein.

Die Frühwarnung binnen 24 Stunden erwähnt der Entwurf. Dass Artikel 14 CRA seit dem 11. September 2026 gilt, steht nicht darin. Ebenso fehlt, dass die Pflicht nach Artikel 69 Absatz 3 auch Produkte erfasst, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Für die Steuerung, die seit Jahren im Feld ist, gilt die Meldepflicht also schon heute, wie im Beitrag CRA-Meldepflichten gelten auch für Bestandsprodukte beschrieben.

Der Überblick zur CVD-Policy kündigt Standardwerte für die Reaktionszeiten an. Die Tabelle in Nummer 6 der Vorlage enthält aber nur Platzhalter. Einziger fester Wert ist die Eingangsbestätigung binnen sieben Kalendertagen, die die ENISA in Fußnote 7 dem Normentwurf zuschreibt. Fristen für Triage, Status-Updates und Embargo legen Sie selbst fest.

Für Maschinen und Anlagen zählen vor allem die OT-Hinweise

Die Umsetzungshinweise enthalten einen Absatz zu Maschinen und anderen OT-Produkten. Ein Fix kann dort eine erneute Validierung verlangen, auch der Sicherheitsfunktionen, und lässt sich oft erst im geplanten Wartungsfenster einspielen. Dauert er länger als die Zielzeiten, stellen Sie zuerst Mitigation und unterstützende Maßnahmen bereit; der Entwurf verweist dazu auf Frage 4.3.1 der FAQ der Kommission zum CRA. Die ENISA schreibt dazu: „CVSS describes severity, not the risk in a specific operating environment.“ (Der CVSS-Wert beschreibt die Schwere, nicht das Risiko in einer bestimmten Betriebsumgebung.)

Für die Steuerung im Beispiel beschreibt das Advisory deshalb die Lage aus Sicht des Betreibers. Es nennt Segmentierung und das Abschalten des Fernzugriffs als unterstützende Maßnahmen und nutzt das Feld „Safety impact“. Die Advisory-Vorlage hält in Nummer 3 fest, dass solche Maßnahmen einen nötigen Fix nicht ersetzen. Damit die Prüfung auf aktive Ausnutzung bei jeder Meldung stattfindet, gehört sie in Ihren CRA-Meldeprozess.

Als Ausgangspunkt halten wir die CVD-Vorlage für brauchbar, Maschinenbauer können sie übernehmen. Aus dem Entwurf selbst ergeben sich zwei Ergänzungen. In Nummer 2 grenzen Sie Anlagen im Betrieb beim Kunden ausdrücklich aus, und in Nummer 6 tragen Sie Fristen ein, die Wartungsfenster berücksichtigen. Kommentare zu Scope, Testregeln und Fristen nimmt die ENISA bis 15. November 2026 entgegen.