CRA-Meldepflicht seit 11. September 2026: Incident Reporting über die Single Reporting Platform organisieren

Für Hersteller von Produkten mit digitalen Elementen ist das Reporting nach Artikel 14 der Verordnung (EU) 2024/2847 operativ gestartet: Seit dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die CRA Single Reporting Platform (SRP) zu melden. Die am 30. September 2026 aktualisierten ENISA-FAQ präzisieren insbesondere die Plattformnutzung, Verantwortlichkeiten und technische Grenzen der ersten Betriebsversion.

Der entscheidende Umsetzungsbedarf liegt damit nicht allein in einer rechtlichen Einordnung. Hersteller benötigen ein belastbares Betriebsmodell, das Erkenntnisse aus SOC, PSIRT und Entwicklung rechtzeitig in eine entscheidungs- und meldefähige Lage überführt. Unvollständige Ermittlungen dürfen dabei nicht dazu führen, dass gesetzliche Fristen übersehen werden.

Was seit dem 11. September 2026 operativ gilt

Die Meldepflichten nach Artikel 14 CRA gelten für Hersteller seit dem 11. September 2026; an diesem Tag nahm auch die von ENISA betriebene SRP ihren Betrieb auf. Dies ist zeitlich von den allgemeinen CRA-Hauptpflichten zu unterscheiden, die überwiegend erst ab dem 11. Dezember 2027 gelten. Die Europäische Kommission ordnet die vorgezogenen Pflichten auf ihrer Seite zu den CRA-Reporting Obligations ein.

Erfasst sind aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle, soweit sie die Sicherheit von Produkten mit digitalen Elementen betreffen. Die Pflicht kann auch Produkte im CRA-Anwendungsbereich erfassen, die bereits vor dem 11. Dezember 2027 auf dem Unionsmarkt bereitgestellt wurden. Keine rückwirkende Meldung ist erforderlich, wenn dem Hersteller die aktive Ausnutzung bereits vor dem 11. September 2026 bekannt war. Erlangt er hiervon erst danach Kenntnis, kann die Pflicht hingegen ausgelöst werden.

Rechtsverbindlich ist die Verordnung (EU) 2024/2847. Hinweise der Kommission und ENISA dienen der Auslegung oder der operativen Anwendung, sind aber keine eigenständigen Rechtsnormen. Für die interne Governance empfiehlt sich deshalb eine dokumentierte Trennung zwischen gesetzlicher Pflicht, fachlicher Bewertung und Plattformvorgabe.

Meldegegenstand richtig abgrenzen: aktive Ausnutzung oder schwerwiegender Sicherheitsvorfall

Nicht jede bekannte Schwachstelle löst eine verpflichtende CRA-Meldung aus. Bei einer aktiv ausgenutzten Schwachstelle kommt es auf belastbare Hinweise an, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des Systeminhabers ausgenutzt hat. Eine theoretische Ausnutzbarkeit, ein CVE-Eintrag oder eine hohe technische Schwere allein genügen dafür nicht.

Diese Abgrenzung muss im Incident-Prozess nachvollziehbar erfolgen. Das SOC kann etwa Telemetrie, Indikatoren oder externe Hinweise liefern. Das PSIRT bewertet, ob ein Bezug zum eigenen Produkt, einer betroffenen Komponente und konkreten Produktversionen besteht. Die Produktentwicklung muss Versionen, Abhängigkeiten und mögliche Korrektur- oder Minderungsmaßnahmen validieren. Bei Unsicherheit sollten Evidenz, Annahmen und offene Prüfpunkte im Fall dokumentiert werden, statt eine Erkenntnislage informell weiterzugeben.

Schwerwiegende Sicherheitsvorfälle bilden einen eigenständigen Meldegegenstand. Entscheidend ist der Sicherheitsbezug zum Produkt mit digitalen Elementen. Für die Bewertung sollten Hersteller daher eine eigene CRA-Entscheidungsmatrix verwenden und nicht allein vorhandene allgemeine Incident-Schweregrade übernehmen. Produktbezug, Sicherheitsauswirkung, betroffene Märkte, bekannte Nutzerfolgen und der Stand der Gegenmaßnahmen gehören in diese Bewertung.

Die drei Meldephasen als internes Datenmodell aufbauen

Der Fristenlauf beginnt mit der Kenntnis des Herstellers. Eine Frühwarnung ist unverzüglich und spätestens innerhalb von 24 Stunden abzugeben. Es folgt eine Meldung unverzüglich und spätestens innerhalb von 72 Stunden. Für aktiv ausgenutzte Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme einzureichen. Bei schwerwiegenden Sicherheitsvorfällen ist er binnen eines Monats nach der 72-Stunden-Meldung fällig.

