Beinahe-Vorfall

Ein Beinahe-Vorfall ist im Cyber Resilience Act (CRA) ein Ereignis, das die Sicherheit von Daten oder Diensten hätte beeinträchtigen können, dessen Eintritt aber verhindert wurde oder das gar nicht erst eingetreten ist. Artikel 3 Nummer 45 definiert den Begriff nicht selbst, sondern verweist auf Artikel 6 Nummer 5 der Richtlinie (EU) 2022/2555, die NIS-2-Richtlinie.

Dort lautet der Wortlaut: ein Ereignis, das die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der Dienste, die über Netz- und Informationssysteme angeboten werden beziehungsweise zugänglich sind, beeinträchtigt haben könnte, dessen Eintritt jedoch erfolgreich verhindert wurde beziehungsweise das nicht eingetreten ist.

Ein einziges Wort trennt ihn vom Vorfall

Die Definition des Sicherheitsvorfalls in Artikel 6 Nummer 6 derselben Richtlinie ist bis auf das Ergebnis wortgleich. Dort heißt es „beeinträchtigt“, hier „beeinträchtigt haben könnte … jedoch erfolgreich verhindert wurde“. Dieselben vier geschützten Eigenschaften, dieselben Datenarten, derselbe Kreis von Diensten.

Die Einordnung entscheidet sich also am Eintritt, nicht an der Schwere. Ein Angriff, der eine Schutzmaßnahme überwunden und danach Daten verändert hat, ist ein Sicherheitsvorfall, auch wenn der Schaden gering blieb. Ein Angriff, der an der Netztrennung gescheitert ist, bleibt ein Beinahe-Vorfall, selbst wenn er groß geworden wäre.

Nicht meldepflichtig

Artikel 14 kennt zwei Meldetatbestände: die aktiv ausgenutzte Schwachstelle und den schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt. Beinahe-Vorfälle kommen dort nicht vor. Für sie läuft keine 24-Stunden-Frist, keine 72-Stunden-Meldung und kein Abschlussbericht.

Das ist kein Versehen, sondern die bewusste Grenze der Meldepflichten: Gemeldet wird, was eingetreten ist.

Der freiwillige Meldeweg nach Artikel 15

Artikel 15 Absatz 2 öffnet einen zweiten Kanal. Hersteller und ausdrücklich auch andere natürliche oder juristische Personen können jeden Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit sowie Beinahe-Vorfälle, die zu einem solchen Vorfall hätten führen können, freiwillig einem als Koordinator benannten CSIRT oder der ENISA melden.

Zwei Details lohnen die Aufmerksamkeit. Erstens ist der freiwillige Kanal weiter gefasst als der verpflichtende: Er verlangt nicht, dass der zugrunde liegende Vorfall schwerwiegend gewesen wäre. Zweitens läuft er über dieselbe einheitliche Meldeplattform nach Artikel 16. Dort dürfen die CSIRTs verpflichtende Meldungen aber vorrangig bearbeiten.

Zeitlich gilt Artikel 15 erst ab dem vollständigen Geltungsbeginn der Verordnung am 11. Dezember 2027. Vorgezogen sind nach Artikel 71 Absatz 2 nur Artikel 14, der ab dem 11. September 2026 anzuwenden ist, und Kapitel IV (Artikel 35 bis 51) zur Notifizierung von Konformitätsbewertungsstellen ab dem 11. Juni 2026.

Wohin eine solche Meldung geht

Eine freiwillige Meldung über einen Beinahe-Vorfall verlässt den CSIRT-Kreis nicht ohne Weiteres. Artikel 16 Absatz 3 verpflichtet die CSIRTs nur bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen dazu, die gemeldeten Informationen der zuständigen Marktüberwachungsbehörde zur Verfügung zu stellen. Beinahe-Vorfälle nennt die Vorschrift nicht.

Genutzt werden die Angaben vor allem statistisch: Aus den Meldungen nach Artikel 14 und Artikel 15 erstellt die ENISA alle 24 Monate einen technischen Bericht über aufkommende Trends der Cybersicherheitsrisiken bei Produkten mit digitalen Elementen. Sind die Informationen für das Management großflächiger Krisen von Bedeutung, kann sie diese zusätzlich an das Netzwerk EU-CyCLONe weitergeben.

Was der CRA offen lässt

Eine Pflicht, Beinahe-Vorfälle intern zu erfassen oder auszuwerten, enthält die Verordnung nicht. Weder Artikel 13 noch Anhang I erwähnen sie. Wer ein Register führt, tut das aus eigenem Interesse.

Die technische Voraussetzung dafür verlangt der CRA allerdings sehr wohl: Nach Anhang I Teil I Nummer 2 Buchstabe l müssen Produkte (auf Grundlage der Risikobewertung nach Artikel 13 Absatz 2 und soweit zutreffend) sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge bereitstellen, etwa des Zugangs zu Daten, Diensten oder Funktionen und der Änderungen daran, und den Nutzern dafür einen Opt-out-Mechanismus bieten. Ohne diese Protokolle bleibt ein verhinderter Angriff schlicht unsichtbar. Und die Frage, ob ein Vorfall eingetreten ist oder eben nicht, lässt sich dann im Ernstfall nicht binnen 24 Stunden beantworten.