Die Meldepflicht des Cyber Resilience Act, Artikel 14 der Verordnung (EU) 2024/2847, wird meist über ihre Uhren erklärt: 24 Stunden, 72 Stunden und ein Abschlussbericht. Die Uhren starten nur, wenn eines von zwei Dingen geschieht, und beide sind in der Verordnung enger definiert, als die meisten Zusammenfassungen nahelegen. Alles zu melden ist ebenso ein Versagen wie nichts zu melden: Es überflutet das CSIRT, sagt den Nutzern nichts und trainiert die Organisation darauf, ihr eigenes Verfahren zu ignorieren.

Hier sind die zwei Auslöser, wie der Text sie definiert, und die Grenze, die jeder zieht.

Auslöser eins: eine aktiv ausgenutzte Schwachstelle

Artikel 14 Absatz 1 verlangt vom Hersteller, „jede aktiv ausgenutzte Schwachstelle in dem Produkt mit digitalen Elementen, von der er Kenntnis erlangt“, zu melden.

Artikel 3 Nummer 42 definiert den Begriff: Eine aktiv ausgenutzte Schwachstelle ist „eine Schwachstelle, für die verlässliche Belege dafür vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemeigentümers in einem System ausgenutzt hat“.

Drei Worte tragen die Definition.

„Verlässliche Belege.“ Nicht der Schweregrad eines Scanners, nicht ein Machbarkeitsnachweis in einem Sicherheitsblog, nicht eine CVE mit einem angehängten Gerücht „in freier Wildbahn ausgenutzt“. Belege, dass die Ausnutzung stattgefunden hat, in einer Qualität, auf die Sie handeln würden. Die Leitlinien der Kommission vom 27. Juli 2026 setzen die Kenntnis bei hinreichender Gewissheit an: nicht das erste Gerücht, nicht die abgeschlossene Forensik.

„Ein böswilliger Akteur.“ Die Ausnutzung durch Ihre eigenen Penetrationstester, durch einen Forscher, der sie verantwortungsvoll gemeldet hat, oder durch einen Kunden, der seine eigene Installation testet, ist keine Ausnutzung durch einen böswilligen Akteur. Die Schwachstelle mag schwerwiegend sein; sie ist auf dieser Grundlage allein kein Auslöser.

„In einem System.“ Irgendeinem System, nicht nur dem Ihres Kunden. Verlässliche Belege, dass die Schwachstelle in Ihrem Produkt irgendwo von einem Angreifer ausgenutzt wurde, genügen; Sie warten nicht, bis einer Ihrer eigenen Nutzer getroffen wird.

Was draußen ist: theoretische Schwachstellen, nicht ausgenutzte Machbarkeitsnachweise, Schwachstellen aus Ihren eigenen Tests und Schwachstellen in Komponenten, die bekannt sind und behoben werden, für die aber keine Belege einer Ausnutzung vorliegen. Das ist Arbeit nach Anhang I Teil II, behandelt und offengelegt nach den Anforderungen an die Schwachstellenbehandlung, keine Meldung nach Artikel 14.

Auslöser zwei: ein schwerwiegender Vorfall mit Auswirkungen auf die Sicherheit des Produkts

Artikel 14 Absatz 3 verlangt die Meldung „jedes schwerwiegenden Sicherheitsvorfalls mit Auswirkungen auf die Sicherheit des Produkts mit digitalen Elementen“. Artikel 14 Absatz 5 sagt, wann ein Vorfall schwerwiegend ist:

(a) er beeinträchtigt die Fähigkeit eines Produkts mit digitalen Elementen, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder ist in der Lage, sie zu beeinträchtigen; oder (b) er hat zur Einschleusung oder Ausführung bösartigen Codes in einem Produkt mit digitalen Elementen oder in den Netz- und Informationssystemen eines Nutzers des Produkts geführt oder ist in der Lage, dazu zu führen.

Zwei Dinge fallen auf.

