Der Cyber Resilience Act als Rechtsrahmen für digitale Produkte

von RA Clemens Handl 

 1. Einleitung

1.1. Mit dem Cyber Resilience Act (Verordnung [EU] 2024/2847), schafft die Europäische Union einen einheitlichen Rechtsrahmen für Cybersicherheitsanforderungen an Produkte mit digitalen Elementen. Anders als sektorspezifische Regelwerke knüpft der CRA nicht primär an eine bestimmte Branche an, sondern an das Produkt selbst und dessen digitale Funktionalität.

1.2. Der Anwendungsbereich ist deshalb bewusst weit gefasst. Erfasst werden grundsätzlich Produkte, die digitale Funktionen enthalten und direkt oder indirekt mit anderen Geräten oder Netzwerken verbunden sind. Für Unternehmen stellt sich damit frühzeitig die Frage, ob ein konkretes Produkt unter den Cyber Resilience Act fällt und welche regulatorischen

2. Was ist ein Produkt mit digitalen Elementen?

2.1. Ausgangspunkt ist die Definition des „Produkts mit digitalen Elementen“ in Art 3 Nr 1 CRA. Diese umfasst sowohl Software als auch Hardware, einschließlich separater Komponenten. Entscheidend ist, dass das Produkt bestimmungsgemäß oder unter vernünftigerweise vorhersehbaren Bedingungen eine direkte oder indirekte Datenverbindung zu einem Gerät oder zu einem Netzwerk aufweist.

2.2. Damit ist der Produktbegriff des CRA technologieneutral und breit angelegt. In der Praxis fallen darunter insbesondere Anwendungssoftware, vernetzte Konsumgüter, industrielle IoT-Lösungen, eingebettete Systeme, Steuerungskomponenten und digitale Infrastrukturprodukte.

2.3. Für die rechtliche Einordnung kommt es daher nicht auf die äußere Bezeichnung des Produkts an, sondern auf dessen digitale Funktion und Konnektivität. Gerade diese funktionale Betrachtung führt dazu, dass der CRA deutlich mehr Produkte erfasst, als auf den ersten Blick angenommen wird.

3.Welche Produkte sind vom Cyber Resilience Act ausgenommen?

3.1. Trotz seines weiten Anwendungsbereichs gilt der Cyber Resilience Act nicht ausnahmslos. Bestimmte Produktgruppen sind ausdrücklich ausgenommen, etwa einzelne Medizinprodukte oder bestimmte Systeme aus dem Fahrzeug- und Luftfahrtbereich. Hintergrund ist, dass für diese Bereiche bereits eigenständige unionsrechtliche Spezialregime bestehen.

3.2. Zusätzlich enthält Art 2 Abs 5 CRA eine Öffnungsklausel. Danach kann der Anwendungsbereich des CRA eingeschränkt oder ausgeschlossen sein, wenn sektorspezifische Vorschriften bereits ein gleichwertiges oder höheres Cybersicherheitsniveau gewährleisten.

3.3. Für die Praxis ist diese Schnittstelle besonders relevant. Unternehmen müssen den Cyber Resilience Act nicht isoliert prüfen, sondern immer auch im Verhältnis zu anderen unionsrechtlichen Vorgaben betrachten, etwa zum AI Act, zu NIS-2-bezogenen Verpflichtungen oder zu sektorspezifischen Sicherheits- und Produktregimen.
Sicherheits- und Produktregimen.

3.4. Welche Produktkategorien unterscheidet der CRA?
Der Cyber Resilience Act arbeitet mit einer risikobasierten Differenzierung. Er unterscheidet zwischen Produkten mit digitalen Elementen, wichtigen Produkten mit digitalen Elementen und kritischen Produkten.
Diese Einordnung ist rechtlich zentral, weil davon abhängt, welches Konformitätsbewertungsverfahren anzuwenden ist. Für die Mehrzahl der Produkte reichen interne Konformitätsbewertungen aus. Für wichtige und kritische Produkte gelten dagegen strengere Verfahren, insbesondere unter Einbindung notifizierter Stellen oder unter Rückgriff auf Zertifizierungssysteme.
Für Unternehmen bedeutet das: Nicht jedes digitale Produkt löst dieselbe regulatorische Intensität aus. Maßgeblich ist vielmehr, ob das Produkt nach seiner Funktion und seinem Risikoprofil in eine höhere Kategorie fällt.

4. Wann ist ein Produkt ein wichtiges oder kritisches Produkt?

4.1. Für die praktische Einordnung ist die Durchführungsverordnung (EU) 2025/2392 von besonderer Bedeutung. Sie konkretisiert, dass es für die Kategorisierung auf die Kernfunktion des Produkts ankommt.

