CRA Artikel 14: Die 24-Stunden-Meldepflicht trifft die IR-Praxis
12.09.2026 crameldepflichtincident-responsenis2
Gestern, am 11. September 2026, ist etwas in Kraft getreten, das viele IR-Teams in Europa monatelang vorbereitet – und trotzdem unterschätzt haben: die Meldepflicht nach Artikel 14 des Cyber Resilience Act (CRA). Ab sofort müssen Hersteller von “Produkten mit digitalen Elementen” aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden an ENISA und das zuständige nationale CSIRT melden. Wer glaubt, das sei nur ein Compliance-Thema für Legal und Product Security, irrt: Die Uhr tickt ab dem Moment, in dem irgendjemand im Unternehmen Kenntnis erlangt – und genau das macht Artikel 14 zu einem IR-Prozessproblem.
Die Kaskade: 24 Stunden, 72 Stunden, 14 Tage
Der Meldemechanismus folgt einer klaren Struktur. Innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle oder eines schweren Vorfalls muss eine “Frühwarnung” an ENISA übermittelt werden, gefolgt von einer detaillierten Meldung innerhalb von 72 Stunden. Für Schwachstellen folgt danach ein Abschlussbericht innerhalb von 14 Tagen, für schwere Vorfälle innerhalb eines Monats. Die technische Abwicklung läuft über eine zentrale Plattform: Hersteller reichen eine einzige Meldung über die Single Reporting Platform beim zuständigen koordinierenden CSIRT und bei ENISA ein, die dann an weitere relevante CSIRTs weitergeleitet wird – ohne dass separate Meldungen auf Mitgliedstaatsebene nötig sind.
Für IR-Teams bedeutet das: Der Auslöser ist nicht die Bestätigung eines Vorfalls durch das SOC, sondern der erste Verdachtsmoment irgendwo in der Organisation. Genau hier liegt die operative Herausforderung, denn der Meldeprozess beginnt, sobald der Hersteller von der aktiv ausgenutzten Schwachstelle oder dem schweren Sicherheitsvorfall Kenntnis erlangt – interne Eskalation wird damit besonders wichtig. Ein Hinweis kann zuerst bei einem Entwickler, im Support oder bei einem Kundenkontakt auftauchen, lange bevor er das SOC erreicht.
Abgrenzung zu NIS2 – und warum beide Pflichten parallel greifen können
Wer bereits NIS2-Meldeprozesse etabliert hat, sollte CRA nicht als Dopplung missverstehen. Bei NIS2 ist der Auslöser ein erheblicher Vorfall mit Auswirkung auf die Dienstkontinuität, bei der CRA ist es die Entdeckung einer aktiv ausgenutzten Schwachstelle in einem Produkt, die eine schnelle, koordinierte Offenlegung erfordert, um größeren Schaden zu verhindern. Beide Regime können sich überschneiden: Eine CRA-Meldung betrifft eine aktiv ausgenutzte Schwachstelle oder einen schweren Vorfall im Produkt und läuft über CSIRT und ENISA, während eine NIS2-Meldung einen erheblichen Vorfall mit Auswirkung auf die eigenen Dienste im nationalen Regime betrifft – ein einzelnes Ereignis kann beide Pflichten auslösen. Wichtig für IR-Playbooks: Meldungen laufen über die von ENISA aufgebaute CRA-Plattform in das CSIRT der Hauptniederlassung des Herstellers, dann an ENISA und weitere betroffene nationale CSIRTs.
Zusätzlich gilt die Pflicht rückwirkend für Bestandsprodukte: Legacy-Produkte fallen unter die Meldepflicht, obwohl sie von der vollständigen CRA-Konformität ausgenommen sind – die Meldepflicht gilt für alles, was bereits auf dem Markt ist.
Was IR-Teams jetzt konkret tun müssen
Praktisch heißt das: Der klassische Incident-Response-Plan muss um CRA-spezifische Trigger erweitert werden. Empfohlen wird, den Incident-Response-Plan und die Vulnerability-Management-Richtlinien so zu aktualisieren, dass CRA-spezifische Trigger und Fristen neben NIS2, DSGVO und weiteren Vorgaben abgebildet sind, Meldevorlagen vorzubereiten und ein internes Vorfallprotokoll zu führen, das Zeitpunkt der Kenntnisnahme, Klassifizierungsentscheidung und Einreichung dokumentiert. Ergänzend braucht es einen belastbaren Triage-Prozess: Er muss nicht vollständig Annex-I-konform sein, aber funktionsfähig – mit Monitoring, Meldekanälen und einem Triage-Prozess, der die Schwere schnell einschätzen kann.
Für SOC- und IR-Verantwortliche ist die Botschaft eindeutig: Artikel 14 ist kein Rechtsabteilungsprojekt, sondern eine neue Eskalationsdisziplin, die Dev, Support, Security und Legal in einem gemeinsamen 24-Stunden-Takt synchronisieren muss – ab sofort, nicht ab dem nächsten Vorfall.
← Zurück zur Übersicht