EU Cyber Resilience Act – Handlungsleitfaden
Cyber Resilience Act: Was ist konkret zu tun?
Der CRA stellt klare Pflichten für Hersteller, Importeure und Händler vernetzter Produkte. Diese Seite gibt eine praxisorientierte Schrittfolge – ohne regulatorisches Kauderwelsch.
Schritt 1
Betroffenheit prüfen: Gilt der CRA für mein Unternehmen?
Der Cyber Resilience Act (EU 2024/2847) gilt für alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen – konkret: Hardware und Software, die eine Netzwerkverbindung haben oder ermöglichen. Betroffen sind Geräte jeder Art (IoT, Router, Smart-Home, Industrie-Hardware), eingebettete Software, Firmware und Anwendungssoftware, die als eigenständiges Produkt in Verkehr gebracht wird.
Grundsätzlich nicht betroffen sind reine SaaS-Dienste ohne lokale Softwarekomponente, Medizinprodukte (MDR/IVDR), Luftfahrtprodukte (EASA) und Kraftfahrzeuge (UNECE WP.29) – diese unterliegen eigenen Sicherheitsregularien. Die Abgrenzung ist in der Praxis jedoch nicht immer eindeutig: B2B-Software, die in Produkte eines anderen Herstellers integriert wird, und Cloud-Dienste mit lokaler Agent-Komponente befinden sich in einer regulatorischen Grauzone, die eine rechtliche Einschätzung erfordert.
Ergebnis von Schritt 1: Eine Liste aller Produkte, für die der CRA gilt – mit Begründung. Diese Liste ist die Grundlage für alle weiteren Schritte. Ohne klare Betroffenheitsanalyse kann keine sinnvolle Ressourcenplanung erfolgen.
Schritt 2
Produktklasse bestimmen: Standard, Klasse I oder Klasse II?
Der CRA differenziert nach Risikoklassen, die unterschiedliche Konformitätswege vorschreiben. Standard-Produkte – der größte Teil aller vernetzten Produkte – können eine Selbstbewertung durch den Hersteller durchlaufen. Klasse-I-Produkte (kritisch) wie Passwortmanager, Browser, VPN-Clients, Identity-Management-Software, Netzwerk-Switches und Home-Automation-Geräte benötigen entweder eine Prüfung durch eine benannte Stelle oder die Einhaltung einer harmonisierten europäischen Norm.
Klasse-II-Produkte (hochkritisch) – darunter Firewalls, industrielle Router, Hardware-Sicherheitsmodule (HSM), Betriebssysteme, Mikrocontroller mit sicherheitsrelevanter Funktion und Software für kritische Infrastrukturen – erfordern zwingend eine Bewertung durch eine Notified Body. Diese Bewertung ist aufwändig, zeitintensiv und muss geplant werden: Notified Bodies haben Kapazitätsengpässe, die Vorlaufzeiten steigen mit Nähe zu den Stichtagen.
Die Klassifizierung erfolgt anhand der Anhänge III und IV der CRA-Verordnung. Für Produkte, die nicht eindeutig in eine Kategorie fallen, entscheidet eine kombinierte technische und rechtliche Bewertung. Eine falsche Einstufung – insbesondere die Unterbewertung von Klasse-II-Produkten als Standard – ist ein erhebliches Haftungsrisiko.
Schritt 3
Gap-Analyse: Wo stehe ich heute?
Eine strukturierte Gap-Analyse vergleicht die bestehenden Prozesse, Werkzeuge und Dokumentationen mit den CRA-Anforderungen pro Produkt. Typische Befunde: kein formales Threat Modeling, keine automatisierte SBOM-Erzeugung, kein Vulnerability Disclosure-Prozess, lückenhafte oder nicht maschinenlesbare Abhängigkeitsdokumentation, fehlende Incident-Response-Prozesse für Produktschwachstellen.
Gleichzeitig bringt die Gap-Analyse ans Licht, was bereits vorhanden ist: ISO 27001-Zertifizierungen decken Teile des Schwachstellenmanagements ab; bestehende SDLC-Prozesse enthalten häufig bereits Security-Reviews; Vulnerability-Scanning-Tools sind oft schon im Einsatz, nur nicht strukturiert in einen CRA-Konformitätspfad eingebettet.
Ergebnis von Schritt 3: Eine priorisierte Liste der kritischsten Lücken und eine realistische Roadmap mit Timelines zur September-2026- und Dezember-2027-Frist. Die Priorität liegt auf den Lücken mit dem höchsten regulatorischen Risiko und dem längsten Umsetzungshorizont – Security-by-Design-Prozesse brauchen deutlich länger als die Erstellung technischer Dokumentation.
Schritt 4
Security by Design einführen
Security by Design ist die zentrale Anforderung des CRA: Sicherheitsaspekte müssen von der ersten Designentscheidung an systematisch berücksichtigt werden, nicht als nachträglicher Patch. Konkret bedeutet das: Threat Modeling als fester Bestandteil der Produktentwicklung (STRIDE, PASTA oder Attack Trees), sichere Coding-Standards (OWASP Secure Coding Practices, CERT/SEI C/C++ Coding Standard), und automatisierte Sicherheitstests in der CI/CD-Pipeline.
Automatisierte Sicherheitstests umfassen mindestens: Static Application Security Testing (SAST) zur Erkennung von Code-Schwachstellen während des Builds, Software Composition Analysis (SCA) zur Schwachstellenerkennung in Drittkomponenten, und – wo anwendbar – Dynamic Application Security Testing (DAST) und Fuzzing. Diese Tests müssen nicht nur eingeführt, sondern auch dokumentiert werden: Ergebnisse, Behandlung von Findings, Ausnahmen.
Security by Design ist der zeitaufwändigste Teil der CRA-Umsetzung, weil er Prozesse und Kultur verändert – nicht nur Tools einführt. Entwicklungsteams brauchen Training. Prozesse müssen angepasst werden. Regressionstests müssen erweitert werden. Planen Sie mindestens 6–12 Monate für eine substanzielle Einführung in einer bestehenden Entwicklungsorganisation.
Schritt 5
SBOM aufbauen: Software Bill of Materials als CRA-Pflicht
Der CRA verlangt, dass Hersteller für jedes Produkt eine maschinenlesbare Software Bill of Materials (SBOM) erstellen und aktuell halten. Die SBOM ist die Stückliste aller Softwarekomponenten: Bibliotheken, Frameworks, Abhängigkeiten, Laufzeitumgebungen – mit exakten Versionsangaben. Die akzeptierten Formate sind SPDX (ISO/IEC 5962) und CycloneDX.
Die technische SBOM-Erzeugung ist mit modernen Tools (Syft, cdxgen, SPDX-Tools, Build-Plugins für Maven, Gradle, npm, pip) handhabbar und sollte als automatisierter Build-Schritt implementiert werden, nicht als manueller Prozess. Entscheidend ist der nächste Schritt: die SBOM muss kontinuierlich gegen aktuelle Schwachstellendatenbanken (NVD, OSV, GHSA) abgeglichen werden, um neu gemeldete CVEs in verwendeten Komponenten sofort zu erkennen.
Ein funktionierendes SBOM-System produziert täglich neue Schwachstellenwarnungen – und erfordert daher einen definierten Triage-Prozess: Welche CVEs sind für das konkrete Produkt tatsächlich ausnutzbar? Was ist die Priorität? Wer entscheidet, und bis wann? Ohne diesen Prozess ist eine SBOM regulatorisch wertlos. VEX-Dokumente (Vulnerability Exploitability eXchange) ermöglichen die strukturierte Dokumentation dieser Entscheidungen.
Schritt 6
Meldeprozesse einrichten: ENISA-Pflichten ab September 2026
Ab September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen (actively exploited vulnerabilities) in ihren Produkten innerhalb von 24 Stunden nach Bekanntwerden an ENISA und die zuständige nationale Behörde melden. Innerhalb von 72 Stunden folgt ein Frühwarnbericht, innerhalb von 14 Tagen ein abschließender Bericht. Diese Fristen sind nicht verhandelbar und setzen voraus, dass ein funktionierender Erkennungs-, Triage- und Eskalationsprozess bereits operativ ist.
Voraussetzungen für die Einhaltung dieser Fristen: ein Vulnerability-Monitoring-System, das neue CVEs in Echtzeit erkennt; klare Verantwortlichkeiten für die Erstbewertung (ist die Schwachstelle in unserem Produkt aktiv ausgenutzt?); und ein vorbereitetes Meldeverfahren mit Kenntnis der nationalen Behörde und des ENISA-Meldeprozesses. Wer diese Infrastruktur erst nach einer akuten Schwachstelle aufbaut, kann die 24-Stunden-Frist nicht einhalten.
Parallel zur ENISA-Meldepflicht verlangt der CRA eine öffentlich zugängliche Vulnerability Disclosure Policy (VDP). Diese Policy regelt, wie Dritte (Sicherheitsforscher, Kunden) Schwachstellen melden können und wie der Hersteller damit umgeht. Die VDP ist ein einfach umsetzbarer, aber häufig fehlender Baustein – und ein Signal an Behörden, Kunden und den Markt, dass das Unternehmen Sicherheit ernst nimmt.
Schritt 7
Technische Dokumentation und CE-Konformitätsbewertung
Der CRA verlangt für jedes Produkt eine technische Dokumentation, die alle sicherheitsrelevanten Designentscheidungen, Risikoanalysen, implementierten Maßnahmen, Testergebnisse und Schwachstellenbehandlungen nachvollziehbar dokumentiert. Diese Dokumentation ist kein einmaliges Dokument, sondern ein lebendes Artefakt: Sie muss bei jedem Release, jeder wesentlichen Änderung und bei neu entdeckten Schwachstellen aktualisiert werden.
Auf Basis der technischen Dokumentation und der durchgeführten Konformitätsbewertung stellt der Hersteller eine EU-Konformitätserklärung (Declaration of Conformity, DoC) aus und bringt die CE-Kennzeichnung am Produkt an. Für Standard-Produkte kann der Hersteller die Konformitätsbewertung selbst durchführen (Selbstbewertung), sofern harmonisierte Normen angewendet werden. Für Klasse-I- und Klasse-II-Produkte ist die Einbeziehung einer Notified Body verpflichtend oder zumindest teilweise erforderlich.
Notified Bodies für den CRA sind zertifizierte Prüforganisationen, die von nationalen Akkreditierungsbehörden (in Deutschland die DAkkS) anerkannt werden. Die Verfügbarkeit ist begrenzt; Kapazitäten werden mit Nähe zu den Stichtagen 2026 und 2027 knapper. Wer eine Notified-Body-Bewertung benötigt, sollte frühzeitig planen – realistisch 6–12 Monate Vorlauf einkalkulieren.
CRA-Checkliste
- 01
Betroffenheit prüfen
Produkte mit digitalen Elementen + Netzwerkfunktion identifiziert
- 02
Produktklasse bestimmen
Standard / Klasse I / Klasse II eingestuft
- 03
Gap-Analyse
Abstand zu CRA-Anforderungen bewertet, Prioritäten gesetzt
- 04
Security by Design
Threat Modeling, Secure Coding, SAST/DAST in CI/CD
- 05
SBOM aufbauen
Automatisierte SBOM-Erzeugung + kontinuierliches CVE-Monitoring
- 06
Meldeprozesse
ENISA Disclosure, 24h/72h/14d Fristen operativ
- 07
CE-Konformität
Technische Dokumentation, DoC, ggf. Notified Body
Fristen im Überblick
CRA in Kraft getreten
Meldepflichten aktiv (ENISA 24h/72h/14d)
Vollständige CRA-Wirkung: alle Anforderungen
Verwandte Seiten
Gap-Analyse anfragen
In 4–6 Wochen erhalten Sie eine vollständige Bestandsaufnahme, klare Priorisierung und eine belastbare Roadmap.
Jetzt anfragenZusammenfassung
Was ist zu tun – in sieben Schritten
1. Betroffenheit klären: Welche Produkte fallen in den CRA-Geltungsbereich?
2. Produktklasse bestimmen: Standard, Klasse I oder Klasse II?
3. Gap-Analyse: Wo liegen die kritischsten Lücken?
4. Security by Design: Threat Modeling + sichere SDLC-Prozesse
5. SBOM aufbauen: Automatische Erzeugung + CVE-Monitoring
6. Meldeprozesse: ENISA-Disclosure + Vulnerability Disclosure Policy
7. CE-Konformität: Technische Dokumentation + Konformitätserklärung
Häufige Fragen zum Cyber Resilience Act
Muss ich sofort handeln oder reicht es, bis 2027 zu warten?
Warten ist die teuerste Strategie. Die Einführung von Security-by-Design-Prozessen, SBOM-Infrastruktur und einem funktionierenden Vulnerability Management dauert erfahrungsgemäß 12–24 Monate. Wer erst Ende 2026 beginnt, riskiert nicht nur das Dezember-2027-Deadline, sondern auch den September-2026-Meldepflichtstichtag, der bereits ein funktionierendes Incident-Disclosure-System voraussetzt. Unternehmen, die jetzt starten, haben außerdem den strategischen Vorteil, CRA-Konformität vor dem Wettbewerb als B2B-Argument einzusetzen.
Was droht konkret, wenn ein Produkt bis Dezember 2027 nicht CRA-konform ist?
Produkte ohne CRA-Konformität verlieren den gesetzlichen Zugang zum EU-Binnenmarkt. Nationale Marktüberwachungsbehörden können Rückrufe, Verkaufsstopps und Bußgelder bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes verhängen – je nachdem, was höher ist. Für Importeure und Händler gelten eigene Pflichten: Sie dürfen keine nicht-konformen Produkte in Verkehr bringen und haften für importierte Produkte, wenn der Hersteller außerhalb der EU sitzt.
Wie aufwändig ist die SBOM-Implementierung in der Praxis?
Die technische SBOM-Erzeugung selbst ist mit modernen Tools (Syft, CycloneDX-Plugins für Maven/Gradle/npm) in einem Sprint umsetzbar. Der eigentliche Aufwand liegt im kontinuierlichen Betrieb: CVE-Matching gegen aktuelle Schwachstellendatenbanken, Triage der Treffer, Risikoentscheidungen und Dokumentation der Reaktion. Ohne integrierten Prozess ist eine SBOM nur eine statische Liste – kein Compliance-Nachweis. Wir empfehlen, SBOM-Erzeugung und -Monitoring als automatisierten CI/CD-Schritt zu implementieren, nicht als manuellen periodischen Prozess.
Müssen alle Produkte eine eigene SBOM haben?
Ja – und zwar produktspezifisch, nicht unternehmensübergreifend. Jedes Produkt mit digitalen Elementen braucht eine eigene SBOM, die alle enthaltenen Komponenten exakt widerspiegelt. Bei Produktfamilien mit gemeinsamer Codebasis kann eine Basis-SBOM pro Produktversion mit produktspezifischen Ergänzungen strukturiert werden. Wichtig: Die SBOM muss versioniert, maschinenlesbar und aktuell gehalten werden – bei jedem Release-Zyklus aktualisiert.
Was ist der Unterschied zwischen Hersteller-, Importeurs- und Händlerpflichten?
Hersteller tragen die umfangreichsten Pflichten: Security by Design, SBOM, Vulnerability Management, ENISA-Meldung, Konformitätsbewertung und CE-Kennzeichnung. Importeure, die Produkte von Herstellern außerhalb der EU einführen, müssen sicherstellen, dass diese Produkte den CRA-Anforderungen entsprechen – und haften gegenüber europäischen Marktüberwachungsbehörden, wenn der ausländische Hersteller nicht erreichbar ist. Händler müssen prüfen, ob die vertriebenen Produkte CE-gekennzeichnet sind und die CRA-Dokumentation vorliegt. Keine Vertriebs- oder Bestellstrategie, die nicht-konforme Produkte in Verkehr bringt, ist nach Dezember 2027 legal.
Kontakt aufnehmen
CRA-Umsetzung strukturiert angehen
Von der Betroffenheitsanalyse über SBOM-Integration und Meldeprozesse bis zur CE-Konformität – wir begleiten Hersteller, Importeure und Händler durch alle CRA-Anforderungen.