EU-Verordnung | Produktsicherheit

Cyber Resilience Act: Pflichten für Hersteller digitaler Produkte.

Der CRA (Verordnung (EU) 2024/2847) ist die erste verbindliche EU-Verordnung zur Cybersicherheit digitaler Produkte. Seit dem 11. September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen. Bis Dezember 2027 kommen SBOM-Pflichten, Vulnerability Management und Sicherheitsupdates über 5 Jahre dazu.

CRA Readiness Check vereinbaren SBOM & Supply Chain Security

Zuletzt aktualisiert: September 2026 · Von zertifizierten Experten geprüft

11.09.2026
Meldepflicht gilt seit: Dez. 2027
Vollständige Geltung: 15 Mio. EUR
Maximales Bußgeld: 5 Jahre
Pflicht-Sicherheitsupdates

Grundlagen

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist die erste verbindliche EU-Verordnung, die Cybersicherheitsanforderungen direkt an Produkte mit digitalen Elementen knüpft. Sie wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft.

Der CRA schließt eine kritische Lücke: Während NIS-2 Betreiber von Diensten verpflichtet, regelt der CRA die Sicherheit der Produkte selbst, von der Entwicklung über die Markteinführung bis zum Ende des Lebenszyklus. Jedes vernetzt verkaufte Produkt muss künftig nachweislich sicher gebaut und dauerhaft gewartet werden.

Betroffen sind Hersteller, Importeure und Händler. Der wichtigste Paradigmenwechsel: Sicherheit wird zur rechtlichen Produkteigenschaft. Ab dem 11. Dezember 2027 dürfen Produkte ohne die geforderten Nachweise in der EU nicht mehr in Verkehr gebracht werden.

CRA auf einen Blick

EU-Verordnung: Verordnung (EU) 2024/2847
Veröffentlicht: 20. November 2024 (Amtsblatt der EU)
In Kraft: 10. Dezember 2024
Volle Geltung: 11. Dezember 2027 (Meldepflichten seit 11. September 2026)
Meldeplattform: ENISA CRA-SRP (portal.cra-srp.enisa.europa.eu)
Zuständig (DE): Bundesamt für Sicherheit in der Informationstechnik (BSI)
Bußgeld max.: 15 Mio. EUR / 2,5 % weltw. Umsatz

Meldepflicht gilt seit 11. September 2026

Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind seit dem 11. September 2026 innerhalb von 24 Stunden zu melden, über die CRA-SRP der ENISA. Wer den Meldeprozess noch nicht eingerichtet hat, steht bereits in der Pflicht.

Art. 14 CRA

Meldepflicht: seit 11. September 2026 in Kraft

Die erste CRA-Pflicht läuft bereits. Hersteller melden aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, sobald sie belastbare Kenntnis davon haben. Die drei Stufen bauen aufeinander auf, die Uhr startet mit der Kenntnis und nicht mit dem nächsten Werktag.

Stufe 1

24 Stunden

Frühwarnung

Nach belastbarer Kenntnis über eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall.

Stufe 2

72 Stunden

Detailliertere Meldung

Erste Bewertung, Auswirkungen, bereits ergriffene Korrektur- oder Risikominderungsmaßnahmen, Hinweise für Nutzer.

Stufe 3, Schwachstelle

14 Tage

Abschlussbericht

Spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Schutzmaßnahme, etwa eines Sicherheitsupdates.

Stufe 3, Vorfall

1 Monat

Abschlussbericht

Einen Monat nach der detaillierteren Meldung, wenn ein schwerwiegender Sicherheitsvorfall gemeldet wurde.

Meldeweg: die ENISA CRA-SRP

Gemeldet wird über die Single Reporting Platform der ENISA, kurz CRA-SRP, erreichbar unter portal.cra-srp.enisa.europa.eu. Für den Zugang braucht es ein EU-Login-Konto. Eine Registrierung auf Vorrat verlangt das BSI nicht: Registrierung und Meldung sind im Bedarfsfall in wenigen Minuten erledigt.

Das koordinierende CSIRT nimmt die Meldung entgegen und verteilt sie an die CSIRTs der weiteren Mitgliedstaaten, in denen das Produkt verfügbar ist. ENISA erhält sie parallel. In Deutschland ist das CERT-Bund im BSI das koordinierende CSIRT.

