zur Übersicht

Cyber Resilience Act: Was Unternehmen jetzt wissen und tun müssen

Der Cyber Resilience Act (CRA), offiziell Verordnung (EU) 2024/2847, ist die erste EU-Verordnung, die ein einheitliches Mindestniveau an Cybersicherheit für alle „Produkte mit digitalen Elementen“ schafft, die im EU-Binnenmarkt bereitgestellt werden. Ziel ist es, die wachsende Zahl von Sicherheitslücken und Cyberangriffen nicht nur durch organisatorische Maßnahmen (Firewalls, ISMS etc.), sondern bereits durch sichere Produkte zu adressieren – also Security by Design und über den gesamten Lebenszyklus hinweg.

Der CRA ist unmittelbar geltendes EU-Recht, eine nationale Umsetzung ist – anders als bei NIS‑2 – nicht erforderlich.

Hier zeigen wir Ihnen, ob Ihr Unternehmen bzw. Ihr Produkt voraussichtlich betroffen ist und wie Sie die Compliance mit dem neuen Gesetz pragmatisch angehen sollten.

Anwendungsbereich: Welche Produkte betroffen sind

Der CRA gilt für alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht oder bereitgestellt werden.

  • Erfasst sind insbesondere:
    • Vernetzte Hardware: Smartphones, Laptops, Smart-Home-Produkte, Smartwatches, vernetztes Spielzeug, Firewalls, Smart-Meter-Gateways, Mikroprozessoren.
    • Softwareprodukte: B2B‑Software, Buchhaltungssoftware, mobile Apps, Computerspiele.
  • Ausnahmen gelten u. a. für:
    • Sektoren mit Spezialregelungen (z. B. Medizinprodukte, Fahrzeuge, zivile Luftfahrt, Schiffsausrüstung); diese unterfallen vorrangig ihrem eigenen Produktrecht.
    • Nicht-kommerzielle Open-Source-Software (OSS) ist ausgenommen.

Je nach Risiko werden Produkte als Standard, „wichtig“ oder „kritisch“ eingestuft; die Kategorie wirkt sich auf das Konformitätsbewertungsverfahren aus (Selbstbewertung vs. Einbindung einer notifizierten Stelle).

Zentrale Anforderungen des CRA

Grundanforderungen an Cybersicherheit

Ziel des CRA ist es, zu gewährleisten, dass Produkte mit digitalen Elementen ein Mindestmaß an Cybersicherheit erfüllen, bevor sie in Verkehr gebracht werden. Verantwortlich dafür sind vor allem die Hersteller dieser Produkte.

Konkret verlangt der CRA das Folgende:

  • Security by Design & by Default
    • Cybersicherheit muss bereits im Produktdesign und in der Architektur berücksichtigt werden.
    • Sichere Voreinstellungen, Schutz vor Manipulation, angemessene Zugriffskontrollen, sichere Update-Mechanismen.
  • Sicherer Entwicklungsprozess
    • Einführung eines „Secure Software Development Lifecycle“ mit Bedrohungsmodellierung, Code-Analyse, Tests, Review von Sicherheitsanforderungen.
  • Risikomanagement & Dokumentation
    • Technische Dokumentation inkl. Risikoanalyse, Sicherheitsarchitektur, Update-Strategie und Schwachstellenmanagement.
    • Diese Dokumentation muss Behörden auf Anfrage zur Verfügung gestellt werden.
  • Lebenszyklus-Sicherheit
    • Pflicht zur Behandlung von Schwachstellen und Bereitstellung von Sicherheitsupdates während eines definierten Supportzeitraums (in der Praxis häufig mind. fünf Jahre; das BSI nennt fünf Jahre „in der Regel“).

Schwachstellen- und Incident-Meldepflichten

Hersteller müssen außerdem:

  • Ein systematisches Schwachstellenmanagement etablieren; eingehende Hinweise über Schwachstellen sind strukturiert zu bewerten und zu bearbeiten.
  • Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Sicherheit ihrer Produkte an eine zentrale Plattform der ENISA melden:
    • Erste Meldung (Frühwarnung) innerhalb von 24 Stunden,
    • ergänzende Informationen innerhalb von 72 Stunden,
    • Abschlussbericht spätestens 14 Tage nach Sicherheitsupdate/Workaround (bei Schwachstellen) bzw. einen Monat nach der Erstmeldung (bei Vorfällen).

ENISA entwickelt hierfür die Single Reporting Platform (SRP) als zentrale Meldeplattform. Hiermit gibt es also eine weitere Meldepflicht mit eigenen Fristen. Die Koordination mit bestehenden Pflichten, z. B. nach Art. 33 DSGVO, wird herausfordernd sein. Unternehmen müssen hier dringend prüfen, wie integrierte Prozesse aussehen können, die alle relevanten Normen berücksichtigen.

Transparenz gegenüber Nutzern

Hersteller müssen u.a.:

  • den Supportzeitraum (Dauer der Sicherheitsupdates) klar angeben und nachvollziehbar herleiten,
  • die Nutzer über relevante Schwachstellen, Patches und sichere Konfigurationen informieren,
  • verständliche Benutzerinformationen zur sicheren Nutzung bereitstellen.

