EU Cyber Resilience Act: Was er für die Hardwaresicherheit bedeutet

Der Cyber Resilience Act, Verordnung (EU) 2024/2847 [1], ist die erste horizontale EU-Gesetzgebung, die verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen über deren gesamten Lebenszyklus hinweg stellt. Sie gilt für Hersteller, Importeure und Händler, die solche Produkte auf dem Unionsmarkt in Verkehr bringen, unabhängig von ihrer Niederlassung. Der Anwendungsbereich ist bewusst weit gefasst: Jedes Produkt mit Software, Firmware oder vernetzten Komponenten, von Industriereglern bis zu Consumer-Wearables, fällt unter die Verordnung, sofern es nicht explizit ausgeschlossen ist [2].

Die rechtliche Architektur folgt dem aus der Funkanlagenrichtlinie und der Maschinenverordnung vertrauten Muster: wesentliche Anforderungen in Anhang I, Konformitätsbewertungsverfahren, CE-Kennzeichnung und ein Marktüberwachungsregime, das durch Sanktionen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes (je nachdem, welcher Betrag höher ist) gestützt wird [3]. Die strukturelle Neuerung ist die Hinzufügung eines verbindlichen Regimes zur Bearbeitung und Offenlegung von Schwachstellen, das sich über den gesamten Supportzeitraum erstreckt.

Anhang I, Teil I listet die Cybersicherheitsanforderungen auf, die jedes in den Anwendungsbereich fallende Produkt im Zeitpunkt des Inverkehrbringens erfüllen muss. Zentrale Pflichten umfassen: eine secure-by-default-Konfiguration, Schutz vor unbefugtem Zugriff durch angemessene Authentifizierung und Zugriffskontrolle, Schutz der Vertraulichkeit und Integrität gespeicherter und übertragener Daten, Minimierung der Angriffsfläche, Minderung der Auswirkungen von Vorfällen durch resilientes Design und Bereitstellung von Mechanismen für Sicherheitsupdates [1].

Anhang I, Teil II regelt den Prozess der Schwachstellenbearbeitung über den Supportzeitraum. Hersteller müssen die Komponenten und Schwachstellen ihrer Produkte über eine Software Bill of Materials identifizieren und dokumentieren, Schwachstellen ohne Verzögerung über kostenlose Sicherheitsupdates beheben, Informationen über behobene Schwachstellen öffentlich offenlegen, sobald ein Patch verfügbar ist, und eine Politik der Coordinated Vulnerability Disclosure betreiben. Dies sind fortlaufende Pflichten, keine punktuellen Prüfungen [1].

Für Hardwarehersteller bedeutet dies praktisch, dass die Firmware-Update-Infrastruktur, die SBOM-Toolchain und die CVD-Politik nun regulierte Vermögenswerte sind, keine optionale Ingenieurhygiene. Ein Produkt kann ohne sie nicht in Verkehr gebracht werden, und die Konformitätsbewertung wird sie prüfen.

Anhang III stuft eine Teilmenge der Produkte als wichtig ein (Klasse I und Klasse II), und Anhang IV identifiziert kritische Produkte. Die Einstufung bestimmt den Weg der Konformitätsbewertung. Standardprodukte dürfen sich selbst bewerten. Wichtige Produkte der Klasse I erfordern entweder die Anwendung einer harmonisierten Norm oder eine Drittparteienbewertung. Wichtige Produkte der Klasse II erfordern eine Drittparteienbewertung durch eine notifizierte Stelle. Kritische Produkte erfordern eine europäische Cybersicherheitszertifizierung unter dem Rahmen, der durch die Verordnung (EU) 2019/881 [1][7] eingerichtet wurde.

Im Bereich der Hardwaresicherheit umfassen die relevanten Einträge der Klasse II Hardwaregeräte mit Security Boxes, Smartcard-Lesegeräte mit Sicherheitsfunktionen, Mikroprozessoren mit sicherheitsbezogenen Funktionen, die für wesentliche Einrichtungen im Sinne der NIS2 bestimmt sind [4], sowie Hardware-Mikrocontroller mit sicherheitsbezogenen Funktionen. Ein Gerät wie ein post-quanten Hardwareschlüssel oder ein souveräner Endpunkt für sichere Kommunikation fällt vollständig unter dieses Regime. Der Status eines kritischen Produkts, sofern durch delegierten Rechtsakt der Kommission für die Hardware-Vertrauensanker mit dem höchsten Risiko festgelegt, schreibt eine verbindliche EU-Cybersicherheitszertifizierung auf der im delegierten Rechtsakt festgelegten Vertrauensstufe vor.

