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 Sicherheit durch Design, Patches, SBOMs und die Offenlegung von Schwachstellen über den gesamten Lebenszyklus eines Produkts.

Beginnt im Dezember 2027. Das Ziel verfehlt? Rechnen Sie mit Geldbußen von über 15 Mio. € oder Marktverboten.

Zusammenfassung der EU Cyber Resilience Act (CRA) Scorecard:

• Entwickelnde Aufwand: Hoch (Erfordert die Einbettung der Sicherheit in den gesamten Produktlebenszyklus: sicherer Entwurf, sichere Kodierung, strenge Tests, Implementierung von Verfahren zur Behandlung von Schwachstellen, Bereitstellung sicherer Updates, Pflege von SBOMs).
• Tooling-Kosten: Mäßig bis hoch (Erfordert sichere SDLC-Tools - SAST/SCA/DAST, SBOM-Generierungstools, Plattformen für das Schwachstellenmanagement, potenziell sichere Update-Infrastruktur - OTA-Plattformen).
• Auswirkungen auf den Markt: Sehr hoch (verpflichtend für fast alle in der EU verkauften Hardware-/Softwareprodukte; setzt eine neue globale Basis für die Erwartungen an die Cybersicherheit von Produkten).
• Flexibel: Mäßig (Definiert grundlegende Anforderungen, erlaubt aber unterschiedliche Wege der Konformitätsbewertung auf der Grundlage der Produktrisikoklassifizierung).
• Intensität der Prüfung: Mäßig bis hoch (Erfordert Konformitätsbewertungen - Selbstbewertung für Standardprodukte, Bewertung durch Dritte für kritische Produkte; Marktaufsichtsbehörden werden dies durchsetzen).

Was ist der EU Cyber Resilience Act (CRA)?

Der EU Cyber Resilience Act (CRA) ist eine Verordnung zur Festlegung harmonisierter Cybersicherheitsanforderungen für "Produkte mit digitalen Elementen" (PDEs), die auf dem Markt der Europäischen Union angeboten werden. Sie zielt darauf ab, das weit verbreitete Problem unsicherer Hardware- und Softwareprodukte und das Fehlen rechtzeitiger Sicherheitsupdates zu bekämpfen.

Die CRA gilt im Großen und Ganzen für fast jedes Software- oder Hardware-Produkt, das direkt oder indirekt mit einem anderen Gerät oder Netzwerk verbunden werden kann, mit einigen Ausnahmen (z. B. medizinische Geräte, Luftfahrt, Autos, die bereits unter spezielle Rechtsvorschriften fallen, SaaS, sofern nicht kritisch). Dazu gehören IoT-Geräte für Verbraucher, Netzwerkausrüstung, industrielle Steuerungskomponenten, Betriebssysteme, mobile Apps, Desktop-Software und mehr.

Hauptpfeiler der Ratingagentur:

1. Grundlegende Anforderungen an die Cybersicherheit (Anhang I): Die Hersteller müssen sicherstellen, dass PDEs während ihres gesamten Lebenszyklus bestimmte Sicherheitsziele erfüllen. Dies umfasst:
   
   • Sicherheit durch Design und Standard: Produkte müssen so konzipiert, entwickelt und produziert werden, dass sie ein angemessenes Maß an Cybersicherheit gewährleisten. Sie müssen mit einer sicheren Standardkonfiguration ausgeliefert werden.
   • Schwachstellen-Management: Die Hersteller müssen über Verfahren verfügen, um Schwachstellen während der gesamten erwarteten Lebensdauer des Produkts oder mindestens fünf Jahre lang zu erkennen und zu beheben, einschließlich der unverzüglichen und kostenlosen Bereitstellung von Sicherheitsupdates.
   • Schutz der Daten: Schutz der Vertraulichkeit, Integrität und Verfügbarkeit der von dem Produkt verarbeiteten Daten.
   • Zugangskontrolle: Verhinderung von unberechtigtem Zugriff.
   • Widerstandsfähigkeit: Die Fähigkeit, Vorfälle zu überstehen und sich von ihnen zu erholen.
   • Minimierung der Angriffsfläche: Begrenzung der Angriffsfläche und Milderung der Auswirkungen von Zwischenfällen.
