Wie Hersteller ausgenutzte Schwachstellen und Sicherheitsvorfälle nach dem CRA unterscheiden

· Florian Hackel · Cyber-Security

Was die Meldepflicht nach Art. 14 CRA auslöst und wie Sie die beiden Tatbestände auseinanderhalten

Seit dem 11. September 2026 gilt Art. 14 des Cyber Resilience Act (CRA). Hersteller von Produkten mit digitalen Elementen müssen seitdem aktiv ausgenutzte Schwachstellen (Abs. 1) und schwerwiegende Sicherheitsvorfälle (Abs. 3) melden, auch für Produkte, die vor dem Stichtag in Verkehr gebracht wurden (Art. 69 Abs. 3 CRA). Für beide gilt dieselbe Taktung mit Frühwarnung binnen 24 und Meldung binnen 72 Stunden. Den Ablauf haben wir im Beitrag „Cyber Resilience Act – Die Meldepflichten“ beschrieben.

Die Abgrenzung ist keine akademische Übung. Die Tatbestände haben unterschiedliche Voraussetzungen, und wer falsch einordnet, übersieht im ungünstigsten Fall eine Meldepflicht.

Eine aktiv ausgenutzte Schwachstelle ist ein Fehler im Produkt selbst

Schwachstelle ist nach Art. 3 Nr. 40 CRA eine „Schwäche, Anfälligkeit oder Fehlfunktion eines Produkts mit digitalen Elementen“, die ausgenutzt werden kann. Der Begriff ist produktbezogen. Aktiv ausgenutzt ist sie, wenn verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat (Art. 3 Nr. 42 CRA). Wo das geschah, spielt keine Rolle. Auch der Angriff auf Ihren Router im Netz einer Kundin ist eine Ausnutzung in Ihrem Produkt.

Eine Erheblichkeitsschwelle gibt es nicht. Jede belegte Ausnutzung zählt, die bloße Möglichkeit aber nicht. Ein veröffentlichter Exploit oder bloße Portscans reichen nach Auffassung des BSI nicht aus. Lücken, die ein Prüflabor oder ein Bug-Bounty-Programm ohne Hinweis auf böswillige Ausnutzung aufdeckt, sind ebenfalls nicht meldepflichtig (Erwägungsgrund 68 CRA).

Der Angriff auf fremde Produkte mit derselben Komponente verpflichtet Sie nicht

Moderne Produkte bestehen zu großen Teilen aus fremden Bibliotheken. Wird eine Lücke in einer solchen Bibliothek bei einem anderen Hersteller ausgenutzt, müssen nach Auffassung der Kommission nicht alle melden, die sie verbauen. Meldepflichtig ist nur, wer von einer Ausnutzung im eigenen Produkt Kenntnis erlangt (Leitlinien C(2026) 5252, Rn. 218). Ist die Lücke im eigenen Produkt gar nicht ausnutzbar, etwa weil der betroffene Code in Ihrem Produkt über den ausgenutzten Angriffsvektor nicht erreichbar ist, entfällt die Pflicht ebenfalls.

Wir halten diese Lesart für überzeugend, weil der CRA die Schwachstelle an das einzelne Produkt knüpft. Verbindlich ist sie nicht. Die Leitlinien hat die Kommission im Juli 2026 nur als Entwurf gebilligt. Die Kenntnis über die Ausnutzung bei Dritten sollte deshalb sofort die Prüfung auslösen, ob auch Ihre eigenen Installationen betroffen sind.

Ein schwerwiegender Sicherheitsvorfall betrifft das Umfeld des Produkts

Der zweite Tatbestand setzt keinen Fehler im Produkt voraus. Ein Sicherheitsvorfall ist jedes Ereignis, das Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Diensten beeinträchtigt (Art. 3 Nr. 43 CRA; vergleichbar auch Art. 6 Nr. 6 NIS2-Richtlinie). Schwerwiegend ist er, wenn er die Fähigkeit des Produkts gefährdet, sensible oder wichtige Daten oder Funktionen zu schützen, oder zur Einschleusung oder Ausführung von Schadcode im Produkt oder im Netz von Nutzer:innen führen kann (Art. 14 Abs. 5 CRA).

