Der 11. September 2026 ist das erste scharfe Datum unter dem Cyber Resilience Act (CRA). Ab diesem Tag gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, über ein Jahr vor der vollständigen Anwendbarkeit am 11. Dezember 2027.
Wer ein Produkt mit digitalen Elementen auf dem Markt hat, muss die Meldewege bis dahin praktisch beherrschen. Sie sind ein fester Baustein im Anforderungsrahmen, den der Cyber Resilience Act insgesamt setzt.
Die CRA Meldepflichten verpflichten Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei ihren Produkten mit digitalen Elementen zu melden. Jede Meldung geht gleichzeitig an ein koordinierendes CSIRT und an die ENISA, gestaffelt über drei Stufen mit festen Fristen. Geregelt ist die Meldepflicht des Cyber Resilience Act in Artikel 14 der Verordnung (EU) 2024/2847.
Meldepflichtige Ereignisse: Schwachstellen und Sicherheitsvorfälle
Der CRA unterscheidet zwei auslösende Ereignisse, und die Abgrenzung entscheidet darüber, welche Fristen gelten:
- Aktiv ausgenutzte Schwachstelle: eine Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners in einem System ausgenutzt hat. Entscheidend ist nicht die theoretische Ausnutzbarkeit, sondern der belegte tatsächliche Angriff. Sobald ein Hersteller von einer solchen Schwachstelle in seinem Produkt Kenntnis erlangt, greift die Meldepflicht.
- Schwerwiegender Sicherheitsvorfall: ein Vorfall, der sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Schwerwiegend ist er auch, wenn er zur Einführung oder Ausführung von böswilligem Code im Produkt selbst oder im Netz- und Informationssystem eines Nutzers geführt hat oder führen kann.
Der entscheidende Unterschied liegt im Bezugspunkt. Eine Schwachstelle ist ein Defekt im Produkt selbst, also im Code, in der Konfiguration oder im Design; aktiv ausgenutzt ist sie erst, wenn verlässliche Nachweise einen realen Angriff belegen, nicht schon bei theoretischer Ausnutzbarkeit. Ein Sicherheitsvorfall ist dagegen ein sicherheitsrelevantes Ereignis mit Bezug zum Produkt. Er kann auch herstellerseitige Infrastruktur betreffen, die für die Produktsicherheit kritisch ist.
Ein typisches Beispiel für eine Schwachstelle ist ein Pufferüberlauf (Buffer Overflow) in der Routine, die eingehende Netzwerkpakete validiert. Über diese Lücke kann ein Angreifer eigenen Code ausführen und das System übernehmen (Remote Code Execution). Aktiv ausgenutzt ist die Schwachstelle, sobald belegte Hinweise zeigen, dass sie tatsächlich angegriffen wird. Der Defekt sitzt hier im Produkt selbst.
Ein schwerwiegender Sicherheitsvorfall sieht anders aus. Kommen die Signaturschlüssel (Code-Signing-Keys) des Herstellers abhanden oder werden sie kompromittiert, ist die Authentizität und Integrität von Firmware- oder Software-Updates nicht mehr gewährleistet. Ein Angreifer könnte dann signierten und damit vom Produkt akzeptierten Schadcode ausliefern. Ein zweites typisches Beispiel ist die Kompromittierung der Fernwartungsinfrastruktur, über die der Hersteller auf die ausgelieferten Produkte zugreift. In beiden Fällen ist nicht das Produkt selbst defekt, sondern ein Ereignis betrifft herstellerseitige Systeme, die für die Produktsicherheit kritisch sind.
Beide Meldepflichten bestehen eigenständig. Eine aktiv ausgenutzte Schwachstelle und ein schwerwiegender Sicherheitsvorfall können zusammentreffen, müssen es aber nicht. Die Meldepflicht erfasst dabei das Produkt als Ganzes einschließlich zugehöriger Fernverarbeitungslösungen (Remote Data Processing Solutions). Die genannte Fernwartungskomponente ist eine solche Fernverarbeitungslösung, sodass auch ein Sicherheitsvorfall in einer vom Hersteller betriebenen Cloud- oder Fernwartungskomponente meldepflichtig ist.
Das dreistufige Meldeschema und seine Fristen
Für beide Ereignisarten gilt ein gestaffeltes Meldeschema mit drei Stufen. Die ersten beiden Stufen sind identisch, die dritte unterscheidet sich.
- Die erste Stufe ist eine Frühwarnung. Sie ist unverzüglich zu übermitteln, in jedem Fall aber innerhalb von 24 Stunden nach Kenntniserlangung. Diese 24-Stunden-Frist verlangt zunächst nur knappe Angaben: bei der Schwachstelle die Mitgliedstaaten, in deren Hoheitsgebiet das betroffene Produkt nach Kenntnis des Herstellers bereitgestellt wurde, beim Vorfall zumindest die Angabe, ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht.
- Die zweite Stufe ist eine detaillierte Meldung innerhalb von 72 Stunden nach Kenntniserlangung. Sie enthält allgemeine Informationen über das betroffene Produkt, über die Art der Ausnutzung beziehungsweise des Vorfalls sowie über bereits ergriffene Korrektur- oder Risikominderungsmaßnahmen.
- Die dritte Stufe ist der Abschlussbericht, und hier liegt der zentrale Unterschied zwischen beiden Ereignisarten. Bei einer Schwachstelle ist der Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht, vorzulegen. Die Frist knüpft also an die Bereitstellung der Korrekturmaßnahme an. Bei einem Sicherheitsvorfall ist der Abschlussbericht hingegen innerhalb eines Monats nach der detaillierten 72-Stunden-Meldung vorzulegen. Hier läuft die Frist ab der zweiten Meldestufe, nicht ab der Bereitstellung einer Korrektur.
Wann die Meldefrist zu laufen beginnt
Alle drei Fristen knüpfen an denselben Zeitpunkt an: die Kenntniserlangung. Entscheidend ist daher, ab wann ein Hersteller als in Kenntnis gilt. Hier hilft der Leitlinien-Entwurf der Europäischen Kommission zur Anwendung des Cyber Resilience Act. Dieser Entwurf ist noch nicht final angenommen und nach eigenen Angaben nicht rechtsverbindlich; eine verbindliche Auslegung kann allein der Gerichtshof der Europäischen Union geben. Er zeigt aber, wie die Kommission den Begriff der Kenntniserlangung versteht.
Nach den Leitlinien gilt ein Hersteller noch nicht als in Kenntnis, wenn ihn lediglich ein Hinweis auf ein verdächtiges Ereignis erreicht, sei es intern, durch einen Kunden, eine Behörde oder ein Medium. Erst nach einer initialen Bewertung, die mit hinreichender Gewissheit ergibt, dass tatsächlich eine aktiv ausgenutzte Schwachstelle vorliegt oder ein schwerwiegender Sicherheitsvorfall eingetreten ist, beginnt die 24-Stunden-Frist zu laufen. Der Fristbeginn hängt damit von den Umständen des Einzelfalls ab. Mal ist von Anfang an klar, dass eine Schwachstelle ausgenutzt wird, mal braucht die Abklärung Zeit.
Diese Erstbewertung ist kein Freibrief für Verzögerung. Die Leitlinien verlangen, dass sie zügig erfolgt, besonders bei einem erkennbar erheblichen Risiko. Damit verschiebt sich der eigentliche Engpass nach vorn: Ohne vorbereitete Prozesse ist schon diese rasche Erstbewertung kaum zu leisten. Der erste Tag nach Bekanntwerden eines Verdachts ist der falsche Zeitpunkt, um Zuständigkeiten und Bewertungswege zu klären.
Viele Hersteller unterliegen für denselben Vorfall zugleich Meldepflichten aus anderen Rechtsakten, etwa der NIS-2-Richtlinie. Die Kommission richtet den Begriff der Kenntniserlangung im Leitlinien-Entwurf bewusst an der NIS-2-Durchführungsverordnung und an den Datenschutz-Leitlinien zur Meldung von Datenschutzverletzungen aus, um die Auslegung kohärent zu halten. Wer NIS-2-pflichtig ist, sollte prüfen, ob zusätzliche Meldewege bestehen.
Empfänger: CSIRT und ENISA über die einheitliche Meldeplattform
Die Schwachstellenmeldung nach CRA geht nie an nur einen Empfänger. Der Hersteller meldet eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA.
Übermittelt werden soll künftig über die einheitliche Meldeplattform, die die ENISA als Single Reporting Platform (SRP) aufbaut und betreiben wird.
Die SRP ist als zentraler Single Entry Point konzipiert. Hersteller melden einen Vorfall nur einmal, statt jede zuständige nationale Behörde einzeln zu benachrichtigen. Die Plattform leitet die Meldung automatisch an das zuständige Koordinator-CSIRT und gleichzeitig an die ENISA weiter. Das Koordinator-CSIRT verteilt sie bei Bedarf an weitere zuständige CSIRTs in den Mitgliedstaaten, in denen das Produkt bereitgestellt ist, sowie an die Marktüberwachungsbehörden.
Die Plattform ist noch nicht in Betrieb, sondern im Aufbau. Nach Ankündigung der ENISA soll sie zum 11. September 2026 betriebsbereit sein, also genau zu dem Tag, an dem die Meldepflichten gelten. Vor diesem Stichtag ist eine Testphase vorgesehen.
Welches CSIRT zuständig ist, hängt von der Hauptniederlassung in der Union ab. Maßgeblich ist nach Artikel 14 Absatz 7 der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Lässt sich kein solcher Mitgliedstaat bestimmen, gilt der mit der höchsten Beschäftigtenzahl in der Union.
Für Hersteller ohne Hauptniederlassung in der Union gibt es eine feste Reihenfolge:. Zuständig ist dann das CSIRT des Mitgliedstaats, in dem der Bevollmächtigte niedergelassen ist, der für die meisten Produkte des Herstellers handelt. Ist kein Bevollmächtigter bestimmbar, folgt der Mitgliedstaat des Einführers, der die meisten Produkte in Verkehr bringt, danach der des Händlers mit der größten Marktbereitstellung und zuletzt der Mitgliedstaat, in dem sich die meisten Nutzer befinden. Diese Kaskade betrifft besonders Hersteller aus Drittstaaten, die ihre Produkte über europäische Partner vertreiben.
Information der betroffenen Nutzer
Die Meldung an Behörden ersetzt nicht die Information der Nutzer. Der Hersteller informiert die betroffenen und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall, sobald er davon Kenntnis erlangt hat. Erforderlichenfalls weist er auf Risikominderungs- und Korrekturmaßnahmen hin, die die Nutzer selbst ergreifen können, um die Auswirkungen zu mindern. Wo es sich anbietet, soll das in einem strukturierten, maschinenlesbaren Format geschehen.
Versäumt es der Hersteller, die Nutzer rechtzeitig zu informieren, können die als Koordinatoren benannten CSIRTs die Information selbst übernehmen, sofern sie das für verhältnismäßig und erforderlich halten. Für Betreiber vernetzter Maschinen ist die Nutzerinformation oft sicherheitsrelevant, weil sie erst die Grundlage für vorübergehende Schutzmaßnahmen schafft, etwa das Abschalten eines Fernzugangs.
Die Leitlinien der Kommission legen nahe, dass diese Pflicht nicht zwingend eine öffentliche Bekanntmachung bedeutet. Wo angemessen, dürfen Hersteller die Weitergabe detaillierter Informationen zunächst auf die unmittelbar betroffenen Nutzer oder Kunden beschränken, besonders bei Produkten in sensiblen oder kritischen Umgebungen, wo eine öffentliche Offenlegung technischer Details neue Angriffsflächen schaffen könnte. Nach ausreichender Behebung oder Eindämmung kann eine breitere Offenlegung angemessen sein; Zeitpunkt und Detailtiefe sollen dabei verhältnismäßig bleiben.
Erleichterungen für Kleinst- und Kleinunternehmen
Die kurze 24-Stunden-Frist trifft kleine Hersteller besonders hart, weil sie selten ein eingespieltes Lagezentrum vorhalten. Hier setzt eine Erleichterung an. Nach der Berichtigung des Cyber Resilience Act vom 2. Juli 2025 werden Kleinst- und Kleinunternehmen nicht mit Geldbußen belegt, wenn sie die 24-Stunden-Frist für die Frühwarnung versäumen. Die Pflicht zur Meldung selbst bleibt bestehen; entfällt für diese Unternehmensgrößen allein die schärfste Sanktion für ein reines Verfehlen der ersten Frist.
Die Hintergründe und weitere Klarstellungen ordnen wir im Beitrag zur Klarstellung zum CRA ein.
Praxis-Vorbereitung bis September 2026
Bis zum 11. September 2026 sollten Hersteller die organisatorischen Voraussetzungen schaffen, um die Fristen überhaupt einhalten zu können. Im Zentrum steht eine handlungsfähige Reaktionsstruktur. Ein Product Security Incident Response Team (PSIRT) oder eine vergleichbare Incident-Response-Funktion sorgt dafür, dass eine Meldung von einer zuständigen, klar benannten Person entgegengenommen, bewertet und fristgerecht weitergegeben wird, statt im Posteingang zu versanden. Der Aufbau eines solchen Teams orientiert sich am FIRST PSIRT Services Framework, das die nötigen Dienste und Rollen beschreibt.
Eng damit verbunden ist ein koordinierter Prozess zur Offenlegung von Schwachstellen. Wer einen solchen Coordinated Vulnerability Disclosure aufsetzt, kann sich an etablierten Verfahren orientieren, wie sie in den Normen ISO/IEC 29147 und 30111 beschrieben sind. Sie liefern den Rahmen für Eingang, Bearbeitung und Veröffentlichung von Schwachstelleninformationen und greifen damit direkt in die Meldekette nach Artikel 14.
Damit die 24-Stunden-Frist hält, braucht es klare Eskalationswege: Wer entscheidet, ob ein Ereignis meldepflichtig ist, wer formuliert die Frühwarnung, wer übermittelt sie über die Meldeplattform. Standardisierte Melde-Vorlagen für Frühwarnung, detaillierte Meldung und Abschlussbericht verkürzen die Reaktionszeit erheblich, weil sie die Pflichtangaben vorstrukturieren.
Ein Probelauf, der einen fiktiven Vorfall durch die drei Stufen führt, zeigt verlässlich, an welcher Stelle Zuständigkeiten oder Informationen fehlen. Wie diese Meldepflichten in das Gesamtbild der CRA-Herstellerpflichten eingebettet sind, behandeln wir gesondert.