2. Verpflichtungen für Wirtschaftsteilnehmer:
   
   • Hersteller: Sie tragen die Hauptverantwortung für die compliance - sicheres Design, Konformitätsbewertung, technische Dokumentation (einschließlich SBOM), Umgang mit Schwachstellen, Meldung von Vorfällen/Schwachstellen, Bereitstellung von Aktualisierungen und klaren Anweisungen. Dies gilt auch dann, wenn sie ihren Sitz außerhalb der EU haben.
   • Importeure/Vertriebshändler: Sie sind verpflichtet, die compliance durch den Hersteller zu überprüfen (z. B. CE-Kennzeichnung, Dokumentation), bevor sie die Produkte in Verkehr bringen.
3. Umgang mit Schwachstellen und Berichterstattung: Die Hersteller müssen Verfahren für einen wirksamen Umgang mit Sicherheitslücken einrichten und aktiv ausgenutzte Sicherheitslücken innerhalb von 24 Stunden nach Bekanntwerden an die ENISA (EU-Agentur für Cybersicherheit) melden. Außerdem müssen sie die Nutzer über behobene Sicherheitslücken und verfügbare Updates informieren.
4. Konformitätsbewertung und CE-Kennzeichnung: PDEs müssen ein Konformitätsbewertungsverfahren durchlaufen (von der Selbstbewertung des Herstellers bis zur Zertifizierung durch einen Dritten, je nach Kritikalität des Produkts), um die compliance nachzuweisen, bevor sie eine CE-Kennzeichnung erhalten und auf den EU-Markt gebracht werden können.
5. Marktüberwachung: Benennt nationale Marktüberwachungsbehörden, die die CRA durchsetzen,compliance untersuchen und Sanktionen verhängen oder die Rücknahme bzw. den Rückruf von Produkten verlangen.

Die CRA ist Ende 2024 in Kraft getreten, wobei die meisten Verpflichtungen 36 Monate später (etwa im Dezember 2027) in Kraft treten, während die Meldepflichten der Hersteller schon früher (etwa im September 2026) gelten.

Warum ist sie wichtig?

Die CRA ist ein wegweisender Rechtsakt mit erheblichen Auswirkungen:

• Verlagerung der Verantwortung: Die Verantwortung für die Produktsicherheit wird direkt auf die Hersteller verlagert, anstatt sie in erster Linie den Endnutzern zu überlassen.
• Erhöht die Basissicherheit: Festlegung verbindlicher Mindeststandards für die Cybersicherheit einer Vielzahl von in der EU verkauften vernetzten Produkten.
• Sicherheit der Software-Lieferkette: Behebung von Schwachstellen, die von Komponenten Dritter ausgehen, durch Anforderungen wie SBOMs und Schwachstellenmanagement über den gesamten Lebenszyklus.
• Schutz von Verbrauchern und Unternehmen: Ziel ist es, die Zahl der unsicheren Produkte, die von Angreifern ausgenutzt werden, zu verringern und die Nutzer vor Datenschutzverletzungen, finanziellen Verlusten und Sicherheitsrisiken zu schützen.
• Harmonisierung der Anforderungen: Es wird ein einheitliches Regelwerk für die gesamte EU geschaffen, das die potenziell fragmentierten nationalen Ansätze zur Cybersicherheit von Produkten ersetzt.
• Globale Auswirkungen: In Anbetracht der Größe des EU-Marktes setzt die Ratingagentur einen globalen Standard, der Hersteller weltweit beeinflusst, die ihre Produkte in Europa verkaufen wollen.
• Ergänzt andere Verordnungen: Arbeitet zusammen mit NIS2 (Sicherung kritischer Dienste), GDPR (Schutz personenbezogener Daten) und DORA (finanzielle Widerstandsfähigkeit), um eine umfassendere EU-Cybersicherheitslandschaft zu schaffen.