4.2. Ein Produkt fällt demnach nur dann in eine Kategorie wichtiger oder kritischer Produkte, wenn seine Hauptfunktion dieser Kategorie entspricht. Die bloße Integration einzelner relevanter Komponenten genügt nicht. Das ist für die Praxis bedeutsam, weil moderne digitale Produkte regelmäßig aus zahlreichen Software- und Hardwarebausteinen bestehen.

4.3. Der Hersteller muss zwar die Sicherheit des gesamten Produkts bewerten und dabei auch integrierte Funktionen und Komponenten berücksichtigen. Für die Kategorisierung bleibt aber grundsätzlich die Hauptfunktion des Gesamtprodukts maßgeblich. Zusätzliche Funktionen führen daher nicht automatisch zu einer Höherstufung.

5. Beispiele für wichtige Produkte mit digitalen Elementen

5.1. Die Anhänge der Durchführungsverordnung zeigen, welche Produkte typischerweise als wichtige Produkte mit digitalen Elementen eingestuft werden. Dazu zählen vor allem sicherheitsrelevante Software- und Infrastrukturkomponenten, etwa Identitätsmanagementsysteme, Passwortmanager, Antimalware-Software, VPN-Systeme, SIEM-Lösungen, Bootmanager, PKI-Komponenten, Betriebssysteme und Netzwerkgeräte.

5.2. Erfasst sind außerdem bestimmte hardwarebezogene Komponenten mit Sicherheitsfunktion sowie einzelne Verbraucherprodukte, etwa Smart-Home-Sicherheitsgeräte oder Wearables.

5.3. In der höheren Risikoklasse innerhalb der wichtigen Produkte finden sich insbesondere zentrale Infrastrukturkomponenten wie Hypervisoren sowie Intrusion-Detection- und Intrusion-Prevention-Systeme. Für Hersteller solcher Produkte ist die korrekte Einordnung von erheblicher Bedeutung, weil daran strengere Konformitätsanforderungen und zusätzliche Nachweispflichten anknüpfen.

6. Was sind kritische Produkte im Sinn des CRA?

6.1. Die Kategorie der kritischen Produkte ist enger gefasst als jene der wichtigen Produkte. Erfasst werden vor allem Hardwareprodukte mit besonderer sicherheitstechnischer Relevanz, etwa Hardware-Sicherheitsmodule, Smart-Meter-Gateways oder bestimmte sicherheitsrelevante Chipkarten.

6.2. Für diese Produkte kann eine verpflichtende europäische Cybersicherheitszertifizierung vorgesehen werden. Unternehmen, die entsprechende Komponenten entwickeln, importieren oder vertreiben, sollten diese Qualifikation frühzeitig prüfen, weil sie erhebliche Auswirkungen auf Produktentwicklung, Marktzugang und interne Compliance-Strukturen haben kann.

7. Sanktionen und Geschäftsleiterhaftung

7.1. Für quelloffene Software enthält der Cyber Resilience Act eine differenzierte Sonderregelung. Freie und quelloffene Software fällt grundsätzlich nicht in den Anwendungsbereich, wenn sie nicht im Rahmen einer wirtschaftlichen Tätigkeit bereitgestellt wird.

7.2. Entscheidend ist damit nicht die Lizenzform, sondern der funktionale Kontext der Bereitstellung. Eine wirtschaftliche Tätigkeit kann insbesondere dann vorliegen, wenn die Software monetarisiert oder in kostenpflichtige Produkte oder Dienstleistungen integriert wird. Reine Beiträge von Entwicklerinnen und Entwicklern, Community-basierte Entwicklung oder Tätigkeiten gemeinnütziger Organisationen sind demgegenüber nicht ohne Weiteres erfasst.

7.3. Gleichzeitig erkennt der CRA die besondere Rolle von Akteuren an, die Open-Source-Projekte strukturell tragen und auf eine spätere kommerzielle Nutzung ausrichten. Für diese Akteure sieht der Rechtsrahmen eine abgeschwächte, speziell zugeschnittene Regulierung vor. Open Source ist daher nicht pauschal ausgenommen. Ausschlaggebend ist vielmehr, ob und in welchem Umfang die Software in eine wirtschaftliche Wertschöpfungskette eingebunden ist.

8. Welche Pflichten treffen Hersteller nach dem Cyber Resilience Act?

8.1. Unabhängig von der konkreten Produktkategorie sieht der Cyber Resilience Act für alle erfassten Produkte grundlegende Pflichten vor. Diese orientieren sich am gesamten Produktlebenszyklus und betreffen nicht nur die Entwicklung, sondern auch die laufende Marktphase.

