cra-meldepflichten

/cyber-resilience-act:cra-meldepflichten

Zweck

Art. 14 CRA (VO (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in einer dreistufigen Kaskade zu melden. Die Pflicht gilt ab dem 11.09.2026 und ist damit die erste operative CRA-Pflicht überhaupt — mehr als ein Jahr vor der vollständigen Geltung. Dieser Skill bestimmt, ob ein meldepflichtiges Ereignis vorliegt, berechnet die Fristen, liefert die Meldeinhalte und baut den internen Eskalationsprozess, ohne den die 24-Stunden-Frist praktisch nicht einzuhalten ist.

⚠️ Aktualität (Stand 2026-07): Die Verordnung ist am 10.12.2024 in Kraft getreten. Die Meldepflichten gelten ab dem 11.09.2026 — die Frist läuft in sieben Wochen. Seit dem 11.06.2026 gelten die Vorschriften über Konformitätsbewertungsstellen; die vollständige Geltung mit grundlegenden Anforderungen, CE-Kennzeichnung und Konformitätsbewertung folgt erst am 11.12.2027.

Die Meldepflicht ist vorgezogen. Sie greift, bevor die materiellen Produktanforderungen des Anhang I gelten. Ein Hersteller kann also meldepflichtig sein, obwohl seine Produkte die grundlegenden Anforderungen noch nicht erfüllen müssen. Wer auf 2027 plant, verfehlt den relevanten Stichtag um 15 Monate.

Sanktionsrahmen: Verstöße gegen die zentralen Hersteller- und Meldepflichten sind mit bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes bewehrt, je nachdem, welcher Betrag höher ist (Art. 64 CRA).

Eingaben

• Betroffenes Produkt mit Version, Rolle des Mandanten (Hersteller / Verwalter quelloffener Software) und CRA-Einstufung
• Zeitpunkt der Kenntniserlangung, minutengenau, mit Beleg (Ticket, Log, Mail)
• Art des Ereignisses: Schwachstelle mit Ausnutzungsnachweis oder Sicherheitsvorfall
• Nachweise für die aktive Ausnutzung (Exploit in freier Wildbahn, Angriffsindikatoren, Meldung eines Forschers, CERT-Hinweis)
• Auswirkungen: betroffene Nutzerzahl, Verfügbarkeit, Vertraulichkeit, Integrität, grenzüberschreitende Wirkung
• Verfügbarkeit eines Sicherheitsupdates oder einer Umgehungslösung und deren Zeitpunkt
• Mitgliedstaat der Hauptniederlassung in der Union
• Parallel laufende Pflichtenkreise: NIS2-Einrichtung? Personenbezogene Daten betroffen? DORA-Finanzunternehmen?

Sub-Agent-Architektur

Drei gedankliche Rollen strukturieren die Bearbeitung, die im Ernstfall parallel und unter Zeitdruck läuft. Ein Trigger-Prüfer entscheidet als Erstes und binnen Minuten, ob ein meldepflichtiges Ereignis im Sinne des Art. 14 CRA vorliegt — aktiv ausgenutzte Schwachstelle oder schwerwiegender Sicherheitsvorfall — und hält den Zeitpunkt der Kenntniserlangung als fristauslösendes Ereignis fest. Ein Fristen-Rechner leitet daraus die drei Fälligkeiten ab, jeweils mit Datum und Uhrzeit, und überwacht sie bis zum Abschlussbericht. Ein Melde-Redakteur formuliert die Inhalte der jeweiligen Stufe adressatengerecht, ohne unnötige Details preiszugeben und ohne die Untersuchung zu präjudizieren. Der Trigger-Prüfer entscheidet im Zweifel für die Meldung: Die Frühwarnung ist bewusst niedrigschwellig ausgestaltet und kann in der Vollmeldung korrigiert werden.

Ablauf

1. Meldeauslöser bestimmen (Art. 14 CRA)

Der CRA kennt zwei getrennte Auslöser. Sie sind sauber zu unterscheiden, weil die Frist für den Abschlussbericht unterschiedlich läuft.

a) Aktiv ausgenutzte Schwachstelle. Eine Schwachstelle in einem Produkt mit digitalen Elementen, für die belastbare Anhaltspunkte bestehen, dass ein Angreifer sie tatsächlich ausnutzt — ohne dass der Hersteller sie behoben oder öffentlich gemacht hat. Entscheidend ist die Ausnutzung, nicht die Schwere: Eine hoch bewertete, aber nicht ausgenutzte Schwachstelle löst die Meldepflicht nach Art. 14 CRA nicht aus; sie fällt in das Schwachstellenmanagement nach Anhang I Teil II.

Typische Anhaltspunkte: Exploit-Code in freier Wildbahn, Angriffsindikatoren aus Kundeninstallationen, Hinweis eines Sicherheitsforschers mit Proof of Concept in Verbindung mit beobachtetem Angriffsverkehr, Aufnahme in einen Katalog bekannt ausgenutzter Schwachstellen.

b) Schwerwiegender Sicherheitsvorfall. Ein Sicherheitsvorfall, der die Cybersicherheit des Produkts oder die Fähigkeit des Produkts, die Vertraulichkeit, Integrität oder Verfügbarkeit kritischer oder wesentlicher Funktionen zu schützen, nachteilig beeinflusst. Erfasst sind auch Vorfälle in der Entwicklungs- oder Auslieferungsinfrastruktur des Herstellers, soweit sie auf das Produkt durchschlagen — etwa ein kompromittierter Build-Server oder Signaturschlüssel.

