CRA-Meldepflicht: Was Hersteller innerhalb von 24 Stunden melden müssen

Die Meldepflichten des Cyber Resilience Act (CRA) gelten seit dem 11. September 2026. Betroffen sind Hersteller von Produkten mit digitalen Elementen auf dem Binnenmarkt der Europäischen Union. Ab belastbarer Kenntnis einer aktiv ausgenutzten Schwachstelle bleiben 24 Stunden für eine Frühwarnung. Nach der PwC-Erhebung vom Frühjahr 2026 schätzen sich 3 Prozent der befragten Industrieunternehmen als vollständig konform ein.

CRA-Anforderungen an die Meldung: Was Artikel 14 verlangt

Meldepflichtig sind zwei Ereignisarten: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Produktsicherheit.

Rechtsgrundlage ist Artikel 14 der Verordnung (EU) 2024/2847. Die übrigen Pflichten aus dem Cyber Resilience Act, darunter die Cybersicherheitsanforderungen an das Produkt selbst, greifen erst später.

Wen der CRA beim Inverkehrbringen als Hersteller behandelt

Betroffen ist, wer Produkte mit digitalen Elementen in der EU in Verkehr bringt. Nach Artikel 21 CRA gilt ein Einführer oder Händler als Hersteller, sobald er ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt. Dasselbe gilt, wenn er es wesentlich verändert.

Der Bestand ist mitgemeint. Artikel 69 Absatz 2 CRA schützt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Absatz 3 nimmt Artikel 14 davon ausdrücklich aus. Rückwirkend gilt die Meldepflicht trotzdem nicht. Für Schwachstellen, die vor dem 11. September 2026 bekannt, aber nicht aktiv ausgenutzt waren, beginnt die Frist erst mit der Kenntnis einer aktiven Ausnutzung.

CRA-Fristen: 24 Stunden bis ein Monat

Die ersten beiden Stufen sind für beide Ereignisarten identisch, die Abschlussberichte laufen auseinander.

Die Europäische Kommission nennt dieselben vier Stufen. Die Uhr läuft ab der Kenntnis, nicht ab dem Beginn des nächsten Arbeitstags. Was Kenntnis bedeutet, hat die Kommission in ihrer im Juli 2026 gebilligten Leitlinie C(2026) 5252 präzisiert: Maßstab ist ein „hinreichender Grad an Gewissheit“. Bindend ist die Leitlinie nicht.

Woher die Kenntnis kommt, nennt das Bundesamt für Sicherheit in der Informationstechnik (BSI) beispielhaft. Von Schwachstellen erfahren Hersteller über IT-Sicherheitsdienstleister oder Kundinnen und Kunden, von Vorfällen zusätzlich über externe Hinweise oder die interne Auswertung von Logdaten. Ein geregelter Eingang für Hinweise hält die externen Wege offen, ein fortlaufender Schwachstellenscan liefert Befunde aus dem eigenen Bestand.

Was bei Verstößen gegen die CRA-Verordnung droht

Verstöße gegen Artikel 14 stehen in der höchsten Bußgeldkategorie des Artikels 64. Der Rahmen reicht bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Artikel 64 Absatz 10 Buchstabe a nimmt Kleinst- und Kleinunternehmen aus, allerdings nur für die versäumte 24-Stunden-Frist.

Welche Ereignisse der Cyber Resilience Act meldepflichtig macht

Beide Ereignisarten sind eng gefasst. Artikel 3 Nummer 42 CRA definiert eine aktiv ausgenutzte Schwachstelle über den Nachweis. Verlangt sind zuverlässige Belege, dass ein böswilliger Akteur sie ohne Erlaubnis nachweisbar in einem System ausgenutzt hat. Ein veröffentlichter Exploit genügt nicht, Proof-of-Concept-Code und Portscans ebenso wenig.

