Die CRA ist ein Problem für 2026 – nicht für 2027

Fragt man ein Produktteam, wann der Cyber Resilience Act (CRA) für sie relevant wird, nennen die meisten den Dezember 2027. An diesem Datum treten die wesentlichen Anforderungen, die Konformitätsbewertung und die CE-Kennzeichnung in Kraft – und dieser Termin ist der Bezugspunkt für jede Roadmap-Präsentation. Doch genau dieser Termin ist der falsche Ausgangspunkt für die Planung.

Der CRA trat am 10. Dezember 2024 in Kraft, und Artikel 71 sieht einen gestaffelten Zeitplan vor – nicht einen einzigen Stichtag. Die Bestimmungen zur Benachrichtigung von Konformitätsbewertungsstellen (Kapitel IV, Artikel 35 bis 51) gelten ab dem 11. Juni 2026. Die Meldepflichten aus Artikel 14 gelten ab dem 11. September 2026. Erst die Hauptbestimmungen der Verordnung, die wesentlichen Anforderungen in Anhang I und der Weg zur CE-Kennzeichnung, treten erst am 11. Dezember 2027 in Kraft (Verordnung (EU) 2024/2847, Artikel 71; Europäische Kommission, „The Cyber Resilience Act: Summary of the legislative text“). Die erste verbindliche Pflicht für Hersteller, die in den Geltungsbereich fallen, greift also bereits etwa fünfzehn Monate vor dem Datum, auf das sich alle vorbereiten.

Dies ist kein Plädoyer für einen frühen Start. Es ist eine Feststellung zur richtigen Reihenfolge. Das Team, das seine CRA-Arbeit rückwärts vom CE-Zeichen 2027 aus plant, stellt die Meldepflicht an das Ende – dabei zwingen sowohl der Kalender als auch die operationellen Abhängigkeiten dazu, sie an den Anfang zu setzen.

Was ab 2026 tatsächlich in Kraft tritt

Artikel 14 ist keine bloße Dokumentationspflicht, die man am Ende „dranbastelt“. Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen jede aktiv ausgenutzte Schwachstelle in ihrem Produkt sowie jeden schweren Vorfall, der die Sicherheit beeinträchtigt, an das für den jeweiligen Mitgliedstaat zuständige CSIRT und an ENISA über eine zentrale Meldeplattform melden. Die Fristen sind unerbittlich: eine Vorabmeldung innerhalb von 24 Stunden nach Bekanntwerden, eine vollständige Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme bei einer Schwachstelle oder innerhalb eines Monats bei einem schweren Vorfall (Verordnung (EU) 2024/2847, Artikel 14).

Liest man den Auslöser genau: Eine „aktiv ausgenutzte Schwachstelle“ liegt vor, wenn es zuverlässige Belege dafür gibt, dass bösartiger Code auf einem System ohne Erlaubnis des Systemeigentümers ausgeführt wurde (Verordnung (EU) 2024/2847, Artikel 3). Das ist kein hypothetisches Szenario, das man in Ruhe bearbeiten kann. Es ist ein reales, datiertes Ereignis, das eine 24-Stunden-Frist in Gang setzt – und diese Pflicht greift bereits mehr als ein Jahr vor den wesentlichen Anforderungen, die eigentlich erst die Fähigkeit zur Erkennung schaffen würden.

Die Wissenspflicht trifft vor der Handlungsplicht ein

Hier liegt die Umkehrung, die bei einer Planung ab 2027 übersehen wird. Eine Pflicht zur Meldung innerhalb von 24 Stunden nach Bekanntwerden ist in der Praxis eine Pflicht, überhaupt in der Lage zu sein, etwas zu erkennen. Man kann keine Vorabmeldung über eine aktiv ausgenutzte Schwachstelle in seinem Produkt einreichen, wenn es keinen Kanal gibt, über den Ausnutzungen gemeldet werden, keine Bestandsliste, die zeigt, welche ausgelieferten Versionen betroffene Komponenten enthalten, und keine Triage-Regel, die vor Ablauf des 72-Stunden-Fensters entscheidet, ob ein Vorfall „schwerwiegend“ ist.

