TL;DR

Der CRA (Cyber Resilience Act) schreibt Sicherheit für alles „Digitale“ vor, das in der EU verkauft wird – Apps, Firmware, IoT, Software.

Erfordert Security-by-Design, Patching, SBOMs und die Offenlegung von Schwachstellen über den gesamten Produktlebenszyklus hinweg.

Beginnt im Dezember 2027. Nicht eingehalten? Erwarten Sie Bußgelder von über 15 Millionen Euro oder Marktverbote.

EU Cyber Resilience Act (CRA) Scorecard-Zusammenfassung:

• Aufwand für Entwickelnde: Hoch (Erfordert die Integration von Sicherheit über den gesamten Produktlebenszyklus hinweg: sicheres Design, sichere Codierung, rigorose Tests, Implementierung von Prozessen zur Schwachstellenbehandlung, Bereitstellung sicherer Updates, Pflege von SBOMs).
• Tooling-Kosten: Moderat bis hoch (Erfordert sichere SDLC-Tools – SAST/SCA/DAST, SBOM-Generierungstools, Schwachstellenmanagement-Plattformen, potenziell sichere Update-Infrastruktur – OTA-Plattformen).
• Marktauswirkungen: Sehr hoch (Obligatorisch für fast alle in der EU verkauften Hardware-/Softwareprodukte; legt eine neue globale Basis für Erwartungen an die Produktsicherheit fest).
• Flexibilität: Moderat (Definiert wesentliche Anforderungen, erlaubt aber unterschiedliche Konformitätsbewertungsverfahren basierend auf der Produkt-Risikoklassifizierung).
• Auditintensität: Mittel bis hoch (Erfordert Konformitätsbewertungen – Selbstbewertung für Standardprodukte, Drittanbieterbewertung für kritische Produkte; Marktüberwachungsbehörden werden dies durchsetzen).

Was ist der EU Cyber Resilience Act (CRA)?

Der EU Cyber Resilience Act (CRA) ist eine Verordnung, die harmonisierte Cybersicherheitsanforderungen für „Produkte mit digitalen Elementen“ (PDEs) festlegt, die auf dem Markt der Europäischen Union bereitgestellt werden. Sie zielt darauf ab, das weit verbreitete Problem unsicherer Hardware- und Softwareprodukte und den Mangel an zeitnahen Sicherheitsupdates anzugehen.

Der CRA gilt weitgehend für nahezu jedes Software- oder Hardwareprodukt, das direkt oder indirekt mit einem anderen Gerät oder Netzwerk verbunden werden kann, mit einigen Ausnahmen (z. B. Medizinprodukte, Luftfahrt, Autos, die bereits durch spezifische Gesetzgebung abgedeckt sind, SaaS, es sei denn, es ist kritisch). Dies umfasst IoT-Geräte für Verbraucher, Netzwerkausrüstung, industrielle Steuerkomponenten, Betriebssysteme, mobile Apps, Desktop-Software und mehr.

Wesentliche Säulen der CRA:

1. Wesentliche Cybersicherheitsanforderungen (Anhang I): Hersteller müssen sicherstellen, dass PDEs während ihres gesamten Lebenszyklus spezifische Sicherheitsziele erfüllen. Dies umfasst:
   
   • Security by Design & Default: Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass ein angemessenes Maß an Cybersicherheit gewährleistet ist. Sie müssen mit einer sicheren Standardkonfiguration ausgeliefert werden.
   • Schwachstellenmanagement: Hersteller müssen Prozesse zur Identifizierung und Behebung von Schwachstellen während der erwarteten Lebensdauer des Produkts oder mindestens fünf Jahre lang haben, einschließlich der Bereitstellung von Sicherheitsupdates „unverzüglich“ und kostenlos.
   • Datenschutz: Schutz der Vertraulichkeit, Integrität und Verfügbarkeit der vom Produkt verarbeiteten Daten.
   • Zugriffskontrolle: Verhinderung von unbefugtem Zugriff.
   • Resilienz: Fähigkeit, Vorfällen standzuhalten und sich davon zu erholen.
   • Minimierung der Angriffsfläche: Begrenzung der Angriffsflächen und Minderung der Auswirkungen von Vorfällen.
2. Pflichten für Wirtschaftsakteure:
   
   • Hersteller: Tragen die Hauptverantwortung für die Sicherstellung der CRA-Compliance – sicheres Design, Konformitätsbewertung, technische Dokumentation (einschließlich SBOM), Schwachstellenbehandlung, Meldung von Vorfällen/Schwachstellen, Bereitstellung von Updates und klaren Anweisungen. Dies gilt auch bei Sitz außerhalb der EU.
   • Importeure/Händler: Haben die Pflicht, die Compliance des Herstellers (z. B. CE-Kennzeichnung, Dokumentation) zu überprüfen, bevor sie Produkte auf den Markt bringen.
