Nicht klassifiziert
Basis-Cybersecurity. Standard-Produkte ohne kritische Sicherheitsfunktionen. Konformität über Selbstbewertung (Module A) möglich. Lifecycle-Pflichten gelten, aber reduzierte Prüfanforderungen.
Cyber Resilience Act
EU-weite Cybersecurity-Standards
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.
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.
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.