Cyber Resilience Act umsetzen: Roadmap in klaren Schritten

 

Der Cyber Resilience Act, auf Deutsch auch Cyberresilienz-Verordnung genannt, verpflichtet erstmals alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen zu einem Mindestmaß an Cybersicherheit über den gesamten Produktlebenszyklus. Die Fristen laufen, und die eigentliche Frage lautet für die meisten Unternehmen längst nicht mehr ob, sondern wie sie den Cyber Resilience Act umsetzen. Ohne strukturierten Fahrplan zerfasert das Vorhaben schnell in eine unübersichtliche Sammlung von Einzelmaßnahmen.

Dieser Leitfaden liefert genau diesen Fahrplan: eine Roadmap in sechs klaren Phasen, von der ersten Bestandsaufnahme bis zur laufenden Marktüberwachung, jeweils mit Ziel, konkreten Aufgaben, typischer Dauer und Verantwortlichen. Dazu klären wir die zwei Punkte, an denen sich die meisten Fragen entzünden: Selbstbewertung oder notifizierte Stelle sowie die Einbindung der Lieferkette. Wer eine strukturierte Unterstützung bei der CRA-Umsetzung sucht, findet hier die inhaltliche Grundlage.

 

„Nationale Umsetzung“ des Cyber Resilience Act? Ein verbreitetes Missverständnis

Ein häufig gesuchter Begriff ist die „nationale Umsetzung“ des Cyber Resilience Act. Er trifft die Rechtslage nicht ganz: Der CRA ist eine EU-Verordnung, keine Richtlinie. Verordnungen gelten in allen Mitgliedstaaten unmittelbar und müssen nicht erst durch ein nationales Gesetz in deutsches Recht überführt werden. Anders als bei der NIS2-Richtlinie, die auf ihr deutsches Umsetzungsgesetz wartet, gibt es beim CRA also keine nationale Umsetzung, auf die man warten könnte. Die Pflichten aus der Verordnung (EU) 2024/2847 gelten für jeden betroffenen Hersteller in der Union nach demselben Wortlaut.

Was national sehr wohl geregelt wird, sind die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Doppelrolle: als Marktüberwachungsbehörde und als notifizierende Behörde, die ab 2026 die Konformitätsbewertungsstellen benennt. Es kann Korrekturmaßnahmen verlangen, Produkte einschränken, vom Markt nehmen oder zurückrufen und Bußgelder verhängen. Deutschland setzt die europäischen Vorgaben eins zu eins um und verzichtet auf nationale Sonderregeln. Sie richten sich also direkt nach dem Verordnungstext, nicht nach einem noch ausstehenden deutschen Gesetz.

 

Zwei Fristen bestimmen die Reihenfolge

Bevor die Roadmap beginnt, lohnt der Blick auf den Zeitplan, denn er entscheidet über die Priorisierung. Der CRA ist am 10. Dezember 2024 in Kraft getreten, seine Pflichten greifen aber gestaffelt.

Datum	Was gilt ab dann
11. September 2026	Melde- und Berichtspflichten (Art. 14): aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen gemeldet werden, die erste Frühwarnung binnen 24 Stunden.
11. Dezember 2027	Volle Anwendung: alle grundlegenden Anforderungen, Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation müssen erfüllt sein.

Daraus folgt eine klare Priorisierung: Die Meldeprozesse kommen zuerst. Wer erst ab Ende 2027 an CE und Konformität denkt, übersieht, dass die 24-Stunden-Meldepflicht über ein Jahr früher scharf geschaltet wird und bereits im Sommer 2026 stehen muss.

 

Die CRA-Roadmap in sechs Phasen

Die folgende Roadmap gliedert die Umsetzung in sechs aufeinander aufbauende Phasen. Die Zeitangaben sind Erfahrungswerte für ein mittelständisches Portfolio und variieren mit Zahl und Komplexität der Produkte.