Für die Praxis folgt daraus: Der Zeitpunkt der belastbaren Kenntniserlangung muss als eigener, nachvollziehbarer Zeitstempel geführt werden. Sinnvoll sind mindestens Quelle der Erkenntnis, bewertende Person, Entscheidungszeitpunkt und Begründung. Dieser Zeitpunkt darf nicht mit dem Beginn oder Abschluss einer forensischen Untersuchung verwechselt werden.

Die SRP unterscheidet Datenfelder nach Gegenstand und Phase. Gemeinsame Angaben betreffen unter anderem Hersteller, Produktname und Version, betroffene Mitgliedstaaten, Komponenten, bekannte oder erwartete Minderungsmaßnahmen sowie mögliche Nutzermaßnahmen. Bei aktiv ausgenutzten Schwachstellen kommen beispielsweise CVE- oder EUVD-ID, Informationen zur Ausnutzung, Schwere und Auswirkung hinzu. Für schwerwiegende Sicherheitsvorfälle sind insbesondere Art des Vorfalls, Maßnahmen, Schwere, Auswirkungen, wahrscheinliche Ursache und Erstbewertung relevant. Das CRA SRP Glossary erläutert diese Plattformbegriffe.

Ein internes Datenmodell in Ticketing-, PSIRT-Case-Management- oder GRC-Systemen sollte diese Felder früh abbilden. Erforderlich sind zudem Verantwortliche, Freigabestatus, Evidenzverweise, Zeitstempel, Versionen der Meldetexte und der Nachweis der tatsächlichen Einreichung. So lassen sich Frühwarnung, Folgemeldung und Abschlussbericht aufeinander aufbauen, ohne Informationen mehrfach manuell zusammensuchen zu müssen.

SRP-Betrieb: koordinierendes CSIRT, Representatives und manuelle Übermittlung

Die Meldung ist einmalig über die SRP an das koordinierende CSIRT zu richten. Grundsätzlich ist dies das CSIRT des Mitgliedstaats der Hauptniederlassung. Maßgeblich ist der Ort, an dem Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Ist dieser Ort nicht feststellbar, kommt es auf die EU-Niederlassung mit den meisten Beschäftigten an. Für Hersteller ohne EU-Hauptniederlassung enthält der CRA eine vorgegebene Reihenfolge über Bevollmächtigte, Importeure, Händler und letztlich die höchste Nutzerzahl.

Diese Zuordnung sollte vor dem ersten meldepflichtigen Fall als Compliance-Entscheidung dokumentiert sein. Denn laut ENISA kann eine Meldung bei Auswahl des falschen koordinierenden CSIRT für ungültig erklärt und beim zuständigen CSIRT erneut verlangt werden. In Konzernstrukturen sind daher Herstellerrolle, Entscheidungsort für Produktsicherheit und europäische Organisationsstruktur belastbar festzuhalten.

Für den Plattformzugang benötigt der Assigned Representative ein persönliches EU-Login mit Mehrfaktor-Authentisierung. Pro Hersteller sind ein Primary Assigned Representative und bis zu 20 Secondary Assigned Representatives möglich. Die Validierung durch das CSIRT läuft parallel und verhindert eine Meldung nicht. Da Entwürfe nur im jeweiligen Representative-Konto sichtbar sind, ist ein funktionierendes Vertretungskonzept wesentlich: Zugänge testen, mehrere handlungsfähige Personen benennen und Übergaben bei Abwesenheit oder Schichtwechsel verbindlich regeln.

Die erste SRP-Version stellt keine API bereit. Interne Datenerfassung, Freigaben und Qualitätsprüfungen können automatisiert werden; die Übermittlung erfolgt derzeit jedoch manuell über die Plattformoberfläche. Ein Vier-Augen-Prinzip für die Eingabe, ein Übermittlungsnachweis und der Abgleich mit dem internen Case-Status begrenzen dabei Übertragungs- und Nachweisrisiken.

Fristen nicht an der Plattformanzeige ausrichten

Fristzähler in der SRP sind Hilfsmittel, ersetzen aber nicht die gesetzliche Verantwortung. In der aktuellen Plattformversion wird der 72-Stunden-Zähler 48 Stunden nach Abgabe der Frühwarnung berechnet. Dadurch kann die Plattform eine Überfälligkeit anzeigen, obwohl seit Kenntniserlangung noch keine 72 Stunden vergangen sind. Für Abschlussberichte zu aktiv ausgenutzten Schwachstellen gibt es derzeit keinen eigenen Zähler.