Im Zweifel melden. Die Frühwarnung verlangt keine abgeschlossene Analyse. Eine später als nicht meldepflichtig erkannte Frühwarnung ist folgenlos korrigierbar; eine versäumte 24-Stunden-Frist ist es nicht.

2. 24-Stunden-Frühwarnung (Art. 14 CRA)

Fällig innerhalb von 24 Stunden ab Kenntniserlangung. Fristbeginn ist der Zeitpunkt, zu dem der Hersteller Kenntnis erlangt — nicht der Zeitpunkt einer internen Bestätigung, einer Managemententscheidung oder eines abgeschlossenen Forensikberichts.

Inhalt der Frühwarnung, bewusst knapp gehalten:

• Bezeichnung des betroffenen Produkts und der betroffenen Versionen
• Art des Ereignisses: aktiv ausgenutzte Schwachstelle oder schwerwiegender Sicherheitsvorfall
• Erste, vorläufige Einschätzung der Auswirkungen
• Angabe, ob eine Ausnutzung beobachtet wurde und in welchem Umfang
• Betroffene Mitgliedstaaten, soweit bereits absehbar
• Kontaktdaten der verantwortlichen Stelle beim Hersteller

Die Frühwarnung ist kein Vorfallsbericht. Vollständigkeit wird nicht verlangt; Verzögerung zugunsten von Vollständigkeit ist der klassische Fehler.

3. 72-Stunden-Vollmeldung (Art. 14 CRA)

Fällig innerhalb von 72 Stunden ab Kenntniserlangung — die Frist läuft ab demselben Zeitpunkt wie die Frühwarnung, nicht ab deren Absendung. Es bleiben faktisch 48 Stunden nach der Frühwarnung.

Inhalt:

• Allgemeine Informationen über Art und Schwere des Ereignisses
• Betroffene Produkte, Versionen und geschätzte Zahl betroffener Nutzer
• Verfügbare Angaben zur Schwachstelle einschließlich Kennung (CVE), soweit vergeben
• Ergriffene und geplante Korrektur- und Abhilfemaßnahmen
• Handlungsempfehlungen für Nutzer und Betreiber
• Aktualisierung und ggf. Korrektur der Angaben aus der Frühwarnung

Wo die Untersuchung noch läuft, ist das ausdrücklich zu vermerken. Unsichere Angaben sind als vorläufig zu kennzeichnen, nicht wegzulassen.

4. Abschlussbericht — 14 Tage oder 1 Monat (Art. 14 CRA)

