Cyber Resilience Act (CRA) - Cybersicherheitsanforderungen für Produkte mit digitalen Elementen

Stand: August 2026

Ziel des Cyber Resilience Act (CRA) ist es, unsichere Hard‑ und Software in Europa systematisch zu reduzieren und Sicherheitsrisiken für Verbraucher, Unternehmen und kritische Infrastrukturen zu verringern. Die Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung) ist seit dem 10. Dezember 2024 geltendes Recht in allen EU-Mitgliedsstaaten. Die Pflichten für Unternehmen greifen jedoch schrittweise (siehe Fristen).
Wenn ein Produkt mit digitalen Funktionen entwickelt oder vertrieben wird – z. B. eine App, ein smartes Gerät oder eine Software – dann muss zukünftig der Nachweis erbracht werden, dass dieses Produkt cybersicher ist. Hersteller müssen die Konformität mit den Anforderungen des CRA erklären. Die Art der Konformitätserklärung ist abhängig von den Produktkategorien:

Produktkategorien

Alle Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vorhersehbare Verwendung eine Datenverbindung mit dem Internet erfordert, werden in drei Kategorien aufgeteilt:
  • Standardprodukte
Das sind alle Produkte die nicht als wichtige oder kritische Produkte eingestuft sind. Dazu zählen: Smartphones, Tablets, Software/Apps für Businessanwendungen, Gaming, Smart-Home-Geräte, IoT-Sensoren, digital vernetzte Unterhaltungselektronik
Die Konformitätsbewertung führt der Hersteller selbst durch und verantwortet diese auch selbst. (Art. 32)
  • Wichtige Produkte
Diese Kategorie ist in zwei Klassen eingeteilt und beschreibt Produkte, die besonders relevant für die Gesundheit und Sicherheit von Nutzern sind.
Klasse I: Identitäts-, Passwort- und Netzwerk-Manager, Virenscanner, Betriebssysteme, Home-Automation mit Sicherheitsfunktionen (Türschlösser, Kameras)
Klasse II: Firewalls, manipulationssichere Mikroprozessoren und Mikrocontroller, Hypervisors, Container-Runtime-Systeme
Für diese Klassen ist in der Regel die Konformität durch eine notifizierende Stelle (BSI) festzustellen - Das Selbstbewertungsverfahren kann auf die Klasse I angewendet werden, wenn z.B. harmonisierte Normen Anwendung finden und vollständig erfüllt werden.
  • Kritische Produkte
Ein Angriff auf Produkte dieser Kategorie würde zum Beispiel eine ganze Branche, kritische Infrastruktur oder ganze Lieferketten lahmlegen. Beispiele sind: Smart-Meter-Gateways und andere fortgeschrittenen Security-Geräte, Smartcards inkl. Secure Elements, Hardware-Geräte mit Sicherheitsboxen. Für diese Produkte muss ausnahmslos die Konformität durch eine notifizierende Stelle (BSI) festgestellt werden.
Ausgenommen sind: Medizinprodukte, In-Vitro-Diagnostika, Kraftfahrzeuge, Zivilluftfahrt, Schiffsausrüstung, Ersatzteile (die nach denselben Spezifikationen hergestellt werden), Verteidigungsprodukte bzw. Nationale Sicherheit.

Aktueller Stand und Fristen

Als deutsche Umsetzung mittels des Gesetzes zur Durchführung der Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung) liegt seit dem 01.05.2026 ein Regierungsentwurf vor, der u. a. von der IHK-Organisation kommentiert (DIHK-Impulspapier zur Wirtschaftssicherheit in Europa) wurde.
Feststehende Termine:
  • 11.06.2026: Konformitätsbewertungsstellen (KBS) können einen Antrag auf Notifizierung stellen. KBS sind unabhängige, staatlich benannte Prüfstellen, die eine zentrale Rolle bei der Umsetzung des Cyber Resilience Act spielen. Sie unterstützen dabei zu prüfen, ob ein Produkt die gesetzlichen Cybersicherheitsanforderungen erfüllt.
  • 11.09.2026: Meldepflicht für Schwachstellen und Sicherheitsvorfälle. Dazu baut die EU Agency for Cybersecurity (ENISA) die CRA Single Reporting Platform (SRP) als zentrale Meldeplattform auf.
  • 11.12.2027: Alle CRA-Anforderungen sind bei neuen Produkten einzuhalten.

Was ist neu?

Grundlegende Cybersicherheitsanforderungen (Anhang 1) müssen über den gesamten Produktlebenszyklus berücksichtigt werden – also über die Entwicklung, die Herstellung, den Betrieb und die Wartung der Produkte. Dazu muss die voraussichtliche Nutzungsdauer festgelegt und dokumentiert werden.

