Schritt-für-Schritt-Anleitung zur Einhaltung des Cyber ​​Resilience Act (CRA)

Veröffentlicht: Januar 2026. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Was fordert der Cyber ​​Resilience Act?

Der Cyber ​​Resilience Act (CRA), offiziell Verordnung (EU) 2024/2847, ist das erste horizontale Gesetz der Europäischen Union, das verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Hardware oder Software) festlegt, die im gesamten EU-Markt verkauft werden. Die schrittweise Einhaltung des Cyber ​​Resilience Act (CRA) basiert auf einem zentralen Grundsatz, der in Artikel 6 verankert ist : Nur Produkte, die von Grund auf sicher konzipiert sind und über ihren gesamten Lebenszyklus hinweg unterstützt werden, dürfen auf dem EU-Markt angeboten werden.

Dieses Prinzip spaltet sich in zwei Säulen auf.

1. Produkte müssen durch Konstruktion und Verwendung sicher sein (Anhang I, Teil I)

Ein Produkt gilt nur dann als konform, wenn es die grundlegenden Cybersicherheitsanforderungen gemäß Anhang I, Teil I , erfüllt und vom Benutzer oder Betreiber ordnungsgemäß installiert, gewartet und aktualisiert wird. In der Praxis bedeutet dies, dass das Produkt sicher ausgeliefert werden und während seiner gesamten unterstützten Lebensdauer sicher bleiben muss und nicht nur eine Funktionsprüfung am Markteinführungstag bestehen darf.

Die CRA teilt Produkte in vier Risikokategorien ein, und die Kategorie, in die ein Produkt fällt, bestimmt, wie es auf Konformität geprüft wird:

• Standardkategorie: Rund 90 Prozent der Produkte enthalten digitale Elemente, darunter auch Unterhaltungselektronik für den allgemeinen Gebrauch wie Smart Speaker, Festplatten und Fotobearbeitungssoftware.
• Wichtige Produkte der Klasse I: Produkte mit Funktionen, die für die Cybersicherheit relevant sind, wie z. B. Identitätsmanagementsysteme, Webbrowser, Passwortmanager, VPN-Software und Smart-Home-Sicherheitsgeräte.
• Wichtige Produkte der Klasse II: Produkte mit höherem Risiko wie Firewalls, industrielle Intrusion-Detection- und -Prevention-Systeme, Hypervisoren und manipulationssichere Mikroprozessoren.
• Kritische Produkte: Die höchste Risikostufe, bei der wichtige Einrichtungen von dem Produkt abhängig sind, wie z. B. Sicherheitselemente in Smartcards und Smart-Meter-Gateways.

2. Hersteller müssen sichere Entwicklungs- und Lebenszyklusprozesse einhalten (Anhang I, Teil II)

Die Einhaltung der Vorschriften beschränkt sich nicht nur auf das ausgelieferte Gerät. Gemäß Anhang I, Teil II , müssen Hersteller ein Schwachstellenmanagement durchführen, sichere Entwicklungsmethoden über den gesamten Produktlebenszyklus hinweg anwenden und Sicherheitsupdates bereitstellen, solange das Produkt unterstützt wird. Die Einhaltung der CRA-Vorschriften ist ein fortlaufendes operatives Programm und keine einmalige Zertifizierung.

Wer muss die Vorgaben der CRA einhalten?

Alle Hersteller aus der EU oder von außerhalb der EU, die Produkte mit digitalen Elementen in Europa verkaufen, fallen unter diese Regelung. Die Aufschlüsselung sieht wie folgt aus:

• EU-Hersteller Unternehmen mit Sitz in der EU, die Produkte mit Software oder Firmware entwickeln und diese in der EU verkaufen.
• Nicht-EU-Hersteller Unternehmen mit Sitz außerhalb der EU, beispielsweise in den USA oder China, die direkt auf dem EU-Markt oder über EU-Distributoren und -Importeure verkaufen.

Gelangt das Produkt auf den EU-Markt, greift das EU-Verordnungsgesetz (CRA) unabhängig vom Firmensitz. Der Verkauf über einen Online-Marktplatz stellt keine Ausnahme dar; wenn EU-Kunden das Produkt erwerben können, fällt der Hersteller unter das Verordnungsgesetz.

