Anforderungen des EU Cyber Resilience Act: Ein praktischer Leitfaden

Die Europäische Union regelt seit Jahrzehnten die Sicherheit physischer Produkte – von Spielzeug über Maschinen – und schont dabei weitgehend die Software und den Firmware, die diese betreiben. Diese Asymmetrie wird nun enden.

Der Cyber Resilience Act (CRA), formell am 23. Oktober 2024 als Verordnung (EU) 2024/2847 verabschiedet, legt den ersten horizontalen, obligatorischen Cybersicherheitsrahmen für praktisch jedes Produkt mit digitaler Komponente fest, das auf dem EU-Markt verkauft wird. Seine Auswirkungen gehen weit über Brüssel hinaus: Jeder Hersteller, überall auf der Welt, dessen angeschlossenes Produkt einen europäischen Käufer erreicht, muss sich daran halten.

Die Konsequenzen sind erheblich. Nicht konforme Produkte können vom EU-Markt ausgeschlossen werden, und Unternehmen können Verwaltungsstrafen in Höhe von 15 Millionen Euro oder 2,5 Prozent ihres jährlichen weltweiten Umsatzes hinnehmen. Aber die CRA ist nicht nur strafend. Sie stellt einen bewussten Versuch dar, die Last der Cybersicherheit von Endnutzern (die schlecht darin sind, das Risiko von Software zu bewerten) auf die Hersteller zu übertragen, die diese Produkte entwerfen, bauen und warten. Für Hersteller von IoT-Geräten, Entwickler von Embedded-Systemen und die Unternehmen, die von ihnen abhängig sind, ist es nicht länger optional, die CRA zu verstehen. Es ist eine Voraussetzung für das Geschäft in Europa.

Die CRA ist eine direkt anwendbare EU-Verordnung, die grundlegende Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen festlegt. Diese bewusst breite Kategorie umfasst Hardware- und Softwareprodukte, die jede Art von Datenverbindung umfassen – ob direkt oder indirekt, logisch oder physisch. Die Definition erstreckt sich auf alles, von industriellen Steuerungssystemen und Netzwerk-Routern bis hin zu Smart-Home-Geräten, Verbraucher-Wearables und eigenständigen Software-Anwendungen.

Die Verordnung behandelt zwei vermeidbare Fehler, die die europäischen Gesetzgeber als „zusammenhängende Fehler“ bezeichnet haben: ein niedriges Sicherheitsniveau in Bezug auf Cybersicherheit in kommerziellen Produkten, das sich in weit verbreiteten Schwachstellen und unzusammenhängenden Patcheserhebungen widerspiegelt, sowie ein Informationsdefizit, das Käufern nicht die Möglichkeit gibt, fundierte Sicherheitsentscheidungen zu treffen. Die bisherige EU-Gesetzgebung im Bereich der Cybersicherheit, einschließlich der NIS2-Richtlinie und des EU Cybersecurity Act (Verordnung 2019/881), konzentrierte sich eher auf Organisationen und freiwillige Zertifizierungsprogramme als auf die Produkte selbst. Die CRA deckt diese Lücke durch verbindliche Verpflichtungen auf Produktebene.

KRA im Überblick: Hauptinformationen

Die Situation hinsichtlich der Zeitplanung für die Umsetzung des EU-Cyberresilienzgesetzes kann schwierig sein. Obwohl der CRA am 10. Dezember 2024 in Kraft trat, fängt die Verpflichtungsphase erst nach einer verzerrten Zeitplanung an. Die erste Frist ist der 11. Juni 2026, an dem die Bestimmungen zur Benennung der für die Überprüfung der Konformität zuständigen Stellen in Kraft treten. Dies bedeutet, dass die Mitgliedstaaten die Stellen benannt haben müssen, die für die Durchführung von Drittpartei-Cybersecurity-Bewertungen befugt sind, noch lange vor dem vollständigen Inkrafttreten der Bestimmungen.

