Cyber Resilience Act
EU-weite Cybersecurity-Standards

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

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).

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

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.

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.

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).

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.