Hier trennen sich die beiden Auslöser:

Auslöser	Frist für den Abschlussbericht	Fristbeginn
Aktiv ausgenutzte Schwachstelle	spätestens 14 Tage	ab Verfügbarkeit eines Sicherheitsupdates oder einer Umgehungslösung
Schwerwiegender Sicherheitsvorfall	1 Monat	ab der Erstmeldung (72-Stunden-Meldung)

Inhalt des Abschlussberichts:

• Beschreibung der Schwachstelle einschließlich Schweregrad und Auswirkungen
• Angaben zu ausnutzenden Akteuren, soweit verfügbar
• Einzelheiten des bereitgestellten Sicherheitsupdates oder der Abhilfemaßnahme
• Bei einem Vorfall: Ursache, Verlauf, Schweregrad, Auswirkungen und angewandte Abhilfemaßnahmen
• Ggf. grenzüberschreitende Auswirkungen

Die 14-Tage-Frist ist die praktisch heikelste: Sie knüpft nicht an die Meldung, sondern an die Verfügbarkeit des Updates an. Wer den Zeitpunkt der Update-Bereitstellung nicht dokumentiert, kann die Fristwahrung später nicht belegen.

5. Meldeweg — einheitliche Meldeplattform, CSIRT und ENISA (Art. 14, 16 CRA)

Gemeldet wird über die CRA-Einheitliche Meldeplattform (Single Reporting Platform). Adressat ist das CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat. Die ENISA erhält die Information parallel über die Plattform — eine gesonderte Meldung an die ENISA ist nicht erforderlich und nicht vorgesehen.

Praktische Konsequenzen:

• Der Mitgliedstaat der Hauptniederlassung ist vorab zu bestimmen und zu dokumentieren; er steuert das zuständige CSIRT. Für Hersteller ohne Unionsniederlassung ist über den Bevollmächtigten zu bestimmen.
• Für Deutschland ist das BSI (bsi.bund.de) die maßgebliche Schnittstelle. [unverifiziert - prüfen] Die konkrete Ausgestaltung der deutschen Anbindung an die Plattform sowie die Zuständigkeitsverteilung nach Art. 52 CRA sind zu verifizieren.
• Zugänge, Zertifikate und Berechtigungen für die Plattform sind vor dem 11.09.2026 einzurichten und mindestens einmal zu testen. Ein Zugang, der im Ernstfall erst beantragt wird, kostet die 24-Stunden-Frist.
• Der Meldeweg ist auch außerhalb der Geschäftszeiten sicherzustellen; Vorfälle beginnen typischerweise nachts oder am Wochenende.

6. Interner Eskalationsprozess für die 24-Stunden-Frist (Art. 13, 14 CRA)

Die 24-Stunden-Frist ist eine Organisationspflicht, keine bloße Formalität. Erforderlich ist ein dokumentierter Prozess mit mindestens folgenden Elementen:

1. Eingangskanäle bündeln: Support, Sicherheitsforscher über die CVD-Policy, CERT-Hinweise, Monitoring, Lieferantenmeldungen — alle münden in ein Ticket mit Zeitstempel.
2. Kenntniserlangung definieren und protokollieren: Wer im Unternehmen Kenntnis erlangt, gilt als Kenntniserlangung des Herstellers. Der Zeitstempel ist unveränderlich festzuhalten.
3. Triage binnen weniger Stunden durch eine benannte Rolle mit Vertretungsregelung und 24/7-Erreichbarkeit.
4. Entscheidungsbefugnis vorverlagern: Die Freigabe der Frühwarnung darf nicht von der Geschäftsleitung abhängen. Vorab freigegebene Textbausteine und eine klare Freigabematrix.
5. Rufbereitschaft und Eskalationsliste mit Erreichbarkeiten, jährlich geprüft.
6. Übung: mindestens ein Trockenlauf pro Jahr gegen die Plattform, mit Protokoll.
7. Verzahnung mit dem Schwachstellenmanagement nach Anhang I Teil II und mit der Kommunikation an Nutzer.

