Der Cyber Resilience Act ist seit dem 11. Dezember 2024 in Kraft, doch die operative Wirkung entfaltet sich erst jetzt. Ab dem 11. September 2026 greift die Meldepflicht für Schwachstellen und Sicherheitsvorfälle. Ab dem 11. Dezember 2027 gelten die vollständigen Anforderungen – ohne CRA-Konformität kein CE-Kennzeichen, ohne CE-Kennzeichen kein Verkauf in der EU.
Betroffen ist nahezu jedes Produkt mit digitalen Elementen: Software, Hardware, Firmware, IoT-Geräte, Industriesteuerungen, aber auch einzelne zugekaufte Komponenten aus der Lieferkette. Wer vernetzte Produkte in der EU in Verkehr bringt, kommt am CRA nicht vorbei.
ABB. 1 · CRA-ZEITPLAN UND MELDEKETTE AB SEPTEMBER 2026
Die vier Säulen des CRA
Der Rechtsakt lässt sich auf vier Kernanforderungen verdichten, die sich durch Anhang I und die zentralen Artikel ziehen:
- Secure by Design und by Default – Sicherheit ist Teil der Produktentwicklung, nicht ein nachträglicher Prüfschritt.
- Software Bill of Materials (SBOM) – eine maschinenlesbare Stückliste aller Softwarekomponenten, gepflegt über den gesamten Produktlebenszyklus.
- Schwachstellenmanagement – ein funktionierender Prozess von der Erkennung über die Bewertung bis zur Meldung.
- Sicherheitsupdates – kostenlose Updates über einen definierten Supportzeitraum, mit klar kommuniziertem End-of-Support-Datum.
Der Zeitplan bis Ende 2027
Zwischen der ersten operativen Pflicht und der vollständigen Konformität liegen knapp 15 Monate. Wer die Meldepflicht-Readiness im September 2026 verpasst, hat für die anschließende Vollumsetzung entsprechend weniger Puffer.
Einordnung
Nicht jedes digitale Angebot fällt unter den CRA. Reine SaaS-Lösungen ohne installierbare On-Premise-Variante sind ausgenommen, ebenso Medizinprodukte unter der MDR, bestimmte Fahrzeugtypen, Produkte im Bereich der nationalen Sicherheit und nichtkommerzielle Open-Source-Software. Sobald eine on-premise installierbare Variante existiert, gelten für diese die CRA-Pflichten – auch wenn parallel eine SaaS-Version angeboten wird.
Die Meldepflicht ab September 2026
Der operativ kritischste Teil des CRA ist die dreistufige Meldekette: eine Frühwarnung innerhalb von 24 Stunden, eine Vollmeldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit der Korrekturmaßnahme. Gemeldet wird über die CRA Single Reporting Platform an das zuständige CSIRT im Sitzland des Herstellers, ENISA erhält die Information parallel.
Diese Frist ist kein Dokumentationsproblem, sondern ein operativer Prozess. Wer erst beim Eintreten eines Vorfalls beginnt, eine Anlaufstelle zu definieren und Eskalationswege zu klären, verliert wertvolle Stunden der ohnehin knappen 24-Stunden-Frist. Ein funktionierendes Product Security Incident Response Team mit klarer Verantwortlichkeit ist deshalb keine Kür, sondern Voraussetzung.
Stresstest · 10 Minuten
Wo steht Ihr Unternehmen heute?
Kostenloser Compliance-Stresstest für NIS-2, DORA, CRA und den EU AI Act. Kein Login nötig.
Stresstest starten →SBOM: Von der Kür zur Pflicht
Eine SBOM ist im Kern eine Zutatenliste für Software – eine Inventarliste aller verwendeten Komponenten, inklusive der Abhängigkeiten aus Open-Source-Bibliotheken und Drittanbieter-Code. Der CRA verlangt, dass diese Liste in einem maschinenlesbaren Format vorliegt, etwa CycloneDX, und dass sie im Schwachstellenhandling tatsächlich genutzt wird. Veröffentlicht werden muss sie nicht, gepflegt aber schon – eine veraltete SBOM lässt sich im Ernstfall nicht mehr sinnvoll für eine Meldung heranziehen.
Das BSI konkretisiert die Anforderungen in der Technischen Richtlinie TR-03183, aufgeteilt in drei Teile: allgemeine Anforderungen, SBOM-Erstellung und der Umgang mit Schwachstellenmeldungen. Für deutsche Hersteller ist das aktuell die wichtigste Sekundärquelle neben dem Verordnungstext selbst.
Was schon vorhandene Frameworks abdecken – und was nicht
Wer bereits ein ISMS nach ISO 27001 betreibt, deckt einen erheblichen Teil der CRA-Anforderungen auf Governance-Ebene ab. Die produktspezifischen Pflichten bleiben trotzdem offen: CE-Kennzeichnung, maschinenlesbare SBOM und die 24-Stunden-Meldepflicht an CSIRT und ENISA lassen sich aus einem bestehenden Managementsystem allein nicht ableiten. Eine Gap-Analyse macht sichtbar, welche NIS-2- oder ISO-27001-Maßnahmen bereits CRA-Anforderungen mit abdecken und wo tatsächlich neue Prozesse und Nachweise nötig sind – das vermeidet Doppelarbeit über die Frameworks hinweg.
Was das für die Praxis bedeutet
Wer heute noch nicht mit der Vorbereitung begonnen hat, arbeitet gegen einen engen Zeitplan. Realistisch sind 14 bis 20 Monate von der ersten Bestandsaufnahme bis zur vollständigen Konformität – für die Meldepflicht-Readiness allein sind es je nach Ausgangslage vier bis fünf Monate. Drei Schritte lassen sich sofort angehen: ein Produktinventar mit SBOM für alle betroffenen Produkte aufbauen, eine dokumentierte Meldekette mit klaren Zuständigkeiten etablieren, und einen Abgleich mit den Essential Requirements aus Anhang I durchführen, um Showstopper frühzeitig zu erkennen.
Selbsttest · CRA-Meldepflicht
Ab wann muss eine aktiv ausgenutzte Schwachstelle spätestens als Frühwarnung gemeldet sein?
Der CRA verlangt keine neue Bürokratie um ihrer selbst willen, sondern versionierbare, prüfbare Nachweise: eine gepflegte SBOM, eine funktionierende Meldekette, eine dokumentierte Konformitätserklärung. Genau dafür sind BAM CRA-Objekte gebaut – als Teil desselben Datenmodells, das bereits NIS-2, DORA und den EU AI Act abdeckt, statt als isolierte Insellösung für ein weiteres Framework.