Cyber Resilience Act: Die 24-Stunden-Meldekette ab September 2026

Der erste Hinweis auf einen CRA-Meldefall trägt selten den richtigen Betreff. Er kommt als Kundenmeldung mit auffälligen Logzeilen, als Warnung eines Bibliotheksherstellers oder über einen Sicherheitsforscher. Vielleicht existiert schon ein Patch. Was meist fehlt, ist der Bezug zum eigenen Produkt.

Ab dem 11. September 2026 bekommt diese Unsicherheit eine Frist. Dann wird Artikel 14 des Cyber Resilience Act anwendbar. Hersteller erfasster Produkte mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gestuft melden. Die erste Frühwarnung ist unverzüglich, spätestens jedoch binnen 24 Stunden fällig. Das klingt nach knapper Bürokratie. Tatsächlich prüft die Frist, ob ein Unternehmen eine technische Warnung rasch in belastbares Produktwissen übersetzen kann. Der eigentliche Druck entsteht nicht am Ende der Frist, sondern in den ersten Minuten, solange Herkunft und Tragweite des Signals noch unklar sind.

Wann aus einem Hinweis ein Meldefall wird

Für eine aktiv ausgenutzte Schwachstelle verlangt der CRA verlässliche Nachweise dafür, dass ein böswilliger Akteur sie ohne Erlaubnis eines Systemeigentümers ausgenutzt hat. Bei einer Fremdkomponente reicht daher nicht die Nachricht, dass irgendwo Angriffe beobachtet wurden. Der Hersteller muss klären, ob die betroffene Version in seinem Produkt steckt, ob der verwundbare Code im ausgelieferten Aufbau erreichbar ist und ob die Ausnutzung dieses Produkt betrifft. Die aktuelle Leitlinie der Europäischen Kommission zieht genau an dieser Stelle eine Grenze zwischen einer allgemein verwundbaren Komponente und einer aktiv ausgenutzten Schwachstelle im eigenen Produkt.

Ein CVE-Eintrag ist deshalb noch keine CRA-Meldung.

Der zweite Meldeweg betrifft schwerwiegende Sicherheitsvorfälle. Der CRA erfasst Vorfälle, die die Fähigkeit des Produkts tatsächlich beeinträchtigen oder beeinträchtigen können, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Ebenfalls erfasst sind Vorfälle, die zur Einführung oder Ausführung von Schadcode im Produkt oder in Netz- und Informationssystemen eines Nutzers geführt haben oder führen können. Ein böswilliger Ursprung ist für diesen Vorfallstyp nicht zwingend; gerade die Frühwarnung soll erkennen lassen, ob rechtswidrige oder böswillige Handlungen vermutet werden.

Wann die Uhr beginnt, entscheidet sich nach einer unverzüglichen Erstbewertung. Die nicht bindende Kommissionsleitlinie spricht von einem hinreichenden Grad an Sicherheit. Zwischen dem ersten Signal und diesem Befund darf also eine Prüfung liegen, aber kein unbegrenzter Warteraum. Eingang, geprüfte Evidenz und Entscheidung brauchen verlässliche Zeitstempel. Eine spätere Managementfreigabe verschiebt den Kenntniszeitpunkt nicht. Wer lediglich den Zeitpunkt der endgültigen Freigabe protokolliert, dokumentiert deshalb nicht den Beginn der Frist, sondern nur den eigenen Verwaltungsablauf.

Der frühe Stichtag reicht bis in alte Produktlinien

Der Cyber Resilience Act ist seit dem 10. Dezember 2024 in Kraft, doch seine Pflichten beginnen nicht gleichzeitig. Artikel 14 wird am 11. September 2026 anwendbar. Der Großteil der Anforderungen an Entwicklung, Produktdokumentation und Konformität folgt erst am 11. Dezember 2027. Hersteller müssen ihren Vorfallsprozess deshalb früher betriebsbereit machen als das gesamte CRA-Programm. Umgekehrt wäre es falsch, den Septembertermin als vollständige CRA-Konformität auszugeben.