Für Hersteller von Software und angeschlossener Hardware wird die compliance CRA zu einer grundlegenden Voraussetzung für den Marktzugang in der EU.

Was und wie umsetzen (technisch und politisch)

Die Umsetzung der Ratingagentur erfordert die Einbeziehung ihrer grundlegenden Anforderungen (Anhang I) in den gesamten Produktlebenszyklus:

1. Sicheres Design und sichere Entwicklung (Security by Design):
   
   • Modellierung von Bedrohungen: Identifizieren Sie potenzielle Bedrohungen und entwickeln Sie von Anfang an Sicherheitskontrollen.
   • Sichere Kodierungspraktiken: Schulung von Entwicklern und Durchsetzung sicherer Codierungsstandards (z. B. OWASP ASVS, CERT-Codierungsstandards). Verwenden Sie SAST-Tools.
   • Angriffsfläche minimieren: Beschränken Sie Funktionalitäten, offene Ports und Berechtigungen auf das notwendige Minimum.
   • Sichere Standardeinstellungen: Stellen Sie sicher, dass Produkte mit sicheren Konfigurationen ausgeliefert werden (z. B. keine Standardkennwörter, deaktivierte unnötige Dienste). Implementieren Sie eine sichere Rücksetzfunktion.
   • Schutz der Daten: Verschlüsselung von Daten im Ruhezustand und bei der Übertragung, wo dies angebracht ist. Schutz der Datenintegrität.
   • Zugangskontrolle: Implementierung robuster Authentifizierungs- und Autorisierungsmechanismen.
2. Schwachstellen-Management:
   
   • Komponentenanalyse (SBOM): Erstellen und pflegen Sie eine genaue Software Bill of Materials (SBOM), die alle Komponenten (einschließlich Open-Source-Bibliotheken) identifiziert. Verwendung von SCA-Tools, um bekannte Schwachstellen in Abhängigkeiten zu finden.
   • Sicherheitstests: Implementierung regelmäßiger Schwachstellen-Scans (SAST, DAST, SCA, IaC), Fuzz-Tests und Penetrationstests während der Entwicklung und nach der Veröffentlichung.
   • Prozess zur Behandlung von Schwachstellen: Legen Sie klare Verfahren für den Erhalt von Schwachstellenmeldungen (intern/extern), deren Analyse, die Entwicklung von Patches und die unverzügliche Verteilung von Updates fest.
   • Patches/Aktualisierungen: Kostenlose Bereitstellung von Sicherheitsupdates für den erwarteten Lebenszyklus des Produkts (mindestens 5 Jahre). Implementierung eines sicheren Aktualisierungsmechanismus (z. B. sichere OTA-Updates mit Integritätsprüfungen).
3. Transparenz und Dokumentation:
   
   • Technische Dokumentation: Führen Sie eine detaillierte technische Dokumentation, die die compliance der grundlegenden Anforderungen nachweist. Einschließlich der SBOM.
   • Benutzerinformationen: Geben Sie den Anwendern klare Anweisungen zur sicheren Verwendung, Konfiguration, zu Updates und zur Supportdauer des Produkts.
   • Offenlegung von Schwachstellen: Festlegung einer Richtlinie und einer Kontaktstelle für die Entgegennahme von Schwachstellenmeldungen; öffentliche Bekanntgabe behobener Schwachstellen.
