CRA Meldepflichten: Fristen, Empfänger und Praxis-Vorbereitung

Der 11. September 2026 war das erste scharfe Datum unter dem Cyber Resilience Act (CRA). Seit 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 seitdem praktisch beherrschen. Sie sind ein fester Baustein im Anforderungsrahmen, den der Cyber Resilience Act insgesamt setzt.

Inhalt

1. Was die CRA-Meldepflichten verlangen
2. Meldepflichtige Ereignisse: Schwachstellen und Sicherheitsvorfälle
3. Das dreistufige Meldeschema und seine Fristen
4. Wann die Meldefrist zu laufen beginnt
5. Empfänger: CSIRT und ENISA über die einheitliche Meldeplattform
6. Information der betroffenen Nutzer
7. Erleichterungen für Kleinst- und Kleinunternehmen
8. Praxis-Vorbereitung für die Meldepflicht

Was die CRA-Meldepflichten verlangen

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). Dazu zählt eine Software aber nur, wenn beides zutrifft: Ohne diese Datenverarbeitung könnte das Produkt eine seiner Funktionen nicht mehr erfüllen, und der Hersteller hat die Software selbst entworfen und entwickelt oder sie unter seiner Verantwortung nach eigenen Vorgaben bauen lassen. Für die Einordnung spielt es keine Rolle, wer sie betreibt und auf welchen Servern sie läuft. Eine lizenzierte Standardlösung eines Dienstleisters erfüllt die zweite Bedingung nicht.

Eine Fernwartungsinfrastruktur ist deshalb nur dann eine Fernverarbeitungslösung, wenn sie eine Funktion des Produkts trägt und der Hersteller sie selbst oder in seinem Auftrag entwickelt hat. Bei einem fremdentwickelten Backend ist er trotzdem nicht aus der Pflicht: Er muss das Risiko auf Produktebene abfangen, etwa indem das Produkt Fernbefehle kryptografisch authentifiziert, Konfigurationsänderungen auf Integrität prüft und bei auffälligem Verhalten Alarm auslöst. Erfasst sind nur die Softwarebestandteile, die die Fernverarbeitung für das Produkt ausführen, nicht die übrige IT des Herstellers. CI/CD-Pipelines und die Verteilung von Sicherheitsupdates an Edge-Standorte nennen die Leitlinien ausdrücklich als Gegenbeispiele. Ob ein Vorfall meldepflichtig ist, entscheidet dagegen seine Auswirkung auf die Sicherheit des Produkts, unabhängig davon, in welchem System er aufgetreten 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.

1. 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.
2. 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.
3. 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 helfen die Leitlinien der Europäischen Kommission zur Anwendung des Cyber Resilience Act. Sie binden Wirtschaftsakteure nach eigenen Angaben nicht; eine verbindliche Auslegung kann allein der Gerichtshof der Europäischen Union geben. Sie zeigen jedoch, 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 in den Leitlinien 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 wird über die einheitliche Meldeplattform, die die ENISA als Single Reporting Platform (SRP) betreibt.

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 seit dem 11. September 2026 in Betrieb, also seit dem Tag, an dem die Meldepflichten gelten. Die ENISA hat zunächst eine erste Ausbaustufe freigeschaltet und will die Funktionen in den kommenden Monaten erweitern; vorausgegangen war eine Testphase.

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.

Neben diesem Ermessen aus Artikel 14 Absatz 8 steht eine eigene Pflicht: Nach Anhang I Teil II Nummer 4 veröffentlicht der Hersteller Informationen über die behobene Schwachstelle, sobald er die Sicherheitsaktualisierung bereitgestellt hat. In begründeten Fällen darf er sie aufschieben, bis die Nutzer den Patch anwenden konnten, sofern die Risiken der Veröffentlichung schwerer wiegen als der Sicherheitsgewinn. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, erfasst diese Veröffentlichungspflicht nicht; die Meldepflichten aus Artikel 14 treffen sie dagegen seit dem 11. September 2026.

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; für diese Unternehmensgrößen entfällt 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 für die Meldepflicht

Seit dem 11. September 2026 brauchen Hersteller die organisatorischen Voraussetzungen, 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.