Die CRA umfasst Software und Firmware, die auf vernetzten Geräten läuft oder mit diesen ausgeliefert wird: Betriebssysteme, eingebettete Firmware, mobile Apps zur Steuerung von IoT-Produkten, Desktop-Verwaltungstools und Cloud-Schnittstellen zur Interaktion mit diesen Geräten. Typische Kategorien sind IoT- und eingebettete Geräte für Privathaushalte, das Gesundheitswesen und industrielle Anwendungen; industrielle Steuerungs- und Automatisierungsanlagen; sowie Unterhaltungselektronik wie Wearables, intelligente Haushaltsgeräte und vernetzte Sicherheitsprodukte.

Welcher Zeitplan gilt für die Einhaltung der CRA-Vorschriften?

Die CRA wird nach einem festen, von der EU bestätigten Zeitplan schrittweise eingeführt. Es gibt keine Übergangsfrist über diese Termine hinaus.

1. Am 10. Dezember 2024 tritt der CRA in Kraft. Die Verordnung trat an diesem Tag in Kraft. Sie erfordert keine sofortige Einhaltung, setzt aber den Countdown in Gang; Hersteller, Importeure und Händler sollten damit beginnen, die Prozesse, Dokumentationen und technischen Kontrollen aufzubauen, die für die späteren Fristen erforderlich sind.
2. Ab dem 11. Juni 2026 gelten die Bestimmungen über benannte Stellen und die Marktüberwachung. Die Bestimmungen des Kapitels IV, die Konformitätsbewertungsstellen und Marktüberwachungsbehörden regeln, treten in Kraft und geben der Durchsetzungsinfrastruktur Zeit, sich aufzubauen, bevor die Meldepflichten beginnen.
3. Am 11. September 2026 beginnt die Meldepflicht für Sicherheitslücken und Vorfälle. Gemäß Artikel 14 müssen Hersteller aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle innerhalb festgelegter Fristen an ENISA und die nationalen CSIRTs melden und bereits über einen grundlegenden Prozess für das Management und die Offenlegung von Sicherheitslücken verfügen. Dies ist der sanfte Start des CRA: Transparenz und Frühwarnung vor der vollständigen Produktkonformität.
4. 11. Dezember 2027, vollständige Einhaltung erforderlich. Alle Produkte mit digitalen Elementen, die auf dem EU-Markt in Verkehr gebracht werden, müssen die Anforderungen der Cybersicherheitsbehörde (CRA) vollständig erfüllen: Entwicklung nach dem Prinzip „Secure by Design“ und „Secure by Default“, Erstellung und Pflege des Security Business Order Model (SBOM), dokumentiertes Schwachstellenmanagement, funktionierende Sicherheitsupdate-Mechanismen und CE-Kennzeichnung in Verbindung mit der Cybersicherheitskonformität. Nicht konforme Produkte dürfen nach diesem Datum in der EU nicht mehr verkauft werden.

Produkte, die vor dem 11. Dezember 2027 rechtmäßig auf dem EU-Markt in Verkehr gebracht wurden, sind grundsätzlich von den Hauptanforderungen ausgenommen, sofern sie nach diesem Datum keiner wesentlichen Änderung unterzogen werden. Eine wesentliche Änderung führt dazu, dass das modifizierende Unternehmen für Zwecke der CRA als Hersteller gilt und das Produkt vollständig in den Anwendungsbereich fällt. Die einzige Anforderung, die unabhängig von dieser Ausnahme für bereits auf dem Markt befindliche Produkte gilt, ist die Meldepflicht für Sicherheitslücken und Vorfälle gemäß Artikel 14, die ab dem 11. September 2026 für alle betroffenen Produkte gilt.

Welche Empfehlungen zur Auswahl kryptografischer Verfahren und Algorithmen gibt die CRA?

Die CRA ist bewusst technologieneutral. Anhang I, Teil I verpflichtet Hersteller, die Vertraulichkeit von Daten zu schützen, indem sie relevante Daten im Ruhezustand oder während der Übertragung mit modernsten Mechanismen verschlüsseln (Artikel 2(e)), und die Integrität gespeicherter und übertragener Daten, Befehle und Konfigurationen vor unbefugter Änderung zu schützen (Artikel 2(f)). Spezifische Algorithmen werden jedoch nicht genannt. Die Wahl dieser Algorithmen sowie die dazugehörige Nachverfolgung obliegen dem Hersteller. Genau hier stoßen die meisten Konformitätsbewertungen auf Lücken.

Eine vertretbare Ausgangsbasis für Produkte, die unter den Geltungsbereich der CRA fallen, sieht folgendermaßen aus:

