Cyber Resilience Act: Pflichten für Hersteller von Produkten mit digitalen Elementen

Was der CRA ist – und was er nicht ist

Die Verordnung (EU) 2024/2847 – kurz: Cyber Resilience Act – ist das erste EU-weit verbindliche Regelwerk für die Cybersicherheit von Produkten mit digitalen Elementen. Sie trat am 10. Dezember 2024 in Kraft und gilt unmittelbar in allen EU-Mitgliedstaaten, ohne nationalen Umsetzungsakt.

Was der CRA reguliert, ist klar: Produkte, die Software oder Firmware enthalten oder mit einem Netz verbunden werden können – unabhängig davon, ob dieses Produkt primär als Hardware oder als Software vermarktet wird. Was der CRA nicht ist: ein allgemeines IT-Sicherheitsgesetz, eine Erweiterung der DSGVO oder eine Variante der NIS-2-Richtlinie.

Hier liegt ein häufiges Missverständnis: NIS-2 reguliert Cybersicherheit für Betreiber – also Organisationen, die kritische Infrastrukturen oder wichtige Dienste betreiben. Der CRA reguliert Hersteller von Produkten. Eine Fabrik, die Maschinen baut, ist in der Regel kein NIS-2-Betreiber – aber sehr wohl CRA-Hersteller, wenn in diesen Maschinen Software oder Netzwerkkommunikation steckt.

Der zweite häufige Irrtum: „Der CRA gilt doch erst 2027." Das stimmt für die Hauptpflichten. Die Meldepflichten für Schwachstellen und Sicherheitsvorfälle gelten bereits ab 11. September 2026 – mehr als ein Jahr früher. Wer erst zum zweiten Stichtag anfängt, ist zum ersten bereits in der Pflicht.

Produkte mit digitalen Elementen: Wer betroffen ist

Der Begriff „Produkt mit digitalen Elementen" ist absichtlich weit gefasst. Er umfasst jede Hardware, die direkt oder indirekt mit einem anderen Gerät oder Netz verbunden werden kann – und jede Software, die selbstständig auf dem Markt angeboten wird.

In der Praxis bedeutet das für mittelständische Industrieunternehmen:

Betroffen: Steuergeräte, Microcontroller-Boards und Edge-Computing-Module, die in Maschinen verbaut und über Ethernet, WLAN, OPC-UA oder CAN-Bus kommunizieren. Sensoren, Aktoren oder Gateways mit eigenem Betriebssystem oder aktualisierbarer Firmware. Industrielle HMI-Systeme, auch wenn sie nur im internen Netz eingebunden sind. Embedded Software, die als eigenständiges Lizenzprodukt verkauft wird. Geräte mit Bluetooth, Zigbee, NB-IoT oder vergleichbarer Funktechnik.

Nicht betroffen: Rein mechanische Produkte ohne jede digitale Komponente. Produkte unter sektorspezifischen Ausnahmen des CRA (Medizinprodukte nach MDR, Fahrzeuge nach Typgenehmigungsverordnung, bestimmte Marine- und Luftfahrtprodukte).

Die Abgrenzung ist im Einzelfall nicht immer trivial. Eine Fräsmaschine mit mechanischer NC-Steuerung ohne Netzwerkanbindung fällt nicht unter den CRA. Dieselbe Maschine mit einer SPS, die per OPC-UA ins Firmennetz eingebunden ist, schon. Entscheidend ist nicht die Kategorie des Produkts, sondern seine tatsächliche digitale Vernetzbarkeit.

Die drei Risikoklassen: Was gilt für wen?

Der CRA unterscheidet drei Kategorien, die bestimmen, welches Konformitätsbewertungsverfahren gilt:

Standard-Produkte: Die große Mehrheit der betroffenen Produkte fällt hierunter. Eine Eigenkonformitätserklärung des Herstellers ist ausreichend – keine externe Prüfstelle ist zwingend notwendig. Der Hersteller erklärt selbst, dass sein Produkt die Sicherheitsanforderungen erfüllt.

Klasse I – Wichtige Produkte: Hier besteht die Wahl: Entweder der Hersteller wendet harmonisierte Normen an und erklärt die Konformität selbst, oder er lässt das Produkt von einer akkreditierten Prüfstelle bewerten. Konkrete Beispiele aus dem industriellen Umfeld: Webbrowser, VPN-Produkte, Passwortmanager, allgemeine Betriebssysteme, industrielle IACS-Komponenten (Industrial Automation and Control Systems), industrielle IoT-Geräte, Netzwerkverwaltungstools.

Klasse II – Kritische Produkte: Hier ist eine Prüfung durch eine benannte Stelle (Notified Body) verpflichtend. Beispiele: Steuerungssysteme kritischer Infrastruktur (Energie, Wasser, Verkehr), bestimmte Router und Switches für kritische Infrastruktur.

Für die Praxis bedeutet das: Ein Hersteller von industriellen IoT-Sensoren oder IACS-Komponenten muss prüfen, ob sein Produkt unter Klasse I fällt – und ob er den Nachweis durch harmonisierte Normen erbringen kann oder eine externe Bewertung einplanen muss. Klasse-II-Hersteller müssen Notified Bodies frühzeitig einbeziehen – die Kapazitäten werden mit steigendem Bedarf knapp werden.

