Cyber Resilience Act (CRA): Was die Verordnung erfordert, wen sie betrifft und wie man sich vorbereitet

Der Cyber Resilience Act (CRA) ist die EU-Verordnung zur Festlegung verbindlicher Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Der CRA wurde 2024 verabschiedet und wird phasenweise bis Dezember 2027 vollständig anwendbar. Er schließt eine wichtige Lücke in der EU-Cybersicherheitsgesetzgebung, indem er die Sicherheit von Produkten vor ihrer Markteinführung adressiert.

Für B2B-Softwareunternehmen stellt der CRA einen fundamentalen Wandel dar: Cybersicherheit ist nicht mehr ein freiwilliges Feature, sondern eine rechtliche Voraussetzung für den Marktzugang in der EU. Produkte müssen mit Sicherheit im Blick entwickelt werden, Schwachstellen müssen aktiv verwaltet werden und Hersteller müssen während des gesamten Produktlebenszyklus Sicherheitsupdates bereitstellen.

Dieser Leitfaden behandelt, was der CRA erfordert, wen er betrifft, wesentliche Compliance-Pflichten und wie sich Softwareanbieter vorbereiten können.

Anwendungsbereich und Geltung des CRA

Was sind Produkte mit digitalen Elementen

Der CRA erfasst alle Software- oder Hardwareprodukte und ihre Datenfernverarbeitungslösungen, die auf dem EU-Markt bereitgestellt werden:

Kategorie	Beispiele
Eigenständige Software	Desktop-Anwendungen, Mobile-Apps, SaaS-Plattformen
Betriebssysteme	Desktop-OS, Mobile-OS, Embedded-OS
IoT-Geräte	Smart-Home-Geräte, Wearables, vernetzte Haushaltsgeräte
Netzwerkgeräte	Router, Switches, Firewalls, Access Points
Industrielle Systeme	SPS, SCADA-Systeme, industrielles IoT
Komponenten	Softwarebibliotheken, SDKs, Firmware, Mikrocontroller

Produktklassifizierung

Der CRA kategorisiert Produkte nach Risikoniveau, was die erforderliche Konformitätsbewertung bestimmt:

Kategorie	Bewertung	Beispiele
Standard	Selbstbewertung (bei harmonisierten Normen)	Allgemeine Software, Smart Speaker, Spiele
Wichtig Klasse I	Selbstbewertung mit harmonisierten Normen oder Drittbewertung	Identitätsmanagement, Passwort-Manager, VPNs, SIEM, Netzwerkmanagement
Wichtig Klasse II	Obligatorische Drittbewertung (benannte Stelle)	Betriebssysteme, Hypervisoren, Firewalls, Mikrocontroller, Smartcards, industrielle Automatisierung
Kritisch	Obligatorische Drittbewertung (EU-Zertifizierung)	Hardware-Sicherheitsmodule, Smart-Meter-Gateways, Smartcards für qualifizierte elektronische Signaturen

Wer muss den CRA einhalten

Rolle	Pflichten
Hersteller	Sichere Produkte entwickeln, Konformitätsbewertung durchführen, Updates bereitstellen, Schwachstellen melden, technische Dokumentation pflegen, CE-Kennzeichnung
Importeure	Herstellerkonformität überprüfen, CE-Kennzeichnung sicherstellen, Erklärungen bereithalten, nicht konforme Produkte melden
Händler	CE-Kennzeichnung überprüfen, Compliance-Dokumentation sicherstellen, nicht konforme Produkte melden
Open Source (nicht-kommerziell)	Von den meisten Pflichten befreit; Open-Source-Stewards haben leichtere Transparenzanforderungen

Wesentliche Cybersicherheitsanforderungen

Produktsicherheitsanforderungen (Anhang I, Teil I)

Produkte mit digitalen Elementen müssen diese wesentlichen Anforderungen erfüllen:

Design und Entwicklung

Entworfen, entwickelt und hergestellt, um ein angemessenes Cybersicherheitsniveau basierend auf Risikobewertung zu gewährleisten
Ausgeliefert ohne bekannte ausnutzbare Schwachstellen
Standardmäßig sichere Konfiguration, einschließlich der Möglichkeit, den ursprünglichen sicheren Zustand wiederherzustellen
Schutz vor unbefugtem Zugriff mit angemessener Authentifizierung und Identitätsmanagement

Datenschutz

Schutz der Vertraulichkeit gespeicherter, übertragener und verarbeiteter Daten (Verschlüsselung im Ruhezustand und bei der Übertragung)
Schutz der Integrität von Daten, Befehlen und Konfiguration gegen Manipulation
Verarbeitung nur angemessener, relevanter und auf den Verwendungszweck beschränkter Daten (Datenminimierung)

Resilienz und Verfügbarkeit

