Cyber Resilience Act (CRA): Leitfaden für Produkthersteller

Der Cyber Resilience Act (Verordnung 2024/2847) führt verpflichtende Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen auf dem EU-Markt ein. Es ist die weltweit erste Regulierung dieser Art — sie verlangt Security by Design, Sicherheitsupdates über den gesamten Lebenszyklus und transparentes Schwachstellenmanagement.

Wenn Sie vernetzte Produkte oder Software in Europa herstellen, importieren oder vertreiben, betrifft der CRA Sie direkt.

Was ist der Cyber Resilience Act?

Der CRA etabliert horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen über ihren gesamten Lebenszyklus — von Design und Entwicklung über die Markteinführung bis zum Lebensende.

Zentrale Prinzipien:

Security by Design: Produkte müssen von Anfang an mit Cybersicherheit im Blick entwickelt werden
Security by Default: Produkte müssen mit sicherer Standardkonfiguration ausgeliefert werden
Lebenszyklus-Verantwortung: Hersteller müssen Sicherheitsupdates für die erwartete Produktlebensdauer bereitstellen
Transparenz: Schwachstellen müssen gemeldet und koordiniert behandelt werden
Marktzugang: Nicht-konforme Produkte dürfen nicht auf den EU-Markt gebracht werden (CE-Kennzeichnung erforderlich)

Wer muss den CRA einhalten?

Hersteller

Jede Einrichtung, die Produkte mit digitalen Elementen entwirft, entwickelt oder herstellt und unter eigenem Namen vermarktet.

Importeure

Jede in der EU ansässige Einrichtung, die ein Produkt eines Herstellers außerhalb der EU auf den Markt bringt.

Händler

Jede Einrichtung in der Lieferkette, die ein Produkt auf dem Markt bereitstellt.

Was zählt als „Produkt mit digitalen Elementen"?

Vernetzte Hardware: IoT-Geräte, Router, Smart-Home-Geräte, Industriesteuerungen
Eigenständige Software: Anwendungen, Betriebssysteme, Firmware, Middleware
Cloud-Komponenten: Fernverarbeitungslösungen, die für die Kernfunktion eines Produkts wesentlich sind

Ausnahmen

Open-Source-Software in nicht-kommerziellem Kontext
Produkte unter sektorspezifischer EU-Gesetzgebung (Medizinprodukte, Automotive)
Produkte ausschließlich für nationale Sicherheit oder Verteidigung

Produktkategorien und Konformitätsbewertung

Standardkategorie (Mehrheit der Produkte)

Bewertung: Selbstbewertung durch den Hersteller
Beispiele: Die meisten Consumer-IoT-Geräte, Allzweck-Software

Wichtige Produkte (Anhang III)

Klasse I: Identitätsmanagement-Software, VPNs, Firewalls, Router, Mikroprozessoren mit Sicherheitsfunktionen

Selbstbewertung mit harmonisierten Normen ODER Drittbewertung

Klasse II: Hypervisoren, Container-Laufzeitumgebungen, Industriefirewalls

Drittbewertung erforderlich

Kritische Produkte (Anhang IV)

Hardware-Sicherheitsmodule (HSMs), Smartcards, sichere Elemente
Europäische Cybersicherheitszertifizierung erforderlich

Wesentliche Cybersicherheitsanforderungen

Produktanforderungen (Anhang I, Teil I)

Angemessenes Cybersicherheitsniveau gewährleisten
Ohne bekannte ausnutzbare Schwachstellen ausliefern
Sichere Standardkonfiguration mit Reset-Möglichkeit
Schutz vor unbefugtem Zugriff
Schutz der Vertraulichkeit (Verschlüsselung wo angemessen)
Schutz der Datenintegrität
Datenminimierung
Verfügbarkeitsschutz, einschließlich Resilienz gegen DoS
Minimale Angriffsfläche
Sichere Software-Update-Mechanismen

Schwachstellenbehandlung (Anhang I, Teil II)

Schwachstellen und Komponenten identifizieren (einschließlich SBOM)
Schwachstellen unverzüglich durch Sicherheitsupdates beheben
Regelmäßige Tests und Überprüfungen
Öffentliche Offenlegung behobener Schwachstellen mit CVE-Kennungen
Koordinierte Schwachstellenoffenlegungspolitik
Kostenlose Sicherheitsupdates für die erwartete Produktlebensdauer (mindestens 5 Jahre)

