Cyber Resilience Act

Was ist der Cyber Resilience Act?

Der CRA ist die EU-Querschnittsverordnung für "Products with Digital Elements" (PDE) – Hardware, Software und Remote-Processing-Komponenten. Er greift, sobald ein Produkt mit anderen Geräten oder Netzen verbunden wird. Von Firmware über Betriebssysteme bis zu Developer-Tools: Der CRA fordert essentielle Cybersecurity-Anforderungen über den gesamten Produktlebenszyklus.

Risikobasierte Klassifizierung

Der CRA unterscheidet zwischen nicht klassifizierten, Important (Class I/II) und Critical Produkten. Die Klassifizierung bestimmt Konformitätspfade, Prüftiefe und mögliche Zertifizierungspflichten.

Nicht klassifiziert

Basis-Cybersecurity. Standard-Produkte ohne kritische Sicherheitsfunktionen. Konformität über Selbstbewertung (Module A) möglich. Lifecycle-Pflichten gelten, aber reduzierte Prüfanforderungen.

Important Class I

Erhöhte Anforderungen. Produkte mit Kernfunktionen für Cybersecurity (z.B. Authentifizierung, Endpoint-Security, Netzschutz). Module A möglich mit harmonisierten Standards, sonst Third-Party-Assessment (Module B/C/H).

Important Class II

Hohe Schadensintensität. Kritischere Sicherheitsfunktionen (z.B. Intrusion Detection/Prevention, zentrale Systemfunktionen). Verpflichtendes Third-Party-Assessment. Strengere Konformitätsnachweise erforderlich.

Critical Products

Höchste Stufe. Per Delegiertem Rechtsakt können Critical-Produkte auf verpflichtende EU-Zertifizierung (z.B. EUCC, Assurance Level "substantial") aufgeschaltet werden. Umfassende Security-Evaluation notwendig.

Lifecycle-Pflichten: Design bis End-of-Support

Der CRA fordert essenzielle Cybersecurity-Anforderungen über den gesamten Produktlebenszyklus – von der Konzeption bis zur Außerbetriebnahme. Diese Pflichten sind nicht optional, sondern Grundlage der Konformität.

Secure by Design

Security von Anfang an. Risikoanalyse im Design, Threat Modeling, sichere Architektur-Patterns, Zero-Trust-Prinzipien. Security-Requirements müssen vor Entwicklungsbeginn definiert und dokumentiert sein.

Sichere Entwicklung & Build

Supply-Chain-Sicherheit. SBOM-Erstellung, CVE-Scanning, signierte Artefakte, reproduzierbare Builds. Sichere CI/CD-Ketten mit Policy-Gates. Nachvollziehbarkeit von Dependencies (inkl. Open-Source-Komponenten).

Sicheres Deployment & Updates

Update-Fähigkeit garantiert. Sichere Update-Mechanismen, getrennte Security- und Feature-Updates (wo möglich). Rollback-Fähigkeit, signierte Pakete, sichere Delivery-Channels. Keine Zwang zu Feature-Upgrades für Security-Fixes.

Vulnerability Management

CVD-Prozesse verpflichtend. Koordinierte Vulnerability Disclosure Policy, systematische CVE-Behandlung, Dokumentation, Bewertung (CVSS), Remediation. Integration mit Third-Party/OSS-Maintainern. Transparente Kommunikation an Nutzer.

Support-Zeiträume

Mindestens 5 Jahre. Support-Zeitraum orientiert sich an erwarteter Nutzungsdauer – mindestens fünf Jahre, bei längerer Lebensdauer entsprechend länger. Sicherheitsupdates müssen mindestens 10 Jahre verfügbar gehalten werden.

End-of-Support-Kommunikation

Klare User-Information. Rechtzeitige Ankündigung von End-of-Support, Migrationspfade aufzeigen, Sicherheitsrisiken kommunizieren. Keine abrupten Support-Beendigungen ohne Vorwarnung.

Meldepflichten: Incidents & Vulnerabilities

