Die Meldepflichten nach Artikel 14 des Cyber Resilience Act (CRA) gelten seit dem 11. September 2026. Sie greifen damit deutlich früher als die übrigen wesentlichen Verpflichtungen der Verordnung, die grundsätzlich ab dem 11. Dezember 2027 anwendbar werden. Für Hersteller von Produkten mit digitalen Elementen ist dies vor allem eine operative Herausforderung: Die Frist beginnt mit der Kenntniserlangung, nicht erst nach einer abgeschlossenen Ursachenanalyse.
Ein belastbarer Prozess muss daher technische Triage, Produktbewertung, rechtliche Einordnung, behördliche Meldung und Nutzerkommunikation unter erheblichem Zeitdruck verbinden. Die zentrale Frage lautet nicht, ob innerhalb von 24 Stunden sämtliche technischen Details vorliegen. Entscheidend ist, ob die Organisation einen belastbaren Erststand erfassen, die Meldeauslöser bewerten und eine fristgerechte Frühwarnung über die CRA Single Reporting Platform (SRP) absetzen kann.
Welche Ereignisse meldepflichtig sein können
Artikel 14 unterscheidet zwei Meldeauslöser. Erstens sind dem Hersteller bekannt gewordene aktiv ausgenutzte Schwachstellen in einem Produkt mit digitalen Elementen meldepflichtig. Eine solche Schwachstelle setzt verlässliche Anhaltspunkte voraus, dass ein böswilliger Akteur sie ohne Erlaubnis des Systeminhabers ausgenutzt hat. Ein bloßer Hinweis auf eine Schwachstelle oder eine theoretische Ausnutzbarkeit genügt dafür nicht.
Zweitens erfasst die Vorschrift schwerwiegende Sicherheitsvorfälle, die Auswirkungen auf die Sicherheit des Produkts haben. Ein Vorfall ist nach Artikel 14 Absatz 5 schwerwiegend, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit wichtiger oder sensibler Daten beziehungsweise Funktionen zu schützen. Ebenfalls erfasst sind Ereignisse, die zur Einbringung oder Ausführung von Schadcode im Produkt oder in Netz- und Informationssystemen eines Nutzers geführt haben oder führen können.
Diese Kategorien sollten in der Incident-Response-Praxis nicht vermischt werden. Beide führen zwar zu einer Frühwarnung binnen 24 Stunden, die späteren Meldeinhalte unterscheiden sich jedoch. Die Triage braucht deshalb zwei nachvollziehbare Bewertungspfade.
Kenntniserlangung als Startpunkt dokumentieren
Die gesetzliche Frist läuft ab Kenntniserlangung. Für den Prozess bedeutet das: Der Zeitpunkt darf nicht erst nachträglich aus Ticketverläufen, E-Mails oder Chatprotokollen rekonstruiert werden müssen. Er sollte bei Eingang eines belastbaren Hinweises revisionsfähig festgehalten werden.
Ein geeignetes Faktenlog kann mindestens enthalten:
- Informationsquelle, Eingangszeitpunkt und verantwortliche aufnehmende Stelle,
- erste belastbare Indikatoren für Ausnutzung oder einen Sicherheitsvorfall,
- betroffene Produkte, Versionen und gegebenenfalls Komponenten,
- erste Einschätzung der betroffenen Mitgliedstaaten,
- offene Annahmen, Untersuchungsaufträge und Entscheidungen zur Klassifikation.
Die Bewertung muss nicht auf die vollständige forensische Aufklärung warten. Gerade in den ersten Stunden werden Ursache, Umfang, Akteur oder endgültige Auswirkungen häufig noch nicht feststehen. Der Prozess sollte vorläufige Angaben eindeutig als solche kennzeichnen, offene Punkte aktiv nachverfolgen und die Folgemeldung als nächsten verbindlichen Arbeitsschritt planen.
Das 24-Stunden-Runbook für die Frühwarnung
Die Frühwarnung ist ohne unangemessene Verzögerung und spätestens innerhalb von 24 Stunden nach Kenntniserlangung einzureichen. Bei schwerwiegenden Sicherheitsvorfällen muss sie mindestens angeben, ob ein rechtswidriger oder böswilliger Auslöser vermutet wird. Soweit bekannt, sind auch die Mitgliedstaaten zu benennen, in denen das Produkt bereitgestellt wurde.
Praktisch sollte das Runbook vier parallele Arbeitsstränge verbinden. Security- und Engineering-Teams sichern technische Evidenz und prüfen die Indikatoren. Produktverantwortliche bestimmen Produktname, Versionen, Komponentenbezug und Supportstatus. Legal- oder Compliance-Funktionen prüfen den Meldepfad und die formale Konsistenz. Kommunikation und Support bereiten Informationen für betroffene Nutzer vor, ohne die technische Untersuchung zu behindern.
Für die Einreichung über die SRP sind bereits in der Frühwarnung strukturierte Mindestangaben erforderlich, darunter Produktname und -version, betroffene Mitgliedstaaten, eine Zusammenfassung sowie der Zeitpunkt der Kenntniserlangung. Organisationen sollten diese Daten nicht erst im Ereignisfall zusammensuchen. Sinnvoll ist ein vorbefüllbares Meldedatenmodell mit Produktinventar, Verteilung nach Mitgliedstaaten, Hersteller- und Kontaktdaten, sicheren Nutzerhinweisen sowie bekannten Abhilfe- und Minderungsmaßnahmen.
72-Stunden-Meldung: Untersuchung und Maßnahmen verdichten
Spätestens 72 Stunden nach Kenntniserlangung ist eine Meldung vorzulegen. Bei aktiv ausgenutzten Schwachstellen umfasst sie allgemeine Angaben zum Produkt, zur Art von Exploit und Schwachstelle sowie zu bereits ergriffenen und für Nutzer verfügbaren Maßnahmen. Bei schwerwiegenden Sicherheitsvorfällen sind insbesondere die Art des Vorfalls, eine Erstbewertung sowie die ergriffenen und für Nutzer verfügbaren Maßnahmen zu übermitteln.
Der Übergang von der Frühwarnung zur 72-Stunden-Meldung sollte nicht als isolierte Compliance-Aufgabe behandelt werden. Er verbindet die technische Untersuchung mit Entscheidungen über Abhilfe, Risikominderung und Kommunikation. Jede Änderung der Faktenlage sollte nachvollziehbar sein: Was war zum Zeitpunkt der Frühwarnung bekannt? Welche Erkenntnisse kamen hinzu? Welche Maßnahmen wurden umgesetzt oder den Nutzern bereitgestellt?
Diese Dokumentation unterstützt auch die Konsistenz zwischen Behördenmeldung und externer Kommunikation. Nach Artikel 14 Absatz 8 müssen Hersteller betroffene Nutzer und, soweit angemessen, alle Nutzer über das Ereignis sowie verfügbare Minderungs- und Abhilfemaßnahmen informieren. Diese Pflicht ist von der Meldung über die SRP getrennt, sollte aber sachlich abgestimmt gesteuert werden.
Abschlussbericht und Evidenzpaket
Für den Abschlussbericht gelten unterschiedliche Fristen. Bei aktiv ausgenutzten Schwachstellen ist er spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Minderungsmaßnahme fällig. Bei schwerwiegenden Sicherheitsvorfällen ist er innerhalb eines Monats nach der 72-Stunden-Meldung vorzulegen.
Bei Schwachstellen verlangt der Abschlussbericht unter anderem Angaben zur Beschreibung, zum Schweregrad, zu Auswirkungen, zu verfügbaren Informationen über den Akteur und zur Abhilfe. Bei Vorfällen sind unter anderem Schweregrad, Auswirkungen, wahrscheinliche Ursache oder Bedrohungsart sowie laufende Maßnahmen relevant. Daraus folgt eine klare Anforderung an die Nachweisführung: Technische Artefakte, Bewertungsentscheidungen, Maßnahmenstatus und Freigaben müssen über den gesamten Vorgang hinweg zusammengeführt werden.
Eine RACI-Logik sollte deshalb mindestens Eigentümer für Triggerbewertung, technische Faktensicherung, Produktzuordnung, Rechtsprüfung, Nutzerkommunikation und formale Freigabe der SRP-Übermittlung festlegen. Besonders wichtig ist eine belastbare Vertretungsregelung: Der Prozess darf nicht davon abhängen, dass eine einzelne fachlich oder organisatorisch zuständige Person erreichbar ist.
SRP-Zugang und Einreichung realistisch planen
Die Meldung erfolgt über die CRA Single Reporting Platform an den zuständigen, als Koordinator benannten CSIRT; die Plattform stellt sie grundsätzlich zugleich ENISA bereit. Zuständig ist im Regelfall der Mitgliedstaat der Hauptniederlassung in der EU, also der Ort, an dem Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden.
Für die Nutzung der SRP ist ein persönliches EU-Login-Konto mit Multi-Faktor-Authentisierung erforderlich. Pro Hersteller gibt es einen Primary Assigned Representative und bis zu 20 Secondary Assigned Representatives. Eine noch nicht abgeschlossene Validierung der Zuordnung zwischen Assigned Representative und Hersteller verhindert die Übermittlung einer Meldung nicht. Dennoch sollten Hersteller Zugang, Rollen und Vertretung vor einem Ereignis testen. Secondary Assigned Representatives werden durch einen verifizierten Primary Assigned Representative eingeladen; zudem sind Entwürfe nur für den jeweiligen Ersteller sichtbar.
Die erste SRP-Version bietet keine API für eine externe automatisierte Übermittlung. Interne Vorbereitungsschritte lassen sich zwar strukturieren oder automatisieren, die Einreichung erfolgt jedoch über die Plattformoberfläche. Vier-Augen-Prüfung, Empfangsbestätigungen sowie Screenshots oder Exportnachweise sollten daher in das Incident-Management integriert werden.
Ausnahmewege eng begrenzen
Die Prüfung besonders außergewöhnlicher Umstände nach Artikel 16 Absatz 2 sollte als eng begrenzter Sonderpfad ausgestaltet werden. Sie ist kein allgemeiner Vorbehalt gegen Meldung oder Nutzerinformation. Falls eine Verzögerung der Weitergabe in Betracht gezogen wird, sollten Tatsachenbasis, Bewertung und gegebenenfalls beantragte Verzögerung nachvollziehbar dokumentiert sein.
Ein funktionsfähiger CRA-Meldeprozess ist damit kein Formularprozess. Er ist ein verbindlicher Teil von Produkt-Cybersecurity, Vulnerability Management und Incident Response. Wer Zeitstempel, Triagepfade, Meldedatenmodell, Rollen und Plattformzugänge vorab etabliert, kann unter Zeitdruck auf einer belastbaren Faktenbasis handeln und die gesetzlich vorgesehenen Folgemeldungen systematisch nachführen.