Meldepflichten für Schwachstellen

Aktiv ausgenutzte Schwachstellen

Innerhalb von 24 Stunden: Frühwarnung an ENISA
Innerhalb von 72 Stunden: Schwachstellenmeldung mit Korrekturmaßnahmen
Innerhalb von 14 Tagen: Abschlussbericht

CRA und der Software-Entwicklungsprozess

Für Softwareunternehmen bedeutet der Cyber Resilience Act eine fundamentale Veränderung im Entwicklungsprozess. Security darf nicht mehr nachträglich hinzugefügt werden — sie muss von Anfang an eingebaut sein.

Secure Development Lifecycle (SDL) nach CRA

Anforderungsphase:

Security-Anforderungen müssen von Beginn an in das Produktspezifikation aufgenommen werden
Threat Modeling als Teil der Produktplanung
Definition der erwarteten Produktlebensdauer (mindestens 5 Jahre für den Support-Zeitraum)

Entwicklungsphase:

Sichere Coding-Standards und Code-Review-Prozesse
Nutzung geprüfter, aktueller Bibliotheken und Abhängigkeiten
Automatisierte Static Application Security Testing (SAST)

Testphase:

Penetrationstests vor Release
Dynamic Application Security Testing (DAST)
Schwachstellen-Scanning aller Komponenten

Veröffentlichungsphase:

Software Bill of Materials (SBOM) erstellen und pflegen
Sichere Standardkonfiguration sicherstellen
Dokumentation für Nutzer zu Sicherheitseinstellungen

Betriebsphase:

Monitoring für neu entdeckte Schwachstellen in verwendeten Komponenten
Patch-Management-Prozess mit definierten Fristen
Koordiniertes Schwachstellenoffenlegungsverfahren (CVD)

Software Bill of Materials (SBOM): Die Grundlage der CRA-Compliance

Eine der praktisch bedeutsamsten CRA-Anforderungen ist die Pflicht zur Software Bill of Materials (SBOM). Eine SBOM ist eine vollständige, maschinenlesbare Liste aller Softwarekomponenten in einem Produkt — Bibliotheken, Frameworks, Open-Source-Pakete.

Warum SBOMs für den CRA entscheidend sind:

Schwachstellen-Tracking: Wenn eine kritische Schwachstelle in einer Open-Source-Bibliothek entdeckt wird (z.B. Log4Shell), können Sie sofort identifizieren, welche Ihrer Produkte betroffen sind.
24-Stunden-Meldepflicht: Ohne SBOM ist eine schnelle Reaktion auf aktiv ausgenutzte Schwachstellen kaum möglich.
Konformitätsnachweis: Behörden können SBOMs anfordern, um die Einhaltung der Anforderungen nachzuprüfen.

SBOM-Mindestinhalt nach CRA:

Name und Version jeder Komponente
Hersteller/Autor der Komponente
Einzigartige Kennung (z.B. PURL)
Abhängigkeitsbeziehungen
Lizenzinformationen

Gängige SBOM-Formate: SPDX (ISO 5962), CycloneDX

Cyber Resilience Act vs. andere EU-Regulierungen

Der CRA ergänzt und überschneidet sich mit anderen EU-Regularien. Verstehen Sie das Zusammenspiel, vermeiden Sie Doppelarbeit:

Regulierung	Fokus	Verhältnis zum CRA
NIS2	Betreiber kritischer Infrastrukturen	CRA ergänzt NIS2 für Produkthersteller; NIS2-Betreiber müssen sichere (CRA-konforme) Produkte einsetzen
DSGVO	Personenbezogene Daten	CRA-Datenschutzanforderungen (Datenminimierung, Verschlüsselung) überlappen mit DSGVO-Pflichten
Maschinenverordnung	Maschinen und Sicherheitskomponenten	Sektorspezifisch; Maschinen mit eingebetteter Software können unter beide fallen
Medizinprodukte-VO (MDR)	Medizinische Geräte	Sektorspezifisch; MDR-konforme Geräte können von bestimmten CRA-Anforderungen ausgenommen sein
Radio Equipment Directive (RED)	Funkgeräte, IoT	Teilüberschneidung; bestimmte RED-konforme Produkte können CRA-Ausnahmen nutzen

