Compliance
Der Cyber Resilience Act: Was Security-Teams dokumentieren müssen

Der EU Cyber Resilience Act (Verordnung 2024/2847) leistet etwas, das kein bisheriges EU-Cybergesetz geleistet hat: Er legt Sicherheitspflichten auf das Produkt, nicht nur auf den Betreiber. Er ist am 10. Dezember 2024 in Kraft getreten, seine zentralen Pflichten gelten ab dem 11. Dezember 2027, und Verstöße werden mit Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet. Für Security- und Netzwerkteams, die NIS2 und DORA gewohnt sind, bildet der CRA eine andere Achse desselben regulatorischen Vorstoßes, und dieser Leitfaden erklärt, wo er sich mit den Netzwerkkontrollen überschneidet, die Sie bereits betreiben, und wo nicht.
Was der CRA tatsächlich reguliert
Der CRA gilt für „Produkte mit digitalen Elementen“, Hardware und Software, die auf dem EU-Markt bereitgestellt werden, unabhängig davon, ob sie mit dem Internet verbunden sind. Das umfasst Router, smarte Geräte, Industriesysteme und Softwarekomponenten, die so alltäglich sind wie eine Bibliothek. Hersteller, Importeure und Händler tragen gemeinsam Verantwortung, und Produkte benötigen eine CE-Kennzeichnung, die die Konformität belegt. Der Überblick der Europäischen Kommission zum Cyber Resilience Act legt die Produktkategorien und den Zeitplan dar.
Welche Produkte in den Geltungsbereich fallen
Der CRA ordnet Produkte mit digitalen Elementen in Risikoklassen ein, und die Klasse bestimmt den Konformitätsweg. Die Standardklasse, die große Mehrheit der Produkte, kann sich selbst gegen die grundlegenden Anforderungen bewerten. Wichtige Produkte (Klasse I und II), darunter Passwort-Manager, Netzwerkmanagementsysteme, VPNs, Router, Firewalls und Mikrocontroller, unterliegen strengeren Erwartungen, wobei Klasse II eine Bewertung durch Dritte verlangt. Kritische Produkte, Hardware-Sicherheitsmodule, sichere Smartcard-Elemente, Smart-Meter-Gateways, können eine europäische Cybersicherheitszertifizierung erfordern.
Beachten Sie, wo die Netzwerkausstattung landet: Router, Firewalls und Netzwerkmanagementsysteme werden ausdrücklich als wichtige Produkte benannt. Wenn Ihre Organisation eine Netzwerk-Appliance für den EU-Markt herstellt oder unter eigenem Namen vertreibt (White-Label), erfasst der CRA Ihre eigene Produktlinie, nicht nur die Ihrer Lieferanten.
CRA vs. NIS2 vs. DORA: Unterschiedliche Achsen
Die häufigste Verwechslung besteht darin, diese als konkurrierende Rahmenwerke zu behandeln. Sie ergänzen sich und regulieren unterschiedliche Gegenstände:
| Verordnung | Reguliert | Wer verpflichtet ist |
|---|---|---|
| CRA | Die Sicherheit des Produkts über seinen gesamten Lebenszyklus | Hersteller, Importeure, Händler |
| NIS2 | Das Cyber-Risikomanagement des Betreibers | Wesentliche & wichtige Einrichtungen |
| DORA | Operationelle Resilienz von Finanz unternehmen und ihrer IKT-Lieferkette | Banken, Versicherer, Wertpapierfirmen, IKT-Dienstleister |
Eine Organisation kann nach allen drei verpflichtet sein: ein Hersteller eines vernetzten Geräts, der zugleich eine wesentliche Einrichtung nach NIS2 ist und, sofern er ein IKT-Zulieferer des Finanzsektors ist, in den Geltungsbereich von DORA fällt. Die Kontrollen überschneiden sich stark, auch wenn sich die rechtlichen Gegenstände unterscheiden.
Die Kernpflichten
Security by Design und by Default. Produkte müssen in einer sicheren Konfiguration ausgeliefert werden, die kein Nachhärten erfordert, mit in die Architektur eingebautem Schutz vor unbefugtem Zugriff und mit unter Angriff aufrechterhaltenen wesentlichen Funktionen.
Schwachstellenbehandlung. Hersteller müssen einen koordinierten Prozess zur Offenlegung von Schwachstellen betreiben, eine Software-Stückliste (SBOM) pflegen sowie Schwachstellen über den gesamten Unterstützungszeitraum hinweg verfolgen und beheben, wobei aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an die ENISA zu melden sind.
Sicherheitsupdates. Sicherheits-Patches müssen über einen festgelegten Unterstützungszeitraum bereitgestellt werden, und dieser Zeitraum muss den Käufern vor dem Kauf mitgeteilt werden, was der Praxis der stillschweigend aufgegebenen Firmware ein Ende setzt.
Datenschutz und Zugriffskontrolle. Datenminimierung, Verschlüsselung während der Übertragung und im Ruhezustand, starke Authentifizierung und Zugriffsprotokollierung, Pflichten, die eng mit Artikel 32 DSGVO und mit den technischen Maßnahmen übereinstimmen, die Netzwerkteams bereits vertraut sind.
Wo der CRA auf das Netzwerkteam trifft
Der CRA ist eine Produktregulierung, daher landet vieles davon bei Produkt- und Entwicklungsteams statt beim Netzwerkbetrieb. Doch drei Stränge verbinden ihn unmittelbar mit der Firewall- und Netzwerkpraxis. Erstens verlangt die Pflicht zur Schwachstellenbehandlung, dass Sie wissen, was exponiert ist, dasselbe kontinuierliche automatisierte Schwachstellen-Scanning, das andere Rahmenwerke stützt, liefert auch CRA-Nachweise. Zweitens wirken dort, wo ein Produkt nicht sofort gepatcht werden kann, Netzwerksegmentierung und Egress-Kontrolle als kompensierende Maßnahmen, die die Exposition begrenzen, eine operative Entscheidung, die das Netzwerkteam verantwortet. Drittens gelten für Organisationen, die selbst gehostete oder On-Premise-Komponenten einsetzen, um Datensouveränitätspflichten zu erfüllen, die Bereitstellungsmuster für selbst gehostete Lösungen regulierter Branchen ebenso für CRA-relevante Software.
Konformitätsbewertung und CE-Kennzeichnung
Die CE-Kennzeichnung belegt die Konformität. Für die meisten Produkte genügt eine Selbstbewertung des Herstellers gegen die grundlegenden Anforderungen; kritische und wichtige Produktkategorien erfordern eine Konformitätsbewertung durch Dritte. Die technische Dokumentation muss die Konformität nachweisen, und eine Konformitätserklärung begleitet das Produkt auf den Markt. Marktüberwachungsbehörden können die Rücknahme nicht konformer Produkte anordnen.
Der Zeitplan
| Datum | Meilenstein |
|---|---|
| 10. Dez. 2024 | Verordnung 2024/2847 tritt in Kraft |
| 11. Sep. 2026 | Meldepflichten für Schwachstellen und Vorfälle beginnen zu gelten |
| 11. Dez. 2027 | Zentrale Pflichten gelten, vollständige CE-Kennzeichnungs-Konformität erforderlich |
Häufig gestellte Fragen
Gilt der CRA für interne oder air-gapped Software?
Er gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, einschließlich Software, die nie auf das Internet zugreift. Der Auslöser ist das Inverkehrbringen des Produkts, nicht die Konnektivität. Rein interne, maßgeschneiderte Software, die Sie nicht auf den Markt bringen, fällt in der Regel nicht in den Geltungsbereich, doch prüfen Sie dies anhand der endgültigen Leitlinien für Ihre Produktkategorie.
Wie unterscheidet sich der CRA von NIS2?
NIS2 regelt, wie ein Betreiber Cyberrisiken managt; der CRA regelt die Sicherheit des Produkts selbst über seinen Lebenszyklus. Ein Gerätehersteller, der zugleich eine wesentliche Einrichtung ist, ist nach beiden verpflichtet, nach dem CRA für das, was er ausliefert, nach NIS2 für die Art, wie er betrieben wird.
Was passiert, wenn ein Produkt nicht konform ist?
Die Geldbußen erreichen 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist, und Marktüberwachungsbehörden können die Rücknahme vom EU-Markt verlangen. Das kommerzielle Risiko eines Marktausschlusses wiegt in der Regel schwerer als die Geldbuße.
Fazit
Der CRA schließt die Lücke, die NIS2 und DORA offen gelassen haben: die Sicherheit der Produkte selbst. Der Dezember 2027 ist näher, als das 36-Monats-Fenster nahelegt, sobald man Konformitätsbewertung und SBOM-Werkzeuge mit einrechnet. Für Netzwerkteams liegen die praktischen Beiträge in der Schwachstellen-Sichtbarkeit und in der Segmentierung als kompensierende Maßnahme, beides messbar mit dem kostenlosen Firewall-Readiness-Check und strukturiert in der FwChange-Methodik.
Erfassen Sie Ihre Exposition als kompensierende Maßnahme
Wo eine CRA-relevante Komponente nicht sofort gepatcht werden kann, begrenzen Segmentierung und Egress-Kontrolle den Schadensradius. Der FwChange-Scanner zeigt, wo Ihr aktuelles Regelwerk diese Pfade offen lässt, in einem Befund-Dokument im Audit-Format.
Kostenlosen Scan starten →Über den Autor
Nick Falshaw ist Principal Security Architect mit über 17 Jahren Erfahrung in Enterprise-Firewall- und Netzwerksicherheit bei europäischen Tier-1-Großunternehmen, KRITIS-regulierten Betreibern und EU-Finanzdienstleistern. Autor der FwChange-Methodik auf Grundlage einer Analyse von mehr als 280 Firewall-Migrationen.