• Daten im Ruhezustand und während der Übertragung: AES-256 für symmetrische Verschlüsselung, TLS 1.3 für Netzwerkkanäle und eine dokumentierte Begründung, wo immer noch eine schwächere Verschlüsselungssuite zur Gewährleistung der Interoperabilität mit älteren Systemen verwendet wird.
• Digitale Signaturen für Firmware- und Update-Integrität: RSA-2048 oder ECDSA P-256 als klassisches Minimum, wobei der Fokus auf hybriden Signaturverfahren liegt, die einen klassischen Algorithmus mit einem NIST-Post-Quanten-Schema wie ML-DSA (FIPS 204) für allgemeine Signaturverfahren kombinieren.
• Beschränkte und langlebige Firmware: NIST SP 800-208 bezeichnet die zustandsbehafteten Hash-basierten Verfahren LMS und XMSS für die Signierung von Firmware und Software, bei denen die Signaturgröße und der Code-Footprint wichtiger sind als der reine Durchsatz. Aus diesem Grund nennt die NSA in ihrer CNSA 2.0 diese Verfahren derzeit als die kurzfristige Wahl speziell für Firmware.
• Schlüsselkapselung zum Schutz der Vertraulichkeit: ML-KEM (FIPS 203), bei dem die erwartete Support-Lebensdauer eines Produkts bis in die 2030er Jahre reicht und ein Expositionsfenster, in dem Daten jetzt gesammelt und später entschlüsselt werden, realistisch ist.

Die Auswahl des Algorithmus ist keine einmalige Entscheidung. Sie muss als Teil der technischen Dokumentation festgehalten werden, die eine benannte Stelle oder Marktüberwachungsbehörde anfordern wird. Außerdem bedarf es eines definierten Verfahrens für den Austausch eines Algorithmus, ohne das Produkt neu entwickeln zu müssen. Genau darum geht es in den nächsten beiden Abschnitten.

Welches Bedrohungsmodell geht die CRA aus?

Die wesentlichen Anforderungen der CRA beziehen sich auf eine spezifische Reihe von Angreiferfähigkeiten, gegen die sich die Hersteller gemäß der Verordnung verteidigen müssen, und nicht auf ein allgemeines „Sicherheitsgebot“:

• Lieferkette und Aktualisierungseinspeisung. Ein Angreifer, der eine Build-Pipeline, einen Signaturschlüssel oder einen Vertriebskanal kompromittiert, versucht, unautorisierte Firmware oder Software auf bereits im Einsatz befindliche Geräte zu übertragen. Anhang I, Teil I 2(c) und 2(f) regeln dies direkt, indem sie signierte, verifizierbare Updates und Manipulationserkennung für Code und Konfiguration vorschreiben.
• Ausnutzung bekannter Sicherheitslücken. Anhang I, Teil I 2(a) geht davon aus, dass Produkte mit nach der Veröffentlichung entdeckten Sicherheitslücken ausgeliefert werden und verlangt eine funktionierende Offenlegungs- und Patch-Pipeline, nicht nur einen sauberen Scan bei der Markteinführung.
• Unbefugter Zugriff und Angriffe auf Anmeldeinformationen. Standardmäßige oder fest codierte Anmeldeinformationen, ungeschützte Verwaltungsschnittstellen und schwache Authentifizierung werden gemäß 2(b) und 2(d) als Designfehler und nicht als Konfigurationsfehler, den der Kunde hätte bemerken müssen, behandelt.
• Jetzt ernten, später entschlüsseln. Die CRA nennt Quantencomputer nicht als Bedrohung, aber die Unterstützungsverpflichtung von mehr als fünf Jahren gemäß Artikel 13 bedeutet, dass Daten oder Signaturen, die heute nur durch klassische Algorithmen geschützt sind, möglicherweise auch dann noch vertraulich oder überprüfbar bleiben müssen, wenn ein kryptografisch relevanter Quantencomputer zu einem glaubwürdigen Risiko wird. Deshalb gehört die algorithmische Agilität in das Bedrohungsmodell, obwohl die Verordnung selbst algorithmenneutral ist.
• Kompromiss zwischen physikalischer und fertigungstechnischer Phase. Bei IoT- und eingebetteten Geräten ist ein Angreifer mit physischem Zugriff auf ein Gerät oder einem Fuß in den Fertigungsprozess ein realistischer Akteur. Deshalb sind Secure Boot, das in der Hardware verankert ist, und die gerätespezifische Bereitstellung genauso wichtig wie die darüber liegenden Softwarekontrollen.