Die Plattform ging am Stichtag selbst in Betrieb. ENISA hat sie zunächst mit einer initialen Betriebsfähigkeit (initial operating capability) veröffentlicht und will die Funktionen in den kommenden Monaten anhand der Betriebserfahrung ausbauen. Ein allgemeines Vorab-Onboarding für Hersteller gab es vor dem 11. September 2026 nicht, eine technische Anbindung setzt also die angekündigten Ausbaustufen voraus.

Ergänzend regelt die Delegierte Verordnung (EU) 2026/881, in Kraft seit dem 10. Mai 2026, unter welchen Bedingungen das koordinierende CSIRT die Weitergabe einer Meldung vorübergehend verzögern darf.

Wie sich die 24-Stunden-Frist organisatorisch abbilden lässt, steht im Beitrag zur CRA-Meldepflicht und zur Meldung über die ENISA-Plattform.

Vorbereitungsstand der Hersteller

Schätzen sich als vollständig CRA-konform ein: 3 %; PwC Product Security Survey 2026 (n = 100)
Ohne dedizierte externe Meldeschnittstelle für Sicherheitsmeldungen: 50 %; PwC Product Security Survey 2026 (n = 100)
Kennen die Bedeutung des CRA für das eigene Haus: 29 %; Bitkom-Umfrage 2026 (n = 1.003)

PwC befragte im Frühjahr 2026 100 Industrieunternehmen in Deutschland, deren Portfolio Produkte mit digitalen Elementen enthält, 65 % davon aus dem Maschinenbau. Die Bitkom-Zahl stammt aus einer Befragung von 1.003 Unternehmen ab 10 Beschäftigten. Die Meldepflicht trifft damit viele Hersteller, die den Kanal für eingehende Hinweise noch gar nicht haben.

Anwendungsbereich

Welche Produkte sind vom CRA betroffen?

Der CRA unterscheidet drei Kritikalitätsklassen mit unterschiedlichen Konformitätsbewertungsanforderungen. Die Einstufung bestimmt, ob eine Selbstbewertung ausreicht oder eine unabhängige Prüfstelle einzuschalten ist.

Klasse I (normal)

Self-Assessment

Konformitätsbewertung durch den Hersteller selbst (EU-Konformitätserklärung)

Klasse II (erhöht)

Third-Party-Audit

Prüfung durch notifizierte Stelle (unabhängige akkreditierte Prüfeinrichtung) erforderlich

Kritisch (Anhang IV)

Strenge Anforderungen

Chipkarten, HSM und Smart-Meter-Gateways: strengste Konformitätspflichten und europäische Zertifizierungsschemata

Klasse I, normale Kritikalität (Anhang III)

Self-Assessment möglich · Bußgeld bei Verstoß bis 15 Mio. EUR oder 2,5 % Umsatz

Router, Modems und Switches Router und Modems für die Internetanbindung
Smart-Home-Produkte mit Sicherheitsfunktionen Türschlösser, Sicherheitskameras, Babyüberwachung, Alarmanlagen
Betriebssysteme Desktop-, Server- und mobile Betriebssysteme
Browser und Passwort-Manager Eigenständige und eingebettete Browser
VPN-Produkte Produkte mit der Funktion eines virtuellen privaten Netzes
Identitäts- und Zugriffsmanagement IAM, Verwaltung privilegierter Zugänge, Lesegeräte
SIEM, Netzmanagement, Malware-Schutz Sicherheitsereignisse, Netzverwaltung, Schadsoftware-Erkennung
Public-Key-Infrastrukturen Software für die Ausstellung digitaler Zertifikate
Chips mit Sicherheitsfunktionen Mikroprozessoren, Mikrocontroller, ASIC und FPGA
Vernetztes Spielzeug und Wearables Spielzeug mit Interaktions- oder Ortungsfunktion, Gesundheits-Wearables

Klasse II, erhöhte Kritikalität (Anhang III)

Notifizierte Stelle erforderlich · Bußgeld bei Verstoß bis 15 Mio. EUR oder 2,5 % Umsatz