„Ist in der Lage.“ Beide Alternativen erfassen Vorfälle, die die Wirkung haben könnten, nicht nur solche, die sie hatten. Ein Vorfall, der eingedämmt wurde, bevor Daten verloren gingen, ist trotzdem schwerwiegend, wenn er zu dem Verlust in der Lage war.

Es geht um die Sicherheit des Produkts, nicht um die Ihres Unternehmens. Ein Einbruch in Ihre Firmen-E-Mail ist ein Vorfall, und nach NIS2 kann er meldepflichtig sein, aber ein Auslöser nach Artikel 14 ist er nur, wenn er Auswirkungen auf die Sicherheit des Produkts hat, das Sie in Verkehr bringen: Ihre Build-Pipeline, Ihren Update-Server, den Signaturschlüssel, das Cloud-Backend, von dem ein Produkt abhängt. Der Test ist, ob die Fähigkeit des Produkts, die Daten oder Funktionen seiner Nutzer zu schützen, beeinträchtigt ist oder ob bösartiger Code über den Vorfall das Produkt oder die Systeme seiner Nutzer erreichen könnte.

Die dritte Pflicht, die mit beiden kommt: Ihre Nutzer informieren

Artikel 14 Absatz 8: Nach Kenntnis eines der beiden Auslöser „informiert der Hersteller die betroffenen Nutzer des Produkts mit digitalen Elementen und gegebenenfalls alle Nutzer über diese Schwachstelle oder diesen Vorfall und, soweit erforderlich, über Risikominderungs- und Abhilfemaßnahmen, die die Nutzer ergreifen können, um die Auswirkungen abzumildern“, gegebenenfalls in einem strukturierten, maschinenlesbaren Format. Informiert der Hersteller die Nutzer nicht rechtzeitig, kann das CSIRT es an seiner Stelle tun.

Das ist die Pflicht, die die meisten Meldeverfahren vergessen. CSIRT und ENISA sind der eine Empfänger. Die Nutzer sind der andere, und der Weg, sie zu erreichen, der Wortlaut und das maschinenlesbare Format sind Dinge, die vor dem Tag zu entscheiden sind.

Nicht meldepflichtig ist trotzdem festzuhalten

Eine Schwachstelle oder ein Vorfall, der keine der beiden Definitionen erfüllt, wird nicht nach Artikel 14 gemeldet, aber die Feststellung, dass er sie nicht erfüllt, ist ein Nachweis, den man aufbewahren sollte: was geschah, warum es als nicht unter 3 Nummer 42 oder 14 Absatz 5 fallend beurteilt wurde, wer das beurteilt hat und wann. Ändern sich die Belege, beginnt die Kenntnis im Sinne von Artikel 14 dann, und der Nachweis zeigt, dass die Uhr beobachtet wurde. Das ist der Unterschied zwischen einem Unternehmen, das entschieden hat, nicht zu melden, und einem, das es nicht bemerkt hat.

Was zu tun ist

Schreiben Sie die beiden Definitionen wörtlich in das Vorfallsverfahren, mit den drei Fragen zu jeder: Liegen verlässliche Belege vor, für eine Ausnutzung durch einen böswilligen Akteur, in irgendeinem System; beeinträchtigt oder bedroht der Vorfall den Schutz sensibler Daten oder Funktionen durch das Produkt oder bösartigen Code im Produkt oder in den Systemen eines Nutzers. Benennen Sie, wer entscheidet, und halten Sie jede Entscheidung fest, auch das „Nein“. Dann die Uhren, an Ihr CSIRT und die ENISA, und die Nachricht an die Nutzer.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3 Nummer 42 (zitiert), Artikel 14 Absätze 1, 3, 5 (zitiert) und 8 (zitiert). Gelesen im Amtsblatt-Text auf EUR-Lex am 11. September 2026.
  • Leitlinien der Europäischen Kommission C(2026) 5252 vom 27. Juli 2026 zur Bedeutung der Kenntnis.

Das ist keine Rechtsberatung. Die beiden Definitionen sind zwei Sätze der Verordnung; sie gehören wörtlich in Ihr Verfahren, nicht aus dem Gedächtnis.