Kurz gefasst · Stand: September 2026
Anhang I Teil I Nr. 2 Buchst. a des Cyber Resilience Act verlangt, dass Produkte „ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden". Wann eine Schwachstelle bekannt ist, sagt die Verordnung nicht. Die Kommissions-Leitlinien nach Art. 26 (C(2026) 5252, Rn. 233) füllen die Lücke: bekannt ist, was in einer öffentlich zugänglichen Datenbank wie der EUVD oder einer anderen prominenten Datenbank steht. Nach unserer Lesart gehören dazu auch die öffentlichen Advisories und CSAF-Feeds der Steuerungshersteller. Für Anlagenbauer heißt das: Eine veröffentlichte CVE zur verbauten Steuerung gilt als bekannt, auch wenn keine Mail dazu eingegangen ist, und zwar zum Zeitpunkt des Inverkehrbringens, nicht zum Software-Freeze.
Der Verordnungstext verlangt „ohne bekannte ausnutzbare Schwachstellen", definiert „bekannt" aber nicht
Die Anforderung steht in Anhang I Teil I Nr. 2 Buchst. a: Auf Grundlage der Risikobewertung nach Art. 13 Abs. 2 müssen Produkte mit digitalen Elementen, soweit zutreffend, „ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden". Zwei der drei Begriffe sind definiert. „Schwachstelle" ist nach Art. 3 Nr. 40 eine Schwäche, Anfälligkeit oder Fehlfunktion, die bei einer Cyberbedrohung ausgenutzt werden kann. „Ausnutzbare Schwachstelle" ist nach Art. 3 Nr. 41 eine Schwachstelle, „die von einem unbefugten Dritten unter praktischen Betriebsbedingungen wirksam genutzt werden kann".
Für „bekannt" gibt es keine Definition. Die Kommission stellt das in ihren Leitlinien selbst fest (Rn. 232): Die Verordnung verlangt Verfahren zur Behandlung gemeldeter Schwachstellen, legt aber nicht ausdrücklich fest, ab wann eine ausnutzbare Schwachstelle als dem Hersteller bekannt gilt und damit die Pflicht zum Zeitpunkt des Inverkehrbringens auslöst. Von dieser Frage hängt ab, ob ein Anlagenbauer beim Inverkehrbringen gegen Anhang I verstoßen hat.
Die Kommission macht das Bekanntsein an öffentlichen Datenbanken fest
Rn. 233 der Leitlinien beantwortet die Frage: Eine Schwachstelle gilt als bekannt, wenn sie in einschlägigen öffentlich zugänglichen Schwachstellendatenbanken gelistet ist, namentlich in der nach Art. 12 Abs. 2 der NIS-2-Richtlinie eingerichteten Europäischen Schwachstellendatenbank oder in anderen prominenten Datenbanken. Rn. 234 ergänzt drei weitere Wege: nicht-öffentliche Information, etwa die koordinierte Offenlegung durch einen Sicherheitsforscher; eigene Tests und Analysen des Herstellers; und prominente Berichte in verlässlichen Medien einschließlich Fachpublikationen.
Die Leitlinien sind nach Art. 26 CRA erlassen und nicht rechtsverbindlich; verbindlich auslegen kann die Verordnung nur der Europäische Gerichtshof. Sie sind aber die offizielle Lesart der Kommission, und eine Marktüberwachungsbehörde wird sich auf sie stützen. Ein Hersteller, der die EUVD vor der Auslieferung nicht geprüft hat, kann sich gegenüber der Behörde deshalb kaum auf Unkenntnis berufen.
Zu den „anderen Datenbanken" zählen auch die öffentlichen Hersteller-Feeds
Rn. 233 nennt die EUVD als Beispiel („such as") und stellt ihr „andere prominente Schwachstellendatenbanken" zur Seite. Erwägungsgrund 34 formuliert dasselbe als „andere öffentlich zugängliche Schwachstellendatenbanken". Das Kriterium ist in beiden Fällen die öffentliche Zugänglichkeit, nicht der Betreiber. Welche Quellen darunter fallen, sagen weder die Verordnung noch die Leitlinien abschließend.
Nach unserer Lesart gehören die öffentlichen Sicherheitsmeldungen der Komponentenhersteller dazu, aus drei Gründen. Anhang I Teil II Nr. 4 verlangt von jedem CRA-Hersteller, Informationen über behobene Schwachstellen öffentlich offenzulegen; die Advisory-Seiten und CSAF-Feeds der Steuerungshersteller erfüllen genau diese Pflicht und sind damit öffentliche, strukturierte Verzeichnisse von Schwachstellen. Die Leitlinien selbst behandeln Hersteller-Advisories als gleichwertige Erkenntnisquelle: Rn. 223 empfiehlt, vor einer Meldung an den Komponentenhersteller „öffentlich zugängliche Schwachstellendatenbanken, projektspezifische Security-Advisories oder etablierte Issue-Tracker" zu prüfen. Und Erwägungsgrund 34 nennt als Sorgfaltsmaßnahme neben der Datenbankprüfung die „Kontrolle der bisherigen Sicherheitsaktualisierungen" einer Komponente; die findet nirgends anders statt als in der Advisory-Historie des Herstellers.
Hinzu kommt, dass die großen Steuerungshersteller ihre Schwachstellen selbst mit CVE-Nummern versehen. Was dort veröffentlicht wird, landet über das CVE-Programm ohnehin in der EUVD, in der Regel mit Verzögerung. Wer nur die EUVD prüft, prüft dieselbe Information später. Der öffentliche Feed des Steuerungsherstellers ist damit nicht nur ein Kanal, über den ein Advisory hoffentlich eintrifft, sondern eine Quelle, deren Inhalt als bekannt gilt, sobald er dort steht.
Ein Datenbankeintrag macht die Schwachstelle bekannt, aber noch nicht ausnutzbar
Die Leitlinien grenzen die Datenbank-Regel in Rn. 235 ein: Dass eine Schwachstelle gemeldet oder gelistet ist, bedeutet für sich genommen nicht, dass sie in der Praxis ausnutzbar ist oder das konkrete Produkt überhaupt betrifft. Der Hersteller muss den Eintrag prüfen und feststellen, ob er auf das eigene Produkt zutrifft. Zwischen Listung und Bestätigung darf deshalb eine begrenzte Zeit vergehen; verlangt wird eine zügige Prüfung.
Was „ausnutzbar unter praktischen Betriebsbedingungen" bedeutet, konkretisiert die Kommissions-FAQ (v1.4, Nr. 4.2.2): Maßgeblich ist unter anderem, ob der verwundbare Code im Betrieb überhaupt geladen oder aufgerufen wird, welcher Zugang für den Angriff nötig ist und ob kompensierende Maßnahmen bereits greifen. Das Beispiel der FAQ ist ein Smartphone, dessen Passwortprüfung sich nur mit physischem Zugriff und einem Laser-Glitch umgehen lässt; das darf der Hersteller begründet als nicht ausnutzbar einstufen. Bei einer Anlage lautet das entsprechende Argument etwa, dass der verwundbare Dienst deaktiviert ist oder die Steuerung in einer Netzzone ohne Fernzugang steht. Die Einstufung ist eine Entscheidung nach Rn. 237, bei der Schwere, Ausnutzbarkeit und Auswirkung abzuwägen sind, und sie gehört mit Begründung in die technische Dokumentation.
Eine veröffentlichte CVE zur verbauten Steuerung gilt als bekannt, auch ohne Mail vom Lieferanten
Das geschichtete Modell des CRA erlaubt es Anlagenbauern, sich bei der Behandlung von Schwachstellen auf die Advisories und Updates der Komponentenhersteller zu stützen. Für die Frage, ob eine Schwachstelle beim Inverkehrbringen bekannt war, hilft diese Arbeitsteilung nach Rn. 233 nicht weiter. Eine CVE zur verbauten Steuerung, die in der EUVD, in einer anderen prominenten Datenbank oder im öffentlichen Advisory des Steuerungsherstellers steht, ist dem Anlagenbauer bekannt, auch wenn keine Mail dazu eingegangen ist oder sie im Postfach eines Servicetechnikers liegt. In dieselbe Richtung geht Erwägungsgrund 34 der Verordnung zur gebotenen Sorgfalt nach Art. 13 Abs. 5. Er nennt als mögliche Maßnahme die „Überprüfung, ob eine Komponente frei von den Schwachstellen ist, die in der [...] europäischen Schwachstellendatenbank oder anderen öffentlich zugänglichen Schwachstellendatenbanken registriert sind".
Die Prüfung setzt voraus, dass der Komponentenstand je Anlage vorliegt, also Hersteller, Typ und Firmware-Version der verbauten Geräte. Ohne ihn lässt sich keine Datenbank abfragen. Dazu kommt ein Identifikator, über den sich ein Datenbankeintrag der Komponente zuordnen lässt. Warum gerade dieser Schritt bei Industriekomponenten der Engpass ist, behandelt der Beitrag zu Lieferanten ohne CSAF.
Der Zeitpunkt ist das Inverkehrbringen, nicht der Software-Freeze
Die Pflicht aus Anhang I Teil I gilt nach Art. 13 Abs. 1 zum Zeitpunkt des Inverkehrbringens. Die Leitlinien behandeln in Rn. 236 auch den Fall, dass eine Schwachstelle erst in der Endphase der Entwicklung oder kurz vor dem Eintritt in die Vertriebskette bekannt wird: Auch sie zählt. Im Anlagenbau liegt der maßgebliche Software-Stand häufig rund zwölf Monate vor der Auslieferung. Alles, was in diesen zwölf Monaten zur verbauten Firmware in die EUVD gelangt, ist zum Stichtag bekannt. Die Anforderung selbst gilt nach Art. 71 Abs. 2 für Anlagen, die ab dem 11. Dezember 2027 in Verkehr gebracht werden; für früher ausgelieferte Anlagen greift sie nur bei einer wesentlichen Änderung (Art. 69 Abs. 2). Wer heute eine Anlage mit Liefertermin 2028 kalkuliert, ist damit bereits im Zeitfenster.
Die Leitlinien verlangen dafür keinen Auslieferungsstopp. Nach Rn. 237 ist die Anforderung risikobasiert: Der Hersteller entscheidet anhand der Risikobewertung, ob das Produkt trotz der neuen Schwachstelle sicher in Verkehr gebracht werden kann oder ob sie vorher zu beheben ist. In die Abwägung dürfen auch die Risiken eines verschobenen Release eingehen, etwa wenn die Anlage kritische Prozesse weiterführen muss. Die Leitlinien verlangen eine begründete Entscheidung, kein bestimmtes Ergebnis.
Nach dem Inverkehrbringen gilt ein anderer Maßstab. Nach der Kommissions-FAQ (Nr. 4.2.3) begründet eine Schwachstelle, die zwischen Inverkehrbringen und Übergabe an den Nutzer bekannt wird, keinen Verstoß gegen Anhang I Teil I. Sie ist nach Anhang I Teil II Nr. 2 unverzüglich zu behandeln, gegebenenfalls mit einem Sicherheitsupdate zur Inbetriebnahme. Bei Anlagen liegen zwischen Lieferung und Inbetriebnahme oft Monate. Welche Schwachstellen in diese Zeit fallen und welche nicht, lässt sich nur mit einem dokumentierten Inverkehrbringdatum belegen.
Die Verordnung kennt drei verschiedene Schwellen für Schwachstellen
Die drei Schwellen werden in der Praxis häufig verwechselt, vor allem die erste mit der zweiten:
| Begriff | Fundstelle | Schwelle | Folge |
|---|
| bekannte ausnutzbare Schwachstelle | Anhang I Teil I Nr. 2 Buchst. a; Leitlinien Rn. 233 | in der EUVD oder einer anderen prominenten Datenbank gelistet, oder auf anderem Weg zur Kenntnis gelangt, und unter Betriebsbedingungen ausnutzbar | darf so nicht in Verkehr gebracht werden, es sei denn, die Risikobewertung trägt die Entscheidung |
| aktiv ausgenutzte Schwachstelle | Art. 3 Nr. 42; Art. 14 Abs. 1 | verlässliche Nachweise, dass ein böswilliger Akteur sie in einem System ausgenutzt hat | Frühwarnung an die ENISA binnen 24 Stunden ab Kenntnis |
| Schwachstelle im Support-Zeitraum | Anhang I Teil II Nr. 2; Art. 13 Abs. 8 | jede Schwachstelle des Produkts einschließlich seiner Komponenten | unverzüglich zu behandeln und zu beheben |
Eine CVE ohne Ausnutzungsnachweis löst keine Meldung nach Art. 14 aus. Bei einer Anlage, die noch nicht in Verkehr gebracht ist, entscheidet dieselbe CVE aber darüber, ob die Auslieferung in diesem Zustand zulässig ist.
Vor der Auslieferung sind drei Dinge zu dokumentieren
- Abgleich vor dem Inverkehrbringen dokumentieren. Komponentenstand der Anlage gegen die EUVD und die öffentlichen Advisories der Komponentenhersteller prüfen, mit Datum. Das ist die Sorgfaltsmaßnahme, die Erwägungsgrund 34 beschreibt.
- Entscheidung nach Rn. 237 festhalten. Für jede bekannte Schwachstelle der verbauten Komponenten: nicht anwendbar, nicht ausnutzbar mit Begründung, behoben, oder mit dokumentiertem Restrisiko ausgeliefert. Diese Liste steht hinter der Unterschrift auf der Konformitätserklärung.
- Inverkehrbringdatum je Anlage festhalten. Es entscheidet, welche Schwachstellen unter Teil I fallen und welche in die Behandlung nach Teil II gehören.
Datenbank-Abgleich für eine Anlage in der Demo ansehen →
Werkspilot gleicht den Komponentenstand ausgelieferter Anlagen laufend mit der EUVD, weiteren Datenbanken und Lieferantenmeldungen ab und dokumentiert die Bewertung nachweisfähig. Dieser Beitrag gibt den Stand der Regulierung zum Zeitpunkt der Veröffentlichung wieder und ist keine Rechtsberatung. Maßgeblich ist der Verordnungstext; die Kommissions-Leitlinien (Stand 27.07.2026) und die FAQ (v1.4, 04.09.2026) sind nicht rechtsverbindlich.