4. Konformitätsbewertung:
   
   • Risikoklassifizierung: Bestimmen Sie, ob das Produkt in die Kategorien Standard, "wichtig" (Klasse I) oder "kritisch" (Klasse II) gemäß Anhang III fällt.
   • Bewertungsverfahren: Befolgen Sie das vorgeschriebene Verfahren (z. B. interne Kontrolle/Selbsteinschätzung für Standards, Bewertung/Zertifizierung durch Dritte für wichtige/kritische Klassen).
   • Erklärung und CE-Kennzeichnung: Stellen Sie eine EU-Konformitätserklärung aus und bringen Sie die CE-Kennzeichnung an, sobald die compliance nachgewiesen ist.
5. Berichtspflichten:
   
   • Aktiv ausgenutzte Schwachstellen: Meldung an ENISA innerhalb von 24 Stunden nach Bekanntwerden.
   • Signifikante Vorfälle: Meldung von Vorfällen mit Auswirkungen auf die Produktsicherheit an die ENISA.

Die Umsetzung erfordert die Einbettung der Sicherheit in die Entwicklungskultur, die Prozesse und die Werkzeuge vom Entwurf bis zur Wartung.

Häufig zu vermeidende Fehler

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

1. Unterschätzung des Anwendungsbereichs: Der Glaube, dass die CRA nur für komplexe IoT-Geräte gilt und nicht für Standardsoftware oder einfachere Hardware mit digitalen Elementen. Der Anwendungsbereich ist sehr weit gefasst.
2. Verzögertes Handeln: Abwarten, bis die Frist 2027 näher rückt, und Unterschätzung der erheblichen Änderungen, die bei Entwurf, Entwicklung, Tests, Schwachstellenmanagement und Aktualisierungsprozessen erforderlich sind.
3. Sicherheit als nachträgliche Maßnahme behandeln: Das Versäumnis, die Sicherheit bereits in der Entwurfsphase zu integrieren ("Security by Design"), und der Versuch, sie nachträglich einzubauen, was weniger effektiv und teurer ist.
4. Unzureichendes Schwachstellenmanagement: Fehlen von robusten Prozessen oder Werkzeugen (SCA, SAST, DAST), um Schwachstellen zu erkennen, oder keine rechtzeitige und kostenlose Bereitstellung von Sicherheitsupdates für den erforderlichen Lebenszyklus.
5. SBOM Ungenauigkeit/Vernachlässigung: Das Versäumnis, eine vollständige SBOM zu erstellen oder sie bei Änderungen von Komponenten auf dem neuesten Stand zu halten, behindert das Schwachstellenmanagement.
6. Ignorieren sicherer Aktualisierungsmechanismen: Fehlen einer zuverlässigen und sicheren Methode (z. B. einer robusten OTA-Plattform), um Updates "ohne Verzögerung" zu liefern. Manuelle Updates werden wahrscheinlich nicht ausreichen.
7. Unzureichende Dokumentation: Das Versäumnis, die für die Marktüberwachung erforderlichen technischen Unterlagen, SBOM und Konformitätsbewertungsnachweise zu führen.
8. Konzentration nur auf die Entwicklung: Vernachlässigung der laufenden Anforderungen nach der Markteinführung für den Umgang mit Schwachstellen und Aktualisierungen während des gesamten Produktlebenszyklus.

Was Prüfer/Behörden fragen könntenEntwickelnde Focus)

Konformitätsbewertungsstellen (für kritische Produkte) oder Marktaufsichtsbehörden könnten Fragen zu den Anforderungen an Ratingagenturen stellen, die sich auf die Entwicklung auswirken:

