Anforderungen des Cyber Resilience Act im Detail

Der Cyber Resilience Act stellt klare Anforderungen an alle Hersteller digitaler Produkte – von Security by Design über Schwachstellenmanagement bis zur CE-Kennzeichnung.

Der Cyber Resilience Act (CRA) – offiziell die Verordnung (EU) 2024/2847 – ist seit dem 10. Dezember 2024 in Kraft und gilt vollumfänglich ab dem 11. Dezember 2027 verbindlich für alle Produkte mit digitalen Elementen auf dem EU-Markt. Was das konkret bedeutet und welche Anforderungen auf dich als Hersteller zukommen, erklären wir in diesem Beitrag Schritt für Schritt.


Du möchtest zunächst genauer verstehen, was der CRA überhaupt ist? Dann lies zuerst unseren Grundlagenartikel zum Cyber Resilience Act.

Risikoklassifizierung: Welche Kategorie trifft dein Produkt?

Der CRA unterscheidet Produkte nach ihrem Risikopotenzial in vier Klassen. Die Einordnung ist entscheidend – sie bestimmt, wie aufwändig der Weg zur CE-Kennzeichnung wird.

Standardprodukte

Die große Mehrheit aller vernetzten Produkte fällt in diese Kategorie. Wer hier landet, kann das Konformitätsbewertungsverfahren selbst durchführen. Das bedeutet: Es ist keine externe Prüfstelle erforderlich, aber alle grundlegenden Sicherheitsanforderungen aus Anhang I des CRA müssen dennoch vollständig erfüllt werden.


Beispiele: Vernetzte Haushaltsgeräte, einfache IoT-Sensoren, Software ohne sicherheitskritische Funktionen

Wichtige Produkte – Klasse I (Anhang III)

Klasse-I-Produkte haben ein erhöhtes Risikopotenzial, weil ihre Kompromittierung weitreichende Folgen haben kann. Hier sind die Anforderungen strenger. Hersteller können die Konformität selbst bewerten – aber nur dann, wenn sie harmonisierte europäische Normen vollständig anwenden. Liegen keine solchen Normen vor oder werden sie nicht angewendet, ist eine benannte Stelle einzubeziehen.


Typische Produkte der Klasse I:


  • Identitätsmanagementsysteme und Zugangskontrollgeräte
  • Passwortmanager
  • Browser (eigenständig und eingebettet)
  • VPN-Produkte und Fernzugriffssoftware
  • Netz- und Konfigurationsmanagementsysteme
  • Software für Updates und Patch-Management
  • Smart-Home-Produkte mit Sicherheitsfunktionen (z. B. vernetzte Türschlösser, Kameras)
  • Betriebssysteme für allgemeine Nutzung

Wichtige Produkte – Klasse II (Anhang III)

Produkte der Klasse II gelten als besonders sicherheitssensibel. Sie betreffen oft kritische Infrastrukturen oder spielen eine zentrale Rolle in der IT-Sicherheit. Hier ist eine externe Konformitätsbewertung durch eine benannte Stelle verpflichtend – eine Selbstbewertung ist nicht ausreichend.


Typische Produkte der Klasse II:


  • Hypervisoren und Container-Runtime-Systeme
  • Firewalls und Intrusion-Detection-Systeme
  • Manipulationssichere Mikroprozessoren und Mikrocontroller

Kritische Produkte (Anhang IV)

Für diese Kategorie – darunter beispielsweise Hardwaregeräte mit Sicherheitsboxen, Chipkarten für qualifizierte elektronische Signaturen oder Smart-Meter-Gateways – gelten im CRA die strengsten Anforderungen. Aktuell noch offen: Neben der Prüfung durch benannte Stellen kann für diese Produkte eine europäische Cybersicherheitszertifizierung verpflichtend vorgeschrieben werden.

Jetzt checken, in welche Kategorie dein Produkt fällt!

Übersicht: Anforderungen nach Risikoklasse


Kriterium

Standard

Klasse I

Klasse II

Kritisch

Grundlegende Sicherheitsanforderungen

(Anhang I)

Schwachstellen-management

Konformitätsbewertung

Selbst-bewertung

Selbstbewertung mit Normen oder benannte Stelle

Benannte Stelle verpflichtend

Benannte Stelle + ggf. EU-Zertifizierung

Technische Dokumentation

CE-Kennzeichnung

EU-Konformitätserklärung

Externe Prüfstelle

erforderlich