Für Softwareunternehmen gilt: CRA und DSGVO adressieren verschiedene Ebenen (Produktsicherheit vs. Datenverarbeitung), aber viele technische Maßnahmen (Verschlüsselung, Zugangskontrolle, Datenminimierung) erfüllen Anforderungen beider Verordnungen gleichzeitig.

CRA-Implementierung: Praktischer Fahrplan für Unternehmen

Schritt 1: Betroffenheitsanalyse (sofort)

Klären Sie grundlegende Fragen:

Welche Ihrer Produkte fallen unter den CRA?
Sind es Standardprodukte, Klasse-I- oder Klasse-II-Produkte?
Welche Konformitätsbewertungsroute gilt (Selbstbewertung vs. Drittbewertung)?

Schritt 2: Gap-Analyse gegen Anhang I (Q1-Q2 2025)

Prüfen Sie Ihre aktuellen Prozesse gegen die 20 Anforderungen aus Anhang I:

Bestehen dokumentierte SDL-Prozesse?
Existiert eine SBOM für alle Produkte?
Gibt es ein koordiniertes Schwachstellenoffenlegungsverfahren?
Sind Patch-Management-Prozesse für den 5-Jahres-Support-Zeitraum definiert?

Schritt 3: Prozesse aufbauen (2025-2026)

Schwachstellenmanagement vor September 2026 aufbauen:

Einrichtung eines PSIRT (Product Security Incident Response Team) oder Benennung Verantwortlicher
CVD-Policy veröffentlichen (security@ihredomain.de oder HackerOne/Bugcrowd)
Monitoring-Prozess für CVEs in verwendeten Komponenten
24-Stunden-Meldeprotokoll für ENISA dokumentieren und einüben

Schritt 4: Technische Dokumentation und CE-Kennzeichnung (bis Dez. 2027)

Die technische Dokumentation für die CRA-Konformität umfasst:

Produkt- und Designbeschreibung
Sicherheitsanforderungen und deren Umsetzung
Risikoanalyse
Testergebnisse
SBOM
Konformitätserklärung

Schritt 5: Kontinuierliche Compliance

Der CRA ist kein einmaliges Projekt. Kontinuierliche Pflichten umfassen:

SBOM bei jedem Release aktualisieren
Schwachstellen-Monitoring und zeitnahe Patches
Regelmäßige Überprüfung der technischen Dokumentation
Sicherheitsupdates bis zum Ende des Support-Zeitraums

Besondere Herausforderungen für Open-Source-Unternehmen

Open-Source-Software in nicht-kommerziellem Kontext ist vom CRA ausgenommen. Aber viele Open-Source-Projekte haben kommerzielle Komponenten — und hier wird es kompliziert:

Kommerzielle Nutzung: Wenn ein Unternehmen Open-Source-Software in einem kommerziellen Produkt vertreibt, gilt der CRA
Stewardship: Open-Source-Foundations, die Software für kommerzielle Nutzung bereitstellen, können als Hersteller im Sinne des CRA gelten
Abhängigkeiten: Kommerzielle Produkte, die Open-Source-Komponenten integrieren, müssen diese in ihrer SBOM führen und Schwachstellen darin tracken

Die EU-Kommission hat einen Open Source Stewardship-Mechanismus angekündigt, der Open-Source-Ökosysteme bei der CRA-Compliance unterstützen soll.

CRA-Zeitplan

Datum	Meilenstein
20. Nov. 2024	Im Amtsblatt veröffentlicht
10. Dez. 2024	In Kraft getreten
11. Jun. 2026	Bestimmungen für Konformitätsbewertungsstellen gelten
11. Sep. 2026	Schwachstellenmeldepflichten gelten
11. Dez. 2027	Vollständige Anwendung aller Anforderungen

Sanktionen

Verstoß	Höchststrafe
Wesentliche Cybersicherheitsanforderungen	15 Mio.€ oder 2,5% des Umsatzes
Sonstige CRA-Pflichten	10 Mio.€ oder 2% des Umsatzes
Irreführende Angaben	5 Mio.€ oder 1% des Umsatzes

Häufige Fragen zur CRA-Implementierung

Gilt der CRA auch für SaaS-Produkte?