Der zweite (und für Hersteller aus operativer Sicht entscheidende) Meilenstein erfolgt am 11. September 2026. Ab diesem Datum müssen die Hersteller aktiv Exploited Vulnerabilities und schwerwiegende Sicherheitsvorfälle an den entsprechenden CSIRT-Koordinator (Computer Security Incident Response Team) und an ENISA über eine einzige EU-Meldeportalplattform melden. Eine frühzeitige Warnung muss innerhalb von 24 Stunden nach Feststellung erfolgen, eine detaillierte Sicherheitsanfrage innerhalb von 72 Stunden und ein abschließendes Bericht spätestens 14 Tage nach der Verfügbarkeit einer Korrektivmaßnahme.

Die vollständige Einhaltung aller Anforderungen, Bewertungen, CE-Kennzeichnung und der technischen Dokumentation ist bis zum 11. Dezember 2027 erforderlich. Dies gilt als Zeitpunkt des Inkrafttretens des EU-Gesetzes zur Cybersicherheit. Produkte, die vor diesem Datum auf den Markt gebracht wurden, unterliegen der CRA nur, sofern sie nach diesem Datum eine wesentliche Änderung erfahren haben. Die Verpflichtungen zur Meldung von Sicherheitslücken gemäß Artikel 14 gelten jedoch rückwirkend für alle im Anwendungsbereich liegenden Produkte.

Produkte mit digitalen Elementen

Die CRA gilt für alle Software- oder Hardwareprodukte (und deren zugehörige Lösungen zur Ferndatenverarbeitung), die eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder einer Netzwerkverbindung haben. Dies umfasst sowohl eigenständige Software als auch Firmware, die auf eingebetteten Geräten ausgeführt wird, sowie Cloud-Services, die für die grundlegende Funktionalität eines Produkts unverzichtbar sind (z. B. die Cloud-Backend-Komponenten eines Smart-Home-Hubs, die die Fernbedienung von Geräten ermöglichen). Websites und generische Cloud-Infrastrukturen, die die Funktionalität eines bestimmten Produkts nicht unterstützen, sind hiervon ausgenommen.

Produktklassifizierung: Standard, Wichtig und Kritisch

Die EU-CRA-Verordnung legt ein stufenförmiges Klassifizierungssystem fest, das bestimmt, welche Verfahren ein Produkt durchlaufen muss. Die meisten Produkte fallen in die Standardkategorie: Sie können die Einhaltung nachweisen, indem sie eine interne Selbstbewertung durchführen (basierend auf dem Modul A). Produkte, die als “wichtig” eingestuft sind, werden in zwei Kategorien unterteilt. Die Klasse I umfasst Identitätsmanagement-Systeme, eigenständige Browser, VPN-Produkte, Netzwerkmanagement-Systeme, SIEM-Plattformen, Betriebssysteme, Router und Modem, Smart-Home-Geräte mit Sicherheitsfunktionen, angeschlossene Spielzeuge mit interaktiven Funktionen sowie Mikroprozessoren oder FPGAs mit Sicherheitsfunktionen. Die Klasse II (mit höherem Risiko) umfasst Hypervisoren und Container-Betriebssysteme, Firewalls, Eindringlingserkennungssysteme und Verhütungssysteme sowie manipulationssichere Mikroprozessoren und Mikrocontroller. Die Produkte der Klasse II erfordern stets eine Konformitätsbewertung durch einen Drittanbieter. In einer separaten Anlage IV werden kritische Produkte (Hardware-Security-Module, Smartmeter-Gateways und Smartcards) aufgeführt, die einer obligatorischen europäischen Cybersicherheitszertifizierung unterliegen können.

Was ist von der CRA ausgeschlossen?

Mehrere Produktkategorien fallen außerhalb des Anwendungsbereichs der CRA, da sie bereits unter sektorbezogenen Regelungen reguliert werden, die die Cybersicherheit betreffen. Medizinische Geräte, die unter der Verordnung (EU) 2017/745 und in vitro-Diagnostika unter der Verordnung (EU) 2017/746 fallen, sind von der Verordnung (EU) 2019/2144 ausgenommen, ebenso wie Kraftfahrzeuge, die nach der Verordnung (EU) 2019/2144 geregelt sind, und Luftfahrtprodukte, die gemäß der Verordnung (EU) 2018/1139 zertifiziert sind. Auch Produkte, die ausschließlich für nationale Sicherheits- oder Verteidigungszwecke entwickelt wurden, sowie solche, die dazu bestimmt sind, klassifizierte Informationen zu verarbeiten, sind von der Verordnung (EU) 2018/1139 ausgenommen. Ersatzteile, die nach identischen Spezifikationen hergestellt wurden wie die Komponenten, die sie ersetzen, sind ebenfalls von der Verordnung (EU) 2018/1139 ausgenommen.