Ein schwerwiegender Sicherheitsvorfall nach Artikel 3 Nummer 44 und Artikel 14 Absatz 5 CRA misst sich an der Produktsicherheit. Nach dem BSI muss mindestens eine von zwei Voraussetzungen erfüllt sein. Die erste: Der Vorfall beeinträchtigt die Fähigkeit des Produkts, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten beziehungsweise Funktionen zu schützen. Dass er sie beeinträchtigen kann, genügt. Die zweite: Der Vorfall hat zur Einschleusung oder Ausführung schädlichen Codes im Produkt oder im Netzwerk eines Nutzers geführt, oder er kann dazu führen.

Ein Ransomware-Vorfall bei einem Hersteller ist nach Auskunft des BSI nicht automatisch ein schwerwiegender Sicherheitsvorfall im Sinne des CRA. Dazu müsste er sich auf die Sicherheit des Produkts auswirken oder zur Manipulation von Software, Updates, Signaturschlüsseln oder Produktfunktionen führen können.

Meldeweg über die CRA-SRP der ENISA und das CERT-Bund

Gemeldet wird über die CRA Single Reporting Platform (CRA-SRP) unter portal.cra-srp.enisa.europa.eu. Betreiberin ist die Agentur der Europäischen Union für Cybersicherheit (ENISA). Die erste Ausbaustufe ging am 11. September 2026 in Betrieb, weitere Funktionen sollen in den kommenden Monaten folgen.

Für den Zugang ist ein EU-Login-Konto nötig, die Meldungen sind auf Englisch zu verfassen. Eine vorherige Registrierung auf der Plattform ist nach Angaben des BSI nicht erforderlich. Im Bedarfsfall sind Registrierung und Meldung in wenigen Minuten möglich. Die Meldung übermittelt eine benannte Vertretungsperson. Das BSI empfiehlt dafür eine verlässliche Vertretung durch mindestens zwei Personen.

Empfänger sind das zuständige koordinierende CSIRT eines EU-Mitgliedstaates und die ENISA. In Deutschland ist das CERT-Bund im BSI das koordinierende Computer Security Incident Response Team. Ohne Hauptniederlassung in der EU richtet sich die Zuständigkeit nach Artikel 14 Absatz 7 CRA. Fällt die Plattform aus, geht die Pflichtmeldung ausnahmsweise per E-Mail an das CERT-Bund.

Das zuerst empfangende CSIRT teilt die Meldung ohne Verzug mit den CSIRTs der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde. Nur in Ausnahmefällen darf es die Weitergabe aus begründeten Cybersicherheitsgründen verzögern. Die Bedingungen nennt die Delegierte Verordnung (EU) 2026/881.

CRA-Compliance: Wie weit die Hersteller sind

PwC hat im Frühjahr 2026 100 Industrieunternehmen in Deutschland befragt. 65 Prozent gehören zum Maschinenbau, 61 Prozent haben weniger als 500 Mitarbeitende. Erst jedes zweite Unternehmen hat mit der aktiven Umsetzung begonnen, 3 Prozent schätzen sich als vollständig konform ein.

Für die Meldepflicht zählt ein anderer Wert: 50 Prozent verfügen über keine dedizierte externe Meldeschnittstelle für Sicherheitsmeldungen, diese Hälfte verweist auf den regulären Kundensupport. 27 Prozent haben intern gar keinen Prozess für Sicherheitsprobleme, weitere 23 Prozent arbeiten informell und ad hoc. Ohne dedizierten Meldekanal für eingehende Hinweise fehlt einer der Wege, über die Hersteller von einer Ausnutzung Kenntnis erlangen.

Die zweite Lücke liegt in der Produktdokumentation. 27 Prozent der Befragten erstellen für die Mehrheit oder das gesamte Portfolio eine Software Bill of Materials (SBOM), 36 Prozent gar keine. Nur 30 Prozent erhalten regelmäßig SBOMs von Zulieferern. Ein detailliertes Komponentenverzeichnis ist nach PwC essenziell, um betroffene Produkte bei Sicherheitsproblemen schnell und zuverlässig zu identifizieren.

