← Zurück zu den Ratgebern
CRA · Verordnung (EU) 2024/2847 7 Min. Lesezeit

Cyberresilienz-Verordnung: der Zeitplan bis 2027

Der CRA gilt ab 11. Dezember 2027 für Produkte mit digitalen Elementen. Was er verlangt, seit wann gemeldet wird und wann die CE-Kennzeichnung kommt.


Die Cyberresilienz-Verordnung (CRA) — Verordnung (EU) 2024/2847 — ist die am meisten unterschätzte Verordnung der EU-Welle von 2024 bis 2027. Sie gilt für praktisch jedes Produkt mit digitalen Elementen, das in der EU verkauft wird, und bringt Pflichten zur Cybersicherheit von Produkten, vergleichbar mit denen, die für die Produktsicherheit seit Langem etabliert sind (CE-Kennzeichnung, Konformitätsbewertung, Beobachtung nach dem Inverkehrbringen). Vollständig gilt sie ab dem 11. Dezember 2027. Dieser Ratgeber zeigt den Zeitplan und den praktischen Anwendungsbereich.

Was der CRA erfasst — Produkte mit digitalen Elementen

Der CRA regelt Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Die Definition ist weit gefasst. Sie umfasst:

  • Softwareprodukte, die kommerziell vertrieben werden (Betriebssysteme, Anwendungen, Bibliotheken)
  • Hardwareprodukte mit Softwarekomponenten (IoT-Geräte, Smartphones, Netzwerkausrüstung, industrielle Steuerungssysteme)
  • Datenfernverarbeitungslösungen, bei denen die Datenverarbeitung fester Bestandteil des Produkts ist

Wenn Ihr Produkt Code ausführt, der in der EU landet, gilt der CRA wahrscheinlich dafür.

Was ausgenommen ist

Der CRA nimmt Produkte aus, für die bereits sektorspezifische Cybersicherheitsvorschriften gelten:

  • Medizinprodukte (geregelt durch MDR/IVDR — Verordnungen (EU) 2017/745 und (EU) 2017/746)
  • Zivilluftfahrt (Verordnung (EU) 2018/1139)
  • Kraftfahrzeuge (bereits durch UN R155/156 abgedeckt)
  • Schiffsausrüstung (Richtlinie 2014/90/EU)
  • Produkte, die unter besondere Ausnahmen für die nationale Sicherheit fallen
  • Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird (mit Feinheiten — siehe Erwägungsgründe 18 und 19; Verwalter quelloffener Software unterliegen nach Art. 24 einer eigenen, leichteren Regelung)

Die Ausnahme für Open Source ist enger, als viele glauben. Maintainer, die Open-Source-Projekte über Dienstleistungen oder Garantien monetarisieren, können trotzdem in den Anwendungsbereich fallen.

Der Zeitplan

Der CRA wurde am 20. November 2024 veröffentlicht und ist am 10. Dezember 2024 in Kraft getreten. Seine materiellen Bestimmungen gelten schrittweise:

DatumWas gilt
10. Dezember 2024Verordnung in Kraft
11. Juni 2026Bestimmungen über die Notifizierung von Konformitätsbewertungsstellen gelten
11. September 2026Meldepflichten der Hersteller für Sicherheitsvorfälle und Schwachstellen gelten (Art. 14)
11. Dezember 2027Vollständige Geltung — grundlegende Anforderungen (Anhang I), Konformitätsbewertung, CE-Kennzeichnung, alle Pflichten verbindlich

Den Septembertermin 2026 für die Meldepflichten übersehen die meisten Teams. Meldungen zu Schwachstellen und zu aktiver Ausnutzung sind durchsetzbar, lange bevor das vollständige System der Konformitätsbewertung greift.

Wenn Sie wissen wollen, wo Sie genau bei den Pflichten stehen, die seit September 2026 gelten, geht der kostenlose CRA-Readiness-Check dieselben Pflichten in zwölf Fragen durch und sagt Ihnen, welche davon Sie bereits erfüllen können.