Phase	Ziel	Typische Dauer	Verantwortliche
1. Produktinventar & Betroffenheit	Alle Produkte mit digitalen Elementen erfassen, Betroffenheit und Risikoklasse bestimmen	2–3 Wochen	Produktmanagement, Compliance
2. Gap-Analyse (Annex I)	Ist-Zustand gegen die grundlegenden Anforderungen abgleichen, Lücken dokumentieren	2–3 Wochen	Security, Entwicklung
3. Risikobewertung	Cybersicherheitsrisiken je Produkt analysieren, Schutzmaßnahmen ableiten	2–4 Wochen	Security, Produktmanagement
4. Security by Design & Prozesse	Schwachstellenmanagement, SBOM, Update- und Meldeprozesse aufbauen und in die Entwicklung integrieren	2–9 Monate	Entwicklung, Security, DevOps
5. Doku, Konformität & CE	Technische Dokumentation erstellen, Konformität bewerten, EU-Konformitätserklärung und CE-Kennzeichnung	5–14 Wochen	Compliance, QA, ggf. notifizierte Stelle
6. Post-Market-Compliance	Monitoring, Sicherheitsupdates, Meldepflichten dauerhaft erfüllen	laufend	Security, Support, PSIRT

Phase 1: Produktinventar und Betroffenheitsanalyse

Ziel der ersten Phase ist ein vollständiges Bild darüber, welche Ihrer Produkte überhaupt in den Anwendungsbereich fallen. Erfasst wird jedes Produkt mit digitalen Elementen, also Hardware und Software mit direkter oder indirekter Datenverbindung zu einem Gerät oder Netz. Zu jedem Produkt gehört die Einordnung in eine Risikoklasse (Standard, wichtig, kritisch), denn davon hängt der spätere Konformitätsweg ab. Eine erste Orientierung, ob und wie stark Ihr Portfolio betroffen ist, liefert der Betroffenheits-Check zum Cyber Resilience Act. Verantwortlich sind Produktmanagement und Compliance, die typische Dauer liegt bei zwei bis drei Wochen.

Phase 2: Gap-Analyse gegen Annex I

In Phase 2 wird jedes betroffene Produkt gegen die grundlegenden Cybersicherheitsanforderungen aus Annex I abgeglichen. Annex I hat zwei Teile: Teil I beschreibt die Produkteigenschaften (etwa sichere Standardkonfiguration, Schutz von Vertraulichkeit und Integrität, minimierte Angriffsfläche), Teil II den Umgang mit Schwachstellen über den Support-Zeitraum. Ergebnis ist eine dokumentierte Lückenliste je Produkt: Was ist erfüllt, was fehlt, wo besteht Handlungsbedarf. Welche Pflichten im Einzelnen dahinterstehen, führt der Beitrag zu den CRA-Pflichten aus Annex I aus. Zuständig sind Security und Entwicklung, üblich sind zwei bis drei Wochen.

Phase 3: Risikobewertung je Produkt

Die Verordnung verlangt, dass Hersteller eine Cybersicherheits-Risikobewertung durchführen und deren Ergebnis in die Gestaltung des Produkts einfließen lassen. In dieser Phase werden je Produkt die relevanten Bedrohungen modelliert, mögliche Angriffswege bewertet und daraus die notwendigen Schutzmaßnahmen abgeleitet. Die Risikobewertung ist kein Selbstzweck, sondern die Begründung für die gewählten Sicherheitsfunktionen, und wird Teil der technischen Dokumentation. Verantwortlich sind Security und Produktmanagement, die typische Dauer beträgt zwei bis vier Wochen.

Phase 4: Security by Design und die Kernprozesse

Phase 4 ist das Herzstück und regelmäßig die längste Etappe, weil hier aus Analyse konkrete Technik und gelebte Prozesse werden. Die Anforderungen aus Annex I werden in Produktentwicklung und Lieferkette verankert, inklusive secure defaults, Update-Mechanismen und Härtung. Drei Prozesse verdienen besondere Aufmerksamkeit:

• Schwachstellenmanagement: ein fortlaufender Prozess, der Schwachstellen in eigenen und fremden Komponenten identifiziert, bewertet, behebt und die Behebung nachweist, über den gesamten Support-Zeitraum.
• SBOM (Software Bill of Materials): eine Stückliste der Softwarekomponenten in einem gängigen, maschinenlesbaren Format, die laut Annex I mindestens die Abhängigkeiten oberster Ebene abdeckt und aktuell gehalten wird.
• Meldeprozesse: ein einsatzbereiter Ablauf, um aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle fristgerecht zu melden. Dieser Prozess sollte wegen der Frist 11. September 2026 vorgezogen werden.

