Mit der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates (Cyber Resilience Act – CRA) vollzieht die Europäische Union einen tiefgreifenden Paradigmenwechsel in der Produkthaftung: Digitale Sicherheit wird von einem freiwilligen Qualitätsmerkmal zu einer zwingenden gesetzlichen Marktzugangsvoraussetzung für hardware- und softwarebasierte Produkte im gesamten EU-Binnenmarkt. Die Verordnung ist am 10. Dezember 2024 in Kraft getreten.
Der CRA regelt insbesondere die Produktsicherheit, Hersteller- und Wirtschaftsakteurepflichten, Konformitätsbewertungsverfahren und den Marktzugang. Von diesen regulatorischen Produktanforderungen ist die zivilrechtliche Schadensersatzhaftung für fehlerhafte Produkte juristisch zu unterscheiden (hierfür ist u. a. die reformierte Produkthaftungsrichtlinie (EU) 2024/2853 maßgeblich). Wer künftig vernetzte Produkte in der Europäischen Union in Verkehr bringt oder bereitstellt, muss deren Cybersicherheit über den gesamten definierten Unterstützungszeitraum sicherstellen.
Anwendungsbereich und Ausnahmen
Der Cyber Resilience Act erfasst nahezu die gesamte Bandbreite moderner IT- und OT-Landschaften. Adressiert werden alle Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz einschließt.
Betroffen sind sämtliche Wirtschaftsakteure entlang der Wertschöpfungskette:
- Hersteller: Tragen die Hauptverantwortung für die Erfüllung der grundlegenden Cybersicherheitsanforderungen, Konformitätsbewertungen und die Bereitstellung von Sicherheits-Updates.
- Bevollmächtigte und Importeure: Müssen vor dem Inverkehrbringen überprüfen, ob der Hersteller das vorgeschriebene Konformitätsverfahren ordnungsgemäß durchgeführt und technische Unterlagen erstellt hat.
- Händler und Distributoren: Unterliegen der Sorgfaltspflicht, Produkte ohne CE-Kennzeichnung oder mit erkennbaren Sicherheitsmängeln nicht auf dem Markt bereitzustellen.
Gesetzliche Ausnahmen
Vom Anwendungsbereich des CRA ausdrücklich ausgenommen sind:
- Produkte, für die bereits gleichwertige sektorspezifische EU-Regelungen gelten: Medizinprodukte (MDR / IVDR), zivile Kraftfahrzeuge (Verordnung (EU) 2019/2144), die Zivilluftfahrt (Verordnung (EU) 2018/1139) sowie bestimmte Ausrüstungsteile für die Seeschifffahrt.
- Software-as-a-Service (SaaS): Reine Cloud-Dienste fallen nicht unter den CRA, es sei denn, es handelt sich um Fernverarbeitungslösungen, die integraler Bestandteil eines physischen oder digitalen Produkts sind.
- Open-Source-Software: Freie und quelloffene Software, die außerhalb einer geschäftlichen Tätigkeit entwickelt oder bereitgestellt wird.
Kernanforderungen an Hersteller und Inverkehrbringer
Die Verordnung definiert konkrete technische und organisatorische Verpflichtungen:
1. Security-by-Design und Security-by-Default
Sicherheitsaspekte müssen bereits in der Konzeptions- und Entwicklungsphase verankert werden. Produkte dürfen grundsätzlich nur ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden und müssen mit einer sicheren Standardkonfiguration ausgeliefert werden:
- Deaktivierung nicht benötigter Dienste, Schnittstellen und Ports sowie Unterbindung vorinstallierter Standard-Passwörter.
- Durchgängige Durchsetzung starker Authentifizierungsmechanismen und Schutz vor Brute-Force-Angriffen.
- Verschlüsselung gespeicherter und übertragener Daten nach dem Stand der Technik.
- Schutz vor unbefugtem Zugriff auf Steuerungsschnittstellen und Sensordaten.
2. Software Bill of Materials (SBOM) & Lieferkettentransparenz
Moderne Software besteht zu großen Teilen aus Open-Source-Frameworks und Drittbibliotheken. Der CRA verpflichtet Hersteller zur Erstellung und laufenden Pflege einer maschinenlesbaren Software-Stückliste (SBOM). Das gesetzliche Mindestformat muss dabei zumindest die obersten Abhängigkeiten (Top-Level-Dependencies) ausweisen. Hersteller müssen Schwachstellen in den integrierten Komponenten überwachen und Sicherheitslücken durch zeitnahe Updates schließen.
3. Lebenszyklus-Support und Patch-Management
Die Pflicht zur Gewährleistung der Cybersicherheit endet nicht mit dem Verkauf:
- Supportzeitraum: Hersteller müssen für die Dauer der vernünftigerweise erwarteten Produktlebensdauer, mindestens jedoch für fünf Jahre (außer die erwartete Lebensdauer ist kürzer), grundsätzlich kostenfreie Sicherheitsupdates bereitstellen. Für maßgeschneiderte Produkte an gewerbliche Nutzer (B2B-Sonderanfertigungen) besteht hiervon eine vertragliche Ausnahme.
- Getrennte Updates: Sicherheits-Patches sind – soweit technisch machbar – getrennt von funktionalen Erweiterungen auszuliefern, um Betreibern eine gezielte Einspielung von Sicherheitskorrekturen zu ermöglichen.
- Vulnerability Disclosure Policy (VDP): Etablierung eines geordneten Verfahrens zur sicheren Entgegennahme und Koordination von Hinweisen externer Sicherheitsforscher.
Risikoklassen und Konformitätsbewertung
Der CRA differenziert Produkte nach ihrem Gefährdungspotenzial in verschiedene Risikoklassen, an die sich das Konformitätsbewertungsverfahren koppelt:
| Produktkategorie | Gesetzliche Zuordnung & Beispiele | Konformitätsverfahren |
|---|---|---|
| Standardprodukte (~90 % aller Produkte) | Standard-Anwendungssoftware, Standard-Hardware, Smart-Home-Sensoren ohne kritische Steuerfunktion, einfaches vernetztes Spielzeug (ohne soziale Interaktions- oder Ortungsfunktionen). | Interne Fertigungskontrolle durch den Hersteller (Selbstdeklaration). |
| Wichtige Produkte (Klasse I, Anhang III) | Identitätsmanagementsysteme, Passwort-Manager, Antivirenprogramme, Netzwerk-Schnittstellen, Router, Betriebssysteme sowie vernetztes Spielzeug mit sozialen Interaktionsfunktionen oder Standortverfolgung (Anhang III Nr. 18). | Anwendung harmonisierter EU-Normen oder Auditierung durch eine benannte Stelle (Notified Body). |
| Wichtige Produkte (Klasse II, Anhang III) | Hypervisoren und Container-Runtime-Systeme, Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme (IDS/IPS), sowie manipulationssichere (tamper-resistant) Mikroprozessoren und Mikrocontroller. | Prüfung und Zertifizierung durch eine unabhängige benannte Stelle (Notified Body) oder den Nachweis über ein einschlägiges europäisches Cybersicherheitszertifikat (gemäß Cybersecurity Act). |
| Kritische Produkte (Anhang IV) | Hardware-Geräte mit Security-Boxes, Smart-Meter-Gateways in intelligenten Messsystemen (und Geräte für erweiterte Sicherheitszwecke / sichere Kryptoverarbeitung), Smartcards und ähnliche Geräte einschließlich Secure Elements. | Europäisches Cybersicherheits-Zertifikat (mindestens Stufe „substanziell“), sofern per delegiertem Rechtsakt der Kommission vorgeschrieben; andernfalls gilt das Verfahren für Klasse II. |
Gesetzliche Meldepflichten und Stichtage
Für Wirtschaftsakteure sieht der Cyber Resilience Act einen klaren Umsetzungsfahrplan vor:
- 10. Dezember 2024: Inkrafttreten der Verordnung (EU) 2024/2847.
- 11. September 2026 (nach 21 Monaten): Geltungsbeginn der Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle (entscheidender Zwischenstichtag!).
- 11. Dezember 2027 (nach 36 Monaten): Volle Anwendbarkeit aller materiellen Produktanforderungen, Konformitätsbewertungsverfahren und der CE-Kennzeichnungspflicht.
Wichtige Übergangsregelung für Altprodukte: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den materiellen Anforderungen des CRA grundsätzlich erst bei einer anschließenden wesentlichen Änderung. Ein pauschales Vertriebsverbot für bestehende Lagerbestände ab Dezember 2027 greift somit nicht. Die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle erfassen dagegen ab dem 11. September 2026 auch entsprechende Altprodukte.
Meldefristen gegenüber CSIRTs und ENISA
Tritt eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall auf, gelten gestaffelte Pflichten:
- Innerhalb von 24 Stunden ab Kenntnisnahme: Frühwarnung an das zuständige nationale CSIRT und die ENISA über die zentrale europäische Single Reporting Platform.
- Innerhalb von 72 Stunden ab Kenntnisnahme: Detaillierte Meldung mit Angaben zum Vorfall bzw. zur Schwachstelle, vorläufiger Risikobewertung und geplanten Abhilfemaßnahmen.
- Abschlussbericht: Spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme (bei Schwachstellen) bzw. bei schwerwiegenden Sicherheitsvorfällen grundsätzlich spätestens einen Monat nach Übermittlung der 72-Stunden-Meldung.
- Nutzerinformation: Pflicht zur unverzüglichen Information der betroffenen Anwender über die Schwachstelle bzw. den Vorfall und erforderliche Abhilfemaßnahmen.
Sanktionsrahmen
Verstöße gegen die Bestimmungen des CRA werden empfindlich sanktioniert:
- Bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verletzung der grundlegenden Cybersicherheitsanforderungen sowie bei Verstößen gegen die Herstellerpflichten nach Art. 13 und Art. 14 (einschließlich der CRA-Meldepflichten).
- Bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes bei Nichteinhaltung sonstiger Verpflichtungen anderer Wirtschaftsakteure (z. B. Händler, Importeure oder Bevollmächtigte).
- Bis zu 5 Millionen Euro oder 1 % des weltweiten Jahresumsatzes bei unvollständigen, unrichtigen oder irreführenden Angaben gegenüber Marktüberwachungsbehörden.
- Berechnungsgrundsatz: Es gilt jeweils der höhere Betrag. Ergänzend drohen behördliche Vertriebsverbote und Produkt-Rückrufe im gesamten Binnenmarkt.
Pragmatischer Fahrplan für Führungskräfte
- Portfolio- und Klassifizierungsanalyse: Identifikation aller im Unternehmen entwickelten oder vertriebenen vernetzten Produkte und Zuordnung zu den CRA-Risikoklassen.
- DevSecOps & SBOM-Automatisierung: Integration automatisierter Software-Stücklisten (z. B. CycloneDX oder SPDX) und Schwachstellen-Scans in die Build-Pipelines.
- Vulnerability-Handling-Prozesse aufbauen: Etablierung einer VDP und Einführung eines Melde-Workflows für die ab September 2026 greifenden Fristen.
- Zuliefererverträge anpassen: Vertragliche Verpflichtung von Hard- und Software-Lieferanten zur Unterstützung von SBOMs und langfristiger Sicherheits-Patches.
Begleitung durch Authenta
Authenta unterstützt Entwicklungsleiter, Produktmanager und Compliance-Verantwortliche bei der praxistauglichen Ausgestaltung von DevSecOps-Prozessen, der Vorbereitung auf Konformitätsbewertungen und der herstellerunabhängigen Auditierung vernetzter Systeme.