Artikel 14 führt Melde­pflichten für Vorfälle und Schwachstellen ein, die strenger sind als die meisten bestehenden Regelungen. Aktiv ausgenutzte Schwachstellen müssen der ENISA [5] und dem zuständigen CSIRT innerhalb von 24 Stunden nach Kenntnisnahme über eine Frühwarnung gemeldet werden, gefolgt von einer vollständigeren Meldung innerhalb von 72 Stunden und einem Abschlussbericht innerhalb von 14 Tagen. Schwerwiegende Vorfälle, die die Sicherheit des Produkts beeinträchtigen, müssen nach demselben Zeitplan gemeldet werden [1].

Operativ bedeutet dies, dass der Hersteller über eine interne Triage- und Meldepipeline verfügen muss, die innerhalb weniger Stunden nach einem Sicherheitsereignis einen strukturierten Bericht an einen Regulierer erzeugen kann. Für einen kleinen oder mittelgroßen Hersteller ist dies eine signifikante organisatorische Anforderung, kein Tooling-Problem. Der CRA sieht ausdrücklich vor, dass die Einhaltung dieses Artikels eine Security-Operations-Funktion mit definierten Rollen und Eskalationswegen erfordert, von der Reife, wie sie typischerweise unter ISO/IEC 27001 [8] formalisiert wird.

Die Verordnung trat Ende 2024 in Kraft [3]. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026. Der vollständige Pflichtenkatalog, einschließlich Konformitätsbewertung und CE-Kennzeichnung, gilt ab dem 11. Dezember 2027. Für Produkte, die nach diesem Datum in Verkehr gebracht werden, gibt es keine Übergangsfrist [1].

Für einen Hardwarehersteller mit einem Entwicklungszyklus von 12 bis 24 Monaten ist der praktische Horizont jetzt. Ein Produkt, das 2026 in die ernsthafte Designphase eintritt, muss den Markt mit einer CRA-konformen Sicherheitshaltung, einer Konformitätsbewertungsakte und einer Infrastruktur für die Schwachstellenbearbeitung erreichen. Eine Nachrüstung ist für die strukturellen Anforderungen wie Secure Update, SBOM-Abdeckung und die architektonischen Elemente, die den resilienten Betrieb stützen, nicht realistisch [6].

Für Hersteller von Hardware-Sicherheitsprodukten, die in die EU verkaufen, ist der CRA keine Dokumentationsübung. Es handelt sich um ein reguliertes Assurance-Regime mit Einbindung einer notifizierten Stelle für jede nicht-triviale Sicherheitsfunktion, fortlaufenden Pflichten während des Supportzeitraums und Sanktionen, die so kalibriert sind, dass Compliance günstiger ist als Non-Compliance. Behandeln Sie ihn so, wie Sie die Medizinprodukteverordnung oder die Funkanlagenrichtlinie behandeln würden: als strukturelle Designgrundlage, nicht als Last-Mile-Audit.

Konkret: Bestimmen Sie heute die Anhang-III-Einstufung Ihres Produkts; binden Sie für Produkte der Klasse II eine notifizierte Stelle mindestens 12 Monate vor dem geplanten Markteintritt ein; integrieren Sie die SBOM- und CVD-Infrastruktur in Ihren Engineering-Prozess, anstatt sie später hinzuzufügen; richten Sie Ihren Firmware-Update-Mechanismus, Ihr Threat Model und Ihre Incident-Response-Runbooks vor dem Tape-out an Anhang I aus, nicht danach.

Für Käufer von Hardware-Sicherheitsprodukten ist der CRA ein wirkungsvoller Beschaffungshebel. Ab Dezember 2027 ist die CE-Kennzeichnung auf einem in den Anwendungsbereich fallenden Produkt eine bindende Erklärung der Konformität mit den wesentlichen Cybersicherheitsanforderungen. Die Konformitätsbewertungsakte, die SBOM und die CVD-Politik sind Dokumente, deren Vorlage Sie verlangen dürfen. Das Vorhandensein einer robusten regulatorischen Haltung ist heute ein Unterscheidungsmerkmal zwischen ernstzunehmenden Anbietern und dem Rest [1][2][3].