Typisch ist nach Erwägungsgrund 68 CRA ein Vorfall, der „die Entwicklungs-, Herstellungs- oder Wartungsprozesse des Herstellers“ beeinträchtigt, etwa Schadcode im Update-Kanal. Ein böswilliger Akteur ist nicht erforderlich (vgl. Art. 14 Abs. 4 lit. a CRA). Umgekehrt ist Ransomware im Unternehmensnetz ohne Auswirkung auf das Produkt nach Auffassung des BSI kein schwerwiegender Sicherheitsvorfall im Sinne des CRA.

Die Abgrenzung hängt an der Frage, wo der Fehler liegt

Oft heißt es, jeder Vorfall beruhe auf einer Schwachstelle. Der CRA meint mit Schwachstelle aber nur Fehler des Produkts, keine organisatorischen Schwächen beim Hersteller und keine Lücken in fremder Software seiner Infrastruktur. Liegt der ausgenutzte Fehler im ausgelieferten Produkt, prüfen Sie Art. 14 Abs. 1 CRA. Liegt die Ursache etwa in Entwicklung, Build-Prozess, Signatur, Fertigung oder Update-Verteilung, prüfen Sie Art. 14 Abs. 3 CRA.

MerkmalAktiv ausgenutzte Schwachstelle (Art. 14 Abs. 1 CRA)Schwerwiegender Sicherheitsvorfall (Art. 14 Abs. 3 CRA)
BezugspunktFehler des Produkts selbstEreignis mit Auswirkung auf die Produktsicherheit, typischerweise in den Prozessen des Herstellers
Böswilliger Akteurzwingend erforderlichnicht erforderlich
Schwellejede belegte Ausnutzungnur schwerwiegende Vorfälle nach Art. 14 Abs. 5 CRA
Ortjedes System, in dem das Produkt eingesetzt wirdtypischerweise die Sphäre des Herstellers

So ordnen Sie typische Fälle ein

Jemand aus dem Entwicklungsteam fällt auf eine Phishing-Mail herein, Unbekannte schleusen mit den Zugangsdaten Schadcode in das nächste Release. Das Produkt war fehlerfrei, es liegt ein schwerwiegender Sicherheitsvorfall vor. Dasselbe gilt, wenn ein privater Signaturschlüssel versehentlich in einem öffentlichen Repository landet, obwohl niemand böswillig handelt.

Dringen Angreifer:innen über eine Lücke im VPN-Gateway Ihres Unternehmens ein und manipulieren Ihre Updates, ist das für Sie ein schwerwiegender Sicherheitsvorfall. Für den Hersteller des Gateways kann zugleich eine aktiv ausgenutzte Schwachstelle seines Produkts vorliegen.

Schwierig wird es, wenn Angreifer:innen einen Fehler in Ihrer eigenen Update-Komponente nutzen, um Schadcode zu verteilen. Dann kommen beide Tatbestände in Betracht, die Meldeplattform verlangt aber je Meldung die Wahl einer Kategorie. Wie hier zu melden ist, regeln weder der CRA noch Kommission oder ENISA. Prüfen Sie beide Tatbestände getrennt und dokumentieren Sie die Entscheidung.

Eine dokumentierte Erstbewertung sichert die Fristen

Die 24 Stunden laufen ab Kenntnis. Diese besteht nach Auffassung der Kommission, sobald der Hersteller nach einer unverzüglichen Erstbewertung hinreichende Gewissheit hat (Leitlinien, Rn. 213). Hinauszögern dürfte den Fristbeginn nicht verschieben. Legen Sie deshalb vorab fest, wer verdächtige Ereignisse bewertet, und dokumentieren Sie den Zeitpunkt der Kenntnis und die Zuordnung zum Tatbestand. Feste Guidelines und Prozessmuster sind diesbezüglich das Mittel der Wahl. Liegen diese zum Zeitpunkt der Meldepflicht vor, sind die Fristen oftmals noch ohne überhöhtes Stresslevel einzuhalten. Müssen diese im Falle eines Vorfalls erst erstellt werden, sind die genannten Fristen unserer Einschätzung nach kaum zu halten.

Verstöße gegen Art. 14 CRA können Geldbußen von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes nach sich ziehen, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2 CRA).

Autor:inFlorian HackelRechtsanwalt und Fachanwalt für IT-Recht

Konkretes Anliegen?
Lassen Sie uns reden.

Mehr Beiträge
News & Blog
Telefon
+49 931 6639232
E-Mail
info@jun.legal