3. Umgang mit Schwachstellen & Meldepflicht: Hersteller müssen Prozesse etablieren, um Schwachstellen effektiv zu behandeln und aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an die ENISA (EU-Agentur für Cybersicherheit) zu melden. Zudem müssen sie Nutzer über behobene Schwachstellen und verfügbare Updates informieren.
4. Konformitätsbewertung & CE-Kennzeichnung: PDEs müssen ein Konformitätsbewertungsverfahren durchlaufen (von der Hersteller-Selbstbewertung bis zur Zertifizierung durch Dritte, abhängig von der Produktkritikalität), um die Compliance nachzuweisen, bevor sie eine CE-Kennzeichnung erhalten und auf dem EU-Markt platziert werden.
5. Marktüberwachung: Benennt nationale Marktüberwachungsbehörden zur Durchsetzung des CRA, zur Untersuchung von Nichteinhaltung und zur Verhängung von Strafen oder zur Anordnung des Produktrückzugs/-rückrufs.

Der CRA trat Ende 2024 in Kraft, wobei die meisten Verpflichtungen 36 Monate später (etwa Dezember 2027) anwendbar werden, während die Meldepflichten für Hersteller früher (etwa September 2026) gelten.

Warum ist es wichtig?

Der CRA ist ein wegweisendes Gesetz mit erheblichen Auswirkungen:

• Verlagert die Verantwortung: Legt die Verantwortung für die Produktsicherheit direkt auf die Hersteller, anstatt sie primär den Endbenutzern zu überlassen.
• Erhöht die Baseline-Sicherheit: Legt verbindliche Mindeststandards für die Cybersicherheit für eine Vielzahl vernetzter Produkte fest, die in der EU verkauft werden.
• Sicherheit der Software-Lieferkette: Behebt Schwachstellen, die von Drittanbieterkomponenten stammen, durch Anforderungen wie SBOMs und Schwachstellenmanagement über den gesamten Lebenszyklus hinweg.
• Schützt Verbraucher und Unternehmen: Zielt darauf ab, die Anzahl unsicherer Produkte zu reduzieren, die von Angreifern ausgenutzt werden, und schützt Nutzer vor Datenlecks, finanziellen Verlusten und Sicherheitsrisiken.
• Harmonisierung der Anforderungen: Schafft einen einheitlichen Regelsatz in der gesamten EU und ersetzt potenziell fragmentierte nationale Ansätze zur Produktsicherheit.
• Globale Auswirkungen: Angesichts der Größe des EU-Marktes setzt die CRA effektiv einen globalen Standard und beeinflusst Hersteller weltweit, die Produkte in Europa verkaufen möchten.
• Ergänzt andere Vorschriften: Arbeitet Hand in Hand mit NIS2 (Sicherung kritischer Dienste), DSGVO (Schutz personenbezogener Daten) und DORA (finanzielle Resilienz), um eine umfassendere EU-Cybersicherheitslandschaft zu schaffen.

Für Hersteller von Software und vernetzter Hardware wird die CRA Compliance zu einer grundlegenden Anforderung für den Marktzugang in der EU.

Was und wie implementieren (Technisch & Policy)

Die Implementierung des CRA erfordert die Integration seiner wesentlichen Anforderungen (Anhang I) über den gesamten Produktlebenszyklus hinweg:

1. Sicheres Design & Entwicklung (Security by Design):
   
   • Bedrohungsmodellierung: Identifizieren Sie potenzielle Bedrohungen und entwerfen Sie Sicherheitskontrollen von Anfang an.
   • Sichere Kodierungspraktiken: Schulen Sie Entwickelnde und setzen Sie sichere Kodierungsstandards durch (z. B. OWASP ASVS, CERT Kodierungsstandards). Verwenden Sie SAST-Tools.
   • Angriffsfläche minimieren: Funktionalitäten, offene Ports und Privilegien auf das notwendige Minimum begrenzen.
   • Sichere Standardeinstellungen: Sicherstellen, dass Produkte mit sicheren Konfigurationen ausgeliefert werden (z. B. keine Standardpasswörter, unnötige Dienste deaktiviert). Sichere Reset-Funktionalität implementieren.
   • Datenschutz: Implementierung der Verschlüsselung für ruhende und übertragene Daten, wo angebracht. Schutz der Datenintegrität.
   • Zugriffskontrolle: Implementieren Sie robuste Authentifizierungs- und Autorisierungsmechanismen.