Der CRA etabliert ein europaweites Single-Reporting-Portal (ENISA-betrieben) mit strikten Meldefristen. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle strukturiert melden.

Frühwarnung: 24 Stunden

Erste Meldung binnen 24h. Sobald Kenntnis über einen schweren Vorfall oder aktiv ausgenutzte Schwachstelle besteht, muss eine Frühwarnung an das ENISA-Portal erfolgen – innerhalb von 24 Stunden ab Kenntnis.

Incident-Bericht: 72 Stunden

Strukturierter Bericht binnen 72h. Detaillierte Beschreibung des Vorfalls, betroffene Systeme, potenzielle Auswirkungen, erste Gegenmaßnahmen. Koordination über das Coordinator-CSIRT des Hauptsitz-Mitgliedstaates.

Abschlussbericht: 1 Monat

Finaler Bericht binnen 30 Tagen. Root-Cause-Analyse, umgesetzte Gegenmaßnahmen, Lessons Learned, Präventivmaßnahmen. Strukturierte Dokumentation für regulatorische Nachvollziehbarkeit.

Vulnerability-Folgebericht: 14 Tage

Nach Fix-Bereitstellung. Bei aktiv ausgenutzten Schwachstellen: Folgebericht binnen 14 Tagen nach Bereitstellung von Patches/Workarounds. Status-Updates bis zur vollständigen Remediation.

Konformitätsnachweis nach Modulen

Der CRA verwendet ein modulares Konformitätssystem (angelehnt an Decision 768/2008/EC). Je nach Produktklasse sind Selbstbewertung oder verpflichtende Third-Party-Assessments vorgeschrieben.

Module A: Selbstbewertung

Für nicht klassifizierte und Important Class I Produkte (mit harmonisierten Standards). Hersteller dokumentiert Konformität selbst. Technische Dokumentation, Test-Ergebnisse, Risikoanalyse müssen nachweisbar sein.

Module B/C/H: Third-Party

Verpflichtend für Important Class II. Benannte Stelle (Notified Body) prüft Produkt und/oder Produktionsprozess. Umfasst technische Dokumentation, Tests, Quality-Management-System. Module H: laufende Überwachung.

EU-Zertifizierung (EUCC)

Für Critical Products möglich. Per Delegiertem Rechtsakt können Critical-Kategorien auf verpflichtende EU-Zertifizierung (European Common Criteria, Assurance Level "substantial" oder höher) aufgeschaltet werden.

Supply-Chain & Souveränitätsrisiken

Der CRA erlaubt nicht-technische Risikofaktoren in die Cybersecurity-Bewertung einzubeziehen – Jurisdiktion, staatlicher Zugriff, "High-Risk Vendors". Eine Brücke zu digitaler Souveränität und Supply-Chain-Sicherheit.

Jurisdiktionelle Risiken

Abhängigkeiten von Nicht-EU-Jurisdiktionen können als Risikofaktor bewertet werden – insbesondere bei extraterritorialen Zugriffsmöglichkeiten (z.B. CLOUD Act, FISA). EU-basierte Alternativen bevorzugt.

High-Risk Vendors

Wirtschaftliche Sicherheit und staatlicher Einfluss auf Zulieferer fließen in die Risikobewertung ein. Multi-Sourcing, EU-Präferenz und Transparenz über Sub-Supplier werden regulatorisch gestärkt.

Supply-Chain-Transparenz

SBOM-Pflicht, Nachvollziehbarkeit von Dependencies, Lizenzen, Update-Quellen. Bei Schwachstellen in Komponenten: Pflicht zur Maintainer-Information und eigener Risikobewertung. Audit-Rechte entlang der Kette.

ayedo und der Cyber Resilience Act

Unsere Software Delivery Plattform und Managed Services sind auf CRA-Konformität ausgelegt – von SBOM-Generierung über CVE-Scanning bis zu 24/7 Incident Response. Wir unterstützen Sie systematisch bei allen Lifecycle-Anforderungen.

SBOM & CVE-Management