Welche Kompromisse gibt es hinsichtlich Leistung und Interoperabilität?

Die Erfüllung der kryptografischen Anforderungen der CRA ist nicht kostenlos, und die damit verbundenen Kompromisse unterscheiden sich je nach Produktklasse.

• Signaturgröße auf ressourcenbeschränkten Geräten. ML-DSA- und SLH-DSA-Signaturen sind etwa 2- bis 8-mal größer als eine ECDSA-P-256-Signatur, was sich direkt auf die Bootzeit und den Flash-Speicherbedarf von IoT-Geräten mit Mikrocontrollern auswirkt. Aus diesem praktischen Grund bleiben LMS und XMSS gemäß NIST SP 800-208 mit ihren kleineren Signaturen die kurzfristige Wahl für Firmware, obwohl sie ein zustandsbehaftetes, absturzsicheres Schlüsselmanagement innerhalb eines validierten HSM erfordern.
• Hybrid-Signatur-Overhead. Die Verwendung sowohl eines klassischen als auch eines Post-Quanten-Algorithmus während der Übergangsphase verdoppelt annähernd die Zeit für die Signaturerstellung und -verifizierung. Bei CI/CD-Signatur-Pipelines mit hohem Durchsatz ist dies in der Regel problemlos möglich; bei einem Gerät, das eine Signatur während eines energiebeschränkten Bootvorgangs verifiziert, ist dies jedoch nicht der Fall.
• Die Harmonisierung der Standards ist noch in Arbeit. Die Europäische Kommission hat CEN und CENELEC mit der Ausarbeitung harmonisierter Normen beauftragt, die Herstellern nach ihrer Veröffentlichung eine Konformitätsvermutung einräumen sollen. Bis zur endgültigen Verabschiedung dieser Normen beurteilen Hersteller die Konformität direkt anhand des Anhangs I, was bedeutet, dass zwei Prüfer bei ein und derselben Kontrolle zu unterschiedlichen Schlussfolgerungen gelangen können, bis die harmonisierten Normen vorliegen.
• Grenzüberschreitende Aktualisierungsverteilung. Ein einziger Aktualisierungsmechanismus muss unter den Netzwerkbedingungen aller EU-Mitgliedstaaten funktionieren und, für Produkte, die auch außerhalb der EU verkauft werden, mit den regulatorischen Anforderungen von Nicht-EU-Ländern koexistieren, ohne dass für jede Region eine separate Signaturpipeline aufrechterhalten werden muss.

Auf welcher Schlüsselverwaltung basiert die sichere Signierung von Updates?

Die in Artikel 13 geforderte sichere Aktualisierung ist nur so wirksam wie das zugrundeliegende Schlüsselmanagement. Eine signierte Aktualisierung, die auf einem unzureichend verwalteten Schlüssel basiert, unterscheidet sich nach einem Schlüsselleck praktisch nicht von einer unsignierten. Eine verteidigungsfähige Architektur trennt mindestens drei Rollen:

• Offline-Root-Schlüssel. Wird selten verwendet, typischerweise nur zur Ausstellung oder Erneuerung des Zertifikats für den Online-Signaturschlüssel, der in einem HSM generiert und gespeichert wird, das von jedem Netzwerk getrennt bleibt und nur für geplante, bezeugte Schlüsselzeremonien online geschaltet wird.
• Online-Signaturschlüssel. Was die Build-Pipeline bei jedem Release tatsächlich aufruft, HSM-gestützt und über eine authentifizierte API erreichbar, sodass die Signierung automatisiert werden kann, jedoch niemals derselbe Schlüssel wie der Offline-Root, sodass die Rotation niemals den bereits in den bereitgestellten Geräten eingebetteten Vertrauensanker berührt.
• Gerätespezifische Fertigungsidentität. Ein einzigartiges Schlüsselpaar, das gemäß dem IEEE 802.1AR-Muster bei der Herstellung bereitgestellt wird und es einem Gerät ermöglicht, sich gegenüber einem Update-Server als echtes, nicht geklontes Gerät zu authentifizieren, bevor es jemals ein signiertes Image empfängt.