Wie die grundlegenden Anforderungen aussehen (Anhang I)

Produkte mit digitalen Elementen müssen so konzipiert sein, dass sie:

Teil I — Sicherheitseigenschaften

  • ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden
  • mit einer sicheren Standardkonfiguration ausgeliefert werden
  • Schutz vor unbefugtem Zugriff gewährleisten
  • die Vertraulichkeit, Integrität und Verfügbarkeit von Daten schützen
  • nur Daten verarbeiten, die angemessen und von Bedeutung sind und sich auf das für die Zweckbestimmung erforderliche Maß beschränken
  • nach dem Grundsatz einer möglichst geringen Angriffsfläche konzipiert sind
  • nach dem Grundsatz konzipiert sind, die Auswirkungen von Sicherheitsvorfällen zu verringern
  • sicherheitsbezogene Informationen bereitstellen, indem sie einschlägige interne Vorgänge aufzeichnen und überwachen
  • den Nutzern die Möglichkeit bieten, alle Daten und Einstellungen sicher und einfach zu entfernen

Teil II — Behandlung von Schwachstellen

  • Schwachstellen und Komponenten des Produkts ermitteln und dokumentieren (Software-Stückliste, SBOM)
  • Schwachstellen unverzüglich behandeln und beheben
  • die Sicherheit wirksam und regelmäßig testen und überprüfen
  • nach Bereitstellung einer Sicherheitsaktualisierung Informationen über die behobene Schwachstelle teilen
  • eine Strategie für die koordinierte Offenlegung von Schwachstellen umsetzen
  • Mechanismen für die sichere Verbreitung von Aktualisierungen bereitstellen

Meldepflichten (Artikel 14)

Seit dem 11. September 2026 müssen Hersteller:

  • der ENISA und dem zuständigen CSIRT jede aktiv ausgenutzte Schwachstelle in ihrem Produkt melden, innerhalb von 24 Stunden, nachdem sie davon Kenntnis erlangt haben
  • jeden schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt, melden: innerhalb von 24 Stunden als Frühwarnung und innerhalb von 72 Stunden mit einer ausführlicheren Meldung
  • einen ausführlichen Abschlussbericht vorlegen: innerhalb von 14 Tagen bei Schwachstellen, innerhalb eines Monats bei Sicherheitsvorfällen

Das Muster aus 24 und 72 Stunden kennen Sie aus NIS-2 und der DSGVO. Wenn Sie bereits ein Programm zur Reaktion auf Sicherheitsvorfälle für NIS-2 oder die DSGVO betreiben, setzt der CRA darauf auf, statt es zu verdoppeln.

Produktkategorien — was die Konformitätsbewertung bestimmt

Hier liegen die meisten Zusammenfassungen falsch, deshalb lohnt sich Genauigkeit: Die Listen stehen in zwei getrennten Anhängen, nicht in einem.

Anhang III — wichtige Produkte mit digitalen Elementen, aufgeteilt in zwei Klassen:

  • Klasse I — Identitätsmanagement und Verwaltung privilegierter Zugänge, Browser, Passwort-Manager, Software für die Suche und Entfernung von Schadsoftware, VPNs, Netzmanagementsysteme, SIEM, Bootmanager, Public-Key-Infrastrukturen und Software für die Ausstellung digitaler Zertifikate, physische und virtuelle Netzschnittstellen, Betriebssysteme, Router sowie Mikroprozessoren oder Mikrocontroller mit sicherheitsrelevanten Funktionen.
  • Klasse II — Hypervisoren und Container-Runtime-Systeme, Firewalls sowie Intrusion-Detection- und Intrusion-Prevention-Systeme und manipulationssichere Mikroprozessoren und Mikrocontroller.

Anhang IV — kritische Produkte mit digitalen Elementen, eine eigene und viel kürzere Liste: Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways und andere Geräte für fortgeschrittene Sicherheitszwecke sowie Chipkarten oder ähnliche Geräte, einschließlich Sicherheitselementen.