Gewährleistung der Verfügbarkeit, einschließlich Widerstandsfähigkeit gegen Denial-of-Service-Angriffe
Minimierung negativer Auswirkungen auf die Verfügbarkeit von Diensten anderer Geräte oder Netzwerke
Verringerung von Angriffsflächen, einschließlich externer Schnittstellen
Begrenzung der Auswirkungen eines Vorfalls durch geeignete Exploit-Mitigationsmechanismen

Überwachung und Protokollierung

Bereitstellung von sicherheitsrelevanter Ereignisprotokollierung und Überwachungsfunktionen
Fähigkeit zur Erkennung und Meldung von Sicherheitsereignissen
Mechanismen zur sicheren Update-Verteilung

Anforderungen an die Schwachstellenbehandlung (Anhang I, Teil II)

Hersteller müssen folgende Prozesse einrichten und aufrechterhalten:

Anforderung	Beschreibung
Schwachstellenidentifizierung	Schwachstellen identifizieren und dokumentieren, auch durch regelmäßige Tests und Meldungen Dritter
Komponentendokumentation	Eine Software-Stückliste (SBOM) pflegen, die Komponenten und Abhängigkeiten identifiziert
Sicherheitsupdates	Wirksame und regelmäßige Updates anwenden, kostenlos während des Unterstützungszeitraums
Schwachstellenoffenlegung	Eine koordinierte Schwachstellenoffenlegungspolitik umsetzen
Informationsaustausch	Informationen über behobene Schwachstellen zeitnah teilen
Update-Verteilung	Sichere Mechanismen zur Verteilung von Updates bereitstellen
Sicherheitshinweise	Hinweise über Schwachstellen und verfügbare Korrekturen veröffentlichen

Meldung von Vorfällen und Schwachstellen

Meldung an ENISA

Hersteller müssen folgende Ereignisse an ENISA melden (über eine zentrale Meldeplattform):

Ereignis	Erstmeldung	Vollständige Meldung	Abschlussbericht
Aktiv ausgenutzte Schwachstelle	24 Stunden	72 Stunden	14 Tage
Schwerwiegender Vorfall mit Sicherheitsauswirkung	24 Stunden	72 Stunden	14 Tage

ENISA leitet Meldungen an die zuständigen nationalen CSIRTs (Computer Security Incident Response Teams) und Marktüberwachungsbehörden weiter.

Nutzerbenachrichtigung

Hersteller müssen außerdem:

Nutzer über Vorfälle und aktiv ausgenutzte Schwachstellen informieren
Hinweise zu möglichen Risikominderungsmaßnahmen geben
Soweit möglich, Korrekturmaßnahmen bereitstellen (Patches, Workarounds)

Meldezeitraum

Die Meldepflicht gilt während der erwarteten Lebensdauer des Produkts oder mindestens fünf Jahre ab Markteinführung, je nachdem, welcher Zeitraum kürzer ist.

Konformitätsbewertung und CE-Kennzeichnung

Bewertungsverfahren

Verfahren	Anwendbar auf	Prozess
Interne Kontrolle (Selbstbewertung)	Standardprodukte; Klasse I mit harmonisierten Normen	Hersteller bewertet gegen Anforderungen, erstellt technische Dokumentation, stellt EU-Konformitätserklärung aus
EU-Baumusterprüfung	Klasse I ohne harmonisierte Normen; Klasse II; kritische Produkte	Benannte Stelle prüft technisches Design und ein Muster des Produkts
Umfassende Qualitätssicherung	Alternative für Klasse I/II	Benannte Stelle genehmigt und überwacht das Qualitätssicherungssystem des Herstellers
EU-Zertifizierung	Kritische Produkte (falls festgelegt)	Zertifizierung im Rahmen eines EU-Cybersicherheitszertifizierungsschemas

Technische Dokumentation

Hersteller müssen technische Dokumentation erstellen und pflegen, einschließlich:

Allgemeine Produktbeschreibung und Verwendungszweck
Design- und Entwicklungsdetails relevant für Cybersicherheit
Risikobewertung und wie wesentliche Anforderungen erfüllt werden
Liste angewandter harmonisierter Normen (oder alternativer Lösungen)
Testberichte aus Cybersicherheitsbewertungen
Software-Stückliste (SBOM)
EU-Konformitätserklärung
Informationen zu Sicherheitsupdates und Unterstützungszeitraum

CE-Kennzeichnung

Produkte, die alle anwendbaren Anforderungen erfüllen, erhalten die CE-Kennzeichnung, die:

Die Konformität mit den wesentlichen Cybersicherheitsanforderungen anzeigt
Für die Bereitstellung des Produkts auf dem EU-Markt erforderlich ist
Sichtbar, lesbar und dauerhaft angebracht werden muss
Bei reinen Softwareprodukten in der Dokumentation oder der digitalen Oberfläche enthalten sein kann

CRA-Umsetzungszeitplan

Datum	Meilenstein
2024	CRA verabschiedet und in Kraft getreten
September 2026	Meldepflichten für Hersteller gelten (Schwachstellen- und Vorfallmeldung an ENISA)
Dezember 2027	Alle CRA-Anforderungen vollständig anwendbar, einschließlich Konformitätsbewertung und CE-Kennzeichnung