Pflichten des Herstellers

Die Pflichten gliedern sich in vier Bereiche:

Sicherheitsanforderungen an das Produkt: Security by Design – Sicherheit muss von Beginn der Entwicklung integriert werden, nicht nachträglich. Minimale Angriffsfläche: nur notwendige Ports, Protokolle und Dienste aktivieren. Standardmäßig sichere Konfiguration. Schutz vor unbefugtem Zugriff und kryptografisch gesicherte Kommunikation, wo relevant. Vertraulichkeit und Integrität gespeicherter und übertragener Daten.

Schwachstellenmanagement (laufend, für die gesamte Lebensdauer des Produkts, mindestens 5 Jahre): Aktive Identifikation und Behebung von Schwachstellen. Kostenlose Sicherheitsupdates für die erwartete Produktnutzungsdauer, in der Praxis typischerweise mindestens fünf Jahre. SBOM (Software Bill of Materials) – vollständige Auflistung aller Software-Komponenten – als Pflicht ab Dezember 2027. Koordiniertes Schwachstellenoffenlegungsverfahren (CVD-Policy) veröffentlichen.

Meldepflichten (ab 11. September 2026): Aktiv ausgenutzte Schwachstellen: 24-Stunden-Frühwarnung an ENISA (und über das nationale CSIRT an das BSI), 72-Stunden-Meldung mit ersten Details, Abschlussbericht innerhalb von 14 Tagen. Für erhebliche Sicherheitsvorfälle gelten dieselben Fristen.

Konformitätsbewertung und Dokumentation: Technische Dokumentation erstellen. EU-Konformitätserklärung ausstellen. CE-Kennzeichnung anbringen. Registrierung in der EU-Datenbank (verpflichtend für Klasse II und auf Verlangen der Aufsichtsbehörde).

Bei Verstößen drohen erhebliche Bußgelder: bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen Sicherheitsanforderungen, bis zu 10 Mio. € / 2 % bei Dokumentations- und CE-Verstößen, bis zu 5 Mio. € / 1 % bei falschen Angaben gegenüber Behörden.

Pflichten von Importeuren und Händlern

Nicht nur Hersteller, sondern auch Importeure und Händler tragen Pflichten nach dem CRA – allerdings geringere.

Importeure müssen sicherstellen, dass Produkte aus Drittstaaten, die sie in der EU in Verkehr bringen, die CRA-Anforderungen erfüllen. Sie müssen die technische Dokumentation auf Anfrage vorlegen können, die EU-Konformitätserklärung aufbewahren und nicht konforme Produkte vom Markt nehmen.

Händler – also Unternehmen im Vertrieb, die weder Hersteller noch Importeur sind – müssen vor der Weitergabe prüfen, ob CE-Kennzeichnung und Konformitätserklärung vorliegen. Bei selbst markierten oder wesentlich modifizierten Produkten gelten sie als Hersteller.

Praxisrelevanz: Wenn Sie als Maschinenbauer Steuerkomponenten aus Asien beschaffen und in Ihre Anlage einbauen, die Sie dann in der EU verkaufen, sind Sie möglicherweise Importeur – mit entsprechenden Prüf- und Dokumentationspflichten.

Der Zeitplan: Was gilt ab wann

• 10. Dezember 2024: Verordnung in Kraft getreten. Nationale Aufsichtsbehörden werden benannt.
• 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und erhebliche Sicherheitsvorfälle gelten. 24h Frühwarnung, 72h erste Meldung, 14 Tage Abschlussbericht – Empfänger: ENISA und nationales CSIRT (in Deutschland: BSI).
• 11. Dezember 2027: Alle Hauptpflichten gelten vollständig – Sicherheitsanforderungen, Schwachstellenmanagement, Konformitätsbewertung, CE-Kennzeichnung, SBOM-Pflicht.

Der entscheidende Punkt: Zwischen dem ersten Stichtag (Meldepflichten, September 2026) und dem zweiten Stichtag (vollständige Compliance, Dezember 2027) liegen 15 Monate. Wer erst zum zweiten Stichtag anfängt, ist zum ersten bereits in der Pflicht – und hat keine Meldeprozesse eingerichtet.

Was Hersteller jetzt konkret tun sollten

Schritt 1: Produkt-Inventur

Erstellen Sie eine Liste aller Produkte, die Sie herstellen oder importieren. Kennzeichnen Sie, welche davon eine digitale Komponente enthalten – Software, Firmware, Netzwerkkommunikation. Rein mechanische Produkte ohne Netzwerkfähigkeit können Sie herausstreichen.

Schritt 2: Risikoklassen-Einordnung

Prüfen Sie für die verbleibenden Produkte: Fällt das Produkt unter Klasse I oder II des CRA-Anhangs? Wenn nicht, gelten die Standardanforderungen. Halten Sie die Einordnung und ihre Begründung schriftlich fest – das ist bereits Teil der Dokumentationspflicht.