Ja und nein. Reine SaaS-Dienste, die nicht als Komponente in ein Produkt integriert sind, fallen grundsätzlich nicht unter den CRA (dafür gibt es andere Regulierungen wie NIS2). Aber: Cloud-Dienste, die für die Kernfunktion eines physischen Produkts wesentlich sind (z.B. eine Cloud-Backend-Plattform für ein IoT-Gerät), können als Teil des Produkts betrachtet werden und müssen die CRA-Anforderungen für diesen Anteil erfüllen.

Faustregel: Wenn Ihre Software als selbstständiges Produkt verkauft wird oder wesentlicher Bestandteil eines vernetzten Produkts ist, gilt der CRA. Wenn es rein als Service ohne Produkteinbindung betrieben wird, eher nicht.

Wie lange muss ich Sicherheitsupdates bereitstellen?

Der CRA fordert Sicherheitsupdates für die erwartete Produktlebensdauer, mindestens jedoch 5 Jahre ab dem letzten Inverkehrbringen des Produkts. Das bedeutet:

Definieren Sie für jedes Produkt einen offiziellen Support-Zeitraum
Kommunizieren Sie diesen Support-Zeitraum klar an Kunden
Planen Sie Ressourcen für Patch-Management über die gesamte Lebensdauer ein

Was passiert, wenn eine Schwachstelle in einem verwendeten Open-Source-Paket entdeckt wird?

Als Hersteller sind Sie verantwortlich — nicht der Open-Source-Autor. Sie müssen:

Die betroffenen Produkte in Ihrer SBOM identifizieren (deshalb ist eine aktuelle SBOM unverzichtbar)
Eine aktiv ausgnutzte Schwachstelle innerhalb von 24 Stunden an ENISA melden
Innerhalb von 72 Stunden ein Update oder einen Workaround bereitstellen (oder zumindest einen konkreten Plan)
Nutzer informieren

Gilt der CRA für Produkte, die vor dem Stichtag entwickelt wurden?

Für Produkte, die nach dem 11. Dezember 2027 auf den Markt gebracht werden, gilt der CRA vollständig. Für ältere Produkte, die nach diesem Datum weiter vertrieben werden, gibt es Übergangsregelungen. Aber: Die Schwachstellenmeldepflicht gilt bereits ab September 2026 — auch für Produkte, die sich bereits auf dem Markt befinden.

CRA Compliance Checkliste: Sofortmaßnahmen

Priorisieren Sie diese Maßnahmen nach Dringlichkeit:

Bis September 2026 (Schwachstellenmeldepflicht):

SBOM für alle betroffenen Produkte erstellen
CVD-Policy veröffentlichen und kommunizieren
Verantwortliche für PSIRT/Schwachstellenmanagement benennen
Meldeprozess für ENISA-Frühwarnung (24h) dokumentieren und einüben
Monitoring für CVEs in verwendeten Komponenten einrichten

Bis Dezember 2027 (vollständige Anwendung):

Betroffenheitsanalyse: Welche Produkte, welche Kategorie?
Gap-Analyse gegen Anhang I (20 Anforderungen)
SDL-Prozesse dokumentieren und an CRA-Anforderungen anpassen
Technische Dokumentation für alle betroffenen Produkte erstellen
Konformitätsbewertungsroute bestimmen (Selbstbewertung / Drittbewertung)
EU-Konformitätserklärung erstellen
CE-Kennzeichnung für alle betroffenen Produkte sicherstellen

Wie Orbiq bei CRA Compliance unterstützt

Lieferketten-Dokumentation: Komponenten und Abhängigkeiten über Ihr Produktportfolio verfolgen
Compliance-Nachweise: Sicherheitstests, Schwachstellenbewertungen und Konformitätsdokumentation zentralisieren
Trust Center: Produktsicherheitsstatus gegenüber Kunden und Marktüberwachungsbehörden darstellen
Lieferantenmanagement: Sicherheitsstatus von Komponenten und Drittanbieter-Abhängigkeiten überwachen

Weiterführende Artikel

Cyber Resilience Act: Artikel 13 & 14 im Detail
NIS2 Compliance Leitfaden — Organisatorische Sicherheitsanforderungen
DORA Compliance Leitfaden — Anforderungen für den Finanzsektor

Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letzte Aktualisierung: März 2026.

Cyber Resilience Act: Was Unternehmen 2025 wissen und vorbereiten müssen