2. Schwachstellenmanagement:
   
   • Komponentenanalyse (SBOM): Generieren und pflegen Sie eine genaue Software-Stückliste (SBOM), die alle Komponenten (einschließlich Open-Source-Bibliotheken) identifiziert. Verwenden Sie SCA-Tools, um bekannte Schwachstellen in Abhängigkeiten zu finden.
   • Sicherheitstests: Implementieren Sie regelmäßige Schwachstellenscans (SAST, DAST, SCA, IaC), Fuzz-Testing und Penetrationstests während der Entwicklung und nach der Veröffentlichung.
   • Prozess zur Schwachstellenbehandlung: Etablieren Sie klare Verfahren für den Empfang von Schwachstellenmeldungen (intern/extern), deren Analyse, die Entwicklung von Patches und die unverzügliche Verteilung von Updates.
   • Patching/Updates: Stellen Sie Sicherheitsupdates während des erwarteten Produktlebenszyklus (mind. 5 Jahre) kostenlos zur Verfügung. Implementieren Sie einen sicheren Update-Mechanismus (z. B. sichere OTA-Updates mit Integritätsprüfungen).
3. Transparenz & Dokumentation:
   
   • Technische Dokumentation: Pflegen Sie detaillierte technische Dokumentation, die die Compliance mit den wesentlichen Anforderungen nachweist. Fügen Sie die SBOM bei.
   • Benutzerinformationen: Geben Sie Benutzern klare Anweisungen zur sicheren Nutzung, Konfiguration, zu Updates und zur Support-Lebensdauer des Produkts.
   • Offenlegung von Schwachstellen: Legen Sie eine Richtlinie und eine Kontaktstelle für den Empfang von Schwachstellenberichten fest; veröffentlichen Sie behobene Schwachstellen.
4. Konformitätsbewertung:
   
   • Risikoklassifizierung: Feststellung, ob das Produkt gemäß Anhang III in die Kategorien Standard, „wichtig“ (Klasse I) oder „kritisch“ (Klasse II) fällt.
   • Bewertungsverfahren: Befolgen Sie das vorgeschriebene Verfahren (z. B. interne Kontrolle/Selbstbewertung für Standardfälle, Drittanbieter-Bewertung/Zertifizierung für wichtige/kritische Klassen).
   • Erklärung & CE-Kennzeichnung: Erstellen Sie eine EU-Konformitätserklärung und bringen Sie die CE-Kennzeichnung an, sobald die Compliance nachgewiesen ist.
5. Meldepflichten:
   
   • Aktiv ausgenutzte Schwachstellen: Innerhalb von 24 Stunden nach Kenntnisnahme an ENISA melden.
   • Wesentliche Vorfälle: Melden Sie Vorfälle, die die Produktsicherheit beeinträchtigen, an die ENISA.

Die Implementierung erfordert die Verankerung von Sicherheit in die Engineering-Kultur, -Prozesse und -Tools vom Design bis zur Wartung.

Häufige Fehler, die es zu vermeiden gilt

Hersteller, die sich auf den CRA vorbereiten, sollten diese häufigen Fehler vermeiden:

1. Umfang unterschätzen: Zu glauben, dass der CRA nur für komplexe IoT-Geräte und nicht für Standardsoftware oder einfachere Hardware mit digitalen Elementen gilt. Der Anwendungsbereich ist sehr breit.
2. Verzögerung von Maßnahmen: Warten bis näher an der Frist 2027, Unterschätzung der erheblichen Änderungen, die in Design, Entwicklung, Tests, Schwachstellenmanagement und Update-Prozessen erforderlich sind.
3. Sicherheit als nachträglichen Gedanken behandeln: Sicherheit nicht von der Designphase an zu integrieren („Security by Design“) und zu versuchen, sie später anzubringen, ist weniger effektiv und kostspieliger.
4. Unzureichendes Schwachstellenmanagement: Fehlen robuster Prozesse oder Tools (SCA, SAST, DAST) zur Identifizierung von Schwachstellen oder das Versäumnis, zeitnahe und kostenlose Sicherheitsupdates für den erforderlichen Lebenszyklus bereitzustellen.
5. Ungenauigkeit/Vernachlässigung der SBOM: Versäumnis, eine vollständige SBOM zu generieren oder sie bei Komponentenänderungen aktuell zu halten, was das Schwachstellenmanagement behindert.
6. Sichere Update-Mechanismen ignorieren: Keine zuverlässige und sichere Möglichkeit (wie eine robuste OTA-Plattform) zu haben, Updates „ohne Verzögerung“ bereitzustellen. Manuelle Updates werden wahrscheinlich nicht ausreichen.
7. Unzureichende Dokumentation: Versäumnis, die erforderliche technische Dokumentation, SBOM und Konformitätsbeweis zu pflegen, die für die Marktüberwachung erforderlich sind.
8. Ausschließlicher Fokus auf die Entwicklung: Vernachlässigung der fortlaufenden Post-Market-Anforderungen für die Schwachstellenbehandlung und Updates über den gesamten Produktlebenszyklus hinweg.