Schritt 3: Sicherheitsanforderungen gegen den Ist-Stand abgleichen

Analysieren Sie Ihre aktuellen Entwicklungsprozesse: Gibt es einen Prozess für Security by Design? Wird die Angriffsfläche bei der Produktentwicklung berücksichtigt? Werden Software-Abhängigkeiten dokumentiert? Wer für strukturiertes Systems Engineering in der Produktentwicklung bereits einen Rahmen hat – etwa über MBSE-Methodik –, kann diese Struktur für die CRA-Dokumentation nutzen. Identifizieren Sie Lücken: Das sind Ihre Handlungsfelder bis Dezember 2027.

Schritt 4: Meldewege einrichten (bis August 2026)

Richten Sie bis September 2026 die Meldewege für sicherheitsrelevante Vorfälle und Schwachstellen ein. In Deutschland ist das BSI die relevante nationale Behörde. Klären Sie intern: Wer meldet? In welchem Format? Mit welchen Informationen innerhalb der 24-Stunden-Frist?

Schritt 5: CVD-Policy veröffentlichen

Veröffentlichen Sie eine Coordinated Vulnerability Disclosure Policy – eine öffentlich zugängliche Beschreibung, wie Sicherheitsforscher oder Kunden Schwachstellen an Sie melden können. Das ist eine explizite Anforderung des CRA und oft schneller umzusetzen als gedacht.

Schritt 6: Technische Dokumentation aufbauen

Beginnen Sie mit der technischen Dokumentation gemäß CRA-Anforderungen. Das ist zeitaufwendig – und das, was die meisten Unternehmen am stärksten unterschätzen. Eine externe methodische Einordnung in dieser Phase reduziert spätere Nacharbeit.

Typische Missverständnisse

„CRA betrifft nur Software-Unternehmen." Falsch. Der CRA betrifft jeden Hersteller von Produkten mit digitalen Elementen. Maschinenbauer, Elektronikentwickler und Automatisierungstechnik-Hersteller sind eindeutig im Scope.

„Open-Source-Software ist ausgenommen." Teilweise richtig – und oft irreführend: Nicht-kommerzielle Open-Source-Projekte sind ausgenommen. Aber wenn ein Unternehmen Open-Source-Software kommerziell in sein Produkt einbettet, trägt es als Hersteller die volle CRA-Verantwortung für das Endprodukt.

„NIS-2 haben wir schon – CRA ist damit abgedeckt." Nein. NIS-2 betrifft Betreiber von Diensten. CRA betrifft Hersteller von Produkten. Die Regelungskreise überschneiden sich kaum. Ein Unternehmen kann unter beide fallen – muss aber nicht.

„Die RED-DA hat das schon geregelt." Die Radio Equipment Directive Delegated Act (RED-DA) wurde mehrfach verschoben. Der CRA hat diesen Bereich faktisch übernommen und abgelöst – die Anforderungen gelten jetzt über den CRA, nicht die RED-DA.

„Mit CE ist alles erledigt." CE ist eine Konformitätskennzeichnung, keine Aussage über Cybersicherheit. Erst wenn die CRA-Sicherheitsanforderungen erfüllt und entsprechend dokumentiert wurden, darf CE im CRA-Kontext angebracht werden.

Schnittstellen: CRA, AI Act und Maschinenverordnung

Für mittelständische Industrieunternehmen ist die Überschneidung mit anderen EU-Regelwerken praktisch relevant:

CRA und AI Act: Wenn ein Produkt mit digitalen Elementen auch KI-Funktionen enthält, kann es gleichzeitig unter den AI Act und den CRA fallen. Der AI Act fokussiert auf das Risiko, das vom KI-System ausgeht (Risikostufen nach Funktion und Einsatzkontext). Der CRA fokussiert auf die Cybersicherheit des Produkts (Schwachstellen, Updates, Meldepflichten). Wer KI-Funktionen in vernetzten Industrieprodukten einsetzt, muss beide Verordnungen prüfen – die Dokumentationspflichten ergänzen sich, überschneiden sich aber auch.

CRA und Maschinenverordnung (EU) 2023/1230: Die neue Maschinenverordnung (gilt vollständig ab Januar 2027) enthält bereits Anforderungen an die Cybersicherheit von Maschinen, soweit sie die Maschinensicherheit betreffen. Der CRA ergänzt das durch produktübergreifende Cybersicherheitspflichten. Wer Maschinen mit Netzwerkanbindung entwickelt, muss ab 2027 beide Regelwerke gleichzeitig erfüllen. Wer strukturiertes Systems Engineering in der Produktentwicklung einsetzt, kann Dokumentationspflichten aus beiden Verordnungen effizienter bündeln.

CRA und NIS-2: Wie beschrieben: NIS-2 betrifft Betreiber, CRA betrifft Hersteller. Wenn Ihr Unternehmen beides ist – zum Beispiel ein Energieversorger, der seine eigene Steuertechnik entwickelt – gelten beide Regelwerke parallel, mit getrennten Anforderungen und Fristen.