Hypervisoren und Container-Runtimes Virtualisierte Ausführung von Betriebssystemen
Firewalls Netzwerkabsicherung und Paketfilterung
Intrusion-Detection- und -Prevention-Systeme IDS und IPS
Manipulationssichere Mikroprozessoren und Mikrocontroller Gegen physische Manipulation gehärtete Chips

Importeure und Händler: mittelbare Pflichten

Importeure und Händler gelten als Hersteller, wenn sie ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringen oder wesentlich ändern (Art. 21 CRA). Importeure dürfen nur konforme Produkte in Verkehr bringen, Händler prüfen vor der Bereitstellung unter anderem die CE-Kennzeichnung (Art. 19, 20 CRA).

Welche Klasse gilt für Ihr Produkt?

Die Klassifizierung entscheidet über Ihren Compliance-Aufwand und die Anforderungen an die Konformitätsbewertung. In einem kostenlosen Erstgespräch prüfen wir Ihre Produkte und geben eine verbindliche Einschätzung.

Produkt klassifizieren lassen

Anhang I CRA

Die 8 Kernpflichten des Cyber Resilience Act

Der CRA definiert in Anhang I verbindliche Sicherheitsanforderungen für alle Phasen des Produktlebenszyklus - von der Konzeption über die Entwicklung bis zum Ende des Supports. Die Anforderungen gelten für alle Hersteller, unabhängig von der Produktkategorie.

Secure by Design & Default

Produkte müssen von Grund auf mit Sicherheitszielen entworfen werden (Art. 13 Abs. 1 CRA). Default-Konfigurationen müssen sicher sein: keine voreingestellten Standardpasswörter, unnötige Dienste deaktiviert, minimale Angriffsfläche. Sicherheitsanforderungen müssen im gesamten Produktentwicklungsprozess berücksichtigt werden (Secure Development Life Cycle).

Produktsicherheit testen

Vulnerability Management & Disclosure

Hersteller müssen einen strukturierten Prozess zur Entgegennahme, Bewertung und Behebung von Schwachstellen einrichten (Anhang I Teil II CRA). Coordinated Vulnerability Disclosure (CVD) muss ermöglicht werden. Entdeckte Schwachstellen sind zeitnah zu beheben und zu dokumentieren. Kontaktkanal für Schwachstellenmeldungen muss öffentlich bekannt gemacht werden.

Vulnerability-Management-Beratung

SBOM: Software Bill of Materials

Hersteller müssen eine vollständige Liste aller Software-Komponenten (SBOM) erstellen und pflegen (Anhang I Teil II Nr. 1 CRA). Die SBOM muss zumindest die obersten Abhängigkeiten der Produkte erfassen, Versionsinformationen enthalten und aktuell gehalten werden. Bei Anforderung muss sie Marktüberwachungsbehörden zur Verfügung gestellt werden. Standardformate: SPDX (ISO 5962) oder CycloneDX.

SBOM & Supply Chain Security

Sicherheitsupdates (mindestens 5 Jahre)

Hersteller sind verpflichtet, Sicherheitsupdates für mindestens 5 Jahre oder die erwartete Nutzungsdauer des Produkts bereitzustellen (Art. 13 Abs. 8 CRA). Updates müssen kostenlos, zeitnah und ohne Verzögerung bereitgestellt werden. Nutzer müssen aktiv über verfügbare Updates informiert werden. Nach Ablauf des Supports muss eine transparente Kommunikation erfolgen.

CE-Kennzeichnung mit Cyber-Konformität

Produkte mit digitalen Elementen dürfen ab der allgemeinen Anwendbarkeit des CRA am 11. Dezember 2027 nur noch in Verkehr gebracht werden, wenn sie die CE-Kennzeichnung für Cybersicherheit tragen (Art. 13 Abs. 12, Art. 30 CRA). Die Kennzeichnung belegt die Konformität mit den Anforderungen des CRA. Sie muss vor dem Inverkehrbringen durchgeführt werden und schließt eine Konformitätsbewertung ein.

Konformitätsbewertung (Self-Assessment / Third-Party)