Der Support-Zeitraum für Sicherheitsupdates bemisst sich an der erwarteten Nutzungsdauer und beträgt in der Regel mindestens fünf Jahre, sofern die Nutzung nicht kürzer ist. Verantwortlich sind Entwicklung, Security und DevOps, die Dauer reicht je nach Produkt von zwei bis neun Monaten.

Phase 5: Technische Dokumentation, Konformitätsbewertung und CE

In Phase 5 wird das Erreichte prüf- und nachweisbar gemacht. Zunächst entsteht die technische Dokumentation, die Risikobewertung, SBOM, Sicherheitsmaßnahmen und Testnachweise bündelt und der Marktüberwachung auf Verlangen vorgelegt wird. Darauf folgen die Konformitätsbewertung (Selbstbewertung oder notifizierte Stelle, siehe unten), die EU-Konformitätserklärung und die CE-Kennzeichnung, mit der das Produkt in Verkehr gebracht werden darf. Verantwortlich sind Compliance und QA, bei bewertungspflichtigen Produkten zusätzlich eine notifizierte Stelle. Rechnen Sie mit drei bis sechs Wochen für die Dokumentation und zwei bis acht Wochen für die Bewertung.

Phase 6: Post-Market-Compliance

Mit dem CE-Zeichen ist die Arbeit nicht beendet, sondern verlagert sich in den Dauerbetrieb. In Phase 6 überwachen Sie Ihre Produkte am Markt fortlaufend auf neue Schwachstellen, stellen kostenfreie Sicherheitsupdates über den Support-Zeitraum bereit und halten die Meldepflichten ein: die 24-Stunden-Frühwarnung an das zuständige CSIRT und ENISA über die zentrale Meldeplattform, gefolgt von einer Meldung binnen 72 Stunden und einem Abschlussbericht. Diese Phase läuft ohne Ende und braucht feste Zuständigkeiten, idealerweise ein Product Security Incident Response Team (PSIRT).

 

 

Selbstbewertung oder notifizierte Stelle? Der Weg hängt von der Produktklasse ab

Eine der meistgestellten Fragen betrifft den Konformitätsweg: selbst bewerten oder durch eine notifizierte Stelle prüfen lassen? Die Antwort ergibt sich aus Art. 32 und Annex VIII und hängt an der Risikoklasse des Produkts.

Produktklasse	Beispiele	Konformitätsweg
Standardprodukte (Mehrheit)	Textverarbeitung, Foto-Apps, smarte Lautsprecher, Festplatten, Spiele	Selbstbewertung über die interne Kontrolle (Modul A)
Wichtige Produkte, Klasse I (Annex III)	Passwort- und Identitätsmanager, Betriebssysteme, Router, VPN, Virenschutz, SIEM	Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen, sonst notifizierte Stelle (Modul B+C oder H)
Wichtige Produkte, Klasse II (Annex III)	Firewalls, IDS/IPS, Hypervisoren, Container-Runtimes, manipulationssichere Mikroprozessoren	Immer notifizierte Stelle (Modul B+C oder H) — harmonisierte Normen ändern das nicht
Kritische Produkte (Annex IV)	Hardware-Sicherheitsmodule, Smartcards, Smart-Meter-Gateways	Höchste Stufe: gegebenenfalls verpflichtendes europäisches Cybersicherheits-Zertifizierungsschema

Die drei Verfahren aus Annex VIII: Modul A ist die interne Kontrolle, also die reine Selbstbewertung ohne externe Beteiligung. Modul B+C kombiniert eine EU-Baumusterprüfung durch eine notifizierte Stelle (B) mit der Produktkonformität auf Basis interner Fertigungskontrolle (C). Modul H ist die umfassende Qualitätssicherung, bei der die notifizierte Stelle das Qualitätsmanagementsystem des Herstellers bewertet. Sobald ein Produkt in die Klasse II der wichtigen oder in die kritischen Produkte fällt, führt kein Weg an einer notifizierten Stelle vorbei, selbst bei vollständiger Anwendung harmonisierter Normen.

 

Die Lieferkette einbinden: Selbstauskunft und Komponenten-SBOM

Kaum ein Produkt besteht heute vollständig aus Eigenentwicklung. Fremde Bibliotheken, Open-Source-Komponenten und zugelieferte Module stecken in nahezu jeder Software. Der Cyber Resilience Act macht Sie als Hersteller des Endprodukts für dessen gesamte Cybersicherheit verantwortlich, einschließlich der Fremdkomponenten. Fremder Code wird damit zu Ihrer Verantwortung, und die Lieferkette ist ein eigener Arbeitsstrang der Umsetzung.