Automatisierte Supply-Chain-Sicherheit. Integrierte SBOM-Generierung, kontinuierliches CVE-Scanning, signierte Artefakte. Nachvollziehbarkeit aller Dependencies – von Open-Source bis proprietär. Policy-Gates für kritische Schwachstellen.

Signierte Builds & Reproducibility

Vertrauenswürdige Artefakte. Signatur-Verifizierung für Container-Images und Helm-Charts. Reproducible Builds, GitOps-Nachvollziehbarkeit. Artifact-Management mit vollständiger Provenance-Chain.

GitOps & CI/CD-Sicherheit

Sichere Delivery-Ketten. Git-to-Prod mit Audit-Trail, Policy-Enforcement, automatisierten Security-Gates. Trennung von Security- und Feature-Updates über Release-Branches. Rollback-Fähigkeit standardmäßig.

Update-Strategie & Archivierung

CRA-konforme Update-Prozesse. Sichere, signierte Updates, getrennte Security-Patches (wo möglich). Update-Archivierung für ≥10 Jahre. Keine Zwangskopplung von Security-Fixes an Feature-Upgrades.

24/7 Vulnerability Response

Incident & CVE-Handling rund um die Uhr. ISO 27001-basiertes ISMS mit dokumentierten CVD-Prozessen. 24/7-Support für Security-Hotfixes. Integration in ENISA/CSIRT-Meldeketten. Strukturierte Incident-Reports.

Support-Roadmaps & Lifecycle

Langfristige Support-Zusagen. Support-Zeiträume ≥5 Jahre (angepasst an Nutzungsdauer). End-of-Support-Kommunikation mit Vorlaufzeit. Transparente Lifecycle-Policies. Update-Archiv ≥10 Jahre verfügbar.

Konformitäts-Unterstützung

ISO 27001-zertifizierte Prozesse. Audit-Trails, Change-Management, Incident-Tracking. Vorbereitet für Module-A-Nachweise und Third-Party-Assessments. Vollständige technische Dokumentation.

EU-Sourcing & Jurisdiktion

Minimierung nicht-technischer Risiken. EU-basierte Operations, Provider-Unabhängigkeit, DSGVO-Konformität. Dedizierte souveräne Stacks verfügbar. Transparenz über Sub-Supplier und deren Jurisdiktion.

CRA-Enablement-Pakete

Strukturierte Konformitäts-Roadmaps. Klassifizierungs-Assessment (Important I/II/Critical), Konformitätspfad-Planung, CVD-Policy-Templates, ENISA-Meldeplaybooks, SBOM/Signatur-Stack-Setup. Turnkey-Implementierung aller Lifecycle-Anforderungen.

Kostenlose Beratung

CRA-Anforderungen im Detail

Was bedeutet der CRA konkret für Ihre Produkte und Prozesse? Von Secure-by-Design über Vulnerability-Management bis zu Meldepflichten – hier sind die Kernpflichten strukturiert aufbereitet.

Secure Development

Threat Modeling, Security-Requirements, Risikoanalyse vor Entwicklung. Sichere Coding-Standards, Code-Reviews, SAST/DAST. Supply-Chain-Sicherheit: SBOM, signierte Dependencies, Vulnerability-Scanning in CI/CD.

Technische Dokumentation

Umfassende Doku für Konformitätsnachweis: Architektur, Datenflüsse, Security-Controls, Test-Ergebnisse, Risikoanalyse. Lifecycle-Prozesse dokumentiert. Update-Mechanismen beschrieben. Für Audits und Notified Bodies.

CVD & Vulnerability Response

Koordinierte Vulnerability Disclosure Policy (öffentlich). CVE-Behandlungsprozess: Intake, Triage, Bewertung (CVSS), Remediation, Disclosure. Maintainer-Koordination bei Third-Party/OSS-Komponenten. Status-Tracking und User-Kommunikation.

Update-Management

Sichere, signierte Update-Mechanismen. Möglichst getrennte Security-Patches von Feature-Releases. Rollback-Fähigkeit. Update-Archiv ≥10 Jahre. Klare Kommunikation zu Updates (Security vs. Feature). Keine Zwangskopplung.