Nur sichere Produkte dürfen in Verkehr gebracht werden.

Das heißt unter anderem:
  • Ausnutzbare Schwachstellen dürfen nicht bekannt sein, wenn das Produkt auf den Markt gebracht wird.
  • Die Standardkonfiguration muss sicher sein und Schutz vor unbefugtem Zugriff bieten.
  • Die Integrität und Sicherheit von gespeicherten, übermittelten oder weiterverarbeiteten Daten muss gewährleistet werden – das betrifft auch den Zugriff über externe Schnittstellen.

Sicherheitsupdates und Support werden Pflicht

Hersteller müssen Schwachstellen unverzüglich behandeln und Sicherheitsupdates während der festgelegten Nutzungsdauer gewährleisten, mindestens aber 5 Jahre. Die Sicherheit muss regelmäßig getestet und überprüft werden.

Schwachstellenmanagement

Hersteller müssen eine Strategie bzw. ein Verfahren etablieren, um die Offenlegung von Schwachstellen zu koordinieren – das beinhaltet die Meldung von intern oder extern, die Bearbeitung, die Behebung, die Dokumentation und die Meldung an Nutzer und Marktüberwachungsbehörden (In Deutschland das BSI).

Hersteller müssen die Konformität mit dem CRA erklären

Der Umfang der technischen Dokumentation muss um die Bewertung der Cybersicherheitsrisiken über den gesamten Produktlebenszyklus, den voraussichtlichen Nutzungszeitraum und die Softwarestückliste (SBOM) erweitert werden.

Pflichten der Hersteller

Die Vorteile für Nutzer sind offensichtlich, denn im Jahr 2025 entstand ein Gesamtschaden von mehr als 200 Mrd. Euro durch Cyberangriffe allein in Deutschland. Besonders für die Hersteller ergeben sich jedoch aus dem CRA deutlich größere Aufwände von der Entwicklung bis zum Ende des Lebenszyklus. Hervorzuheben sind:

Durchgehende Risikoanalyse – sichere Produktentwicklung

Von Beginn an sollte die Konzeption und Entwicklung dokumentiert und die möglichen Risiken bewertet werden. Die Festlegung der Nutzungsdauer und Kategorisierung des Produktes wird zum elementaren Bestandteil des Konzepts.

Vollständiges Schwachstellenmanagement etablieren

Diese Anforderung bedingt ein hohes Maß an Standardisierung und Kommunikation – also die klare Verteilung von Rollen und Verantwortlichkeiten in der Organisation, strukturierte transparente Prozesse und eine nachvollziehbare und durchgängige Dokumentation der Produktarbeit.

Sicherheitsupdates über den gesamten Produktlebenszyklus

Hersteller müssen Sicherheitsaktualisierungen für den gesamten Unterstützungszeitraum gewährleisten. Dazu können öffentliche Softwarearchive unterhalten werden, um Nutzern den Zugang zu historischen Versionen zu erleichtern.

Umfangreichere technische Dokumentation

Der Nachweis der Einhaltung aller Sicherheitsanforderungen, die Risikoanalyse inkl. der Neubewertung bei Produktanpassungen, die Softwarestückliste (SBOM) und nicht zuletzt die Nachweise zu behobenen Schwachstellen gehen über den bekannten Umfang einer technischen Dokumentation weit hinaus.

Meldepflichten für Schwachstellen und Sicherheitsvorfälle

Zu guter Letzt darf die Meldung von aktiv ausgenutzten Schwachstellen oder Sicherheitsvorfällen nicht vergessen werden – sie muss integraler Bestandteil der Produktpflege werden.
Meldepflichten für Hersteller - Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden (Art. 14): Die Erstmeldung hat innerhalb von 24 Stunden zu erfolgen I Eine detaillierte Meldung muss Innerhalb von 72 Stunden folgen I Ein Abschlussbericht ist spätestens nach 14 Tagen einzureichen! Gemeldet wird über ein EU-weites Meldesystem (CRA Single Reporting Plattform – SRP), dass bis zum 11. September 2026 produktiv bereitstehen wird.

Handlungsempfehlungen für Hersteller

  1. Das eigene Produktportfolio überprüfen und eine erste Einordnung in die Produktkategorien vornehmen (CRA Infomaterial des BSI)
  2. Lebensdauer der Produkte realistisch abschätzen und Updatefähigkeit beurteilen
  3. Abhängigkeit von Zulieferern und Komponenten analysieren
  4. Entwicklungs- und Qualitätssicherungsprozesse überarbeiten (CRA sinnvoll integrieren)
Das EU-Projekt SECURE unterstützt KMU direkt bei der Umsetzung der Anforderungen - eine Anmeldung auf der Plattform ist erforderlich um sich für einen kommenden Call zu bewerben.