Erfasst sind Produkte mit digitalen Elementen, die unter die Verordnung fallen und auf dem Unionsmarkt bereitgestellt werden. Dazu können Software, vernetzte Hardware oder separat vermarktete Komponenten gehören. Nicht jede intern entwickelte Anwendung ist automatisch ein CRA-Produkt; maßgeblich bleiben die gesetzliche Definition, die Marktrolle des Unternehmens und mögliche Ausnahmen.

Für die Meldekette ist vor allem der Blick zurück bedeutsam. Nach der Kommissionsleitlinie gilt Artikel 14 auch für erfasste Produkte, die vor dem allgemeinen Anwendungsdatum in Verkehr gebracht wurden. Die Meldepflicht kann nach dieser Auslegung sogar über das Ende eines Supportzeitraums hinausreichen. Ältere Versionen werden dadurch nicht rückwirkend in jeder Hinsicht CRA-pflichtig. Sie dürfen aber nicht aus dem betrieblichen Gedächtnis verschwinden. Wenn ein Produktarchiv mit dem Vertriebsende nur noch aus unverbundenen Dateien besteht, lässt sich später kaum sicher beurteilen, welche Kundeninstallation eine gefährdete Komponente enthält.

Die erste Meldung darf unfertig, aber nicht beliebig sein

Die Frühwarnung markiert den Anfang der Untersuchung.

Innerhalb von 24 Stunden geht es um einen belastbaren Zwischenstand, nicht um fertige Forensik oder einen bereits ausgelieferten Patch. Die ausführlichere Meldung folgt ebenfalls unverzüglich, spätestens 72 Stunden nach dem Kenntniszeitpunkt, und ergänzt Produktbezug, erste Bewertung und bereits ergriffene Maßnahmen. Danach unterscheiden sich die Fristen: Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme fällig. Bei einem schwerwiegenden Sicherheitsvorfall läuft die Frist einen Monat ab der 72-Stunden-Meldung. Das koordinierende CSIRT kann zusätzlich einen Zwischenbericht verlangen.

Diese Staffelung erlaubt, Wissen schrittweise zu ergänzen. Sie erlaubt keine Spekulation. Vermutungen müssen als solche erkennbar bleiben, jede Fassung braucht dieselbe Vorgangskennung. Ändert sich die Menge der betroffenen Versionen, gehört auch diese Korrektur nachvollziehbar in die Fallakte. So bleibt später sichtbar, welcher Stand zu welchem Zeitpunkt vertretbar war. Auch ein später widerlegter Verdacht darf nicht aus der Chronologie verschwinden; gerade die Korrektur zeigt, dass der Befund überprüft und nicht nur fortgeschrieben wurde.

Übermittelt wird einmal über ENISAs Single Reporting Platform an das zuständige koordinierende CSIRT und grundsätzlich zugleich an ENISA. Das empfangende CSIRT leitet die Meldung im Regelfall unverzüglich an die CSIRTs der Mitgliedstaaten weiter, in denen das Produkt bereitgestellt wurde. Nur besonders außergewöhnliche Sicherheitslagen können einen Aufschub rechtfertigen. Diese enge Ausnahme ist nicht mit dem allgemeinen Wunsch zu verwechseln, einen Vorfall möglichst lange vertraulich zu halten.

Das Gedächtnis des Produkts

Unter Zeitdruck scheitert eine Bewertung selten an der Suche nach der Schwachstellenkennung. Schwieriger ist die Rückwärtsfrage: Welche ausgelieferte Produktversion enthält genau die betroffene Bibliothek? In einer jungen Produktlinie führt die Antwort vielleicht direkt aus einem reproduzierbaren Build. Bei älteren Releases beginnt dagegen eine Spurensuche über abgelöste Buildserver, archivierte Repositories und Tabellen, deren damalige Bearbeiter längst andere Aufgaben haben. Entscheidend ist nicht, was heute im Hauptzweig liegt, sondern was tatsächlich ausgeliefert wurde.

Eine versionsgebundene Software Bill of Materials kann diese Suche verkürzen, weil sie Komponenten mit einem Release verbindet. Sie belegt allerdings weder die Erreichbarkeit des verwundbaren Codes noch eine aktive Ausnutzung. VEX ergänzt die Stückliste um eine bewertete Aussage: betroffen, nicht betroffen, noch in Untersuchung oder behoben. Besonders wertvoll ist eine technische Begründung für „nicht betroffen“, etwa weil eine gefährdete Funktion im ausgelieferten Aufbau nicht erreichbar ist. Beide Werkzeuge ordnen Evidenz; die Meldeentscheidung nehmen sie dem Hersteller nicht ab.