Zusätzlich zu dieser Trennung benötigt ein funktionierendes Programm FIPS 140-3-validierte Hardware zum Schutz jedes Signaturschlüssels, eine M-of-N-Genehmigung, um einseitiges Signieren und Ausliefern durch Einzelpersonen zu verhindern, einen Rollback-Schutz, der die Neuinstallation einer älteren, signierten, aber anfälligen Firmware-Version unterbindet, sowie einen vorab bereitgestellten Nachfolgeschlüssel, um einen kompromittierten Schlüssel ohne Feldrückruf ersetzen zu können. Organisationen, die die detaillierteren Mechanismen benötigen, sollten die Dokumente „ Establishing a Firmware Signing Framework for CRA Compliance“ und „CRA Compliance Architecture for Secure Code Signing“ konsultieren , die die vollständige Schlüsselhierarchie und den Widerrufs-Workflow ausführlich beschreiben.

Wie sehen CRA-konforme Implementierungen in der Praxis aus?

Die gleichen grundlegenden Anforderungen werden je nach Produktkategorie unterschiedlich behandelt.

IoT-Gerätehersteller (Standardkategorie). Ein Anbieter von Smart-Home-Sensoren stand vor einem häufig auftretenden Problem: Ein einziger, gemeinsam genutzter Signaturschlüssel wurde für alle Produktlinien verwendet und auf einem Build-Server anstatt in der Hardware generiert. Die Lösung bestand darin, die Schlüsselgenerierung in ein HSM zu verlagern, die Signatur in produktspezifische Schlüssel aufzuteilen, sodass eine Kompromittierung einer Produktlinie nicht die anderen gefährdet, eine Multi-Faktor-Authentifizierung für den Signaturzugriff einzuführen und die Signatur innerhalb der CI/CD-Pipeline mit manipulationssicherer Protokollierung zu automatisieren. Dadurch werden sowohl die Integritätsanforderungen als auch die für eine Konformitätsbewertung erforderliche Rückverfolgbarkeit erfüllt.

Ein Hersteller von Industriesteuerungen (Wichtige Klasse II) benötigte für die Fabrikautomation einen sicheren Bootvorgang, der in einem unveränderlichen Hardware-Root verankert ist. Diese Geräte sind über ein Jahrzehnt oder länger im Feld im Einsatz und nur selten physisch zugänglich für Wartungsarbeiten. Das Design trennt die Boot-Verifizierungskette, die an den selten rotierten Offline-Root gebunden ist, von der Update-Verifizierungskette, die an den häufiger rotierten Online-Signaturschlüssel gebunden ist. Dadurch ist bei einem kompromittierten oder veralteten Online-Schlüssel kein erneutes Flashen des unveränderlichen Boot-ROMs erforderlich.

Ein Hersteller von Medizinprodukten (wichtige Klasse I oder kritisch, je nach Funktion) musste die Anforderungen der CRA hinsichtlich des SBOM und der Meldung von Sicherheitslücken mit den bestehenden regulatorischen Anforderungen für Medizinprodukte in Einklang bringen. Der gewählte Ansatz sah vor, das SBOM der CRA als zentrales Inventar zu verwenden, das sowohl den Meldeprozess gemäß Artikel 14 als auch den bestehenden Prozess der Medizinprodukteüberwachung speist, anstatt zwei separate, möglicherweise voneinander abweichende Komponenteninventare zu führen.

CRA-Anforderungen auf einen Blick: Anforderungen, Kontrollen und wo die EU-Kommission hilft

Die nachstehende Tabelle ordnet die wesentlichen Cybersicherheitsanforderungen, die ein Hersteller erfüllen muss, den technischen Kontrollmaßnahmen zu, die diese Anforderungen erfüllen, sowie den für diese Kontrollmaßnahmen entwickelten Verschlüsselungsberatungsdienstleistungen oder -produkten.