Konformitätsbewertung und CE-Kennzeichnung

  • Der CRA baut auf dem bekannten System der CE‑Kennzeichnung auf.
  • Hersteller müssen eine Konformitätsbewertung durchführen:
    • bei Standardprodukten in vielen Fällen per Selbstbewertung,
    • bei „wichtigen“ und „kritischen“ Produkten ist häufig eine notifizierte Stelle (Konformitätsbewertungsstelle, KBS) einzubeziehen.
  • Ohne CRA‑Konformität ist eine CE‑Kennzeichnung und damit das Inverkehrbringen in der EU nicht zulässig – bis hin zu Verkaufsverboten und Rückrufen.

Zeitplan: Bis wann müssen Unternehmen was erledigt haben?

Die Verordnung wurde am 20. November 2024 im EU-Amtsblatt veröffentlicht und ist 20 Tage später in Kraft getreten (11. Dezember 2024). Es gelten gestaffelte Übergangsfristen:

  1. Vorbereitung der Markt- und Konformitätsinfrastruktur
    • Ab 11. Juni 2026: Mitgliedstaaten benennen Konformitätsbewertungsstellen und etablieren die Verfahren für deren Bewertung und Notifizierung.
    • Bis 11. Dezember 2026: Es muss eine „ausreichende Zahl“ notifizierter Stellen verfügbar sein, um Engpässe beim Marktzugang zu vermeiden.
  2. Beginn der Meldepflichten
    • September 2026: Hersteller unterliegen der Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an ENISA über die zentrale Plattform.
  3. Ende der Übergangsfrist / Volle Geltung
    • Ab 11. Dezember 2027: Alle CRA‑Anforderungen gelten vollumfänglich; neu in Verkehr gebrachte Produkte mit digitalen Elementen müssen die CRA‑Vorgaben vollständig erfüllen.

Was Unternehmen jetzt konkret tun müssen

Praktisch bedeutet das: Unternehmen haben bis Ende 2027 Zeit, ihre Produktentwicklung, Prozesse und Dokumentation CRA‑konform aufzustellen – der Zeitraum 2026–2027 wird wegen der Abhängigkeit von notifizierten Stellen jedoch eng. Daher ist bereits jetzt Aktivität gefragt. Betroffene Unternehmen sollten daher die folgenden Punkte so bald wie möglich angehen.

Betroffenheit klären und Produktportfolio analysieren

Erster Schritt ist es, zu klären, ob und wie weit die eigenen Produkte tatsächlich vom CRA betroffen sind. Es ist also eine aktuelle Übersicht mit bestimmten Basisinformationen zusammenzustellen.

  1. Produkte identifizieren, die „digitale Elemente“ enthalten:
    • Eigene Hardwareprodukte mit Firmware/Software,
    • reine Softwareprodukte (On-Prem, Cloud, Apps),
    • eingebettete Komponenten in Kundenprodukten (OEM, White-Label).
  2. Abgleich mit Ausnahmen:
    • Sektorspezialrecht (z.B. Medizinprodukte, Automotive),
    • nicht-kommerzielle Open-Source-Software,
    • reine Ersatzteile für Bestandsprodukte können unter Umständen anders behandelt werden.
  3. Risikoklasse bestimmen:
    • Zuordnung als Standard-, „wichtiges“ oder „kritisches“ Produkt gem. CRA-Anhängen (z.B. Passwortmanager, Firewalls, Smartcards, Smart-Meter-Gateways i.d.R. „wichtig“/„kritisch“).

Gap-Analyse: Wo fehlen heute Sicherheits- und Compliance-Bausteine?

Im nächsten Schritt wird geprüft, welche konkreten Anforderungen ein Produkt erfüllen muss, was davon bereits erfüllt ist und wo es noch Lücken gibt.

  • Secure Development Lifecycle:
    • Existiert ein dokumentierter, gelebter Secure-SDLC?
    • Bedrohungsmodellierung, Code-Reviews, Security-Tests, Freigabeprozesse?
  • Schwachstellenmanagement:
    • Gibt es ein geregeltes Verfahren für eingehende Schwachstellenmeldungen (inkl. Reporting an ENISA)?
    • Rollen, SLAs, Kommunikationsprozesse mit Kunden?
  • Dokumentation und Risikobewertung:
    • Vollständige technische Dokumentation inkl. Sicherheitsarchitektur, Risikoanalyse, Updatekonzept?
    • Nachweise zur Konformität mit relevanten Normen (künftig harmonisierte CRA‑Normen)?
  • Vertrags- und Lieferkettenmanagement:
    • Entsprechende Security-Klauseln gegenüber Zulieferern/Software-Drittanbietern?
    • Klare Verantwortlichkeiten beim Inverkehrbringen (Hersteller/Importeur/Händler)?

Prozesse und Governance auf CRA trimmen