Sicherheit durch Design und Standardeinstellungen

Anhang I der Verordnung enthält die Anforderungen an die Cybersicherheitsstandards, die Produkte bei der Markteinführung erfüllen müssen. Produkte müssen so konzipiert und hergestellt werden, dass ein angemessenes Sicherheitsniveau gewährleistet ist, entsprechend dem Risikoprofil der Produkte. Sie müssen ohne bekannte Exploitationsschwachstellen ausgeliefert werden und in einer konfigurationssicheren, standardmäßig gesicherten Umgebung, die der Benutzer jederzeit zurücksetzen kann. Sie müssen vor unbefugten Zugriffen durch Authentifizierung und Zugangskontrolle schützen, die Vertraulichkeit und Integrität gespeicherter und übermittelter Daten mithilfe modernster Verschlüsselung gewährleisten, die Datenverarbeitung auf das unbedingt notwendige Maß reduzieren und ihre Angriffssicherheit durch Design optimieren. Es sind auch Anforderungen an die Abwehr von Denial-of-Service-Angriffen und die Möglichkeit zur Aufzeichnung von sicherheitsrelevanten internen Aktivitäten vorgeschrieben.

Schutz vor Gefahren und Meldung von Vorfällen

Die CRA legt lebenslange Verpflichtungen zur Sicherheitsmanagement zu den Schwachstellen fest. Hersteller müssen Schwachstellen ohne Verzögerung identifizieren, dokumentieren und beheben, regelmäßige Sicherheitsprüfungen durchführen und eine koordinierte Richtlinie zur Offenlegung von Schwachstellen aufrechterhalten. Wenn eine Fixierung verfügbar ist, müssen Hersteller die Schwachstelle öffentlich bekannt geben zusammen mit klaren Anweisungen zur Behebung. Aktiv ausgenutzte Schwachstellen führen zu den oben beschriebenen Stufen der Benachrichtigung: eine frühe Warnung innerhalb von 24 Stunden, eine detaillierte Benachrichtigung innerhalb von 72 Stunden und einen abschließenden Bericht innerhalb von 14 Tagen nach der Korrekturmaßnahme.

SBOM-Verpflichtungen

Nach Teil II des Anhangs I müssen die Hersteller alle Komponenten ihrer Produkte identifizieren und dokumentieren, unter anderem durch die Erstellung einer Software-Materialbeschreibungsdatei (SBOM) in einem allgemein verwendeten, maschinenlesbaren Format. Die SBOM muss zumindest die obersten Abhängigkeiten des Produkts abdecken. Obwohl Hersteller nicht verpflichtet sind, die SBOM öffentlich zugänglich zu machen, können Marktüberwachungsbehörden sie im Rahmen von Compliance-Kontrollen verlangen und ENISA kann aggregierte, anonymisierte SBOM-Daten verwenden, um in der gesamten Union Abhängigkeitsanalysen durchzuführen. Insbesondere zur Kartierung der Abhängigkeit von freien und offenen Softwarekomponenten.

Automatischer Sicherheits-Update-Service und Anforderungen an OTA-Updates

Produkte, die an Verbraucher gerichtet sind, müssen automatische Sicherheitsupdates standardmäßig unterstützen und einen klaren Opt-out-Mechanismus bieten. Hersteller müssen außerdem sicherstellen, dass Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt werden können, sofern dies technisch möglich ist, damit die Nutzer nicht gezwungen werden, neue Funktionen anzunehmen, nur um kritische Patches zu erhalten. Jedes Sicherheitsupdate, das während der Support-Periode veröffentlicht wird, muss mindestens zehn Jahre lang oder bis zum Ende der Support-Periode verfügbar bleiben, je nachdem, welcher Zeitraum länger ist.