Zwei Fallen sollten Sie kennen. Betriebssysteme gehören zu Klasse I, nicht zu Klasse II — sie stehen neben Browsern, nicht neben Hypervisoren. Und Mikroprozessoren und Mikrocontroller erscheinen in beiden Klassen: die mit einfachen sicherheitsrelevanten Funktionen in Klasse I, die manipulationssicheren in Klasse II.

Die meiste Software fällt unter keine der drei Listen. In dieser Standardkategorie steht das interne Kontrollverfahren als Weg zur Konformität offen.

CE-Kennzeichnung und Konformitätsbewertung

Wenn der CRA ab dem 11. Dezember 2027 vollständig gilt, braucht jedes Produkt mit digitalen Elementen, das auf dem EU-Markt in Verkehr gebracht wird:

  • eine CE-Kennzeichnung
  • eine unterzeichnete EU-Konformitätserklärung
  • technische Dokumentation nach Anhang VII
  • eine Konformitätsbewertung, die der Kategorie des Produkts entspricht

Das ist genau dieselbe Grundstruktur wie bei der CE-Kennzeichnung für die Produktsicherheit — nur um die Cybersicherheit erweitert. Wenn Ihr Entwicklungsteam die CE-Kennzeichnung für die Produktsicherheit gewohnt ist, wird Ihnen der CRA vertraut vorkommen. Wenn Sie ein SaaS-Team sind, das noch nie technische Dokumentation für eine CE-Kennzeichnung erstellt hat, rechnen Sie für das erste Produkt mit 2–3 Monaten Arbeit.

Geldbußen (Artikel 64)

Der CRA sieht in Art. 64 drei Stufen von Geldbußen vor:

  • Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen in Anhang I und Verstöße gegen die Pflichten aus Art. 13 und 14 (einschließlich der Meldepflichten): bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes
  • Andere Pflichten: bis zu 10 Mio. € oder 2 %
  • Falsche Angaben: bis zu 5 Mio. € oder 1 %

Was jetzt zu tun ist

Da der CRA ab Dezember 2027 vollständig gilt, die Meldepflichten aber bereits seit September 2026, sieht die vernünftige Rückwärtsplanung so aus:

  • Q3 2026 (bereits fällig): Playbook für die Meldung von Sicherheitsvorfällen und Schwachstellen in Betrieb, Kontakte zu ENISA und CSIRT bestätigt, Werkzeuge für die SBOM eingerichtet
  • Q1 2027: Lückenanalyse gegenüber den grundlegenden Anforderungen in Anhang I
  • Q2 2027: Dokumentation im Entwurf, Prozess für die interne Konformitätsbewertung konzipiert
  • Q3 2027: externer Penetrationstest oder Bewertung durch Dritte, falls zutreffend
  • Q4 2027: EU-Konformitätserklärung, CE-Kennzeichnung und technische Dokumentation vor dem 11. Dezember fertiggestellt

Das Zusammenspiel mit NIS-2 und der KI-Verordnung

Der CRA regelt Produkte. NIS-2 regelt Dienste und Einrichtungen. Die KI-Verordnung der EU (Verordnung (EU) 2024/1689) regelt speziell KI-Systeme. Ein mittelgroßes SaaS-Unternehmen kann leicht unter alle drei fallen.

In der Praxis deckt Ihr Sicherheitsprogramm alle drei ab:

KontrollbereichCRANIS-2KI-Verordnung
Sichere Standardkonfiguration✓✓ (Art. 21)—
Offenlegung von Schwachstellen✓✓ (Art. 21)—
Verschlüsselung bei der Übertragung und im Ruhezustand✓✓✓ (Art. 15 für Hochrisiko-KI-Systeme)
Protokollierung und Überwachung✓✓ (Art. 21)✓ (Art. 12)
Meldung von Sicherheitsvorfällen✓ (Art. 14)✓ (Art. 23)✓ (Art. 73, schwerwiegende Vorfälle)
SBOM✓——

Ein Sicherheitsprogramm aufbauen, drei Regelwerke erfüllen.