Incident Response

24h-Frühwarnung bei schweren Incidents. 72h-Incident-Bericht an ENISA-Portal. 30-Tage-Abschlussbericht. Strukturierte Meldeketten, Coordinator-CSIRT-Integration. Interne Schwellwerte für "severe incidents" definiert.

Konformitätsnachweise

Module A (Selbstbewertung) für nicht klassifiziert / Important I mit Standards. Module B/C/H (Third-Party) für Important II. EUCC-Vorbereitung für Critical-Produkte. Technische Doku, Test-Reports, QMS-Nachweise.

CRA im regulatorischen Kontext

Der CRA ist Teil des umfassenden EU-Digital-/Cybersecurity-Ökosystems. Er verzahnt sich mit NIS2, DORA, Cloud Sovereignty Framework, Data Act, GDPR und weiteren EU-Verordnungen.

CRA & NIS-2

Komplementär auf Produkt-/Operations-Ebene. NIS-2 fordert organisatorische und technische Maßnahmen für kritische Infrastrukturen. CRA ergänzt dies um produktseitige Cybersecurity-Anforderungen. Zusammen: resiliente Systeme von der Supply Chain bis zum Betrieb. Mehr zu NIS-2.

CRA & DORA

Produktsicherheit für Finanzsektor. DORA zielt auf digitale Betriebsresilienz im Finanzsektor. CRA stellt sicher, dass eingesetzte Produkte (IKT-Drittdienstleister, Software) grundlegende Cybersecurity-Standards erfüllen. Security by Design (CRA) unterstützt DORA-IKT-Risikomanagement. Mehr zu DORA.

CRA & Cloud Sovereignty

Sichere, souveräne Produkte. Cloud Sovereignty Framework bewertet Unabhängigkeit und Kontrolle. CRA fordert Sicherheit über Produktlebenszyklus. Zusammen: sichere EU-Produkte mit offenen Standards, Transparenz (SBOM), Exit-Fähigkeit – ohne Lock-in. Mehr zum Framework.

CRA & Data Act

Sichere, interoperable Produkte. CRA fordert Sicherheit über Produktlebenszyklus. Data Act fordert Interoperabilität und Datenportabilität. Zusammen: sichere Produkte mit offenen Schnittstellen – ohne Lock-in. Vulnerability-Management (CRA) schützt Datenflüsse (Data Act). Mehr zum Data Act.

CRA & GDPR

Security by Design trifft Privacy by Design. CRA fordert sichere Produkte (Software, Hardware), GDPR fordert Datenschutz bei deren Nutzung. Privacy by Design (GDPR Art. 25) ↔ Security by Design (CRA). Vulnerability-Management (CRA) unterstützt Art. 32 GDPR (Sicherheit der Verarbeitung). Mehr zur GDPR.

EUCC & Zertifizierung

European Common Criteria für Critical-Produkte. EUCC wird für Critical CRA-Produkte relevant. Assurance Level "substantial" oder höher. Umfassende Security-Evaluation nach harmonisierten Standards. Notified Bodies führen Prüfungen durch. Kohärente EU-Cybersecurity-Zertifizierung.

Supply-Chain-Souveränität

Nicht-technische Risikofaktoren. CRA erlaubt Berücksichtigung von Jurisdiktion und Vendor-Kontrolle. Verzahnung mit europäischen Souveränitäts-Initiativen. Multi-Sourcing, EU-Präferenz, Transparenz (SBOM, CVD) werden regulatorisch gestärkt.

ayedo Compliance-Übersicht

Comprehensive Compliance-Ansatz. Wie ayedo CRA, NIS-2, DORA, Data Act, GDPR, ISO 27001 und weitere Standards systematisch adressiert. Zertifizierungen, Prozesse, technische Maßnahmen und Audit-Bereitschaft – hier finden Sie unsere vollständige Compliance-Roadmap. Zur Übersicht.