Nur ohne harmonisierte Standards

EU-Cybersicherheits-zertifizierung

Möglich / verpflichtend


Grundlegende Sicherheitsanforderungen (Anhang I)

Egal, welcher Risikoklasse dein Produkt oder deine Software angehört, diese grundlegenden Sicherheitsanforderungen des CRA müssen in jedem Fall erfüllt werden.

1. Security by Design & Security by Default

Das Kernprinzip des CRA ist, Cybersicherheit nicht nachträglich aufzusetzen, sondern es von Anfang an als Teil des Entwicklungsprozesses zu integrieren – über den gesamten Lebenszyklus eines Produkts hinweg: Von der Planung über die Entwicklung und Herstellung bis hin zu Lieferung, Wartung und Außerbetriebnahme.

Security by Design

Was das konkret bedeutet:


  • Risikobewertung in der Entwicklung: Bereits in der Planungs- und Konzeptionsphase müssen Cybersicherheitsrisiken systematisch identifiziert und bewertet werden. Die Ergebnisse dieser Bewertung müssen in alle weiteren Phasen einfließen und wenn nötig bei Änderungen am Produkt angepasst und neu bewertet werden.
  • Minimale Angriffsfläche: Das Produkt soll nur die Funktionen bereitstellen, die tatsächlich benötigt werden. Nicht benötigte Schnittstellen, Dienste oder Funktionen sind zu deaktivieren oder gar nicht erst zu integrieren.
  • Datenschutz und Verschlüsselung: Gespeicherte und übertragene Daten müssen angemessen geschützt werden – in der Regel durch Verschlüsselung nach aktuellem Stand der Technik.
  • Integrität und Authentizität: Mechanismen zur Überprüfung der Softwareintegrität und zur Authentifizierung von Nutzern und Komponenten müssen eingebaut sein.
  • Software Bill of Materials (SBOM): Anforderung des CRA ist die Erstellung einer SBOM – vergleichbar mit einem Zutatenverzeichnis für Software. Sie listet alle verwendeten Bibliotheken und Komponenten auf und ist Grundlage für ein effektives Schwachstellenmanagement.

Security by Default

Produkte müssen so ausgeliefert werden, dass Nutzer ohne zusätzliche Konfiguration bereits sicher unterwegs sind:


Keine schwachen Standardpasswörter: Voreingestellte Passwörter müssen stark sein oder beim ersten Login geändert werden müssen.


Automatische Sicherheitsupdates: Wo technisch möglich und sinnvoll, sollten Updates standardmäßig automatisch eingespielt werden.


Minimale Datenerhebung: Nur die für den Betrieb tatsächlich notwendigen Daten dürfen in der Standardkonfiguration erhoben werden.

2. Schwachstellenmanagement und Meldepflichten

Ein zentrales Element des CRA ist das aktive und kontinuierliche Schwachstellenmanagement über die gesamte Produktlebensdauer hinweg. Folgende Aspekte müssen im Prozess des Schwachstellenmanagements enthalten sein:


  • Identifikation und Dokumentation: Hersteller müssen aktiv nach Schwachstellen suchen und diese systematisch dokumentieren.
  • Koordinierte Offenlegung: Es muss eine Strategie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) vorliegen. Eine zentrale Kontaktstelle für Schwachstellenmeldungen muss benannt und öffentlich zugänglich sein.
  • Komponenten-Weitermeldung: Wird eine Schwachstelle in einer integrierten Komponente (z. B. einer Open-Source-Bibliothek) festgestellt, muss diese an die verantwortliche Person oder Organisation gemeldet werden.
  • Kostenlose Sicherheitsupdates: Patches und Updates zur Behebung von Schwachstellen müssen rechtzeitig und ohne zusätzliche Kosten für die Nutzer bereitgestellt werden.


Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten klar definierte Meldefristen:

Lorem Ipsum


Frist

Inhalt der Meldung

24 Stunden

Erste Frühwarnung an ENISA und das zuständige CSIRT

(Computer Security Incident Response Team)

72 Stunden

Ausführliche Schwachstellenmeldung mit Details zur Schwachstelle,

betroffenen Produkten und bereits ergriffenen Gegenmaßnahmen

14 Tage

Detaillierter Abschlussbericht mit vollständiger Dokumentation

für aktiv ausgenutzte Schwachstellen

30

Detaillierter Abschlussbericht mit vollständiger Dokumentation

für schwerwiegende Sicherheitsvorfälle


