Welche CRA-Meldepflichten gelten ab September 2026?
Artikel 14 des CRA verpflichtet Hersteller von Produkten mit digitalen Elementen, zwei Ereignisarten zu melden:
- aktiv ausgenutzte Schwachstellen im Produkt und
- schwerwiegende Vorfälle, die sich auf dessen Sicherheit auswirken.
Die Meldung erfolgt über die Single Reporting Platform von ENISA (European Union Agency for Cybersecurity). Sie ist gleichzeitig für die zuständige koordinierende Stelle des Computer Security Incident Response Teams (CSIRT) und für ENISA zugänglich. ENISA bereitet die Plattform aktuell für den Start am 11. September 2026 vor; Unternehmen sollten sich frühzeitig mit dem Registrierungsprozess vertraut machen.
Die Pflicht betrifft Hersteller, die Hardware oder Software im Rahmen einer geschäftlichen Tätigkeit auf dem EU-Markt bereitstellen. Für Schweizer Unternehmen ist sie daher relevant, sobald ihre Produkte mit digitalen Elementen in der EU angeboten werden.
Artikel 14 gilt zudem auch für Produkte, die bereits vor der vollständigen Anwendung des CRA in Verkehr gebracht wurden und in den Anwendungsbereich der Verordnung fallen.
Die meisten weiteren Anforderungen des Cyber Resilience Act gelten erst ab 11. Dezember 2027. Dazu zählen unter anderem umfassende Produktanforderungen, die Konformitätsbewertung und technische Dokumentation.
Die Cyber-Resilience-Act-Meldepflichten gehören damit zu den vorgezogenen Betriebspflichten. Der CRA wird im Deutschen gelegentlich auch als Cyberresilienzgesetz bezeichnet. Rechtlich handelt es sich jedoch um die unmittelbar geltende EU-Verordnung 2024/2847.
Einen kompakten Überblick über den Geltungsbereich, die Anforderungen und die zeitliche Anwendung finden Sie auf unserer CRA-Übersichtsseite.
Whitepaper
Was Hersteller von Connected Devices jetzt wissen müssen
Erfahren Sie, wie der neue EU Cyber Resilience Act die Anforderungen für Hersteller von vernetzten Geräten verändert.
Was muss überhaupt gemeldet werden?
Aktiv ausgenutzte Schwachstellen
Eine entdeckte Schwachstelle ist nicht automatisch meldepflichtig. Die CRA-Meldepflicht greift erst, wenn verlässliche Hinweise auf eine tatsächliche Ausnutzung vorliegen. Das kann beispielsweise durch Sicherheitsanalysen, Protokolldaten oder bestätigte Meldungen von Behörden, Kunden oder Sicherheitsforschenden belegt sein.
Beispiel: Ein Hersteller erfährt, dass Angreifer eine Schwachstelle in einer Softwarekomponente seines Produkts ausnutzen. Protokolldaten zeigen, dass über diese Schwachstelle bereits unbefugte Zugriffe auf ausgelieferte Produkte erfolgt sind. In diesem Fall muss der Hersteller die aktiv ausgenutzte CRA-Schwachstelle melden.
Eine Schwachstelle, die lediglich bei einem internen Test entdeckt wurde und für die keine Hinweise auf eine aktive Ausnutzung vorliegen, löst dagegen nicht allein deshalb eine Meldepflicht nach Artikel 14 aus.
Schwerwiegende Sicherheitsvorfälle
Daneben müssen Hersteller schwerwiegende Sicherheitsvorfälle melden, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken. Entscheidend ist, ob der Vorfall wichtige Daten oder Funktionen gefährdet – etwa deren Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit. Die Meldepflicht greift auch, wenn Schadcode in das Produkt oder in die Systeme seiner Nutzer eingeschleust oder dort ausgeführt wurde beziehungsweise werden kann.
Beispiel: Angreifer verschaffen sich Zugriff auf den Update-Kanal eines Herstellers und schleusen Schadcode in ein Produktupdate ein. Das manipulierte Update wird an Kunden ausgeliefert und kann Schadcode in deren Systemen ausführen. Ein solcher Vorfall beeinträchtigt die Integrität des Produkts und kann als schwerwiegender Sicherheitsvorfall unter die CRA-Sicherheitsvorfall-Meldepflicht fallen.
Was nicht automatisch gemeldet werden muss
Nicht jede Schwachstelle, Störung oder Attacke löst eine Cyber-Resilience-Act-Meldepflicht aus. Ein technischer Ausfall ohne Sicherheitsbezug oder ein Angriff auf die interne Unternehmens-IT fällt nicht allein deshalb unter Artikel 14. Voraussetzung ist ein Bezug zur Sicherheit des Produkts mit digitalen Elementen.
Unternehmen sollten jeden Verdachtsfall dennoch nachvollziehbar bewerten und dokumentieren. Auch wenn keine CRA-Meldepflicht besteht, können andere Vorgaben greifen – beispielsweise nach NIS2 oder dem Datenschutzrecht.
bbv Academy zu EU-Regeln
Machen Sie Ihr Team fit für den CRA
Die EU erlässt verschiedene Gesetze zu Cybersecurity. Das betrifft besonders Produkteentwickler:innen. Mit diesem Kurs erhalten sie den Durchblick
Welche CRA-Fristen müssen Unternehmen einhalten?
Der CRA sieht ein gestuftes Meldeverfahren vor. Entscheidend ist jeweils der Zeitpunkt, zu dem der Hersteller von der aktiv ausgenutzten Schwachstelle oder dem schwerwiegenden Sicherheitsvorfall Kenntnis erlangt:
- Unverzüglich, spätestens innerhalb von 24 Stunden: Frühwarnung mit den zu diesem Zeitpunkt verfügbaren Basisinformationen.
- Unverzüglich, spätestens innerhalb von 72 Stunden: ergänzende Schwachstellen- oder Vorfallmeldung mit einer ersten Einordnung sowie bereits getroffenen oder empfohlenen Korrektur- und Minderungsmassnahmen.
- Bei aktiv ausgenutzten Schwachstellen: Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Minderungsmassnahme verfügbar ist.
- Bei schwerwiegenden Sicherheitsvorfällen: Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung.
Die kurzen CRA-Fristen verlangen keine vollständig abgeschlossene Analyse innerhalb von 24 Stunden. Sie setzen aber voraus, dass ein Unternehmen ein relevantes Signal schnell erkennt, intern eskaliert und mit den verfügbaren Informationen meldet.
Bei Bedarf kann das koordinierende CSIRT zusätzliche Zwischenberichte verlangen. Hersteller müssen betroffene Nutzer zudem über die Schwachstelle beziehungsweise den Sicherheitsvorfall informieren und erforderlichenfalls auf Korrektur- oder Risikominderungsmassnahmen hinweisen.
Warum sind CRA-Meldepflichten nicht nur ein IT-Thema?
Technische Teams erkennen und analysieren Schwachstellen. Ob ein Ereignis die Kriterien aus Artikel 14 erfüllt, welche Informationen gemeldet werden und wie Nutzer informiert werden, betrifft jedoch mehrere Unternehmensbereiche: Product Security und Entwicklung liefern technische Fakten. Legal und Compliance ordnen die regulatorische Relevanz ein. Das Qualitätsmanagement sichert nachvollziehbare Abläufe und Nachweise. Das Management schafft Entscheidungsbefugnisse und Ressourcen.
Nur wenn diese Bereiche auf einen gemeinsamen Prozess zugreifen, lassen sich die Fristen zuverlässig einhalten. Eine zentrale Entscheidungsrolle sollte Meldungen auslösen dürfen, ohne auf langwierige Freigabeschlaufen angewiesen zu sein. Zugleich muss klar sein, welche weiteren regulatorischen Vorgaben geprüft werden. Ein Vorfall kann neben der CRA-Sicherheitsvorfall-Meldepflicht weitere Benachrichtigungen erfordern.
Diese Prozesse sollten Unternehmen jetzt etabliert haben
Ein belastbares Meldesystem verbindet Erkennung, Bewertung, Entscheidung, Kommunikation und Nachweisführung. Folgende Bausteine gehören dazu:
- Verantwortlichkeiten: Zuständigkeiten, Stellvertretungen und Eskalationsrechte für Product Security, Entwicklung, Legal, Kommunikation und Management festlegen.
- Incident Response: Produktbezogene Vorfälle in den bestehenden Prozess integrieren und regulatorische Prüfpunkte ergänzen.
- Schwachstellenbewertung: Hinweise auf aktive Ausnutzung, betroffene Versionen, Auswirkungen und verfügbare Gegenmassnahmen strukturiert erfassen.
- Meldeentscheidung: Kriterien aus Artikel 14 in einem dokumentierten Entscheidungsbaum abbilden und die 24-Stunden-Frist ab Kenntnisnahme berücksichtigen.
- Dokumentation und Kommunikation: Entscheidungen, Zeitpunkte und Meldungsinhalte revisionsfähig festhalten sowie Nutzerinformationen vorbereiten.
- Lieferkette: Vertragliche Meldewege und Fristen mit Komponentenlieferanten definieren. Eine aktuelle Software Bill of Materials (SBOM) erleichtert die Zuordnung betroffener Produkte.
- Secure Development Lifecycle: Erkenntnisse aus Vorfällen in Architektur, Entwicklung, Tests, Releases und Schwachstellenmanagement zurückführen.
Mit der Checkliste zur Umsetzung des Cyber Resilience Act können Sie prüfen, welche organisatorischen und technischen Anforderungen bereits abgedeckt sind und wo noch Handlungsbedarf besteht.
Typische Stolpersteine in der Praxis
In der Praxis scheitert die Umsetzung oft nicht am Fachwissen, sondern an unklaren Übergaben und fehlenden Entscheidungswegen. Besonders kritisch sind folgende Punkte:
- Unklare Verantwortung: Security erkennt einen Vorfall, aber niemand entscheidet verbindlich, ob eine CRA-Meldepflicht besteht.
- Verteilte Produktinformationen: Relevante Angaben liegen in Entwicklung, Qualitätsmanagement, Support oder Lieferantenportalen und müssen unter Zeitdruck zusammengetragen werden.
- Verspätete Lieferantenmeldungen: Komponentenlieferanten informieren zu spät oder liefern nicht genügend Details für eine belastbare Bewertung.
- Fehlende Produktübersicht: Unvollständige Asset- und SBOM-Daten erschweren die schnelle Feststellung, welche Produkte und Versionen betroffen sind.
- Zu eng gefasste Incident Response: Der Prozess endet mit der technischen Behebung. Regulatorische Bewertung, Nutzerinformation und Abschlussmeldung bleiben offen.
Checkliste
Für die erfolgreiche Implementierung des Cyber Resilience Act
Unsere Checkliste zur Umsetzung des Cyber Resilience Act bietet Ihnen einen klaren Leitfaden, um alle erforderlichen Schritte effizient zu planen und umzusetzen.
Praxis-Tipp: Mit einer Tabletop-Übung lässt sich prüfen, ob die Beteiligten auch unter Zeitdruck abgestimmt handeln. Das Team sollte dabei nicht nur einen Cyberangriff simulieren, sondern den gesamten Meldeprozess durchspielen: Wann gilt der Vorfall als bekannt? Wer bewertet die Meldepflicht? Wer startet die Fristen, gibt die Meldung frei und koordiniert die Nutzerinformation?
Ergänzend können Entwicklungs- und Security-Teams mit der Security Principles Checklist prüfen, welche Sicherheitsprinzipien in Architektur, Entwicklung und Betrieb bereits berücksichtigt werden und wo noch Lücken bestehen.
CRA-Meldepflichten als Chance nutzen
Ein guter Meldeprozess dient nicht nur der Compliance. Er verkürzt die Zeit zwischen Erkennung und Reaktion, schafft eindeutige Verantwortlichkeiten und verbessert die Qualität sicherheitsrelevanter Produktdaten. Strukturierte Rückmeldungen aus Vorfällen können direkt in die Entwicklung und das Produktmanagement einfliessen. Das unterstützt robustere Releases und nachvollziehbare Entscheidungen gegenüber Kunden, Partnern und Aufsichtsstellen.
Zugleich bereiten sich Unternehmen damit auf die vollständige CRA-Anwendung ab Dezember 2027 vor. Wer heute Verantwortlichkeiten, SBOM-Daten, Schwachstellenmanagement und Nutzerkommunikation verbindet, schafft ein operatives Fundament für die weiteren Produkt- und Nachweispflichten. Mit der CRA Survival Map behalten Sie anstehende Pflichten, Verantwortlichkeiten und Umsetzungsschritte über den gesamten CRA-Zeitraum im Blick.
CRA-Meldepflichten als Grundlage für nachhaltige Cyber-Resilienz
Die Meldepflichten des Cyber Resilience Act sind mehr als eine regulatorische Formalität. Sie verlangen, dass Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle schnell erkennen, fundiert bewerten und fristgerecht melden. Entscheidend sind nicht allein technische Werkzeuge, sondern klare Rollen, belastbare Daten und abgestimmte Entscheidungen über Abteilungsgrenzen hinweg.
Gerade für mittelgrosse Unternehmen lohnt sich ein pragmatischer Einstieg. Die CRA-Meldepflichten verlangen keinen überdimensionierten Apparat, sondern klare Zuständigkeiten, belastbare Produktinformationen und einen Prozess, der im Ernstfall funktioniert. Wer diese Grundlagen jetzt schafft, kann die Anforderungen angemessen umsetzen und bleibt auch unter Zeitdruck handlungsfähig.
bbv unterstützt Sie dabei, die Meldepflichten des Cyber Resilience Act in bestehende Abläufe zu integrieren, Verantwortlichkeiten zu klären und die Organisation Schritt für Schritt auf die vollständige Anwendung des CRA vorzubereiten.
FAQ zu CRA-Meldepflichten
Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle melden. Die Meldung erfolgt über die Single Reporting Platform von ENISA und betrifft Unternehmen, die Hardware oder Software geschäftlich auf dem EU-Markt bereitstellen.
Eine Schwachstelle ist nicht automatisch meldepflichtig. Die Meldepflicht greift erst, wenn verlässliche Hinweise auf eine tatsächliche aktive Ausnutzung vorliegen, etwa durch Sicherheitsanalysen, Protokolldaten oder bestätigte Meldungen von Behörden, Kunden oder Sicherheitsforschenden.
Hersteller müssen spätestens innerhalb von 24 Stunden eine Frühwarnung abgeben und spätestens innerhalb von 72 Stunden eine ergänzende Meldung nachreichen. Bei aktiv ausgenutzten Schwachstellen folgt der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmassnahme. Bei schwerwiegenden Sicherheitsvorfällen ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung fällig.
DAS KÖNNTE SIE AUCH INTERESSIEREN
Das Tal der Tränen überwinden: KI-Implementierung und neue Workflows
CRA trifft Realität: 5 typische Fehler, die Unternehmen aktuell machen
Das letzte Bollwerk – Datenschutz & PII-Schutz in der KI