Firmware- und Embedded-Software-Compliance

Für IoT-Hersteller verändert die CRA den gesamten Produktentwicklungsprozess. Firmware und Eingebettete Software Diese Sicherheitsfunktionen müssen unter Berücksichtigung der dokumentierten Cybersicherheitsrisikobewertung entwickelt werden, die während der gesamten Supportphase aufrechtzuerhalten und aktualisieren ist. Diese Bewertung muss die Risiken anhand des beabsichtigten Verwendungszwecks, der vorhersehbaren Nutzung und der betrieblichen Umgebung des Produkts analysieren und explizit angeben, welche essentiellen Anforderungen aus Anhang I gelten und wie diese umgesetzt wurden. Hersteller, die Drittkomponenten (einschließlich Open-Source-Bibliotheken) integrieren, sind verpflichtet, sicherzustellen, dass diese Komponenten die Cybersicherheit des Endprodukts nicht beeinträchtigen.

Produktlebenszyklus und Supportdauer

Die Supportphase, in der der Hersteller Schwachstellen effektiv beheben muss, muss mindestens fünf Jahre dauern, sofern die erwartete Nutzungsdauer des Produkts nicht kürzer ist. Für Hardwarekomponenten wie Mikroprozessoren, Netzwerkgeräte oder industrielle Steuerungsanlagen, die über ein Jahrzehnt oder länger in Betrieb bleiben, müssen die Hersteller eine entsprechend längere Supportdauer festlegen. Die von der CRA eingesetzte Sondergruppe für Verwaltungskooperation (ADCO) wird Statistiken über durchschnittliche Zeiträume nach Produktkategorien veröffentlichen und kann die Schwerpunktsetzung auf Kategorien empfehlen, in denen solche Zeitrahmen als unzureichend erscheinen.

CE-Kennzeichnung für Cybersicherheit

Produkte, die die erforderliche Konformitätsprüfung bestehen, müssen die CE-Kennzeichnung tragen. Die sichtbare Kennzeichnung, dass sie die Cybersicherheitsanforderungen der CRA erfüllen und somit innerhalb des Binnenmarktes frei bewegen können. Für Produkte der Kategorie „Standard“ reicht eine interne Selbstüberprüfung aus. Für Produkte der Kategorie „Wichtige Klasse I“ ist eine Selbstüberprüfung nur dann zulässig, wenn der Hersteller harmonisierte Normen, gemeinsame Spezifikationen oder ein anerkanntes europäisches Cybersicherheitszertifizierungssystem angewendet hat; ansonsten ist eine Drittanbieterüberprüfung obligatorisch. Für Produkte der Kategorie „Wichtige Klasse II“ und „Kritische Produkte“ ist eine Beteiligung Dritter immer erforderlich.

Gesundheitswesen, IoT und medizinische Geräte

Medizintechnische Geräte, die bereits gemäß der Verordnung (EU) 2017/745 oder 2017/746 auf den EU-Markt gebracht wurden, sind ausdrücklich von der CRA ausgeschlossen. Allerdings gibt es eine erhebliche Grauzone für gesundheitsbezogene angeschlossene Produkte: persönliche tragbare Gesundheitsmonitore, Wellness-Tracker und Peripheriegeräte zur Fernüberwachung von Patienten, die nicht als Medizinprodukte nach den bestehenden EU-Vorschriften gelten. Solche Produkte fallen ausdrücklich in den Geltungsbereich der CRA. In Anhang III werden persönliche tragbare Produkte zur Gesundheitsüberwachung, für die die Medizinprodukte-Vorschriften nicht gelten, als „Importklasse I“-Produkte eingestuft, die eine strengere Konformitätsprüfung erfordern.

Industrielles IoT und Fertigung