Die Prozessdokumentation ist zugleich der Entlastungsnachweis gegenüber der Marktüberwachungsbehörde.

7. Nutzerinformation, Dokumentation und Abgrenzung zu NIS2 und DSGVO (Art. 14 CRA)

Nutzerinformation. Neben der Behördenmeldung sind die betroffenen Nutzer über das Ereignis und erforderlichenfalls über Abhilfemaßnahmen zu unterrichten. Behördenmeldung und Nutzerinformation sind getrennte Pflichten; die eine ersetzt die andere nicht.

Dokumentation. Zu jedem Ereignis sind aufzubewahren: Zeitpunkt und Beleg der Kenntniserlangung, Triage-Entscheidung mit Begründung, Fristberechnung, Wortlaut aller drei Meldestufen mit Sendenachweis, Zeitpunkt der Update-Bereitstellung, Nutzerinformation, Nachbereitung.

Abgrenzung — ein Ereignis, mehrere Meldepflichten:

Regime	Anknüpfung	Adressat	Fristen
CRA Art. 14	Produkt mit digitalen Elementen	CSIRT über die einheitliche Meldeplattform, ENISA parallel	24h / 72h / 14 Tage bzw. 1 Monat
NIS2 Art. 23	Einrichtung in einem erfassten Sektor	zuständige Behörde, in Deutschland das BSI	24h / 72h / 1 Monat
DSGVO Art. 33	personenbezogene Daten	Aufsichtsbehörde (LfDI/BfDI), ggf. Betroffene nach Art. 34	72h
DORA Art. 19	Finanzunternehmen, IKT-Vorfall	zuständige Finanzaufsicht	eigener Fristenlauf

Ein einziger Vorfall kann alle vier Pflichten gleichzeitig auslösen. Die Meldungen sind inhaltlich abzustimmen, aber getrennt abzusetzen; keine Pflicht konsumiert eine andere.

Quellen

Statute

• VO (EU) 2024/2847 (Cyber Resilience Act) — Volltext mit Anhängen
• Art. 14 CRA (Meldepflichten der Hersteller — 24 Stunden / 72 Stunden / Abschlussbericht), Art. 13 CRA (Pflichten der Hersteller), Art. 16 CRA (einheitliche Meldeplattform, ENISA) [unverifiziert - prüfen], Art. 52 CRA (Marktüberwachung), Art. 64 CRA (Sanktionen)
• Anhang I Teil II CRA (Schwachstellenbehandlung) — Schnittstelle zur Meldepflicht
• Art. 23 RL (EU) 2022/2555 (NIS2) — einrichtungsbezogene Meldepflicht
• Art. 33, 34 DSGVO — Datenschutzmeldung
• VO (EU) 2022/2554 (DORA) — IKT-Vorfallmeldung im Finanzsektor

Leitlinien

• Europäische Kommission, Cyber Resilience Act — Meldepflichten und FAQ zur Umsetzung
• ENISA, technische Vorgaben zur einheitlichen Meldeplattform
• BSI — Meldewege und Umsetzung in Deutschland

Rechtsprechung: Zum Cyber Resilience Act ist keine Rechtsprechung ersichtlich (Stand 07/2026); die Meldepflichten gelten erst ab dem 11.09.2026. Erfahrungswerte aus der DSGVO- und NIS2-Meldepraxis sind allenfalls analog heranzuziehen und ausdrücklich als Analogie zu kennzeichnen.

Ausgabeformat

CRA-MELDUNG — <Vorfall-ID> — <Produkt> — <Datum>

I.    Rolle und Produkt              [Hersteller / OSS-Verwalter; Produkt, Version]
II.   Auslöser (Art. 14 CRA)         [aktiv ausgenutzte Schwachstelle /
                                      schwerwiegender Sicherheitsvorfall / keiner]
      Begründung                     <…>