Jede dieser Fähigkeiten ist in Anhang I, Teil II derselben Verordnung beschrieben: die Führung einer Software Bill of Materials (SBOM) für mindestens die Top-Level-Abhängigkeiten in maschinenlesbarem Format, die Umsetzung einer Richtlinie für koordinierte Offenlegung von Schwachstellen mit einer Kontaktstelle für Meldungen sowie die unverzügliche Behebung von Schwachstellen durch Sicherheitsupdates (Verordnung (EU) 2024/2847, Anhang I, Teil II). Diese Anforderungen gelten rechtlich erst ab dem 11. Dezember 2027. Doch die Meldepflicht, die einen bereits ab dem 11. September 2026 bindet, lässt sich ohne sie kaum zuverlässig erfüllen. Das Gesetz erlaubt es, den Prozess der Behebung auf 2027 zu verschieben – es erlaubt es aber nicht, die Konsequenzen zu verschieben, sobald die Erkenntnis da ist.

Der praktische Effekt von Artikel 14 besteht für jeden, der tatsächlich in den Geltungsbereich fällt, also darin, dass Teile des in Anhang I, Teil II beschriebenen Betriebsmodells bereits fünfzehn Monate früher benötigt werden. Nicht weil die wesentlichen Anforderungen frühzeitig gelten, sondern weil die Meldepflicht ohne die operationelle „Wirbelsäule“, die diese Anforderungen beschreiben, kaum zuverlässig erfüllt werden kann.

Der Einwand – und warum er nicht trägt

Ein sorgfältiger Praktiker wird hier widersprechen, und dieser Einwand ist ernst zu nehmen. Artikel 14 ist eng gefasst. Er wird nur bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen ausgelöst, nicht bei der routinemäßigen Liste von Befunden mit geringer Schwere. Ein gut geführtes Produkt mag lange Zeit ohne meldepflichtige Ereignisse auskommen. Warum also nicht ab September 2026 einen schlanken Meldeprozess betreiben, die eigentliche Schwachstellenbehebung aber erst für 2027 aufbauen – und das geringe Risiko eines frühen Auslösers akzeptieren?

Drei Gründe sprechen dagegen, dass eine „schlanke“ Lösung eine Falle ist.

Erstens: Die Argumentation mit seltenen Ereignissen kehrt das Risiko um. Die Pflicht ist nicht belastend, weil sie häufig greift. Sie ist gefährlich, weil sie unvorhersehbar zuschlägt und eine 24-Stunden-Frist in Gang setzt, die man nicht pausieren kann, um erst noch Fähigkeiten aufzubauen. Gerade in der Woche, in der eine Schwachstelle aktiv ausgenutzt wird, hat man keine Zeit, eine SBOM zu erstellen, um herauszufinden, welche Kunden betroffen sind.

Zweitens: Die Haftungsstruktur unterscheidet sich von einer Lücke bei der Konformität – und ist schlimmer. Eine unvollständige Umsetzung von Anhang I wird bei einer Bewertung in einem Raum mit der Chance auf Nachbesserung sichtbar. Eine versäumte 24-Stunden-Meldung ist ein diskretes, datiertes, extern nachweisbares Versagen. Sie schafft einen Eintrag, der später in Aufsichts- oder Durchsetzungsverfahren relevant werden kann – und die Meldehistorie, die man ab September 2026 aufbaut, ist Teil dieser Dokumentation. Ein schlanker Prozess ist keine kleinere Version von Compliance; er ist eine nachweisbare Spur der Momente, in denen man nicht bereit war.

Drittens: Ein Meldeprozess ohne dahinterstehenden Behebungsprozess ist reine Show. Innerhalb von 24 Stunden ein Formular an ENISA zu übermitteln, ist wertlos, wenn man die eigentlichen Fragen des Formulars nicht beantworten kann: Welche Versionen sind betroffen? Was ist die Korrekturmaßnahme? Wann wird sie ausgeliefert? Die Meldepflicht und die Handlungsanforderungen sind ein System, das zu zwei Zeitpunkten beobachtet wird. Man kann sich nicht die beobachtbare Hälfte kaufen und die technische ignorieren.