Das Wissensproblem bleibt beim Hersteller.

Auch die allgemeine CRA-Anforderung an eine maschinenlesbare Software-Stückliste gehört grundsätzlich zum späteren Hauptpflichtenblock. Für Artikel 14 lohnt sich die Vorarbeit schon jetzt. Ein Hersteller, der Build, Komponentenstand und ausgelieferte Version dauerhaft miteinander verknüpft, kann eine Warnung schneller eingrenzen. Fehlt diese Verbindung, werden die ersten Stunden mit Rekonstruktion verbraucht – gerade dann, wenn der Sachverhalt ohnehin noch unscharf ist. Diese Verknüpfung ist kein neues Archivprojekt neben der Entwicklung. Sie sollte aus dem normalen Build- und Freigabeprozess entstehen und mit dem ausgelieferten Artefakt erhalten bleiben.

Melden, beheben und informieren bleiben ein Vorgang

Mit der Frühwarnung beginnt die nächste Phase des Vorfalls. Die technische Arbeit läuft weiter.

Während die regulatorische Meldung fortgeschrieben wird, muss das Produktteam den Vorfall eindämmen und eine tragfähige Abhilfe entwickeln. Artikel 14 verlangt außerdem, betroffene Nutzer und, soweit angemessen, alle Nutzer unverzüglich zu informieren. Das bedeutet nicht, ungepatchte technische Details unterschiedslos zu veröffentlichen. Eine gute Sicherheitsinformation benennt betroffene Versionen und erklärt den sicheren Updateweg oder eine vorläufige Minderungsmaßnahme. Intern braucht der Fall eine klare Führung: Das Produktsicherheitsteam bewertet den Eingang, die Entwicklung untersucht Reichweite und Abhilfe. Produktverantwortliche halten den Bezug zu den ausgelieferten Versionen, während die regulatorische Einordnung parallel läuft. Wer die Plattform bedient, benötigt denselben Faktenstand und eine benannte Vertretung.

ENISA bereitet die Single Reporting Platform nach dem veröffentlichten Stand vom August für den 11. September 2026 vor. Vorgesehen ist die Anmeldung über EU Login; eine API zur automatisierten Einreichung ist zunächst nicht geplant. ENISA rät derzeit dazu, das EU-Login-Konto vorzubereiten, die Registrierung in der Plattform aber erst bei einem konkreten Meldefall anzustoßen. Weil sich die Betriebshinweise noch ändern können, zählen im Ernstfall die aktuellen Vorgaben und nicht ein alter Screenshot aus dem Prozesshandbuch.

Der Name Single Reporting Platform bezieht sich auf die CRA-Meldung. Andere gesetzliche oder sektorale Meldewege werden dadurch nicht automatisch erfüllt.

Ob die Organisation vorbereitet ist, zeigt ein Probelauf außerhalb des Meldesystems. Ein Lieferant meldet am Wochenende die aktive Ausnutzung einer Bibliothek, die in mehreren Produktgenerationen vorkommen könnte. Der zuständige Entwickler ist nicht erreichbar, ein Kunde hat unvollständige Logdaten geschickt. Nun muss das Team die betroffenen Builds eingrenzen und den Kenntniszeitpunkt begründen, während die technische Untersuchung weiterläuft. Dabei wird schnell sichtbar, ob alte Releases auffindbar sind und ob die Vertretung funktioniert. Der Probelauf endet deshalb nicht mit einem ausgefüllten Entwurf, sondern erst dann, wenn die nachfolgende Untersuchung denselben Fall ohne Informationsbruch übernehmen kann.

Die knappe Frist lässt sich nicht mit hektischerem Arbeiten beherrschen. Sie verlangt geordnetes Produktwissen und einen Entscheidungsweg, der auch unter Unsicherheit trägt. Welche Pflichten im Einzelfall gelten, hängt von Produkt und Marktrolle ab. Der betriebliche Maßstab ist dennoch klar: Vom ersten Signal bis zur belastbaren Entscheidung darf kein organisatorisches Vakuum liegen.