Industrieumgebungen stellen besondere Herausforderungen dar. Produkte mit digitalen Elementen, die in den Bereichen Betriebstechnik (OT) eingesetzt werden (PLC-Steuerungen, Industriegateways, SCADA-Komponenten), fallen direkt in den Anwendungsbereich. Die automatischen Update-Anforderungen der CRA umfassen eine Sonderregelung für Produkte, die in professionellen ICT-Netzen und kritischen oder industriellen Umgebungen eingesetzt werden, in denen automatisierte Updates zu Betriebsstörungen führen könnten. Hersteller müssen jedoch weiterhin rechtzeitige Sicherheitsupdates bereitstellen und Anwender über verfügbare Patches informieren, unabhängig davon, ob der Update-Mechanismus automatisch ist. Die Schnittstelle zwischen der CRA und IEC 62443, dem primären internationalen Standard für die Sicherheit von Industrieautomatisierungs- und Steuerungssystemen, bietet einen praktischen Weg zur Ausrichtung: Hersteller, die bereits den IEC 62443 entsprechen, werden erhebliche Überschneidungen mit den wesentlichen Anforderungen der CRA feststellen können, wobei die Verpflichtungen zur SBOM, zur Incident-Reporting und zur CE-Kennzeichnung der CRA jedoch zusätzliche Anforderungen darstellen.

Die CRA arbeitet neben, und nicht anstelle der anderen EU-Instrumente zur Cybersicherheitskontrolle. Die NIS2-Richtlinie (Richtlinie 2022/2555) legt Anforderungen an das Risikomanagement und die Meldung von Vorfällen für essenzielle und wichtige Organisationen (Organisationen, nicht Produkte) fest. Die von der NIS2-Richtlinie geregelten Organisationen sollen als Teil ihrer Lieferketten-Sicherheitsverpflichtungen CRAs-konforme Produkte verwenden, was eine Nachfrageeffekt-Wirkung erzeugt. Der EU-Cybersecurity Act (Verordnung 2019/881) legt einen freiwilligen Zertifizierungskontext für IKT-Produkte, -Verfahren und -Dienste fest. CRAs-konforme Produkte, die gemäß einem EU-Zertifizierungssystem für Cybersicherheit zertifiziert wurden, profitieren von einer Annahme der Konformität, und die Zertifizierung auf der “wesentlichen” Sicherheitsstufe beseitigt die Notwendigkeit einer separaten CRAs-Zertifizierung durch Dritte. Kurz zusammengefasst: Die NIS2-Richtlinie regelt das Verhalten von Organisationen, das EU-Gesetz zur Cybersicherheit sieht freiwillige Zertifizierung vor, und die CRA schreibt eine Produktkonformität vor – alles zusammen bildet eine mehrschichtige regulatorische Architektur.

Das Strafregime der CRA ist auf die Schwere der Verstöße abgestimmt. Die Nichterfüllung der Anforderungen an die Cybersicherheit gemäß Anhang I oder der Pflichten gemäß den Artikeln 13 und 14 (Herstellerpflichten und Meldepflichten) kann zu Geldstrafen von bis zu 15 Millionen Euro oder 2,5 Prozent des globalen Jahresumsatzes, je nachdem, welches der höhere Wert ist, führen. Verstöße gegen andere Pflichten (wie solche, die sich mit Importeuren, Vertriebspartnern, Konformitätsbewertung oder technischer Dokumentation befassen) können zu Geldstrafen von bis zu 10 Millionen Euro oder 2 Prozent des Umsatzes führen. Die Bereitstellung falscher oder irreführender Informationen an Behörden kann zu Geldstrafen von bis zu 5 Millionen Euro oder 1 Prozent des Umsatzes führen. Mikrofirmen und kleine Unternehmen sind von Geldstrafen für die Nichterfüllung der Frist für die 24-Stunden-frühe Warnung ausgenommen, und Administrativstrafen sind für Open-Source-Software-Entwickler vollständig ausgeschlossen.