CRA-Anforderung (Anhang I)	Technische Kontrolle	Verschlüsselungsberatungsdienst
Sicherheit durch Design (Teil I.1)	Risikobewertung, sicherer Entwicklungslebenszyklus, Minimierung der Angriffsfläche	Compliance-Beratung
Keine bekannten ausnutzbaren Schwachstellen (2(a))	Schwachstellenscan, SBOM-Prüfung, Behebung von Sicherheitslücken vor der Veröffentlichung	Compliance-Beratung, CBOM Secure
Sichere Standardkonfiguration (2(b))	Voreingestellte Standardeinstellungen, Unterstützung für Werksreset, deaktivierte ungenutzte Dienste	Compliance-Beratung
Zeitnahe, überprüfbare Sicherheitsupdates (2(c))	Signierte Updatepakete, HSM-gestützte Signaturschlüssel, Rollback-Schutz	CodeSign Secure
Vertraulichkeit gespeicherter und übermittelter Daten (2(e))	Modernste Verschlüsselung im Ruhezustand und während der Übertragung, verwalteter Schlüssellebenszyklus	PKI-as-a-Service, HSM-as-a-Service
Integrität von Daten, Befehlen und Konfiguration (2(f))	Digitale Signaturen, Prüfsummen, authentifizierte Kommunikationskanäle	CodeSign Secure, PKI-as-a-Service
Sicherheitsereignisüberwachung und -protokollierung (2(l))	Unveränderliche Prüfprotokolle, die mit jedem Signierungs- und Zugriffsereignis verknüpft sind.	CodeSign Secure, CBOM Secure
SBOM und Komponentenverfolgung (Teil II.1)	Kryptografische Erkennung, Abhängigkeitsinventar, CVE-Überwachung	CBOM Secure
Offenlegung und Meldung von Sicherheitslücken (Teil II.4, Artikel 14)	Koordinierte Offenlegungspolitik, ENISA-Meldeverfahren, dokumentierte Zeitpläne	Compliance-Beratung

Welche Strafen drohen bei Nichteinhaltung?

Artikel 64 räumt den Marktüberwachungsbehörden sowohl Bußgeld- als auch Korrekturbefugnisse ein: Sie können die Rücknahme von Produkten vom Markt anordnen, den weiteren Verkauf einschränken oder verbieten und eine Überarbeitung des Designs vor der Wiederzulassung eines Produkts verlangen. Die Höhe der Bußgelder richtet sich nach der Schwere des Verstoßes.

Verstoß	Höchststrafe	Umsatzobergrenze (der höhere Wert)
Verstoß gegen wesentliche Cybersicherheitsanforderungen (Anhang I), Verpflichtungen aus Artikel 13 oder 14	15 Millionen Euro	2.5 % des weltweiten Jahresumsatzes
Weitere Verpflichtungen: unvollständige technische Dokumentation, fehlende Konformitätsbewertung, fehlerhafte CE-Kennzeichnung, fehlendes SBOM	10 Millionen Euro	2 % des weltweiten Jahresumsatzes
Falsche, irreführende oder unvollständige Informationen an die Behörden	5 Millionen Euro	1 % des weltweiten Jahresumsatzes

Checkliste zur Einhaltung der CRA-Vorschriften

Die CRA verlangt den Nachweis, dass Cybersicherheit verantwortet, gesteuert und dokumentiert ist und nicht nur ad hoc erfolgt. Nutzen Sie diese Checkliste, um den aktuellen Stand Ihrer Organisation zu ermitteln.

Risikobewertung

• Ein formaler Risikomanagementprozess identifiziert, überwacht und steuert Sicherheitsrisiken anhand dokumentierter Risikoakzeptanzkriterien.
• Eine RACI-Matrix definiert Risikoverantwortung, Eskalation und Entscheidungsfindung.
• Kryptografische Richtlinien orientieren sich an anerkannten Standards wie NIST und FIPS.

Vorfallreaktion

• Ein dokumentierter Notfallplan definiert die Verfahren zur Erkennung, Eindämmung und Wiederherstellung und wird regelmäßig getestet.
• Software-Stücklisten (SBOMs) werden aufrechterhalten, um eine schnelle Priorisierung von Vorfällen und eine Analyse ihrer Auswirkungen zu unterstützen.

Datenschutz

• Die Verschlüsselung schützt sensible Daten im Ruhezustand und während der Übertragung mithilfe von Algorithmen, die gemäß einem aktuellen Standard dokumentiert sind.
• Software- und Datenintegritätskontrollen, einschließlich Codesignaturwerden umgesetzt und unabhängig geprüft.

Berichterstattungspflichten

• Meldefristen, Schwellenwerte und Verantwortlichkeiten für Meldungen gemäß Artikel 14 an die ENISA sind klar definiert und wurden geübt.
• SBOMs und andere Nachweise zur Einhaltung der Vorschriften werden, wo immer möglich, automatisiert, um Reaktionszeiten und Fehler zu reduzieren.

Einschränkungen

