Bin ich überhaupt meldepflichtig? (Schnellcheck) Meldepflichtig nach Art. 14 VO (EU) 2024/2847 sind ausschließlich Hersteller von Produkten mit digitalen Elementen. Importeure und Händler haben eigene Pflichten, sind aber nicht selbst Adressat der Meldepflicht. Prüfen Sie zuerst Ihre Rolle, bevor Sie einen Prozess aufsetzen. Welche Rollen sind meldepflichtig Der Cyber Resilience Act unterscheidet (neben der Spezialrolle des “Open Source Stewards”), drei primäre Wirtschaftsakteure. Nur eine Rolle trägt die Meldepflicht aus Art. 14. Hersteller: Entwickelt oder lässt ein Produkt mit digitalen Elementen entwickeln und bringt es unter eigenem Namen oder eigener Marke in Verkehr. Trägt die Meldepflicht nach Art. 14. Importeur: Bringt ein Produkt aus einem Drittstaat in den EU-Markt. Muss laut Art. 19 den Hersteller informieren, wenn er Grund zur Annahme hat, dass ein Produkt nicht konform ist. Meldet nicht selbst an die Single Reporting Platform. Händler/Distributor: Stellt ein Produkt auf dem Markt bereit, ohne Hersteller oder Importeur zu sein. Hat laut Art. 20 vergleichbare Sorgfaltspflichten gegenüber dem Hersteller, aber keine eigenständige Meldepflicht nach Art. 14. Wenn Sie ein fremdes Produkt lediglich vertreiben, sind Sie kein Meldepflichtiger im Sinne von Art. 14. Sie müssen aber Informationen über Schwachstellen oder Vorfälle unverzüglich an den Hersteller weiterleiten. Ergebnis: Meldepflichtig/Unklar/Nicht betroffen Sie sind meldepflichtig, wenn Sie Hersteller eines Produkts mit digitalen Elementen sind und eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall feststellen. Das gilt unabhängig von der Unternehmensgröße. Ihr Status ist unklar, wenn Sie Software oder Hardware unter eigener Marke vertreiben, die Entwicklung aber ausgelagert haben, oder wenn Sie White-Label-Produkte anbieten. In diesen Fällen entscheidet die tatsächliche Markenverantwortung, nicht die technische Entwicklungsleistung. Sie sind nicht selbst meldepflichtig, wenn Sie ausschließlich als Importeur oder Händler auftreten. Sie behalten dennoch Melde- und Informationspflichten gegenüber dem Hersteller. Eine vollständige Einordnung aller CRA-Pflichten für Ihre Rolle finden Sie im Schnellcheck zu den CRA-Anforderungen. Melde-Trigger Was löst eine Meldung aus? Die CRA-Trigger im Überblick Der CRA kennt zwei getrennte Meldestränge: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Beide Stränge haben eigene Fristen und eigene Rechtsgrundlagen. Verwechseln Sie beide Kategorien nicht, denn die Berichtsinhalte unterscheiden sich. Aktiv ausgenutzte Schwachstellen Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Nachweise zeigen, dass ein böswilliger Akteur sie bereits ausnutzt (Art. 3 Nr. 42). Das ist die gesetzliche Definition, an der Sie sich orientieren müssen. Ein bloßer Verdacht reicht nicht aus. Maßgeblich ist der Zeitpunkt, an dem Sie Kenntnis von der aktiven Ausnutzung erlangen. Ab diesem Moment beginnt die Frist für die Frühwarnung zu laufen. Dieser Meldestrang folgt Art. 14 Abs. 1 und Abs. 2. Die Meldung geht zunächst bei der einheitlichen Meldeplattform ein, die ENISA (European Union Agency for Cybersecurity) betreibt. Von dort wird sie gleichzeitig an ENISA und an das koordinierende CSIRT (Computer Security Incident Response Team) weitergeleitet. Typische Beispiele sind ein öffentlich dokumentierter Exploit gegen Ihre Software oder ein Angriff, den Sie über Ihre eigene Telemetrie oder über Dritte bestätigt bekommen. Entscheidend ist die tatsächliche Ausnutzung, nicht die theoretische Ausnutzbarkeit. Sicherheitsvorfälle mit erheblichen Auswirkungen Ein schwerwiegender Sicherheitsvorfall betrifft die Sicherheit des Produkts mit digitalen Elementen selbst und löst den zweiten Meldestrang aus (Art. 14 Abs. 3 und Abs. 4). Die Definition, wann ein Vorfall als schwerwiegend gilt, ist in Art. 14 Abs. 5 geregelt. Zu den dort genannten Kriterien zählen unter anderem die tatsächliche oder mögliche Beeinträchtigung der Verfügbarkeit, Integrität oder Vertraulichkeit des Produkts sowie das Ausmaß der betroffenen Nutzendenbasis. Auch das Schadenspotenzial für Dritte spielt eine Rolle. Auch hier beginnt die Frist mit der Kenntniserlangung vom Vorfall, nicht mit dessen tatsächlichem Eintritt. Dokumentieren Sie deshalb immer den Zeitpunkt, an dem Ihr Unternehmen erstmals verlässliche Informationen erhalten hat. Grenzfälle Nicht jede gemeldete Schwachstelle und nicht jede Anomalie löst automatisch eine CRA-Meldung aus. Eine theoretische Schwachstelle ohne Ausnutzungsnachweis fällt nicht unter Art. 14 Abs. 1. Sie unterliegt stattdessen Ihrer Coordinated Vulnerability Disclosure Policy nach Art. 13 CRA. Ein interner Fehlalarm oder ein abgewehrter Angriffsversuch ohne Auswirkung auf das Produkt erfüllt in der Regel nicht die Schwelle aus Art. 14 Abs. 5. Prüfen Sie in Zweifelsfällen konkret anhand der dort genannten Kriterien, ob eine erhebliche Auswirkung vorliegt. Bei Unsicherheit empfiehlt sich eine kurze interne rechtliche Prüfung, bevor Sie eine Entscheidung gegen eine Meldung treffen. Eine unterlassene Meldung ist regulatorisch riskanter als eine im Ergebnis nicht notwendige Meldung. Meldekanäle: Wo Trigger-Informationen entstehen Meldeauslösende Informationen erreichen Unternehmen über unterschiedliche Kanäle. Bauen Sie Ihren Meldeprozess so auf, dass alle Kanäle an einer zentralen Stelle zusammenlaufen. Nur so erkennen Sie Trigger rechtzeitig. Relevante Kanäle sind unter anderem: Meldungen von Sicherheitsforschenden über Ihren Vulnerability-Disclosure-Kanal Eigene SOC- oder SIEM-Alarme (Security Operations Center, Security Information and Event Management) Hinweise von Kundinnen und Kunden oder Nutzenden Informationen von Zulieferern oder Komponentenherstellern Öffentlich bekannt gewordene Exploits aus CVE-Datenbanken (Common Vulnerabilities and Exposures) und ähnlichen Advisories Meldungen von Importeuren oder Händlern gemäß Art. 19 und Art. 20 Welche Fristen gelten? Der CRA setzt für beide Meldestränge identische Fristen für Frühwarnung und Erstmeldung, aber unterschiedliche Fristen für den Abschlussbericht. Die Uhr beginnt mit Ihrer Kenntniserlangung zu ticken, nicht mit dem tatsächlichen Ereignis. Eine Übersicht aller CRA-Fristen jenseits der Meldepflicht finden Sie in unserer Timeline zu den CRA-Fristen. Erstmeldung 24h Innerhalb von 24 Stunden nach Kenntniserlangung müssen Sie eine Frühwarnung übermitteln. Das gilt für beide Meldestränge gleichermaßen: aktiv ausgenutzte Schwachstelle (Art. 14 Abs. 1) und schwerwiegender Sicherheitsvorfall (Art. 14 Abs. 3). Diese Frühwarnung ist bewusst knapp gehalten und dient der schnellen Erstinformation. Die Frühwarnung muss noch keine vollständige Analyse enthalten. Sie signalisiert dem koordinierenden CSIRT, dass ein meldepflichtiges Ereignis vorliegt und weitere Informationen folgen. Folgemeldung/Vorfallsmeldung 72h Innerhalb von 72 Stunden nach Kenntniserlangung folgt die ausführlichere Meldung. Bei aktiv ausgenutzten Schwachstellen ist das die Schwachstellenmeldung nach Art. 14 Abs. 2. Bei schwerwiegenden Sicherheitsvorfällen ist das die Vorfallsmeldung nach Art. 14 Abs. 4. Diese Meldung enthält bereits eine erste Bewertung des Ereignisses, einschließlich Schweregrad und Auswirkungen, soweit zu diesem Zeitpunkt bekannt. Beide 72-Stunden-Fristen laufen ab dem gleichen Kenntniszeitpunkt wie die 24-Stunden-Frist, nicht erst ab der Frühwarnung. Abschlussbericht Der Abschlussbericht folgt bei den zwei Meldesträngen nach unterschiedlicher Logik. Verwechseln Sie die beiden Fristen nicht, da falsche Fristannahmen zu einer verspäteten Meldung führen können. Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme fällig. Der Fristbeginn koppelt sich hier an die Bereitstellung eines Fixes, nicht an die 72-Stunden-Meldung. Bei einem schwerwiegenden Sicherheitsvorfall ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Vorfallsmeldung fällig (Art. 14 Abs. 4 lit. c). Der Fristbeginn liegt hier fest an der bereits erfolgten 72-Stunden-Meldung, unabhängig vom Stand einer möglichen Behebung. Zusätzlich kann das koordinierende CSIRT einen Zwischenbericht anfordern, wenn es diesen für erforderlich hält (Art. 14 Abs. 6). Dieser Zwischenbericht ist keine Pflichtmeldung aus eigenem Antrieb, sondern erfolgt nur auf ausdrückliche Anforderung. An wen geht die Meldung Die Meldung erfolgt über die einheitliche Meldeplattform (SRP, Single Reporting latform) an den elektronischen Endpunkt des koordinierenden CSIRT (Art. 14 Abs. 7 i. V. m. Art. 16). Zuständig ist in der Regel das CSIRT des Mitgliedstaats, in dem sich Ihre Hauptniederlassung befindet. ENISA erhält gleichzeitig Zugriff auf die Meldung. ENISA betreibt die Plattform und ist Mitempfänger, nicht primärer Adressat. Getrennt davon regelt Art. 14 Abs. 8 die Informationspflicht gegenüber betroffenen oder allen Nutzenden. Diese Information kann auch maschinenlesbar erfolgen, etwa über ein Security-Advisory-Format. Sie ersetzt nicht die Meldung an das CSIRT und ist nicht mit einer Weiterleitung an Marktüberwachungsbehörden gleichzusetzen. Was muss die Meldung enthalten? Der Umfang der Angaben wächst mit jeder Meldestufe. Die Frühwarnung bleibt knapp, der Abschlussbericht liefert die vollständige Analyse. Bereiten Sie Ihre Vorlagen entsprechend gestaffelt vor. Pflichtangaben Erstmeldung Die 24-Stunden-Frühwarnung sollte mindestens folgende Angaben enthalten: Produktname, Version und HerstellerArt des Ereignisses (aktiv ausgenutzte Schwachstelle oder Sicherheitsvorfall)Zeitpunkt der KenntniserlangungErste Einschätzung der betroffenen Nutzendenbasis, soweit bekanntAnsprechperson für Rückfragen des CSIRT Zusätzliche Angaben Folgemeldung/Abschlussbericht Die 72-Stunden-Meldung ergänzt die Frühwarnung um eine erste inhaltliche Bewertung. Dazu zählen Schweregrad, betroffene Produktversionen und, soweit bereits vorhanden, geplante Gegenmaßnahmen. Der Abschlussbericht enthält zusätzlich eine vollständige Ursachenanalyse, die umgesetzten oder verfügbaren Korrekturmaßnahmen sowie eine Bewertung der tatsächlichen Auswirkungen. Bei Sicherheitsvorfällen gehört auch eine Einschätzung zur Wirksamkeit der ergriffenen Reaktionsmaßnahmen dazu. Nachweisanforderungen/Audit-Trail Dokumentieren Sie jeden Schritt des Meldeprozesses lückenlos, einschließlich Zeitstempeln. Ein sauberer Audit-Trail schützt Sie im Streitfall und erleichtert die interne Nachvollziehbarkeit. Halten Sie mindestens Trigger-Zeitpunkt, Meldezeitpunkte und verantwortliche Person fest. Beispiel für ein Audit-Trail-Log bei einer aktiv ausgenutzten Schwachstelle:EreignisZeitpunktFristStatusKenntniserlangung (Trigger)13.08.2026, 09:12 Uhr– Dokumentiert Frühwarnung (24h)13.08.2026, 18:40 Uhrbis 14.08.2026, 09:12 UhrFristgerechtSchwachstellenmeldung (72h)15.08.2026, 14:05 Uhrbis 16.08.2026, 09:12 UhrFristgerechtAbschlussbericht14 Tage nach Fix-Verfügbarkeitabhängig vom Patch-TerminOffen Wer ist intern verantwortlich? Ohne klare Rollenverteilung verstreichen 24-Stunden-Fristen unbemerkt. Legen Sie Verantwortlichkeiten fest, bevor ein Ereignis eintritt, nicht währenddessen. Das gilt besonders für Unternehmen mit verteilten Produktteams. CRA-Rollen zu Unternehmensrollen Der CRA definiert rechtliche Rollen, die Sie auf konkrete Positionen in Ihrem Unternehmen abbilden müssen. In der Praxis übernimmt meist ein Product Security Incident Response Team (PSIRT) die fachliche Bewertung. Die formale Meldung erfolgt häufig über die Rechts- oder Compliance-Abteilung, in enger Abstimmung mit dem PSIRT. RACI-Matrix Eine RACI-Matrix schafft Klarheit über Zuständigkeiten entlang des Meldeprozesses. Dabei werden für relevante Rollen die entsprechenden Zuständigkeiten und der Umfang der Einbindung dargestellt. Es wird ersichtlich wer bei welcher Aufgabe die Umsetzungszuständigkeit (responsible) trägt, wer haftend zurechenbar ist (accountable), wer informiert wird (informed) oder beratend unterstützt (consulted). Die konkrete Ausgestaltung ist stark unternehmens- und kontextabhängig. Eskalationspfade Definieren Sie feste Eskalationsstufen, die unabhängig von Urlaubs- oder Krankheitszeiten funktionieren. Ein Ereignis am Wochenende darf die 24-Stunden-Frist nicht gefährden. Hinterlegen Sie deshalb Vertretungsregelungen und mindestens einen Notfallkontakt außerhalb der Kernarbeitszeiten. Eine verspätete interne Klärung darf nicht dazu führen, dass die 24-Stunden-Frist gegenüber dem CSIRT verstreicht. Meldeprozess Wie setze ich den Meldeprozess auf? Meldekanäle zentral bündeln Führen Sie alle potenziellen Trigger-Quellen in einem zentralen System zusammen, etwa einem Ticketsystem oder einer PSIRT-Mailbox. Ohne Bündelung gehen frühe Warnsignale unter, vor allem bei Meldungen von Sicherheitsforschenden. Der CRA schreibt einen verplfichtenden Single-Point-of-Contact vor (siehe CRA, Anhang II, 2) 2 Validierung Erstellen Sie ein Bewertungsschema, das jeingehende Hinweise auf ihre Validität prüft und in in verschiedene Kategorien einordnet, u.a. aktiv ausgenutzte Schwachstelle, schwerwiegender Vorfall,kein Trigger. 3 Fristen technisch überwachen Hinterlegen Sie automatisierte Erinnerungen für die 24-Stunden- und 72-Stunden-Fristen, ausgelöst durch den dokumentierten Kenntniszeitpunkt. Verlassen Sie sich nicht auf manuelle Kalendereinträge einzelner Mitarbeitender. 4 Nachbereitung und Lessons Learned Werten Sie jeden abgeschlossenen Meldefall intern aus. Prüfen Sie, ob Fristen eingehalten wurden und wo der Prozess Verzögerungen verursacht hat. Wer den Meldeprozess proaktiv in seine Compliance-Struktur einbettet, reduziert das Risiko verspäteter Meldungen deutlich, wie unser Beitrag zur CRA-Compliance-Umsetzung zeigt. Vulnerability Disclosure nach CRA Die Coordinated Vulnerability Disclosure Policy ist von der Meldepflicht nach Art. 14 zu unterscheiden. Beide Mechanismen ergänzen sich, folgen aber unterschiedlichen Zwecken. Was ist Vulnerability Disclosure Nach Art. 13 CRA müssen Hersteller eine Coordinated Vulnerability Disclosure Policy einführen. Sie regelt, wie Sicherheitsforschende Schwachstellen an Sie melden können und wie Sie mit diesen Meldungen umgehen. Ziel ist ein strukturierter Kanal, über den Schwachstellen gemeldet werden, bevor sie öffentlich bekannt oder ausgenutzt werden. Verhältnis zur Meldepflicht Eine über den Disclosure-Kanal gemeldete Schwachstelle löst nicht automatisch eine CRA-Meldung an das CSIRT aus. Erst wenn verlässliche Nachweise einer aktiven Ausnutzung vorliegen, greift Art. 14 Abs. 1. Bis dahin bearbeiten Sie die Meldung im Rahmen Ihres Vulnerability-Management-Prozesses. Die Disclosure Policy ist damit vorgelagert: Sie hilft, Schwachstellen frühzeitig zu erkennen, bevor sie zum Trigger für eine Meldepflicht werden. Ein funktionierender Disclosure-Prozess reduziert das Risiko, dass eine Schwachstelle unbemerkt aktiv ausgenutzt wird. Zusammenspiel mit nationaler Anlaufstelle Für Rückfragen zu Ihrer Disclosure Policy oder zur Einordnung von Grenzfällen können Sie sich an die nationale Anlaufstelle wenden. Diese Stelle unterstützt bei Auslegungsfragen, ersetzt aber nicht die Meldung an das koordinierende CSIRT bei einem tatsächlichen Trigger-Ereignis. Typische Fehler Die häufigsten Fehler bei der CRA-Meldepflicht entstehen durch falsche Fristannahmen und unklare Zuständigkeiten. Die folgenden vier Muster tauchen in der Praxis besonders oft auf. Die folgenden vier Muster tauchen in der Praxis besonders oft auf. 01 Fehler 1: Fristbeginn mit dem Ereignis statt mit der Kenntniserlangung verwechseln Viele Unternehmen zählen die 24-Stunden-Frist ab dem tatsächlichen Eintritt des Vorfalls. Maßgeblich ist aber der Zeitpunkt, an dem Sie verlässliche Kenntnis erlangen. Dokumentieren Sie diesen Zeitpunkt aktiv, sonst lässt sich die Fristeinhaltung später nicht belegen. 02 Fehler 2: Aktiv ausgenutzte Schwachstelle mit theoretischer Schwachstelle gleichsetzen Nicht jede gemeldete Schwachstelle löst Art. 14 Abs. 1 aus. Ohne Nachweis einer tatsächlichen Ausnutzung durch einen böswilligen Akteur kann es bei der Bearbeitung über die Vulnerability Disclosure Policy bleiben. 03 Fehler 3: Die Rolle von ENISA und der Meldeplattform missverstehen Die Meldung erfolgt über die von ENISA betriebene einheitliche Meldeplattform, das ist der korrekte und einzige Einreichungsweg. Die Plattform leitet die Meldung automatisch gleichzeitig an das koordinierende CSIRT und an ENISA weiter. Der Fehler liegt darin zusätzlich eigene, direkte Meldewege an einzelne nationale Behörden aufzubauen. 04 Fehler 4: Nutzendeninformation mit der Behördenmeldung verwechseln Die Information der Nutzenden nach Art. 14 Abs. 8 ersetzt nicht die Meldung an das CSIRT. Beide Pflichten laufen parallel und mit unterschiedlichen Adressaten. Wer nur die Nutzenden informiert, hat die eigentliche Meldepflicht nicht erfüllt. Templates & Checklisten Vorbereitete Vorlagen verkürzen die Reaktionszeit im Ernstfall erheblich. Passen Sie die folgenden Muster an Ihre internen Prozesse an, bevor Sie sie produktiv einsetzen. Inhalt Meldetemplate Betreff: CRA-Erstmeldung nach Artikel 14 VO (EU) 2024/2847, [Produktname] Inhalt der Frühwarnung: Hersteller und Kontaktdaten Betroffenes Produkt und Version Art des Ereignisses (aktiv ausgenutzte Schwachstelle oder Sicherheitsvorfall) Zeitpunkt der Kenntniserlangung Erste Einschätzung der Auswirkungen Verantwortliche Ansprechperson Inhalt Checkliste Rolle im Sinne des CRA geklärt (Hersteller, Importeur oder Händler) Zuständiges koordinierendes CSIRT identifiziert Fristüberwachung technisch hinterlegt RACI-Matrix mit Vertretungsregelung dokumentiert Vulnerability Disclosure Policy nach Art. 13 CRA festgelegt Nutzendeninformation nach Art. 14 Abs. 8 als eigenen Prozessschritt definiert Häufige Fragen (FAQ) Die folgenden sechs Fragen fassen die zentralen Praxisfragen zur CRA-Meldepflicht zusammen. Welche Ereignisse lösen eine CRA-Meldung aus? Zwei Ereignistypen lösen eine Meldung aus: eine aktiv ausgenutzte Schwachstelle mit verlässlichem Ausnutzungsnachweis und ein schwerwiegender Sicherheitsvorfall nach den Kriterien aus Art. 14 Abs. 5. Eine rein theoretische Schwachstelle ohne Ausnutzungsnachweis zählt nicht dazu. Welche Fristen gelten für die CRA-Meldepflicht? Für beide Meldestränge gilt eine Frühwarnung binnen 24 Stunden und eine ausführlichere Meldung binnen 72 Stunden nach Kenntniserlangung. Der Abschlussbericht folgt bei Schwachstellen 14 Tage nach Verfügbarkeit eines Fixes, bei Sicherheitsvorfällen einen Monat nach der 72-Stunden-Meldung. An welche Behörde muss ich nach dem Cyber Resilience Act melden? Die Meldung geht über die einheitliche Meldeplattform an das koordinierende CSIRT des Mitgliedstaats Ihrer Hauptniederlassung. ENISA erhält gleichzeitig Zugriff auf die Meldung. Was ist der Unterschied zwischen CRA-Meldepflicht und NIS2-Meldepflicht? Die CRA-Meldepflicht betrifft Hersteller von Produkten mit digitalen Elementen und bezieht sich auf Schwachstellen und Vorfälle am Produkt selbst. Die NIS2-Meldepflicht richtet sich an Betreiber kritischer und wichtiger Einrichtungen und betrifft Vorfälle in deren Betrieb. Beide Regelwerke können bei einem betroffenen Unternehmen parallel greifen. Was passiert, wenn ich die CRA-Meldepflicht nicht einhalte? Verstöße gegen die Meldepflicht können sanktioniert werden mit bis zu 15. Mio Euro oder 2,5% des weltweiten Jahresumsatzes. Gilt die CRA-Meldepflicht auch für Open-Source-Software? Der CRA unterscheidet drei Konstellationen. Wer Open-Source-Software kommerziell unter eigener Marke vertreibt, gilt als Hersteller und unterliegt der vollen Meldepflicht nach Art. 14. Wer als Open-Source Software Steward im Sinne von Art. 3 Nr. 14 CRA, etwa als Stiftung oder Trägerorganisation, systematisch und dauerhaft die Entwicklung eines kommerziell genutzten FOSS-Produkts unterstützt, trägt eigene, reduzierte Pflichten nach Art. 24, darunter eine eingeschränkte Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, soweit die eigenen Entwicklungssysteme betroffen sind. Rein nicht kommerzielle, ehrenamtliche Open-Source-Entwicklung ohne Steward-Struktur fällt in der Regel nicht unter den CRA. Prüfen Sie Ihre konkrete Konstellation im Einzelfall. Wie wir Sie unterstützen Axians unterstützt Sie beim Aufbau eines nachweisfesten CRA-Meldeprozesses, von der Rollenklärung bis zur technischen Fristüberwachung. Wir helfen bei der Rollenklärung, der Trigger-Bewertung und der technischen Fristüberwachung. Gemeinsam entwickeln wir Meldevorlagen, RACI-Matrizen und Eskalationspfade, die zu Ihrer Organisationsstruktur passen. So vermeiden Sie verspätete Meldungen und schaffen Klarheit für alle Beteiligten. CRA-Meldeprozess mit Axians aufsetzen Quellen: EUR-Lex, Volltext der Verordnung (EU) 2024/2847 ENISA, CRA-Themenseite BSI, CRA-Themenseite Rechtlicher Hinweis Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung. Er spiegelt den Stand der Verordnung (EU) 2024/2847 zum Zeitpunkt der Veröffentlichung wider. Für eine rechtsverbindliche Einschätzung Ihrer individuellen Meldepflichten wenden Sie sich an eine auf IT-Recht spezialisierte Rechtsberatung. Das könnte Sie auch interessieren: Cyber Resilience Act Timeline: Alle Fristen und Meilensteine im Überblick Der Cyber Resilience Act (CRA) gilt vollständig ab dem 11. Dezember 2027. Die Meldepflicht für Schwachstellen und Sicherheitsvorfälle startet bereits am 11. September 2026, unabhängig davon, wann Ihr Produkt in Verkehr gebracht wurde. Ohne bestehende Sicherheitszertifizierung sollten Sie 14 bis 20 M CRA Weiterlesen → CRA-Meldepflicht: Wann, was und an wen melden. So setzen Sie den Prozess nachweisfest auf. CRA-Meldepflicht: Welche Ereignisse lösen eine Meldung aus, welche Fristen gelten und wie Sie den Meldeprozess nachweisfest aufsetzen. CRA Weiterlesen → CRA, NIS2, DORA und CSA: Welche EU-Verordnung gilt für Ihr Unternehmen? CRA, NIS2, DORA, CSA – welche EU-Verordnung betrifft Ihr Unternehmen? Klare Abgrenzung, Vergleichstabelle und Einordnung für IT-Entscheider. CRA Weiterlesen → CRA Compliance: Schritt für Schritt zur Umsetzung des Cyber Resilience Act CRA Compliance konkret: Pflichten ableiten, Nachweise sichern, Fristen einhalten. Checkliste & Umsetzungsplan für den Cyber Resilience Act. CRA Weiterlesen → Cyber Resilience Act: Anforderungen, Anwendungsbereich und wer betroffen ist Welche Anforderungen stellt der Cyber Resilience Act? Wer ist betroffen – und was gilt für IoT, SaaS, Open Source & Co.? Jetzt kompakt erklärt. CRA Weiterlesen → < Zurück zur Übersicht CRA
Sie sind meldepflichtig, wenn Sie Hersteller eines Produkts mit digitalen Elementen sind und eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall feststellen. Das gilt unabhängig von der Unternehmensgröße.
Ihr Status ist unklar, wenn Sie Software oder Hardware unter eigener Marke vertreiben, die Entwicklung aber ausgelagert haben, oder wenn Sie White-Label-Produkte anbieten. In diesen Fällen entscheidet die tatsächliche Markenverantwortung, nicht die technische Entwicklungsleistung.
Sie sind nicht selbst meldepflichtig, wenn Sie ausschließlich als Importeur oder Händler auftreten. Sie behalten dennoch Melde- und Informationspflichten gegenüber dem Hersteller. Eine vollständige Einordnung aller CRA-Pflichten für Ihre Rolle finden Sie im Schnellcheck zu den CRA-Anforderungen.
Aktiv ausgenutzte Schwachstellen Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Nachweise zeigen, dass ein böswilliger Akteur sie bereits ausnutzt (Art. 3 Nr. 42). Das ist die gesetzliche Definition, an der Sie sich orientieren müssen. Ein bloßer Verdacht reicht nicht aus. Maßgeblich ist der Zeitpunkt, an dem Sie Kenntnis von der aktiven Ausnutzung erlangen. Ab diesem Moment beginnt die Frist für die Frühwarnung zu laufen. Dieser Meldestrang folgt Art. 14 Abs. 1 und Abs. 2. Die Meldung geht zunächst bei der einheitlichen Meldeplattform ein, die ENISA (European Union Agency for Cybersecurity) betreibt. Von dort wird sie gleichzeitig an ENISA und an das koordinierende CSIRT (Computer Security Incident Response Team) weitergeleitet. Typische Beispiele sind ein öffentlich dokumentierter Exploit gegen Ihre Software oder ein Angriff, den Sie über Ihre eigene Telemetrie oder über Dritte bestätigt bekommen. Entscheidend ist die tatsächliche Ausnutzung, nicht die theoretische Ausnutzbarkeit.
Sicherheitsvorfälle mit erheblichen Auswirkungen Ein schwerwiegender Sicherheitsvorfall betrifft die Sicherheit des Produkts mit digitalen Elementen selbst und löst den zweiten Meldestrang aus (Art. 14 Abs. 3 und Abs. 4). Die Definition, wann ein Vorfall als schwerwiegend gilt, ist in Art. 14 Abs. 5 geregelt. Zu den dort genannten Kriterien zählen unter anderem die tatsächliche oder mögliche Beeinträchtigung der Verfügbarkeit, Integrität oder Vertraulichkeit des Produkts sowie das Ausmaß der betroffenen Nutzendenbasis. Auch das Schadenspotenzial für Dritte spielt eine Rolle. Auch hier beginnt die Frist mit der Kenntniserlangung vom Vorfall, nicht mit dessen tatsächlichem Eintritt. Dokumentieren Sie deshalb immer den Zeitpunkt, an dem Ihr Unternehmen erstmals verlässliche Informationen erhalten hat.
Grenzfälle Nicht jede gemeldete Schwachstelle und nicht jede Anomalie löst automatisch eine CRA-Meldung aus. Eine theoretische Schwachstelle ohne Ausnutzungsnachweis fällt nicht unter Art. 14 Abs. 1. Sie unterliegt stattdessen Ihrer Coordinated Vulnerability Disclosure Policy nach Art. 13 CRA. Ein interner Fehlalarm oder ein abgewehrter Angriffsversuch ohne Auswirkung auf das Produkt erfüllt in der Regel nicht die Schwelle aus Art. 14 Abs. 5. Prüfen Sie in Zweifelsfällen konkret anhand der dort genannten Kriterien, ob eine erhebliche Auswirkung vorliegt. Bei Unsicherheit empfiehlt sich eine kurze interne rechtliche Prüfung, bevor Sie eine Entscheidung gegen eine Meldung treffen. Eine unterlassene Meldung ist regulatorisch riskanter als eine im Ergebnis nicht notwendige Meldung.
Erstmeldung 24h Innerhalb von 24 Stunden nach Kenntniserlangung müssen Sie eine Frühwarnung übermitteln. Das gilt für beide Meldestränge gleichermaßen: aktiv ausgenutzte Schwachstelle (Art. 14 Abs. 1) und schwerwiegender Sicherheitsvorfall (Art. 14 Abs. 3). Diese Frühwarnung ist bewusst knapp gehalten und dient der schnellen Erstinformation. Die Frühwarnung muss noch keine vollständige Analyse enthalten. Sie signalisiert dem koordinierenden CSIRT, dass ein meldepflichtiges Ereignis vorliegt und weitere Informationen folgen.
Folgemeldung/Vorfallsmeldung 72h Innerhalb von 72 Stunden nach Kenntniserlangung folgt die ausführlichere Meldung. Bei aktiv ausgenutzten Schwachstellen ist das die Schwachstellenmeldung nach Art. 14 Abs. 2. Bei schwerwiegenden Sicherheitsvorfällen ist das die Vorfallsmeldung nach Art. 14 Abs. 4. Diese Meldung enthält bereits eine erste Bewertung des Ereignisses, einschließlich Schweregrad und Auswirkungen, soweit zu diesem Zeitpunkt bekannt. Beide 72-Stunden-Fristen laufen ab dem gleichen Kenntniszeitpunkt wie die 24-Stunden-Frist, nicht erst ab der Frühwarnung.
Abschlussbericht Der Abschlussbericht folgt bei den zwei Meldesträngen nach unterschiedlicher Logik. Verwechseln Sie die beiden Fristen nicht, da falsche Fristannahmen zu einer verspäteten Meldung führen können. Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme fällig. Der Fristbeginn koppelt sich hier an die Bereitstellung eines Fixes, nicht an die 72-Stunden-Meldung. Bei einem schwerwiegenden Sicherheitsvorfall ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Vorfallsmeldung fällig (Art. 14 Abs. 4 lit. c). Der Fristbeginn liegt hier fest an der bereits erfolgten 72-Stunden-Meldung, unabhängig vom Stand einer möglichen Behebung. Zusätzlich kann das koordinierende CSIRT einen Zwischenbericht anfordern, wenn es diesen für erforderlich hält (Art. 14 Abs. 6). Dieser Zwischenbericht ist keine Pflichtmeldung aus eigenem Antrieb, sondern erfolgt nur auf ausdrückliche Anforderung.
An wen geht die Meldung Die Meldung erfolgt über die einheitliche Meldeplattform (SRP, Single Reporting latform) an den elektronischen Endpunkt des koordinierenden CSIRT (Art. 14 Abs. 7 i. V. m. Art. 16). Zuständig ist in der Regel das CSIRT des Mitgliedstaats, in dem sich Ihre Hauptniederlassung befindet. ENISA erhält gleichzeitig Zugriff auf die Meldung. ENISA betreibt die Plattform und ist Mitempfänger, nicht primärer Adressat. Getrennt davon regelt Art. 14 Abs. 8 die Informationspflicht gegenüber betroffenen oder allen Nutzenden. Diese Information kann auch maschinenlesbar erfolgen, etwa über ein Security-Advisory-Format. Sie ersetzt nicht die Meldung an das CSIRT und ist nicht mit einer Weiterleitung an Marktüberwachungsbehörden gleichzusetzen.
CRA-Rollen zu Unternehmensrollen Der CRA definiert rechtliche Rollen, die Sie auf konkrete Positionen in Ihrem Unternehmen abbilden müssen. In der Praxis übernimmt meist ein Product Security Incident Response Team (PSIRT) die fachliche Bewertung. Die formale Meldung erfolgt häufig über die Rechts- oder Compliance-Abteilung, in enger Abstimmung mit dem PSIRT.
RACI-Matrix Eine RACI-Matrix schafft Klarheit über Zuständigkeiten entlang des Meldeprozesses. Dabei werden für relevante Rollen die entsprechenden Zuständigkeiten und der Umfang der Einbindung dargestellt. Es wird ersichtlich wer bei welcher Aufgabe die Umsetzungszuständigkeit (responsible) trägt, wer haftend zurechenbar ist (accountable), wer informiert wird (informed) oder beratend unterstützt (consulted). Die konkrete Ausgestaltung ist stark unternehmens- und kontextabhängig.
Eskalationspfade Definieren Sie feste Eskalationsstufen, die unabhängig von Urlaubs- oder Krankheitszeiten funktionieren. Ein Ereignis am Wochenende darf die 24-Stunden-Frist nicht gefährden. Hinterlegen Sie deshalb Vertretungsregelungen und mindestens einen Notfallkontakt außerhalb der Kernarbeitszeiten. Eine verspätete interne Klärung darf nicht dazu führen, dass die 24-Stunden-Frist gegenüber dem CSIRT verstreicht.
Was ist Vulnerability Disclosure Nach Art. 13 CRA müssen Hersteller eine Coordinated Vulnerability Disclosure Policy einführen. Sie regelt, wie Sicherheitsforschende Schwachstellen an Sie melden können und wie Sie mit diesen Meldungen umgehen. Ziel ist ein strukturierter Kanal, über den Schwachstellen gemeldet werden, bevor sie öffentlich bekannt oder ausgenutzt werden.
Verhältnis zur Meldepflicht Eine über den Disclosure-Kanal gemeldete Schwachstelle löst nicht automatisch eine CRA-Meldung an das CSIRT aus. Erst wenn verlässliche Nachweise einer aktiven Ausnutzung vorliegen, greift Art. 14 Abs. 1. Bis dahin bearbeiten Sie die Meldung im Rahmen Ihres Vulnerability-Management-Prozesses. Die Disclosure Policy ist damit vorgelagert: Sie hilft, Schwachstellen frühzeitig zu erkennen, bevor sie zum Trigger für eine Meldepflicht werden. Ein funktionierender Disclosure-Prozess reduziert das Risiko, dass eine Schwachstelle unbemerkt aktiv ausgenutzt wird.
Zusammenspiel mit nationaler Anlaufstelle Für Rückfragen zu Ihrer Disclosure Policy oder zur Einordnung von Grenzfällen können Sie sich an die nationale Anlaufstelle wenden. Diese Stelle unterstützt bei Auslegungsfragen, ersetzt aber nicht die Meldung an das koordinierende CSIRT bei einem tatsächlichen Trigger-Ereignis.
01 Fehler 1: Fristbeginn mit dem Ereignis statt mit der Kenntniserlangung verwechseln Viele Unternehmen zählen die 24-Stunden-Frist ab dem tatsächlichen Eintritt des Vorfalls. Maßgeblich ist aber der Zeitpunkt, an dem Sie verlässliche Kenntnis erlangen. Dokumentieren Sie diesen Zeitpunkt aktiv, sonst lässt sich die Fristeinhaltung später nicht belegen.
02 Fehler 2: Aktiv ausgenutzte Schwachstelle mit theoretischer Schwachstelle gleichsetzen Nicht jede gemeldete Schwachstelle löst Art. 14 Abs. 1 aus. Ohne Nachweis einer tatsächlichen Ausnutzung durch einen böswilligen Akteur kann es bei der Bearbeitung über die Vulnerability Disclosure Policy bleiben.
03 Fehler 3: Die Rolle von ENISA und der Meldeplattform missverstehen Die Meldung erfolgt über die von ENISA betriebene einheitliche Meldeplattform, das ist der korrekte und einzige Einreichungsweg. Die Plattform leitet die Meldung automatisch gleichzeitig an das koordinierende CSIRT und an ENISA weiter. Der Fehler liegt darin zusätzlich eigene, direkte Meldewege an einzelne nationale Behörden aufzubauen.
04 Fehler 4: Nutzendeninformation mit der Behördenmeldung verwechseln Die Information der Nutzenden nach Art. 14 Abs. 8 ersetzt nicht die Meldung an das CSIRT. Beide Pflichten laufen parallel und mit unterschiedlichen Adressaten. Wer nur die Nutzenden informiert, hat die eigentliche Meldepflicht nicht erfüllt.
Inhalt Meldetemplate Betreff: CRA-Erstmeldung nach Artikel 14 VO (EU) 2024/2847, [Produktname] Inhalt der Frühwarnung: Hersteller und Kontaktdaten Betroffenes Produkt und Version Art des Ereignisses (aktiv ausgenutzte Schwachstelle oder Sicherheitsvorfall) Zeitpunkt der Kenntniserlangung Erste Einschätzung der Auswirkungen Verantwortliche Ansprechperson
Inhalt Checkliste Rolle im Sinne des CRA geklärt (Hersteller, Importeur oder Händler) Zuständiges koordinierendes CSIRT identifiziert Fristüberwachung technisch hinterlegt RACI-Matrix mit Vertretungsregelung dokumentiert Vulnerability Disclosure Policy nach Art. 13 CRA festgelegt Nutzendeninformation nach Art. 14 Abs. 8 als eigenen Prozessschritt definiert
Cyber Resilience Act Timeline: Alle Fristen und Meilensteine im Überblick Der Cyber Resilience Act (CRA) gilt vollständig ab dem 11. Dezember 2027. Die Meldepflicht für Schwachstellen und Sicherheitsvorfälle startet bereits am 11. September 2026, unabhängig davon, wann Ihr Produkt in Verkehr gebracht wurde. Ohne bestehende Sicherheitszertifizierung sollten Sie 14 bis 20 M CRA Weiterlesen →
CRA-Meldepflicht: Wann, was und an wen melden. So setzen Sie den Prozess nachweisfest auf. CRA-Meldepflicht: Welche Ereignisse lösen eine Meldung aus, welche Fristen gelten und wie Sie den Meldeprozess nachweisfest aufsetzen. CRA Weiterlesen →
CRA, NIS2, DORA und CSA: Welche EU-Verordnung gilt für Ihr Unternehmen? CRA, NIS2, DORA, CSA – welche EU-Verordnung betrifft Ihr Unternehmen? Klare Abgrenzung, Vergleichstabelle und Einordnung für IT-Entscheider. CRA Weiterlesen →
CRA Compliance: Schritt für Schritt zur Umsetzung des Cyber Resilience Act CRA Compliance konkret: Pflichten ableiten, Nachweise sichern, Fristen einhalten. Checkliste & Umsetzungsplan für den Cyber Resilience Act. CRA Weiterlesen →
Cyber Resilience Act: Anforderungen, Anwendungsbereich und wer betroffen ist Welche Anforderungen stellt der Cyber Resilience Act? Wer ist betroffen – und was gilt für IoT, SaaS, Open Source & Co.? Jetzt kompakt erklärt. CRA Weiterlesen →