Die Behandlung von Open-Source-Software war eine der kontroversesten Bestimmungen des CRA während ihrer Verabschiedung durch das Gesetz. Die endgültige Verordnung zieht eine klare Linie: Freie und Open-Source-Software, die von ihren Entwicklern nicht monetarisiert wird und nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, fällt außerhalb des Anwendungsbereichs der CRA. Mitwirkende, die Quellcode zu Open-Source-Projekten bereitstellen, sind gemäß der Verordnung nicht haftbar. Wenn ein Hersteller jedoch Open-Source-Komponenten in ein kommerzielles Produkt integriert, trägt der Hersteller die Sorgfalts- und Sicherheitsrisikomanagementpflichten für diese Komponenten. Eine neue Kategorie von “Open-Source-Software-Stewards”, Organisationen, die nachhaltige Entwicklungsunterstützung für Open-Source-Projekte bereitstellen, die für die kommerzielle Integration bestimmt sind, unterliegt einem leichteren Regelwerk: Sie müssen eine Cybersicherheitsrichtlinie dokumentieren und Sicherheitslücken melden, müssen jedoch nicht die gesamten Verpflichtungen des Herstellers tragen und dürfen keine CE-Kennzeichnung anbringen.

Schritt 1: Durchführung einer Produktumfassungsanalyse.

Festlegen, welche Ihrer Produkte als Produkte mit digitalen Elementen gelten und ob sie in die Standardkategorie „Wichtig“ (Klasse I oder II) oder „kritisch“ fallen. Diese Klassifizierung legt den Konformitätsbewertungspfad fest.

Schritt 2: Durchführen einer Cyber-Sicherheits-Gap-Analyse.

Kartieren Sie Ihre aktuelle Sicherheitslage anhand der Anforderungen in Anhang I. Identifizieren Sie Lücken in den voreingestellten Sicherheitskonfigurationen, Verschlüsselungspraktiken, Zugriffskontrollen, Update-Mechanismen und Prozessen zur Handhabung von Sicherheitslücken.

Schritt 3: Implementieren Sie Sicherheitsmaßnahmen bereits in der Entwicklung.

Integrieren Sie die Risikobewertung im Bereich der Cybersicherheitsmaßnahmen in Ihre Produktplanung, Design- und Entwicklungsprozesse. Die CRA fordert dokumentierte Risikobewertungen, die während der gesamten Supportphase aufrechtzuerhalten sind, und nicht nur eine einmalige Überprüfung.

Schritt 4: Erstellen Sie Prozesse für die Verwaltung von Schwachstellen.

Erstellen Sie eine koordinierte Richtlinie zur Offenlegung von Sicherheitslücken, implementieren Sie die erforderliche Reporting-Infrastruktur, um die Fristen für 24-stündige Frühwarnung und 72-stündige Benachrichtigung einzuhalten, und entwickeln Sie ein Verfahren zur schnellen und kostenlosen Verteilung von Sicherheitsupdates.

Schritt 5: Erstellen der technischen Dokumentation und des SBOM.

Erstellen Sie die von Anhang VII geforderten technischen Dokumentation, einschließlich Ihrer Cybersicherheitsrisikobewertung, Beschreibungen der Systemarchitektur, SBOM in einem maschinenlesbaren Format sowie der EU-Konformitätserklärung.

Der EU-Cyberresilienz-Gesetzesentwurf stellt den ambitioniertesten Versuch einer Jurisdiktion dar, die Cybersicherheit kommerzieller digitale Produkte auf horizontaler Ebene zu regulieren. Die schrittweise Zeitplanung mit Verpflichtungen zur Meldung von Schwachstellen ab September 2026 und vollständiger Konformität bis Dezember 2027 bietet Herstellern einen engen, aber überschaubaren Zeitraum, um sich darauf vorzubereiten. Für Unternehmen im Bereich IoT und Embedded Systems sind die Prioritätsschritte klar: Klassifizieren Sie Ihr Produktportfolio, analysieren Sie die Sicherheitslage Ihrer Systeme anhand der Anforderungen der Anhang-I-Liste, entwickeln Sie die Generation von SBOM und die Funktionen zur Handhabung von Schwachstellen und bereiten Sie die Drittanbieter-Konformitätsprüfung vor, falls erforderlich. Die CRA wird die Wettbewerbssituation für vernetzte Produkte in Europa neu gestalten, und Unternehmen, die die Einhaltung als strategische Investition anstatt als regulatorische Belastung betrachten, sind bestens gerüstet, um erfolgreich zu sein.