• (Anhang I) Sicherer Entwurf: "Wie wurde die Sicherheit während der Entwurfsphase berücksichtigt? Können Sie Bedrohungsmodelle oder Dokumente zur Sicherheitsarchitektur vorlegen?"
• (Anhang I) Schwachstellenmanagement: "Welche Werkzeuge und Prozesse werden verwendet, um Schwachstellen in Erstanbieter-Code und Komponenten von Drittanbietern (SAST, SCA) während der Entwicklung zu identifizieren?"
• (Anhang I) Sichere Kodierung: "Welche Standards für sichere Kodierung werden befolgt? Wie wird die compliance durchgesetzt (z. B. Linters, Code-Reviews, Schulungen)?"
• (Anhang I) Sicherheitstests: "Nachweis der Sicherheitstests (z.B. Penetrationstests, Fuzz-Tests), die vor der Freigabe durchgeführt wurden."
• (Anhang I) Sichere Updates: "Beschreiben Sie den Mechanismus für die Bereitstellung von Sicherheitsaktualisierungen. Wie wird die Integrität und Authentizität der Aktualisierungen sichergestellt?"
• (Art. 10) SBOM: "Geben Sie die Software-Stückliste (SBOM) für diese Produktversion an."
• (Art. 10) Behandlung von Schwachstellen: "Beschreiben Sie den Prozess zur Behandlung einer gemeldeten Schwachstelle, von der Aufnahme bis zur Veröffentlichung eines Patches."
• (Anhang I) Sichere Standardkonfiguration: "Wie gewährleistet das Produkt eine sichere Standardkonfiguration?"

Sie benötigen Nachweise aus den Entwurfs-, Entwicklungs-, Test- und Wartungsphasen, einschließlich Dokumentation, Tool-Berichte, Prozessbeschreibungen und möglicherweise Zugang zu Code-Reviews.

Quick Wins für Entwicklungsteams

Auch wenn die vollständige compliance CRA-Richtlinien einige Zeit in Anspruch nimmt, können Entwicklerteams bereits mit den ersten Vorbereitungen beginnen:

1. SBOM-Generierung implementieren: Integrieren Sie Tools zur automatischen Generierung einer SBOM als Teil des Build-Prozesses.
2. Integrieren Sie SCA und SAST: Stellen Sie sicher, dass Software Composition Analysis und Static Application Security Testing zuverlässig in der CI/CD-Pipeline laufen.
3. Führen Sie eine grundlegende Bedrohungsmodellierung ein: Beginnen Sie damit, potenzielle Bedrohungen während der Entwurfssitzungen für neue Funktionen oder Produkte zu diskutieren.
4. Überprüfen Sie die Standardkonfigurationen: Prüfen Sie aktiv die Standardeinstellungen für Produkte vor der Auslieferung und sichern Sie sie. Entfernen Sie Standard-Anmeldeinformationen.
5. Dokumentieren Sie den Aktualisierungsprozess: Dokumentieren Sie den aktuellen Prozess für die Erstellung und Freigabe von Software-Updates klar und deutlich, auch wenn er anfangs manuell ist.
6. Einrichten einer Schwachstellen-Intake: Schaffen Sie eine einfache, dokumentierte Möglichkeit für interne Teams oder externe Forscher, potenzielle Schwachstellen zu melden (z. B. eine spezielle E-Mail-Adresse oder ein Formular).

Ignorieren Sie dies und... (Folgen der Compliance)

Die compliance der Ratingagentur kann zu schwerwiegenden Konsequenzen führen, die von den nationalen Marktaufsichtsbehörden durchgesetzt werden:

• Hohe Geldstrafen: Beicompliance der grundlegenden Anforderungen können Bußgelder in Höhe von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Gesamtjahresumsatzes des Herstellers im vorangegangenen Geschäftsjahr verhängt werden, je nachdem, welcher Betrag höher ist. Bei geringeren Verstößen werden Geldbußen von bis zu 10 Mio. EUR/2 % oder 5 Mio. EUR/1 % verhängt.
• Marktrücknahme/Rückruf: Die Behörden können verlangen, dass nicht konforme Produkte vom EU-Markt genommen oder von den Endverbrauchern zurückgerufen werden.
• Verkaufsverbot/Einschränkung: Das Inverkehrbringen von nicht konformen Produkten kann verboten oder eingeschränkt werden.
• Schädigung des Rufs: Die öffentliche Bekanntgabe voncompliance, Rückrufen oder erheblichen Schwachstellen schadet dem Vertrauen in die Marke und der Marktwahrnehmung.
• Verlust des Marktzugangs: Werden die Anforderungen der Ratingagenturen nicht erfüllt, so wird der Zugang zum gesamten EU-Binnenmarkt für die betroffenen Produkte blockiert.