Dieser Leitfaden dient als Ausgangspunkt und ersetzt weder eine formelle Konformitätsbewertung noch eine rechtliche Prüfung. Einige Punkte sollten klar dargelegt werden. Die von CEN und CENELEC erarbeiteten harmonisierten Normen werden Herstellern künftig eine Konformitätsvermutung für bestimmte technische Kontrollen einräumen. Bis zu deren Veröffentlichung lässt die direkte Bewertung anhand des Anhangs I Raum für unterschiedliche Interpretationen zwischen Herstellern und benannten Stellen. Die Produktkategorienbeispiele in diesem Leitfaden sind beispielhaft und ersetzen nicht das formelle Klassifizierungsverfahren, das den Konformitätsbewertungsweg für ein bestimmtes Produkt festlegt. Fällt ein Produkt auch unter NIS2, DORA oder eine branchenspezifische Regelung wie die Medizinprodukteverordnung, ersetzt die Konformitätsbewertung diese Verpflichtungen nicht, sondern ergänzt sie. Überschneidungen müssen im Einzelfall geklärt werden. Die in diesem Leitfaden enthaltenen Algorithmen- und Normenverweise spiegeln den aktuellen Stand von NIST und CA/B Forum (Stand: August 2026) wider. Da sich PQC-Standards und CA/B Forum-Abstimmungen ständig weiterentwickeln, benötigt ein Konformitätsprogramm ein Verfahren zur Nachverfolgung von Aktualisierungen und nicht nur das einmalige Lesen dieses Artikels.

Was würde Encryption Consulting empfehlen?

Führen Sie vor dem Kauf von Tools eine Gap-Analyse durch. Der Compliance- Beratungsdienst von Encryption Consulting führt eine detaillierte Bewertung anhand der spezifischen CRA-Artikel und der Anforderungen von Anhang I durch, die für die jeweilige Produktkategorie gelten, und identifiziert konkrete Lücken wie veraltete Protokolle, schwaches Schlüsselmanagement oder falsch konfigurierte TLS-Einstellungen anstelle einer allgemeinen Reifegradbewertung.

Speziell für die Anforderungen an sichere Updates und Firmware-Signaturen wurde CodeSign Secure genau für diese Kontrolle entwickelt: Private Signaturschlüssel verbleiben in FIPS 140-2 Level 3 zertifizierten HSMs, die M-of-N-Genehmigung verhindert einseitige Signaturen, jedes Signaturereignis erzeugt ein unveränderliches Audit-Log, und die hybride Signatur unterstützt sowohl klassische Algorithmen als auch Post-Quanten-Verfahren wie ML-DSA und LMS von derselben Signaturinfrastruktur aus, sodass ein Hersteller die Pipeline nicht erneut aufbauen muss, wenn die harmonisierten Standards in Kraft treten.

Für die Anforderungen an Vertraulichkeit und Integrität von ruhenden und übertragenen Daten bietet PKI-as-a-Service die verwaltete Zertifikats- und Schlüsselinfrastruktur, die verschlüsselte Kanäle und Geräteidentitäten unterstützt, ohne dass eine eigene Zertifizierungsstelle aufgebaut werden muss. Dies ist besonders wichtig für Hersteller, die diese Lösung weit vor dem Meldestichtag im September 2026 benötigen, nicht erst danach.

Ein Unternehmen, das IoT-Geräte herstellt, stand vor genau dieser Kombination von Problemen: einem gemeinsamen Signaturschlüssel, fehlender Rückverfolgbarkeit zwischen Zertifikaten und Releases sowie einem fehlenden Sperrprotokoll. Die Integration von HSM-gestütztem Schlüsselschutz, Multi-Faktor-Authentifizierung für den Signaturzugriff und automatisierter CI/CD-Signierung schloss die Lücken in Bezug auf Integrität und Zugriffskontrolle. Gleichzeitig erfüllten manipulationssichere Audit-Protokollierung und definierte Schlüsselsperrverfahren die Anforderungen der Zertifizierungsstelle hinsichtlich Rückverfolgbarkeit und Umgang mit Schwachstellen.

Fazit

Die CRA setzt einen neuen Standard: Cybersicherheit wird als kontinuierliche, nachweisbare Verantwortung über den gesamten Produktlebenszyklus hinweg verstanden, nicht nur als Checkliste am Markteinführungstag. Die Meldefrist am 11. September 2026 stellt zunächst die Funktionsfähigkeit des Prozesses zur Offenlegung von Sicherheitslücken unter Druck auf die Probe; die Frist am 11. Dezember 2027 prüft alle weiteren Aspekte, von der Entwicklung sicherer Systeme über die Genauigkeit des SBOM bis hin zu signierten, nachvollziehbaren Updates. Hersteller, die die Auswahl von Algorithmen, das Schlüsselmanagement und die Signierung von Updates als Infrastruktur betrachten, die jetzt aufgebaut werden muss, anstatt als Dokumentationsarbeit, die später erledigt werden muss, werden beide Fristen problemlos einhalten.