8.2. Hersteller müssen insbesondere eine Cybersicherheits-Risikobewertung durchführen und diese über Entwicklung, Herstellung und Nutzung hinweg laufend aktualisieren. Die Anforderungen sind risikobasiert umzusetzen. Maßgeblich sind unter anderem Zweckbestimmung, Einsatzumgebung und erwartete Nutzungsdauer des Produkts.

8.3. Ein weiterer Schwerpunkt liegt auf dem Schwachstellenmanagement. Hersteller müssen Prozesse zur Identifikation, Dokumentation und Behebung von Schwachstellen etablieren. Dabei sind auch Risiken aus Drittkomponenten zu berücksichtigen, einschließlich Open-Source-Software. Der CRA verlangt damit eine deutlich strukturiertere Security Governance entlang der gesamten Entwicklungs- und Lieferkette.

9. Meldepflichten und Sicherheitsupdates

9.1. Zusätzlich normiert der Cyber Resilience Act Meldepflichten gegenüber Behörden. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen innerhalb kurzer Fristen gemeldet werden, zunächst im Wege einer Frühwarnung und anschließend in detaillierterer Form.

9.2. Darüber hinaus müssen Hersteller Sicherheitsupdates über einen definierten Unterstützungszeitraum bereitstellen. Dieser beträgt grundsätzlich mindestens fünf Jahre oder orientiert sich an der erwarteten Nutzungsdauer des Produkts.

9.3. Diese Vorgaben wirken nicht nur auf die juristische Dokumentation, sondern unmittelbar auf Produktdesign, Wartungsprozesse, Release-Management, Support-Strukturen und Geschäftsmodelle. Der Cyber Resilience Act ist damit kein reines Compliance-Thema, sondern ein Regelwerk mit direkter Auswirkung auf die technische und organisatorische Produktverantwortung.

10. Fazit: Der CRA erfasst mehr Produkte und Unternehmen als vielfach angenommen

10.1. Der Cyber Resilience Act ist kein Spezialregime für einzelne Hochrisikobranchen, sondern ein horizontaler Rechtsrahmen für eine große Bandbreite digitaler Produkte. Gerade wegen des weiten Produktbegriffs, der risikobasierten Kategorienbildung und der lebenszyklusbezogenen Pflichten ist eine frühe rechtliche Einordnung entscheidend.

10.2. Unternehmen sollten bestehende und künftige Produkte daher systematisch daraufhin prüfen, ob sie als Produkte mit digitalen Elementen im Sinn des CRA einzustufen sind, ob sie in die Kategorie wichtiger oder kritischer Produkte fallen und welche Folgen sich daraus für Entwicklung, Dokumentation, Schwachstellenmanagement und Update-Pflichten ergeben.

FAQ zum Cyber Resilience Act

Q: Für welche Produkte gilt der Cyber Resilience Act?

A: Der Cyber Resilience Act gilt grundsätzlich für Produkte mit digitalen Elementen, also für Software, Hardware und digitale Komponenten, die direkt oder indirekt mit Geräten oder Netzwerken verbunden sind.

Q: Gilt der CRA auch für Software?

A: Der Produktbegriff des CRA erfasst ausdrücklich auch Software. Dazu können etwa Anwendungssoftware, Betriebssysteme, Sicherheitssoftware oder eingebettete Softwarelösungen gehören.

Q: Sind Open-Source-Produkte vom CRA ausgenommen?

A: Nicht pauschal. Freie und quelloffene Software ist grundsätzlich ausgenommen, wenn sie nicht im Rahmen einer wirtschaftlichen Tätigkeit bereitgestellt wird. Bei kommerzieller Einbindung kann der CRA aber sehr wohl anwendbar sein.

Q: Was sind wichtige Produkte mit digitalen Elementen?

A: Darunter fallen bestimmte sicherheitsrelevante Software- und Infrastrukturkomponenten, etwa Passwortmanager, VPN-Systeme, Betriebssysteme, SIEM-Lösungen oder einzelne Smart-Home-Sicherheitsprodukte.

Q: Welche Pflichten haben Hersteller nach dem CRA?

A: Hersteller müssen unter anderem Cybersicherheits-Risikobewertungen durchführen, Schwachstellenmanagement etablieren, Sicherheitsvorfälle melden und Sicherheitsupdates über einen gesetzlich vorgegebenen Zeitraum bereitstellen.

Q: Wie lange müssen Sicherheitsupdates bereitgestellt werden?

A: Grundsätzlich mindestens fünf Jahre oder für die erwartete Nutzungsdauer des Produkts, sofern diese länger maßgeblich ist.