CRA und andere Rahmenwerke

CRA und NIS2

Aspekt	CRA	NIS2
Fokus	Produktsicherheit (vor Markteinführung)	Organisatorische Cybersicherheit (operativ)
Anwendungsbereich	Produkte mit digitalen Elementen	Wesentliche und wichtige Einrichtungen
Art	Verordnung (unmittelbar anwendbar)	Richtlinie (erfordert Umsetzung)
Bewertung	Konformitätsbewertung vor Markteinführung	Risikomanagement und Vorfallmeldung im Betrieb
Meldung	Aktiv ausgenutzte Schwachstellen an ENISA	Erhebliche Vorfälle an zuständige Behörden
Verhältnis	Komplementär — CRA sichert das Produkt, NIS2 sichert die Organisation, die es nutzt

CRA und ISO 27001

Aspekt	ISO 27001	CRA-Ergänzungen
Fokus	Organisatorisches ISMS	Produktebene Sicherheit
Schwachstellenmanagement	A.8.8 Management technischer Schwachstellen	Obligatorisches SBOM, koordinierte Offenlegung, kostenlose Patches
Vorfallmeldung	Interne Verfahren	24/72-Stunden-Meldung an ENISA
Sichere Entwicklung	A.8.25-A.8.31 Anwendungssicherheit	Obligatorisches Secure-by-Default-Design
Lieferkette	A.5.19-A.5.23 Lieferantensicherheit	Komponentendokumentation und SBOM-Anforderungen

Vorbereitung auf CRA-Compliance

Für Software-Hersteller

Produkt klassifizieren — Bestimmen Sie, ob Ihr Produkt Standard, Wichtig Klasse I/II oder Kritisch ist
Gap-Analyse — Aktuelle Sicherheitspraktiken gegen die wesentlichen CRA-Anforderungen (Anhang I) abgleichen
Sicherer Entwicklungslebenszyklus — SDL-Praktiken implementieren oder stärken, einschließlich Bedrohungsmodellierung und Sicherheitstests
Schwachstellenmanagement — Koordinierte Schwachstellenoffenlegung, Patch-Management und Sicherheitshinweis-Prozesse einrichten
SBOM-Erstellung — Software-Stückliste für alle Produkte generieren und pflegen
Technische Dokumentation — Dokumentation erstellen, die Konformität mit wesentlichen Anforderungen nachweist
Meldebereitschaft — Kapazität für 24-Stunden-Schwachstellen- und Vorfallmeldung an ENISA aufbauen
Unterstützungszeitraum planen — Sicherheitsunterstützungszeitraum für jedes Produkt definieren und kommunizieren

Für B2B-SaaS-Unternehmen

Anwendbarkeit prüfen — Bewerten, ob Ihr SaaS als Produkt mit digitalen Elementen oder Datenfernverarbeitung qualifiziert
Kundenverträge überprüfen — Auf CRA-konforme vertragliche Anforderungen von Unternehmenskunden vorbereiten
Schwachstellenbehandlung stärken — SBOM-Generierung, Schwachstellenscanning und koordinierte Offenlegung implementieren
Im Trust Center veröffentlichen — Sicherheitsdokumentation, Schwachstellenbehandlungsprozesse und Compliance-Nachweise für Käufer bereitstellen
Konformitätsbewertung planen — Geeignetes Bewertungsverfahren bestimmen und entsprechend vorbereiten
Harmonisierte Normen beobachten — Entwicklung harmonisierter Normen verfolgen, die Selbstbewertung für Klasse-I-Produkte ermöglichen

Wie Orbiq die CRA-Compliance unterstützt

Trust Center: Veröffentlichen Sie Ihre CRA-Compliance-Position — sichere Entwicklungspraktiken, Schwachstellenbehandlungsprozesse, SBOM-Verfügbarkeit und Sicherheitsupdate-Richtlinien für Käufer-Self-Service
Kontinuierliches Monitoring: Verfolgen Sie die wesentlichen CRA-Anforderungen über Ihre Produktsicherheitskontrollen mit Echtzeit-Compliance-Status
Evidenz-Management: Zentralisieren Sie technische Dokumentation, Sicherheitstestberichte und Schwachstellenaufzeichnungen, zugeordnet zu CRA Anhang I-Anforderungen
KI-gestützte Fragebögen: Beantworten Sie CRA-bezogene Sicherheitsfragebogen-Fragen automatisch von Unternehmenskunden

Weiterführende Lektüre

NIS2-Compliance — Das Verhältnis zwischen CRA-Produktsicherheit und NIS2-Organisationssicherheit verstehen
DORA-Compliance — CRA-Auswirkungen für IKT-Anbieter im Finanzsektor
Penetrationstest — CRA-Sicherheitstestanforderungen erfüllen
Incident Response — Meldefähigkeiten für CRA-Schwachstellen- und Vorfallbenachrichtigungen aufbauen

Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letztes Update: März 2026.