Bestehende Prozesse müssen systematisch erfasst, analysiert und ggf. angepasst werden. Dies betrifft mit Blick auf den Cyber Resilience Act vor allem:

  1. Secure-by-Design-Prozesse verankern
    • Sicherheitsanforderungen bereits in der Produktplanung definieren,
    • verbindliche Sicherheits-Checkpoints in der Entwicklung,
    • Integration in bestehende Qualitäts- und Produktfreigabeprozesse.
  2. Schwachstellenmanagement professionalisieren
    • Interne Richtlinie und Prozess (inkl. Eingangskanal für Meldungen),
    • Schnittstelle zur ENISA Single Reporting Platform,
    • definierte Fristen und Verantwortliche für Bewertung, Patching und Reporting.
  3. Supportzeitraum definieren und absichern
    • Methodik zur Herleitung eines plausiblen Supportzeitraums (Nutzungsdauer, Kritikalität, Lieferkette, Updatefähigkeit), wie sie in der Fachliteratur betont wird,
    • Ressourcen- und Budgetplanung für den Lebenszyklus-Support.
  4. Konformitätsbewertung vorbereiten
    • Abhängig von der Risikoklasse: interne Checklisten vs. frühzeitige Einbindung einer notifizierten Stelle,
    • Aufbau eines internen „CRA Technical File“ analog zu klassischen CE‑Dossiers.
  5. Schnittstelle zu anderen Regimen (NIS‑2, Data Act, KI‑VO, Produktsicherheitsrecht)
    • Harmonisierung mit bereits bestehenden oder kommenden Pflichten (z.B. NIS‑2-Risikomanagement, GPSR/Produktsicherheitsverordnung, Maschinenverordnung, KI-VO).

Wie Two Towers Unternehmen bei der CRA-Umsetzung unterstützt

Als spezialisierter externer Dienstleister können wir Unternehmen entlang des gesamten CRA-Compliance-Zyklus unterstützen. Dies insbesondere dort, wo Produktrecht, Cybersicherheit und Datenschutz zusammenlaufen.

Typische Unterstützungsleistungen:

  1. CRA Readiness-Check
    • Systematische Analyse des Produktportfolios und der Rollen (Hersteller/Importeur/Händler),
    • Einstufung der Produkte (Standard, wichtig, kritisch),
    • Gap-Analyse gegenüber den CRA-Anforderungen und bestehenden Prozessen (z.B. ISMS, NIS‑2, ISO 27001/62443).
  2. Aufbau und Optimierung von Prozessen
    • Konzeption und Implementierung eines Secure Software Development Lifecycle, abgestimmt auf Größe und Reifegrad des Unternehmens,
    • Design eines Schwachstellen- und Incident-Managementprozesses inkl. ENISA-Meldestrecke und Schnittstellen zur internen IT-Security,
    • Etablierung eines Governance-Rahmens (Rollen, Verantwortlichkeiten, Reporting an Geschäftsleitung).
  3. Dokumentation und Konformitätsbewertung
    • Unterstützung beim Aufbau der technischen Dokumentation und Risikoanalysen,
    • Vorbereitung auf Audits/Konformitätsbewertungen durch notifizierte Stellen,
    • Harmonisierung der CRA-Dokumentation mit bestehenden CE‑Dossiers und Produktakten, um Doppelaufwand zu vermeiden.
  4. Vertrags- und Lieferketten-Check
    • Prüfung und Anpassung von Lieferanten- und Kundenverträgen (Security-Klauseln, Updatepflichten, Haftung, Rollenverteilung beim Inverkehrbringen),
    • Definition von Mindestanforderungen an Zulieferer und OEM-Partner im Lichte des CRA.
  5. Schulungen und Awareness
    • Zielgruppenspezifische Trainings für Entwicklung, Produktmanagement, Einkauf, Vertrieb und Management zu CRA-Anforderungen,
    • Einbettung von CRA- und Security-Awareness in bestehende Compliance- und Datenschutzstrukturen.
  6. Kontinuierliche Begleitung
    • Monitoring der weiteren Ausgestaltung durch harmonisierte Normen und Leitlinien (z.B. BSI-TR 03183),
    • regelmäßige Updates zu regulatorischen Entwicklungen und Best Practices,
    • punktuelle Unterstützung bei konkreten Vorfällen (z.B. bei der ersten Meldung über die ENISA-Plattform).

Fazit

Der Cyber Resilience Act ist kein „reines IT-Thema“, sondern ein Produkt- und Haftungsthema mit erheblicher strategischer Relevanz. Gefordert ist hier nicht zuletzt ein effektives Projekt-Management.

  • Ohne CRA‑Konformität drohen Marktverwehrung, Rückrufe und Haftungsrisiken.
  • Die Übergangsfristen wirken lang, der operative Umsetzungszeitraum – insbesondere mit Blick auf notifizierte Stellen und Normen – ist jedoch knapp.

Unternehmen, die Produkte mit digitalen Elementen herstellen, importieren oder vertreiben, sollten die Zeit bis 2027 nutzen, um ihre Produktentwicklung, Dokumentation und Governance konsequent auf Security by Design auszurichten.

Wir unterstützen Sie gerne bei dieser Aufgabe. Kontaktieren Sie uns unverbindlich und abonnieren Sie unseren Newsletter, um immer auf dem aktuellen Stand in Sachen Compliance zu bleiben.