Minimalprozess: PSIRT, Triage und Fristenkontrolle

Ein konformer Meldeprozess braucht benannte Zuständigkeiten und eine Fristenkontrolle, die unabhängig von Wochenenden und Feiertagen greift, weil die Frist mit der Kenntnis beginnt.

1. Eingang bündeln. Hinweise von außen und Befunde aus dem eigenen Monitoring laufen an einer Stelle zusammen. Nach dem BSI kann eine Trennung zwischen Product Security Incident Response Team (PSIRT) und CSIRT sinnvoll sein.
2. Triage mit Zeitstempel. Geprüft wird, ob zuverlässige Belege für eine Ausnutzung vorliegen oder ob ein Vorfall die Produktsicherheit berührt. Das Ergebnis gehört dokumentiert, weil die 24-Stunden-Frist an diesem Zeitpunkt hängt.
3. Zugang vorbereiten. Namen der Vertretungspersonen und das Verfahren sollten feststehen, auch ohne Registrierung auf Vorrat.
4. Kaskade abarbeiten. Die Fristen stehen in der Tabelle oben.
5. Nebenpflichten mitdenken. Die CRA-Meldung ersetzt keine anderen Pflichten des Herstellers. Artikel 14 Absatz 8 CRA verlangt zusätzlich die Information betroffener Nutzerinnen und Nutzer, ohne Zahlenfrist, nur „rechtzeitig“.
6. Technische Richtlinie heranziehen. Das BSI hält es für sinnvoll, die Empfehlungen der BSI TR-03183 zum CRA frühzeitig zu berücksichtigen.

Wann zusätzlich die NIS2-Meldepflicht greift

Derselbe Vorfall kann nach NIS2 und nach dem CRA meldepflichtig sein. Dann ist er über beide Wege zu melden: nach NIS2 über das Portal des BSI, nach dem CRA über die CRA-SRP. Der vorgeschlagene Digital Omnibus könnte die Doppelmeldung entfallen lassen, sofern die Regelung so beschlossen wird. Wer die Meldepflichten nach NIS2 bereits organisiert hat, kann Triage und Eskalation in der Regel weiterverwenden, den Meldeweg nicht.

Einordnung

Die Meldepflicht ist der Teil des CRA, der ohne Schonfrist scharf gestellt wurde. Die Anforderungen an das Produkt folgen am 11. Dezember 2027. Ab diesem Datum melden nach Artikel 24 Absatz 3 CRA auch Verwalter quelloffener Software. Bis dahin lassen sich IoT- und OT-Produkte auf Schwachstellen testen.

Der Engpass liegt vor dem Formular. Registrierung und Meldung sind laut BSI in wenigen Minuten möglich, die 24 Stunden beginnen aber mit der Kenntnis. Kenntnis entsteht erst, wenn ein Hinweis oder ein eigener Befund ankommt und jemand ihn bewertet.

Quellen

1. BSI: Cyber Resilience Act, Meldepflicht für Schwachstellen startet (11.09.2026)
2. BSI: CRA Single Reporting Platform
3. ENISA: The CRA Single Reporting Platform is launched (11.09.2026)
4. ENISA: CRA Single Reporting Platform, Portal
5. Europäische Kommission: Cyber Resilience Act, reporting obligations
6. EUR-Lex: Verordnung (EU) 2024/2847 (Cyber Resilience Act)
7. EUR-Lex: Delegierte Verordnung (EU) 2026/881
8. PwC: Nur 3 Prozent der deutschen Industrieunternehmen sind vollständig auf den EU Cyber Resilience Act vorbereitet (11.09.2026)
9. PwC: Product Security Survey 2026
10. Greenbone: CRA-Meldepflicht in der Praxis
11. Greenbone: CRA-Meldepflichten für Schwachstellen
12. sector7: CRA-Meldepflicht ab 11. September