Häufig gestellte Fragen

Wann tritt der Cyber ​​Resilience Act tatsächlich in Kraft?

Die CRA trat am 10. Dezember 2024 in Kraft. Die Meldepflichten für Sicherheitslücken und Vorfälle gemäß Artikel 14 gelten ab dem 11. September 2026. Die vollständige Einhaltung der Vorschriften, einschließlich der CE-Kennzeichnung, ist bis zum 11. Dezember 2027 erforderlich. Nach diesen Terminen gibt es keine weitere Übergangsfrist.

Ist für die CRA ein bestimmter Verschlüsselungsalgorithmus erforderlich?

Nein. Anhang I, Teil I fordert zwar eine Verschlüsselung nach dem Stand der Technik zum Schutz der Vertraulichkeit und Integrität von Daten, Befehlen und Konfigurationen, nennt aber keine spezifischen Algorithmen. Hersteller wählen und dokumentieren Algorithmen wie AES-256, TLS 1.3 und Signaturverfahren, die den Anforderungen und der erwarteten Lebensdauer des Produkts entsprechen. Diese Auswahl wird Bestandteil der technischen Dokumentation, die im Rahmen einer Konformitätsbewertung geprüft wird.

Gibt es Produkte, die von der CRA ausgenommen sind?

Produkte, die vor dem 11. Dezember 2027 rechtmäßig auf dem EU-Markt in Verkehr gebracht wurden, sind grundsätzlich von den Hauptanforderungen ausgenommen, es sei denn, sie werden nach diesem Datum wesentlich verändert. Für bestimmte Kategorien, wie beispielsweise Produkte, die bereits unter branchenspezifische EU-Verordnungen für Medizinprodukte, Luftfahrt oder Fahrzeuge fallen, gelten gesonderte Ausnahmeregelungen gemäß der Verordnung. Die Meldepflichten nach Artikel 14 bezüglich Sicherheitslücken und Vorfällen gelten ab dem 11. September 2026 ungeachtet dieser Ausnahme weiterhin für die betroffenen Produkte.

In welchem ​​Verhältnis stehen CRA, NIS2 und DORA?

NIS2 und DORA regeln die Cybersicherheit und die operative Resilienz von Organisationen, die kritische Infrastrukturen betreiben, sowie von Finanzinstituten. CRA regelt die Produkte, die diese und andere Organisationen erwerben und nutzen. Eine Bank, die beispielsweise DORA unterliegt, muss weiterhin sicherstellen, dass die von ihr erworbenen vernetzten Geräte und Software den CRA-Anforderungen entsprechen; die Vorschriften ergänzen sich, sind aber keine sich überschneidenden Alternativen.

Was ist der größte Fehler, den Hersteller im Zusammenhang mit Kryptographie bei der Vorbereitung auf die CRA begehen?

Die Verwendung eines einzigen gemeinsamen Signaturschlüssels für alle Produktlinien ist zwar der schnellste Weg zur Konformität, birgt aber gemäß Artikel 14 das größte Risiko: Die Kompromittierung eines einzigen Schlüssels führt zu einer Meldung über einen Vorfall, der das gesamte Portfolio betrifft, anstatt nur eine einzelne Produktlinie. Die produktspezifische Schlüsselisolation, generiert innerhalb eines HSM, ist daher ohnehin die Lösung, die die meisten Konformitätsbewertungen erfordern.

Referenzen

• Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates, Cyber ​​Resilience Act, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• Europäische Kommission, Cyber ​​Resilience Act, Gestaltung der digitalen Zukunft Europas: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CRA-Anhänge I bis VIII, Wesentliche Anforderungen und Produktlisten: https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/
• Cyber ​​Resilience Act, Artikel 71, Inkrafttreten und Anwendung: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html
• NIST SP 800-208, Empfehlung für zustandsbehaftete Hash-basierte Signaturverfahren: https://csrc.nist.gov/pubs/sp/800/208/final
• NIST FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA), finalisiert im August 2024: https://csrc.nist.gov/pubs/fips/204/final