III.  Kenntniserlangung              <TT.MM.JJJJ, HH:MM> — Beleg: <…>
IV.   Meldekaskade
      24h-Frühwarnung   Frist: <TT.MM. HH:MM>  Status: <abgesetzt / offen>
      72h-Vollmeldung   Frist: <TT.MM. HH:MM>  Status: <…>
      Abschlussbericht  Frist: <14 Tage ab Update / 1 Monat ab Erstmeldung>
V.    Meldeweg                       Einheitliche Meldeplattform →
                                     CSIRT <Mitgliedstaat der Hauptniederlassung>
                                     ENISA erhält parallel — keine Zusatzmeldung
VI.   Inhalte je Meldestufe          <Textbausteine / Verweise>
VII.  Nutzerinformation              [erforderlich? Kanal, Zeitpunkt]
VIII. Parallele Meldepflichten       NIS2 [ja/nein] · DSGVO Art. 33 [ja/nein]
                                     DORA [ja/nein]
IX.   Sanktionsrisiko (Art. 64 CRA)  [bis 15 Mio. EUR / 2,5 %]

Eskalationspfad: <Rolle, Erreichbarkeit, Freigabematrix>
Risikoeinstufung: 🟢 / 🟡 / 🔴
Nächster Schritt: <…>

Risiken / typische Fehler

• Fristbeginn falsch angesetzt — die 24 Stunden laufen ab Kenntniserlangung, nicht ab interner Bestätigung, Managementfreigabe oder Abschluss der Forensik. Die Verschiebung des Fristbeginns ist der praktisch häufigste und teuerste Fehler.
• 72-Stunden-Frist von der Frühwarnung aus gerechnet — sie läuft ab demselben Zeitpunkt wie die 24-Stunden-Frist. Nach der Frühwarnung verbleiben faktisch 48 Stunden, nicht 72.
• Abschlussbericht-Fristen vertauscht — Schwachstelle: 14 Tage ab Verfügbarkeit des Sicherheitsupdates oder der Umgehungslösung; Vorfall: 1 Monat ab der Erstmeldung. Die Anknüpfungspunkte sind verschieden.
• Zeitpunkt der Update-Bereitstellung nicht dokumentiert — ohne ihn ist die Wahrung der 14-Tage-Frist nicht belegbar.
• Schwere mit Ausnutzung verwechselt — Art. 14 CRA knüpft an die aktive Ausnutzung an, nicht an einen CVSS-Wert. Eine kritische, aber nicht ausgenutzte Schwachstelle ist nicht nach Art. 14 CRA meldepflichtig, bleibt aber Gegenstand des Schwachstellenmanagements nach Anhang I Teil II.
• Gesonderte ENISA-Meldung abgesetzt — die ENISA erhält die Information parallel über die einheitliche Meldeplattform. Eine Zusatzmeldung ist weder erforderlich noch vorgesehen.
• Falsches CSIRT adressiert — Adressat ist das CSIRT des Mitgliedstaats der Hauptniederlassung, nicht des Landes, in dem der Vorfall auftrat.
• Plattformzugang erst im Ernstfall beantragt — Zugänge und Berechtigungen sind vor dem 11.09.2026 einzurichten und zu testen.
• Freigabe an die Geschäftsleitung gebunden — eine Frühwarnung, die auf eine Vorstandsentscheidung wartet, ist regelmäßig verspätet. Die Freigabebefugnis ist vorzuverlagern.
• Nutzerinformation vergessen — Behördenmeldung und Unterrichtung der betroffenen Nutzer sind getrennte Pflichten.
• Parallelpflichten übersehen — ein Ereignis kann CRA, NIS2, DSGVO und DORA gleichzeitig auslösen; keine Meldung ersetzt eine andere.
• Auf 11.12.2027 geplant — die Meldepflicht gilt bereits ab 11.09.2026, unabhängig davon, dass die grundlegenden Anforderungen später greifen.
• ⚠️ Artikelnummern ungeprüft übernommen — insbesondere die Fundstelle zur einheitlichen Meldeplattform ist [unverifiziert - prüfen] und vor mandantengerichteter Verwendung am Amtsblatttext der VO (EU) 2024/2847 zu verifizieren.