--- title: "Cyber Resilience Act (CRA): Anforderungen und Vorbereitung" description: "Ein praktischer Leitfaden zum EU Cyber Resilience Act — was der CRA für Produkte mit digitalen Elementen erfordert, wer betroffen ist, wesentliche Sicherheitsanforderungen, Konformitätsbewertungsverfahren und wie sich Softwareanbieter vorbereiten können." canonical: https://www.orbiqhq.com/de/glossar/cyber-resilience-act html: https://www.orbiqhq.com/de/glossar/cyber-resilience-act publisher: Orbiq GmbH language: en --- # Cyber Resilience Act (CRA): Anforderungen und Vorbereitung Ein praktischer Leitfaden zum EU Cyber Resilience Act — was der CRA für Produkte mit digitalen Elementen erfordert, wer betroffen ist, wesentliche Sicherheitsanforderungen, Konformitätsbewertungsverfahren und wie sich Softwareanbieter vorbereiten können. 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 1. **Produkt klassifizieren** — Bestimmen Sie, ob Ihr Produkt Standard, Wichtig Klasse I/II oder Kritisch ist 2. **Gap-Analyse** — Aktuelle Sicherheitspraktiken gegen die wesentlichen CRA-Anforderungen (Anhang I) abgleichen 3. **Sicherer Entwicklungslebenszyklus** — SDL-Praktiken implementieren oder stärken, einschließlich Bedrohungsmodellierung und Sicherheitstests 4. **Schwachstellenmanagement** — Koordinierte Schwachstellenoffenlegung, Patch-Management und Sicherheitshinweis-Prozesse einrichten 5. **SBOM-Erstellung** — Software-Stückliste für alle Produkte generieren und pflegen 6. **Technische Dokumentation** — Dokumentation erstellen, die Konformität mit wesentlichen Anforderungen nachweist 7. **Meldebereitschaft** — Kapazität für 24-Stunden-Schwachstellen- und Vorfallmeldung an ENISA aufbauen 8. **Unterstützungszeitraum planen** — Sicherheitsunterstützungszeitraum für jedes Produkt definieren und kommunizieren ### Für B2B-SaaS-Unternehmen 1. **Anwendbarkeit prüfen** — Bewerten, ob Ihr SaaS als Produkt mit digitalen Elementen oder Datenfernverarbeitung qualifiziert 2. **Kundenverträge überprüfen** — Auf CRA-konforme vertragliche Anforderungen von Unternehmenskunden vorbereiten 3. **Schwachstellenbehandlung stärken** — SBOM-Generierung, Schwachstellenscanning und koordinierte Offenlegung implementieren 4. **Im Trust Center veröffentlichen** — Sicherheitsdokumentation, Schwachstellenbehandlungsprozesse und Compliance-Nachweise für Käufer bereitstellen 5. **Konformitätsbewertung planen** — Geeignetes Bewertungsverfahren bestimmen und entsprechend vorbereiten 6. **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 --- > **Vollständiger Leitfaden:** [Cyber Resilience Act (CRA): Vollständiger Compliance-Leitfaden 2026](/de/eu-vorschriften/cyber-resilience-act) — Umfassende Behandlung der September-2026-Frist für Schwachstellenmeldungen, SBOM-Anforderungen, Open-Source-Steward-Pflichten, der Kommissions-Leitlinien vom März 2026 und des vollständigen Compliance-Fahrplans. ## Weiterführende Lektüre - [NIS2-Compliance](/de/glossar/nis2-compliance) — Das Verhältnis zwischen CRA-Produktsicherheit und NIS2-Organisationssicherheit verstehen - [DORA-Compliance](/de/glossar/dora-compliance) — CRA-Auswirkungen für IKT-Anbieter im Finanzsektor - [Penetrationstest](/de/glossar/penetrationstest) — CRA-Sicherheitstestanforderungen erfüllen - [Incident Response](/de/glossar/incident-response) — Meldefähigkeiten für CRA-Schwachstellen- und Vorfallbenachrichtigungen aufbauen --- *Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letztes Update: März 2026.*