Klasse-I-Produkte (normale Kritikalität) können per Selbstbewertung konform erklärt werden (Art. 32 CRA). Klasse-II-Produkte (erhöhte Kritikalität) erfordern eine unabhängige Prüfung durch eine akkreditierte Konformitätsbewertungsstelle (notifizierte Stelle). Kritische Produkte (Anhang IV) unterliegen den strengsten Anforderungen. Die Bewertungsergebnisse müssen dokumentiert und aufbewahrt werden.

CRA-Assessment anfragen

Meldepflicht bei ausgenutzten Schwachstellen (gilt seit 11.09.2026)

Seit dem 11. September 2026 gilt Art. 14 CRA. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle brauchen innerhalb von 24 Stunden nach belastbarer Kenntnis eine Frühwarnung, innerhalb von 72 Stunden folgt die detailliertere Meldung. Der Abschlussbericht ist bei einer Schwachstelle spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Schutzmaßnahme fällig, bei einem Sicherheitsvorfall einen Monat nach der detaillierteren Meldung. Gemeldet wird über die Single Reporting Platform der ENISA (CRA-SRP); in Deutschland ist das CERT-Bund im BSI das koordinierende CSIRT.

Meldeweg und Fristen im Detail

Technische Dokumentation

Hersteller müssen eine umfangreiche technische Dokumentation erstellen und 10 Jahre nach Inverkehrbringen aufbewahren (Art. 13 Abs. 13 CRA). Diese umfasst: Produktbeschreibung, Sicherheitskonzept, Risikoanalyse, Design- und Fertigungsunterlagen, SBOM, Testergebnisse, EU-Konformitätserklärung. Die Dokumentation muss Marktüberwachungsbehörden auf Anfrage jederzeit vorgelegt werden können.

Hinweis: Die acht Anforderungen gelten für alle Hersteller. Für Klasse-II-Produkte kann die EU-Kommission delegierte Rechtsakte erlassen, die zusätzliche sektorspezifische Anforderungen definieren, vergleichbar mit den europäischen Cybersicherheitszertifizierungsschemata nach ENISA CSA (EU 2019/881).

Praxis

Warum der CRA notwendig ist: Reale Vorfälle

Die folgenden Vorfälle zeigen, welche Schäden unsichere Produkte mit digitalen Elementen verursachen können - und warum Regulierung auf Produktebene unvermeidlich war.

Mirai Botnet, Oktober 2016

600.000 IoT-Geräte mit Standard-Passwörtern kompromittiert

Das Mirai-Botnet infizierte über 600.000 Router, IP-Kameras und DVR-Rekorder, die mit voreingestellten Herstellerpasswörtern (admin/admin, root/1234) betrieben wurden. Der daraus resultierende DDoS-Angriff auf den DNS-Provider Dyn legte zeitweise Amazon, Twitter und Netflix lahm. Unter dem CRA wäre die Vermarktung von Geräten mit Standard-Passwörtern verboten, denn Secure by Default ist eine Kernpflicht.
Log4Shell, Dezember 2021

CVE-2021-44228: CVSS 10.0, fehlende SBOM-Transparenz

Die kritische Schwachstelle in der Java-Logging-Bibliothek Log4j (CVSS 10.0) betraf Millionen von Produkten und Diensten weltweit. Das zentrale Problem: Viele Hersteller wussten nicht einmal, dass sie Log4j in ihren Produkten verwendeten. Mit einer vollständigen SBOM hätten betroffene Komponenten innerhalb von Stunden identifiziert werden können. Die CRA-SBOM-Pflicht zielt direkt auf dieses Problem ab.
Kaseya VSA, Juli 2021

Supply-Chain-Ransomware: 1.500 MSPs, 50.000 Endkunden

Die REvil-Ransomware-Gruppe nutzte eine Zero-Day-Schwachstelle in der MSP-Management-Software Kaseya VSA, um über einen einzigen Angriffspunkt 1.500 Managed-Service-Provider und deren 50.000 Endkunden zu kompromittieren. Lösegeldforderung: 70 Millionen US-Dollar. Unter dem CRA wären Vulnerability-Disclosure-Prozesse und zeitnahe Patch-Veröffentlichung verpflichtend gewesen.
VPN-Appliance 0-Days, 2023/2024

Fortinet, Ivanti, Palo Alto: Kritische Schwachstellen in Perimeter-Geräten