Planen Sie rückwärts ab September 2026

Die praktische Korrektur besteht nicht darin, „alles jetzt zu tun“. Sie besteht darin, die kleinste Teilmenge der für 2027 geltenden wesentlichen Anforderungen zu identifizieren, die Artikel 14 bereits 2026 unverzichtbar macht, und diese Teilmenge gegen den September-Termin – nicht gegen Dezember 2027 – zu planen.

Diese minimale Meldebereitschaft ist kleiner als das vollständige Anhang-I-Programm und spezifisch genug, um sie zu planen:

• Eine aktuelle Software Bill of Materials (SBOM) für jedes ausgelieferte Produkt, mindestens für die Top-Level-Abhängigkeiten, damit man am Tag einer ausgenutzten Schwachstelle den Umfang der Auswirkungen innerhalb von Stunden – nicht Wochen – bestimmen kann.
• Einen überwachten Eingangskanal und eine Richtlinie für koordinierte Offenlegung von Schwachstellen, damit Ausnutzungen und Meldungen Dritter tatsächlich bei Ihnen ankommen und die Frist in Gang setzen, für die Sie verantwortlich sind.
• Eine schriftlich festgelegte Regel zur Schweregrad- und Vorfalls-Triage, die eine Einstufung als meldepflichtiges Ereignis innerhalb des 72-Stunden-Fensters ermöglicht – ohne dass ein Komitee einberufen werden muss.
• Einen benannten Verantwortlichen und einen erprobten Meldeweg zum koordinierenden CSIRT und zu ENISA, der vor dem Ernstfall auf der Meldeplattform getestet wurde.

All dies erfordert nicht die harmonisierten Normen oder den Konformitätsweg, die erst 2027 finalisiert werden. Alles lässt sich jetzt aufbauen – und alles ist eine Vorauszahlung auf die Pflichten von 2027, kein „Abfall“. Hersteller von wichtigen Produkten der Kategorie III in Anhang III haben einen weiteren Grund, nicht zu warten: Ihr Konformitätsweg erfordert in der Regel eine benannte Stelle, und diese Stellen können erst ab dem 11. Juni 2026 – dem Inkrafttreten der Bestimmungen in Kapitel IV – benannt werden. Die Kapazität für Bewertungen ist begrenzt, und Warteschlangen bilden sich erst an Stichtagen, nicht davor.

Die Regel, die es zu beachten gilt

Wenn eine Verordnung gestaffelt in Kraft tritt, ist das headline Datum meist das letzte – und das letzte Datum ist das am wenigsten nützliche für die Planung. Lesen Sie stattdessen den gestaffelten Zeitplan und fragen Sie sich, welche Pflicht von den anderen abhängt. Beim CRA kommt die Meldepflicht aus Artikel 14 sowohl im Kalender als auch in der Abhängigkeitskette zuerst: Man kann nicht melden, was man nicht erkennen kann – und man kann nicht erkennen, ohne die operationelle „Wirbelsäule“, die die Anforderungen von 2027 beschreiben. Planen Sie die Arbeit rückwärts ab dem 11. September 2026, nicht vorwärts zum 11. Dezember 2027, und die richtige Reihenfolge ergibt sich von selbst.

Wenn Ihre nächste Aufgabe darin besteht, zu ermitteln, welche Ihrer Produkte vom CRA betroffen sind und was die Meldepflicht ab September 2026 konkret für jedes von ihnen bedeutet, dann ist genau diese Einordnung und Querverweisung die Art von Arbeit, für die ISMS Copilot entwickelt wurde, um sie zu beschleunigen. Für viele Teams ist die CE-Kennzeichnung ein Tor für 2027; die Meldebereitschaft nach Artikel 14 ist ein Tor für 2026. Planen Sie also zuerst das frühere.

Dies ist eine Analyse zur praktischen Compliance – nicht eine Rechtsberatung. Prüfen Sie den Geltungsbereich und die Pflichten Ihres Produkts anhand der Verordnung selbst und, wo relevant, mit Ihrer zuständigen Behörde oder Ihrem Rechtsbeistand.