Zwei Instrumente sind hier zentral. Erstens die Lieferantenselbstauskunft: eine strukturierte Abfrage bei jedem Zulieferer, wie er die CRA-relevanten Anforderungen erfüllt, ob und wie lange er Sicherheitsupdates liefert und wie er mit Schwachstellen umgeht. Zweitens die Komponenten-SBOM: eine maschinenlesbare Stückliste der in den zugelieferten Komponenten enthaltenen Softwarebestandteile. Nur so können Sie beim Bekanntwerden einer Schwachstelle in einer weit verbreiteten Bibliothek innerhalb von Stunden beantworten, ob und wo Ihr Produkt betroffen ist. Beides gehört vertraglich verankert, denn ohne Mitwirkung der Lieferanten bleiben blinde Flecken, für die am Ende Sie geradestehen.

 

 

Fazit: Umsetzung ist Prozess, nicht Projekt

Den Cyber Resilience Act umzusetzen ist kein einmaliges Projekt mit Enddatum, sondern der Aufbau dauerhafter Fähigkeiten. Die sechs Phasen geben die Reihenfolge vor, doch sie ist nicht starr: Der Meldeprozess muss wegen der Frist 11. September 2026 vorgezogen werden, die volle Konformität mit CE-Kennzeichnung folgt bis zum 11. Dezember 2027. Wer früh mit einem vollständigen Produktinventar und einer sauberen Klassifizierung beginnt, verschafft sich den größten Vorteil, denn davon hängen Gap-Analyse, Risikobewertung und Konformitätsweg ab.

Entscheidend ist, die Umsetzung als zusammenhängenden Prozess zu führen, nicht als Sammlung isolierter Aufgaben. Mit einer klaren Roadmap, vorgezogenen Meldeprozessen und werkzeuggestützter Steuerung wird aus einer regulatorischen Pflicht ein belastbarer Baustein Ihrer Produktsicherheit.

 

Häufige Fragen (FAQ)

Braucht der Cyber Resilience Act eine nationale Umsetzung in Deutschland?

Nein. Der Cyber Resilience Act ist eine EU-Verordnung (Verordnung (EU) 2024/2847) und gilt in allen Mitgliedstaaten unmittelbar, ohne ein nationales Umsetzungsgesetz. National geregelt werden nur die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das BSI die Rolle der Marktüberwachungs- und notifizierenden Behörde.

Ab wann gelten welche Pflichten des Cyber Resilience Act?

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Melde- und Berichtspflichten gelten ab dem 11. September 2026, darunter die Pflicht, aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden. Die volle Anwendung mit allen grundlegenden Anforderungen, Konformitätsbewertung und CE-Kennzeichnung folgt am 11. Dezember 2027.

Wann darf ich mein Produkt selbst bewerten und wann muss eine notifizierte Stelle prüfen?

Standardprodukte, also die große Mehrheit, dürfen sich per interner Kontrolle (Modul A) selbst bewerten. Wichtige Produkte der Klasse I dürfen das nur bei vollständiger Anwendung harmonisierter Normen, sonst ist eine notifizierte Stelle nötig. Wichtige Produkte der Klasse II und kritische Produkte müssen in jedem Fall über eine notifizierte Stelle beziehungsweise ein Zertifizierungsschema.

Was ist eine SBOM und fordert der Cyber Resilience Act sie verpflichtend?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts. Der CRA verlangt in Annex I, dass Hersteller mindestens die Abhängigkeiten oberster Ebene in einem gängigen, maschinenlesbaren Format dokumentieren und aktuell halten. Die SBOM ist Teil der technischen Dokumentation und wird den Marktüberwachungsbehörden auf Verlangen vorgelegt, sie muss aber nicht zwingend öffentlich sein.

Wie binde ich meine Lieferanten in die CRA-Umsetzung ein?

Über zwei Instrumente: eine Lieferantenselbstauskunft zu den CRA-Anforderungen und zur Update-Versorgung sowie eine Komponenten-SBOM, die die Softwarebestandteile der zugelieferten Komponenten offenlegt. Beides gehört vertraglich verankert, denn als Hersteller des Endprodukts haften Sie auch für die integrierten Fremdkomponenten.