FAQ

Welche Produkte werden von der CRA erfasst?

"Produkte mit digitalen Elementen" (PDEs), deren beabsichtigte oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk beinhaltet. Dazu gehört die meiste Software (eigenständig, mobil, eingebettet) und Hardware mit Konnektivität (IoT-Geräte, Router, intelligente Geräte, Industriekomponenten usw.). Es gibt bestimmte Ausnahmen (z. B. medizinische Geräte, Autos, Luftfahrt, bestimmte SaaS).

Wann werden die Anforderungen der Ratingagenturen verbindlich?

Die meisten Verpflichtungen, einschließlich der Konformitätsbewertungen und der grundlegenden Anforderungen, gelten 36 Monate nach Inkrafttreten der Ratingagentur (ca. Dezember 2027). Die Meldepflicht des Herstellers für aktiv ausgenutzte Schwachstellen und Zwischenfälle gilt jedoch schon früher, nämlich 21 Monate nach Inkrafttreten (etwa im September 2026).

Gilt die CRA für freie und quelloffene Software (FOSS)?

Eigenständige FOSS, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, ist generell ausgeschlossen. FOSS, das in ein kommerzielles Produkt integriert ist, ist jedoch abgedeckt, und der Hersteller des Endprodukts ist verantwortlich. FOSS-Projekte mit formalen Strukturen (z. B. Stiftungen), die Unterstützung oder Versionen zu Geld machen, könnten ebenfalls unter einige CRA-Verpflichtungen fallen (über die Einzelheiten wird noch diskutiert).

Was bedeutet die CE-Kennzeichnung im Zusammenhang mit der Ratingagentur?

Ähnlich wie bei anderen EU-Produktvorschriften müssen Hersteller die CE-Kennzeichnung auf konformen PDEs anbringen, um anzuzeigen, dass sie die grundlegenden Anforderungen der Ratingagentur erfüllen, bevor sie sie auf den EU-Markt bringen. Voraussetzung dafür ist eine erfolgreiche Konformitätsbewertung.

Was ist eine SBOM und warum ist sie erforderlich?

Eine Software-Bill-of-Materials (SBOM) ist ein formaler Datensatz, der die Details und Lieferkettenbeziehungen der verschiedenen Komponenten enthält, die bei der Erstellung von Software verwendet werden. Die CRA verlangt von den Herstellern die Erstellung und Pflege einer SBOM für ihre Produkte, um die Transparenz zu verbessern und das Schwachstellenmanagement in der gesamten Lieferkette zu erleichtern.

Wie lange müssen die Hersteller im Rahmen der CRA Sicherheitsupdates bereitstellen?

Die Hersteller müssen Sicherheitsupdates für die erwartete Lebensdauer des Produkts oder für einen Zeitraum von mindestens fünf Jahren nach dem Inverkehrbringen des Produkts bereitstellen, je nachdem, welcher Zeitraum kürzer ist. Die erwartete Lebensdauer muss bei der Entwicklung berücksichtigt werden. Die Aktualisierungen müssen kostenlos und rechtzeitig ("ohne Verzögerung") erfolgen.

Was hat die Ratingagentur mit NIS2 oder GDPR zu tun?

• NIS2: konzentriert sich auf die Sicherheit von Netzen und Systemen, die von wesentlichen/wichtigen Dienstleistern genutzt werden. Die 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 im Rahmen der CRA trägt zum Schutz der von ihm verarbeiteten personenbezogenen Daten bei (zur Unterstützung der DSGVO), aber der Anwendungsbereich der CRA ist breiter als nur personenbezogene Daten. Sie sind komplementäre Teile der digitalen Sicherheitsstrategie der EU.