Wichtig: Die Meldepflichten für Schwachstellen und Sicherheitsvorfälle gelten bereits ab dem 11. September 2026 – also über ein Jahr vor der vollständigen Anwendbarkeit des CRA im Dezember 2027.


Detaillierte Infos zu den geltenden Fristen findest du in unserem Beitrag zu Fristen des CRA.

3. Dokumentations- und Berichtspflichten

Transparenz ist ein tragendes Prinzip des CRA. Sowohl gegenüber Behörden als auch gegenüber Nutzern bestehen umfangreiche Informationspflichten.

Technische Dokumentation (Anhang VII)

Die technische Dokumentation muss vor dem Inverkehrbringen erstellt und über den gesamten Supportzeitraum aktuell gehalten werden. Sie enthält unter anderem:


  • Beschreibung der Systemarchitektur und der Sicherheitsfunktionen
  • Ergebnisse der Risikobewertung und der Sicherheitsanalysen
  • Festgelegte Verfahren zur Erkennung und Behebung von Schwachstellen
  • Angaben zur SBOM (Software Bill of Materials)
  • Dokumentation von Entwicklungs- und Build-Prozessen
  • Kontaktadresse für Schwachstellenmeldungen

Nutzerinformationen (Anhang II)

Nutzer müssen klar und verständlich informiert werden über:


  • Sicherheitsmerkmale des Produkts und deren Funktionsweise
  • Anleitung zur sicheren Installation, Konfiguration und Nutzung
  • Hinweise auf bekannte Risiken und empfohlene Sicherheitseinstellungen
  • Erwartete Produktlebensdauer und Dauer des Sicherheits-Supports
  • Kontaktmöglichkeit zur Meldung von Schwachstellen
  • Informationen über verfügbare Updates und wie sie eingespielt werden

EU-Konformitätserklärung (Anhang V / VI)

Die EU-Konformitätserklärung ist das formelle Dokument, mit dem der Hersteller bestätigt, dass sein Produkt die Anforderungen des CRA erfüllt. Sie muss in der Sprache jedes Mitgliedstaats verfasst sein, in dem das Produkt vermarktet wird, und kann entweder dem Produkt beigelegt oder über eine Internetadresse zugänglich gemacht werden.

4. CE-Kennzeichnung und Konformitätsbewertung

Ohne CE-Kennzeichnung darf kein Produkt mit digitalen Elementen ab dem 11. Dezember 2027 auf dem EU-Markt in Verkehr gebracht werden. Der Weg dorthin hängt von der Produktklasse ab.


Der Ablauf im Überblick:


  1. Produktklasse bestimmen: In welche Risikoklasse fällt das Produkt?
  2. Risikobewertung durchführen: Für alle Klassen verpflichtend.
  3. Sicherheitsanforderungen umsetzen: Alle grundlegenden Anforderungen aus Anhang I erfüllen.
  4. Konformitätsbewertungsverfahren durchlaufen: Je nach Klasse selbst oder mit benannter Stelle.
  5. Technische Dokumentation erstellen: Vollständig und aktuell.
  6. EU-Konformitätserklärung ausstellen.
  7. CE-Kennzeichnung anbringen: Gut sichtbar, leserlich und dauerhaft. Am Produkt selbst, auf der Verpackung oder (bei Software) in der Benutzeroberfläche oder Dokumentation.

Pflichten des CRA entlang der Lieferkette

Der CRA richtet sich nicht nur an Hersteller – auch Importeure und Händler tragen Verantwortung.


  • Hersteller tragen die Hauptverantwortung: Sie müssen Konformität sicherstellen, Schwachstellen managen, Nutzer informieren und Meldepflichten einhalten. Dazu gehört auch die Prüfpflicht für zugekaufte Komponenten – Drittanbieter-Software oder -Hardware, die ins Produkt einfließt, muss ebenfalls den Anforderungen entsprechen.
  • Importeure dürfen ausschließlich konforme Produkte in die EU einführen. Sie müssen sicherstellen, dass der Hersteller die Anforderungen des CRA erfüllt hat, und ihre eigenen Kontaktdaten am Produkt oder der Verpackung angeben.
  • Händler haben eine Sorgfaltspflicht: Sie dürfen nur Produkte anbieten, die ordnungsgemäß gekennzeichnet sind und den CRA-Anforderungen entsprechen. Bei Verdacht auf Nicht-Konformität müssen sie Maßnahmen ergreifen oder das Produkt vom Markt nehmen.