Mehrere führende Hersteller von VPN-Appliances und Netzwerk-Security-Produkten (Fortinet FortiGate, Ivanti Connect Secure, Palo Alto GlobalProtect) wurden durch aktiv ausgenutzte Zero-Day-Schwachstellen kompromittiert. Staatliche Angreifer exploitierten diese Produkte als Einstiegspunkt in Behörden und kritische Infrastrukturen. Für CRA-Klasse-II-Produkte wie VPN-Gateways gilt seit dem 11. September 2026 die 24-Stunden-Meldepflicht, ab Dezember 2027 kommt die Prüfung durch eine notifizierte Stelle dazu.

Leitfäden zum Thema

Vertiefung

Beratungsleistungen

Wie AWARE7 bei der CRA-Compliance hilft

Wir begleiten Hersteller digitaler Produkte vom ersten Assessment bis zur CE-Kennzeichnung, mit technischer Expertise, Prozessberatung und Penetration Testing auf Produktebene.

Produkt-Penetrationstest

Technische Sicherheitsprüfung Ihrer Produkte gegen die Anforderungen aus Anhang I CRA: IoT, Embedded, Software, Netzwerkkomponenten. Ergebnis: Prüfbericht für die technische Dokumentation.

Pentest anfragen

CRA Gap-Analyse & Readiness Assessment

Strukturierter Abgleich Ihrer Produkte und Prozesse gegen alle CRA-Anforderungen. Produktklassifizierung, Lückenanalyse, priorisierter Maßnahmenplan mit Festpreisangebot.

Gap-Analyse starten

SBOM-Einführung & Supply Chain Security

Aufbau einer CRA-konformen SBOM-Toolchain (SPDX/CycloneDX), Integration in CI/CD-Pipelines, CVE-Monitoring und Supplier-Risk-Assessment für Ihre Lieferkette.

SBOM-Beratung

Secure Development Life Cycle (SDLC)

Einführung und Optimierung sicherheitsorientierter Entwicklungsprozesse: Threat Modeling, Security Reviews und Secure Coding Guidelines als Grundlage für Anhang I CRA.

SDLC-Beratung anfragen

Technische Dokumentation & EU-Konformitätserklärung

Erstellung und Prüfung der gesamten technischen Dokumentation nach Art. 31 CRA: Risikoanalyse, Testberichte, SBOM und EU-Konformitätserklärung, bereit für Marktüberwachungsbehörden.

Dokumentation anfragen

NIS-2 & CRA: kombiniertes Compliance-Programm

Für Unternehmen, die gleichzeitig NIS-2 (als Betreiber) und CRA (als Hersteller) betreffen: kombiniertes Assessment, gemeinsame Maßnahmenumsetzung, maximale Synergien.

Kombiniertes Programm

„Der Cyber Resilience Act ist die wichtigste Produktsicherheitsregulierung seit der CE-Kennzeichnung. Hersteller, die jetzt handeln, bauen einen nachhaltigen Wettbewerbsvorteil auf, denn sichere Produkte werden zum Marktstandard. Wer wartet, riskiert Rückrufe und Bußgelder.“

Chris Wojzechowski

Prüfer mit zusätzlicher Prüfverfahrenskompetenz (§ 8a BSIG) · AWARE7 GmbH

FAQ

Häufige Fragen zum Cyber Resilience Act

Die wichtigsten Fragen zum CRA, fachlich fundiert und praxisnah für Hersteller digitaler Produkte beantwortet.

Wer ist vom Cyber Resilience Act betroffen?

Der CRA betrifft alle Hersteller, Importeure und Händler, die Produkte mit digitalen Elementen in der EU in Verkehr bringen. Dazu zählen physische Produkte mit Software oder Firmware (IoT-Geräte, Industriesteuerungen, Netzwerkkomponenten) sowie reine Software-Produkte, die eigenständig auf dem Markt platziert werden. Open-Source-Software, die nicht kommerziell vertrieben wird, ist ausgenommen. Auch Importeure und Händler tragen Mitverantwortung: Importeure oder Händler, die ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringen oder wesentlich ändern, gelten als Hersteller (Art. 21 CRA).