Hersteller sollten deshalb einen unabhängigen Fristenkalender betreiben, der von dem dokumentierten Awareness-Zeitpunkt ausgeht. Dazu gehören Eskalationen vor Ablauf der 24- und 72-Stunden-Grenze sowie eine Überwachung der Abschlussberichte. Ist die SRP nicht verfügbar, bleibt die Pflicht zur späteren Einreichung über die SRP bestehen. ENISA weist darauf hin, dass Hersteller bei als notwendig erachteter unmittelbarer Kommunikation vor Wiederverfügbarkeit ihr koordinierendes CSIRT direkt kontaktieren können.

Ein belastbarer Übergabeprozess zwischen SOC, PSIRT, Entwicklung, Legal und Management

CRA-Reporting ist keine isolierte PSIRT-Aufgabe. Ein praktikables Rollenmodell definiert mindestens folgende Übergaben:

SOC und Incident Response: Erkennen, sichern und bewerten von Indikatoren, Ereignisdaten und externen Hinweisen; unverzügliche Übergabe potenziell produktbezogener Fälle.
PSIRT: Steuern der CRA-Klassifikation, der Evidenzbewertung und der Meldestrategie; Zusammenführen der Informationen für die Meldephasen.
Produktentwicklung: Validieren von Produkt-, Versions- und Komponentenbezug; Bewerten und Umsetzen von Korrektur- oder Minderungsmaßnahmen.
Legal und Compliance: Prüfen der einschlägigen Meldewege, Freigaben und Dokumentationsanforderungen, ohne die technische Erstbewertung unnötig zu verzögern.
Kundenkommunikation und Management: Vorbereiten abgestimmter Kundeninformationen sowie Entscheiden über Ressourcen, Eskalationen und wesentliche Kommunikationsrisiken.

Der Prozess sollte ausdrücklich festlegen, wer die Kenntniserlangung bestätigt, wer die Frühwarnung freigibt, wer die SRP technisch bedient und wer offene Aussagen bis zur nächsten Meldephase nachverfolgt. Regelmäßige Tabletop-Übungen mit einer aktiv ausgenutzten Drittanbieterkomponente und einem schwerwiegenden produktbezogenen Sicherheitsvorfall machen Lücken in Übergaben sichtbar.

Parallelmeldungen steuern, statt Fristen zu vermischen

Eine CRA-Meldung ersetzt andere Meldewege nicht automatisch. So kann eine Verletzung des Schutzes personenbezogener Daten eine eigenständige Meldung nach Artikel 33 DSGVO binnen 72 Stunden auslösen. Für Einrichtungen im Anwendungsbereich der NIS2-Richtlinie bestehen ebenfalls eigenständige, national umgesetzte Anforderungen an Frühwarnung, Meldung und Abschlussbericht. Hinzu können vertragliche Kundenpflichten treten.

Empfehlenswert ist ein gemeinsames Incident-Register mit getrennten Entscheidungssträngen. Jeder Strang benötigt eigene Rechtsgrundlage, Frist, Empfängergruppe, Freigabe und Nachweiskette. Das verhindert sowohl widersprüchliche externe Kommunikation als auch die falsche Annahme, eine SRP-Meldung decke andere Pflichten pauschal ab.

Kurz-Check: Was Hersteller jetzt testen sollten

Zuständiges koordinierendes CSIRT und die zugrunde liegende Organisationsentscheidung dokumentieren.
Primary und Secondary Assigned Representatives benennen sowie EU-Login und MFA funktionsfähig testen.
CRA-Datenmodell und Awareness-Zeitstempel im Fallmanagement einrichten.
Manuelle SRP-Einreichung mit Vier-Augen-Prinzip, Versionierung und Übermittlungsnachweis erproben.
24-Stunden-Frühwarnung unter realistischen Informationslücken als Tabletop-Übung durchführen.
Fristen unabhängig von SRP-Anzeigen überwachen und Abschlussberichte nachhalten.
Fallback für die direkte Kommunikation mit dem koordinierenden CSIRT bei SRP-Ausfall festlegen.

Der wirksame Nachweis der CRA-Reporting-Fähigkeit entsteht damit nicht erst im Meldeformular. Er beginnt bei der belastbaren Erkennung, setzt sich in klaren Rollen und Datenobjekten fort und endet erst mit einer nachvollziehbaren Abschluss- und Nachweisführung.