Was Gutachter/Behörden fragen könnten (Fokus Entwickelnde)

Konformitätsbewertungsstellen (für kritische Produkte) oder Marktaufsichtsbehörden könnten Fragen zu CRA-Anforderungen stellen, die die Entwicklung betreffen:

• (Anhang I) Sicheres Design: „Wie wurde Sicherheit während der Designphase berücksichtigt? Können Sie Bedrohungsmodelle oder Sicherheitsarchitektur-Dokumente vorlegen?“
• (Anhang I) Schwachstellenmanagement: „Welche Tools und Prozesse werden verwendet, um Schwachstellen in eigenem Code und Drittanbieterkomponenten (SAST, SCA) während der Entwicklung zu identifizieren?“
• (Anhang I) Sichere Programmierung: „Welche Standards für sichere Programmierung werden befolgt? Wie wird die Compliance durchgesetzt (z. B. Linters, Code-Reviews, Schulungen)?“
• (Anhang I) Sicherheitstests: „Legen Sie Nachweise für Sicherheitstests (z. B. Penetrationstests, Fuzz-Tests) vor, die vor der Veröffentlichung durchgeführt wurden.“
• (Anhang I) Sichere Updates: „Beschreiben Sie den Mechanismus zur Bereitstellung von Sicherheitsupdates. Wie wird die Integrität und Authentizität der Updates gewährleistet?“
• (Art. 10) SBOM: „Stellen Sie die Software-Stückliste (SBOM) für diese Produktversion bereit.“
• (Art. 10) Schwachstellenbehandlung: „Beschreiben Sie den Prozess zur Behandlung einer gemeldeten Schwachstelle, von der Erfassung bis zur Patch-Veröffentlichung.“
• (Anhang I) Sichere Standardkonfiguration: „Wie gewährleistet das Produkt eine sichere Konfiguration ab Werk?“

Sie werden Nachweise aus den Design-, Entwicklungs-, Test- und Wartungsphasen verlangen, einschließlich Dokumentation, Tool-Berichten, Prozessbeschreibungen und möglicherweise Zugang zur Code-Überprüfung.

Quick Wins für Entwicklungsteams

Während die vollständige CRA-Compliance Zeit braucht, können Entwicklungsteams bereits die Grundlagen legen:

1. Implementieren Sie die SBOM-Generierung: Integrieren Sie Tools, um automatisch eine SBOM als Teil des Build-Prozesses zu generieren.
2. Integrieren Sie SCA & SAST: Stellen Sie sicher, dass Software-Kompositionsanalyse und Statische Anwendungssicherheitstests zuverlässig in der CI/CD-Pipeline laufen.
3. Grundlegendes Threat Modeling einführen: Beginnen Sie, potenzielle Bedrohungen während der Design-Meetings für neue Funktionen oder Produkte zu diskutieren.
4. Standardkonfigurationen überprüfen: Bewerten und härten Sie aktiv die Standardeinstellungen für Produkte vor der Auslieferung. Entfernen Sie Standardanmeldeinformationen.
5. Update-Prozess dokumentieren: Dokumentieren Sie klar den aktuellen Prozess für die Erstellung und Freigabe von Software-Updates, auch wenn er anfänglich manuell ist.
6. Vulnerability Intake etablieren: Einen einfachen, dokumentierten Weg für interne Teams oder externe Forschende schaffen, um potenzielle Schwachstellen zu melden (z. B. eine dedizierte E-Mail-Adresse oder ein Formular).

Ignorieren Sie dies und... (Konsequenzen der Nichteinhaltung)

Die Nichteinhaltung der CRA kann zu schwerwiegenden Konsequenzen führen, die von nationalen Marktüberwachungsbehörden durchgesetzt werden:

• Hohe Bußgelder: Verwaltungsstrafen können bei Nichteinhaltung wesentlicher Anforderungen bis zu €15 Millionen oder 2,5 % des gesamten weltweiten Jahresumsatzes des Herstellers im vorangegangenen Geschäftsjahr betragen, je nachdem, welcher Betrag höher ist. Geringere Verstöße werden mit Bußgeldern von bis zu 10 Mio. €/2 % oder 5 Mio. €/1 % geahndet.
• Marktrückzug/-rückruf: Behörden können verlangen, dass nicht-konforme Produkte vom EU-Markt zurückgezogen oder von Endnutzern zurückgerufen werden.
• Verkaufsverbot/-beschränkung: Das Inverkehrbringen nicht konformer Produkte kann verboten oder eingeschränkt werden.
• Reputationsschaden: Die öffentliche Offenlegung von Non-Compliance, Rückrufen oder erheblichen Schwachstellen schädigt das Markenvertrauen und die Marktwahrnehmung.
• Verlust des Marktzugangs: Die Nichteinhaltung der CRA-Anforderungen blockiert effektiv den Zugang zum gesamten EU-Binnenmarkt für abgedeckte Produkte.

FAQ

Welche Produkte werden von der CRA abgedeckt?

„Produkte mit digitalen Elementen“ (PDEs), deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Dies beinhaltet die meisten Softwareprodukte (eigenständig, mobil, eingebettet) und Hardware mit Konnektivität (IoT-Geräte, Router, Smart Appliances, Industriekomponenten usw.). Es gibt spezifische Ausnahmen (z. B. Medizinprodukte, Autos, Luftfahrt, bestimmte SaaS).

Wann werden CRA-Anforderungen verbindlich?

Die meisten Verpflichtungen, einschließlich Konformitätsbewertungen und wesentlicher Anforderungen, gelten 36 Monate nach Inkrafttreten des CRA (ungefähr Dezember 2027). Die Meldepflicht des Herstellers für aktiv ausgenutzte Schwachstellen und Vorfälle gilt jedoch früher, nämlich 21 Monate nach Inkrafttreten (ungefähr September 2026).

Gilt die CRA für freie und Open-Source-Software (FOSS)?

Eigenständige FOSS, die außerhalb einer kommerziellen Aktivität entwickelt oder bereitgestellt wird, ist im Allgemeinen ausgeschlossen. FOSS, die jedoch in ein kommerzielles Produkt integriert ist, ist abgedeckt, und der Hersteller des Endprodukts ist verantwortlich. FOSS-Projekte mit formalen Strukturen (z. B. Stiftungen), die Support oder Versionen monetarisieren, könnten ebenfalls unter bestimmte CRA-Verpflichtungen fallen (Details werden noch diskutiert).

Was ist die CE-Kennzeichnung im Kontext der CRA?

Ähnlich wie bei anderen EU-Produktvorschriften müssen Hersteller die CE-Kennzeichnung an konformen PDEs anbringen, um anzuzeigen, dass sie die wesentlichen Anforderungen des CRA erfüllen, bevor sie diese auf dem EU-Markt bereitstellen. Dies erfordert eine erfolgreiche Konformitätsbewertung.

Was ist eine SBOM und warum ist sie erforderlich?

Eine Software-Stückliste (SBOM) ist ein formeller Datensatz, der Details und Lieferkettenbeziehungen verschiedener Komponenten enthält, die beim Erstellen von Software verwendet werden. Die CRA verlangt von Herstellern, eine SBOM für ihre Produkte zu erstellen und zu pflegen, um die Transparenz zu verbessern und das Schwachstellenmanagement in der gesamten Lieferkette zu erleichtern.

Wie lange müssen Hersteller Sicherheitsupdates gemäß der CRA bereitstellen?

Hersteller müssen Sicherheitsupdates für die erwartete Lebensdauer des Produkts oder für einen Mindestzeitraum von fünf Jahren ab dem Inverkehrbringen des Produkts bereitstellen, je nachdem, welcher Zeitraum kürzer ist. Die erwartete Lebensdauer muss während der Entwicklung berücksichtigt werden. Updates müssen kostenlos und zeitnah („unverzüglich“) erfolgen.

Wie verhält sich der CRA zu NIS2 oder der DSGVO?

• NIS2: Konzentriert sich auf die Sicherheit von Netzwerken und Systemen, die von wesentlichen/wichtigen Dienstleistern genutzt werden. CRA konzentriert sich auf die Sicherheit der Produkte selbst, die von diesen Anbietern oder Verbrauchern genutzt werden könnten.

GDPR: Konzentriert sich auf den Schutz personenbezogener Daten. CRA konzentriert sich auf die Cybersicherheit von Produkten. Ein sicheres Produkt unter CRA hilft, die von ihm verarbeiteten personenbezogenen Daten zu schützen (unterstützt GDPR), aber der Geltungsbereich von CRA ist breiter als nur personenbezogene Daten. Sie sind komplementäre Bestandteile der digitalen Sicherheitsstrategie der EU.