Was ist der Unterschied zwischen Klasse I und Klasse II Produkten?

Klasse-I-Produkte (normale Kritikalität nach Anhang III CRA) umfassen Produkte mit begrenzten Sicherheitsrisiken wie Consumer-Router, Smart-Home-Geräte oder einfache Browser. Sie können per Selbstbewertung des Herstellers (EU-Konformitätserklärung) CE-gekennzeichnet werden. Klasse-II-Produkte (erhöhte Kritikalität, Anhang III) wie Firewalls, Hypervisoren oder manipulationssichere Mikroprozessoren müssen durch eine unabhängige, notifizierte Stelle geprüft werden. Für kritische Produkte des Anhangs IV (wie bestimmte Chipkarten oder Hardware-Sicherheitsmodule) gelten die strengsten Anforderungen.

Wann gilt der Cyber Resilience Act vollständig?

Der CRA (Verordnung (EU) 2024/2847) wurde am 20. November 2024 veröffentlicht und trat am 10. Dezember 2024 offiziell in Kraft. Die Umsetzungsfristen sind gestaffelt. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle (Art. 14 CRA). Am 11. Dezember 2027 folgen die Hauptpflichten: Konformitätsbewertung und CE-Kennzeichnung. Der Aufbau konformer Prozesse braucht Vorlauf, die verbleibende Zeit ist also knapper, als das Datum 2027 vermuten lässt.

Wo melden Hersteller eine aktiv ausgenutzte Schwachstelle?

Meldungen nach Art. 14 CRA laufen über die Single Reporting Platform der ENISA, kurz CRA-SRP, erreichbar unter portal.cra-srp.enisa.europa.eu. Für den Zugang ist ein EU-Login-Konto nötig. Eine Registrierung auf Vorrat verlangt die Plattform nicht: Laut BSI sind Registrierung und Meldung im Bedarfsfall in wenigen Minuten erledigt. Das koordinierende CSIRT, in Deutschland das CERT-Bund im BSI, nimmt die Meldung entgegen und verteilt sie an die CSIRTs der weiteren betroffenen Mitgliedstaaten; ENISA erhält sie parallel. Die Fristen bauen aufeinander auf: 24 Stunden Frühwarnung, 72 Stunden detailliertere Meldung, danach der Abschlussbericht.

Welche Bußgelder drohen bei CRA-Verstößen?

Der CRA sieht dreistufige Sanktionen vor: Für die schwerwiegendsten Verstöße, also die Nichterfüllung der wesentlichen Cybersicherheitsanforderungen, drohen Bußgelder bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes (der höhere Betrag gilt). Für andere Verstöße wie Nichterfüllung der Konformitätsbewertungspflichten: bis 10 Mio. EUR oder 2 % Jahresumsatz. Für die Bereitstellung falscher oder unvollständiger Informationen für Behörden: bis 5 Mio. EUR oder 1 % Jahresumsatz. In Deutschland ist das BSI die zuständige Marktüberwachungsbehörde.

Wie hängen Cyber Resilience Act und NIS-2 zusammen?

CRA und NIS-2 ergänzen sich, richten sich aber an unterschiedliche Adressaten. NIS-2 verpflichtet Betreiber wichtiger Dienste und Einrichtungen zur Absicherung ihrer eigenen IT-Infrastruktur. Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen zur Produktsicherheit. In der Praxis bedeutet das: NIS-2-betroffene Unternehmen, die auch Software oder vernetzte Geräte herstellen, müssen beide Regelwerke einhalten. Gleichzeitig profitieren NIS-2-Betreiber vom CRA, denn sicherere Produkte am Markt reduzieren das Risiko für die gesamte Lieferkette. Das BSI koordiniert die Aufsicht über beide Regelwerke.

Was muss eine SBOM im Sinne des CRA enthalten?

Die Software Bill of Materials (SBOM) nach CRA (Anhang I Teil II Nr. 1) muss zumindest die obersten Abhängigkeiten des Produkts erfassen; in der Praxis enthält sie Komponenten mit Versionsnummern, Lizenzen und ggf. bekannten Schwachstellen (CVE-Referenzen). Als anerkannte Formate gelten SPDX (ISO/IEC 5962) und CycloneDX. Die SBOM muss mit jeder neuen Produktversion aktualisiert werden. Sie muss nicht standardmäßig veröffentlicht werden, muss aber Marktüberwachungsbehörden auf Anfrage vorgelegt und bei Schwachstellenoffenbarung intern genutzt werden, um betroffene Komponenten schnell identifizieren zu können.

Was kostet die CRA-Compliance?

Der Aufwand für CRA-Compliance hängt stark vom Produkt und dem aktuellen Reifegrad ab. Für einfache Klasse-I-Produkte mit bestehenden Entwicklungsprozessen kann die Umsetzung mit 20.000 bis 80.000 EUR kalkuliert werden. Für Klasse-II-Produkte, die eine unabhängige Prüfung durch eine notifizierte Stelle erfordern, sind typischerweise 80.000 bis 250.000 EUR einzuplanen, je nach Produktkomplexität und Umfang der Dokumentation. Unternehmen, die bereits ISO 27001 oder IEC 62443 implementiert haben, können erhebliche Synergien nutzen und den Aufwand deutlich reduzieren.

Gilt der CRA auch für Open-Source-Software?

Der CRA nimmt Open-Source-Software, die nicht kommerziell vertrieben wird, explizit aus dem Anwendungsbereich aus (Erwägungsgrund 18 CRA). Das bedeutet: Reine Open-Source-Community-Projekte ohne kommerzielle Absicht sind nicht direkt betroffen. Sobald jedoch ein Unternehmen Open-Source-Komponenten in ein kommerziell vertriebenes Produkt integriert, fällt das Endprodukt unter den CRA. Der Hersteller muss dann die SBOM-Pflichten für alle enthaltenen Open-Source-Komponenten erfüllen. Für Open-Source-Stiftungen und -Organisationen, die Software kommerziell unterstützen, gelten spezifische Ausnahmeregelungen.

Welche Rolle spielt das BSI beim Cyber Resilience Act?

In Deutschland fungiert das Bundesamt für Sicherheit in der Informationstechnik (BSI) als nationale Marktüberwachungsbehörde für den CRA. Das BSI kann Produkte auf dem Markt überprüfen, bei Nichtkonformität den Rückruf oder die Marktrücknahme anordnen und Bußgelder verhängen. Für die Meldungen nach Art. 14 CRA, die seit dem 11. September 2026 Pflicht sind, ist das CERT-Bund im BSI das koordinierende CSIRT: Es nimmt die über die CRA-SRP eingereichten Meldungen entgegen und verteilt sie an die CSIRTs der weiteren betroffenen Mitgliedstaaten. Das BSI hat außerdem die Möglichkeit, eigene technische Richtlinien (BSI TR) zu erlassen, die als konformitätsvermutende Standards anerkannt werden können. Bei schwerwiegenden Verstößen koordiniert das BSI mit der EU-Ebene (ENISA, anderen nationalen Behörden).

Wie bereitet AWARE7 Hersteller auf den CRA vor?

Unser CRA-Readiness-Programm folgt vier Phasen: (1) Betroffenheitsanalyse mit Produktklassifizierung (Klasse I / II / Kritisch), Anwendungsbereichsprüfung und erster Gap-Analyse. (2) Prozessaufbau mit Secure Development Life Cycle (SDLC), Vulnerability-Management-Prozessen und SBOM-Toolchain. (3) Dokumentation: technische Dokumentation, Risikoanalyse, EU-Konformitätserklärung, interne Audits. (4) Zertifizierungsbegleitung, also Vorbereitung auf die Prüfung durch notifizierte Stellen bei Klasse-II-Produkten, Koordination mit dem BSI. In der Regel ist eine vollständige CRA-Compliance in 6 bis 18 Monaten erreichbar.

CRA Readiness Check vereinbaren

In einem kostenlosen 30-minütigen Gespräch klassifizieren wir Ihre Produkte, bewerten Ihre CRA-Compliance-Lücke und skizzieren den realistischen Weg zur CE-Kennzeichnung, mit Zeitplan und Festpreisangebot.

Jetzt CRA Readiness Check buchen Mehr über SBOM & Supply Chain Security

Kostenlos · 30 Minuten · Unverbindlich