Cyber Resilience Act: Neue Pflichten für Hersteller von Produkten mit digitalen Elementen

Was ist der Cyber Resilience Act?

Vernetzte Produkte sind überall: Smarte Türschlösser, industrielle Sensoren, Router, Smartwatches, Softwareanwendungen, Firmware in Maschinensteuerungen. Viele dieser Produkte werden mit minimalen Sicherheitsvorkehrungen entwickelt und nach dem Verkauf nie wieder mit Sicherheitsupdates versorgt. Das Ergebnis: Millionen von Geräten mit bekannten Schwachstellen, die als Einfallstore für Cyberangriffe dienen.

Der Cyber Resilience Act (CRA) ist die Antwort der Europäischen Union auf dieses Problem. Die Verordnung (EU) 2024/2847 wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft. Sie stellt erstmals verbindliche Cybersicherheitsanforderungen an Hersteller von Produkten mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden.

Der CRA verfolgt zwei zentrale Ziele: Erstens sollen Produkte mit digitalen Elementen von Anfang an sicher gestaltet sein (Security by Design). Zweitens sollen Hersteller für die Cybersicherheit ihrer Produkte über den gesamten Lebenszyklus verantwortlich bleiben, mindestens fünf Jahre lang oder für die erwartete Nutzungsdauer, je nachdem was kürzer ist.

Zeitplan: Wann gilt was?

Der CRA hat einen gestaffelten Anwendungszeitraum:

• 10. Dezember 2024: Inkrafttreten der Verordnung
• 11. Juni 2026: Die Meldepflichten für Schwachstellen und Vorfälle gelten (Artikel 14)
• 11. Dezember 2026: Anforderungen an Konformitätsbewertungsstellen gelten
• 11. September 2027: Alle Anforderungen gelten vollständig (Anhang I und II)

Das bedeutet: Wenn du Produkte mit digitalen Elementen herstellst, hast du bis September 2027 Zeit, die vollständigen Anforderungen umzusetzen. Aber die Meldepflichten für Schwachstellen gelten bereits ab Juni 2026. Das ist ein ehrgeiziger Zeitplan, besonders wenn du noch kein strukturiertes Schwachstellenmanagement betreibst.

Welche Produkte sind betroffen?

Der CRA definiert "Produkte mit digitalen Elementen" bewusst breit. Betroffen sind:

Hardware-Produkte mit Software-Komponenten: Router, Firewalls, IoT-Geräte, Smart-Home-Produkte, industrielle Steuerungen, medizinische Geräte (soweit nicht durch sektorspezifische Regulierung abgedeckt), Spielzeug mit digitalen Funktionen, Netzwerkgeräte, Smartcards und ähnliche Produkte.

Reine Softwareprodukte: Betriebssysteme, Firmware, Anwendungssoftware, Mobile Apps, Bibliotheken und SDKs, Desktop-Anwendungen und Serveranwendungen.

Remote-Datenverarbeitungslösungen: Wenn ein Produkt auf Remote-Datenverarbeitung angewiesen ist (zum Beispiel eine Cloud-Komponente, die für die Kernfunktionalität erforderlich ist), fällt diese Komponente ebenfalls unter den CRA.

Was ist ausgenommen?

Bestimmte Produktkategorien sind vom CRA ausgenommen, weil sie durch andere Regulierung abgedeckt sind:

• Medizinprodukte (Verordnung (EU) 2017/745 und 2017/746)
• Fahrzeuge (Verordnung (EU) 2019/2144)
• Luftfahrtprodukte (Verordnung (EU) 2018/1139)
• Produkte für die nationale Sicherheit und Verteidigung
• Open-Source-Software, die nicht kommerziell bereitgestellt wird (mit Einschränkungen)

Die Ausnahme für Open-Source-Software verdient eine genauere Betrachtung: Nicht-kommerzielle Open-Source-Projekte sind ausgenommen. Aber wenn ein Unternehmen Open-Source-Software kommerziell nutzt und als Teil eines Produkts vertreibt, trägt es als Hersteller die CRA-Verantwortung. Und "Open Source Stewards", also Stiftungen und Organisationen, die Open-Source-Projekte koordinieren, haben reduzierte Pflichten, insbesondere im Bereich Schwachstellenmanagement.

Produktkategorien und Konformitätsbewertung

Der CRA unterscheidet drei Risikokategorien von Produkten, die unterschiedliche Konformitätsbewertungsverfahren erfordern.

Standardprodukte (Default-Kategorie)

Die Mehrheit der Produkte mit digitalen Elementen fällt in die Standardkategorie. Für diese Produkte reicht eine Selbstbewertung durch den Hersteller (Konformitätsbewertung nach Modul A). Der Hersteller prüft selbst, ob sein Produkt die Anforderungen des Anhangs I erfüllt, erstellt die technische Dokumentation und bringt die CE-Kennzeichnung an.

Wichtige Produkte (Klasse I und Klasse II)

Produkte mit höherem Risiko werden als "wichtig" eingestuft und in zwei Klassen unterteilt:

Klasse I umfasst unter anderem: Browser, Passwort-Manager, VPN-Software, Netzwerk-Management-Systeme, SIEM-Systeme, Boot-Manager, Firewalls für den privaten Gebrauch, Router für den privaten Gebrauch und Mikroprozessoren mit sicherheitsrelevanten Funktionen.

Für Klasse-I-Produkte kann der Hersteller entweder einen harmonisierten Standard anwenden (und dann selbst bewerten) oder muss eine Bewertung durch eine benannte Stelle (Notified Body) durchführen lassen.

Klasse II umfasst unter anderem: Firewalls und Intrusion Detection Systeme für den industriellen Einsatz, Router und Switches für den industriellen Einsatz, Hypervisoren und Container-Runtime-Systeme, sichere Elemente, Hardware-Sicherheitsmodule (HSMs), Smartcard-Leser und Robotik-Geräte.

Für Klasse-II-Produkte ist grundsätzlich eine Bewertung durch eine benannte Stelle erforderlich.

Kritische Produkte

Eine dritte Kategorie für "kritische Produkte" kann durch delegierte Rechtsakte definiert werden. Für diese Produkte wäre eine europäische Cybersicherheitszertifizierung nach dem Cybersecurity Act (CSA) erforderlich.

Die Anforderungen im Detail

Sicherheitsanforderungen an das Produkt (Anhang I, Teil I)

Der CRA definiert grundlegende Sicherheitsanforderungen, die jedes Produkt mit digitalen Elementen erfüllen muss:

Security by Design. Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten. Das umfasst: keine bekannten ausnutzbaren Schwachstellen bei der Marktbereitstellung, sichere Standardkonfiguration (Secure by Default), Schutz vor unbefugtem Zugriff, Schutz der Vertraulichkeit und Integrität gespeicherter und übertragener Daten, Minimierung der Angriffsfläche und Begrenzung der Auswirkungen eines erfolgreichen Angriffs.

Authentifizierung und Zugriffskontrolle. Produkte müssen Mechanismen zur Authentifizierung und Autorisierung bieten. Standardpasswörter müssen bei der Ersteinrichtung geändert werden oder für jedes Gerät einzigartig sein.

Sicherheitsupdates. Produkte müssen die Möglichkeit bieten, Sicherheitsupdates automatisch oder manuell einzuspielen. Updates müssen kostenlos bereitgestellt werden.

Datenschutz und Datenminimierung. Produkte dürfen nur die Daten verarbeiten, die für ihren bestimmungsgemäßen Gebrauch erforderlich sind.

Anforderungen an das Schwachstellenmanagement (Anhang I, Teil II)

Neben den Produktanforderungen müssen Hersteller ein umfassendes Schwachstellenmanagement betreiben:

Dokumentation. Hersteller müssen eine Software-Stückliste (Software Bill of Materials, SBOM) erstellen und pflegen, die alle Komponenten und Abhängigkeiten des Produkts dokumentiert.

Schwachstellenbehandlung. Hersteller müssen Schwachstellen identifizieren, dokumentieren und zeitnah beheben. Sicherheitsupdates müssen kostenlos und ohne unnötige Verzögerung bereitgestellt werden.

Koordinierte Offenlegung. Hersteller müssen eine Richtlinie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) haben und eine Kontaktadresse für die Meldung von Schwachstellen bereitstellen.

Kontinuierliches Monitoring. Hersteller müssen die Cybersicherheit ihrer Produkte über den gesamten Supportzeitraum aktiv überwachen, einschließlich der Überwachung von Schwachstellen in Drittkomponenten.

Meldepflichten (Artikel 14)

Die Meldepflichten gelten bereits ab Juni 2026 und umfassen:

Aktiv ausgenutzte Schwachstellen. Wenn der Hersteller Kenntnis davon erlangt, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird, muss er dies innerhalb von 24 Stunden an die ENISA melden. Innerhalb von 72 Stunden folgt eine aktualisierte Meldung mit weiteren Details.

Schwerwiegende Vorfälle. Vorfälle, die die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen, müssen nach dem gleichen Zeitplan gemeldet werden.

Information der Nutzer. Der Hersteller muss die Nutzer über die Schwachstelle und verfügbare Gegenmaßnahmen informieren.

Was bedeutet der CRA für Hersteller?

Wenn du Produkte mit digitalen Elementen herstellst, musst du deine Entwicklungs- und Supportprozesse grundlegend anpassen.

Secure Development Lifecycle einführen

Cybersicherheit muss von der Konzeptphase bis zum End-of-Life in den Entwicklungsprozess integriert werden. Ein Secure Development Lifecycle umfasst: Threat Modeling in der Designphase, sichere Codierungspraktiken, Code Reviews und statische Analyse, Sicherheitstests (Fuzzing, Penetrationstests), Dependency-Management und Überwachung von Drittkomponenten.

Software Bill of Materials erstellen

Die SBOM ist eine neue Pflichtdokumentation. Sie muss alle Software-Komponenten des Produkts auflisten, einschließlich Open-Source-Bibliotheken und deren Versionen. Die SBOM muss aktuell gehalten und auf Anfrage der Aufsichtsbehörde bereitgestellt werden.

Supportzeitraum definieren und kommunizieren

Hersteller müssen einen Supportzeitraum für ihr Produkt definieren, in dem sie Sicherheitsupdates bereitstellen. Dieser Zeitraum muss mindestens fünf Jahre betragen oder der erwarteten Nutzungsdauer entsprechen, je nachdem was kürzer ist. Der Supportzeitraum muss vor dem Kauf klar kommuniziert werden.

CE-Kennzeichnung und Konformitätserklärung

Produkte, die die CRA-Anforderungen erfüllen, erhalten die CE-Kennzeichnung. Der Hersteller erstellt eine EU-Konformitätserklärung und hält die technische Dokumentation für die Marktüberwachungsbehörden bereit.

Was bedeutet der CRA für Betreiber und Nutzer?

Auch wenn der CRA primär auf Hersteller abzielt, gibt es Auswirkungen auf Betreiber und Nutzer:

Beschaffungskriterien anpassen. Betreiber sollten bei der Beschaffung von Produkten mit digitalen Elementen prüfen, ob der Hersteller CRA-konform ist. Ab September 2027 dürfen nur noch CRA-konforme Produkte auf dem EU-Markt bereitgestellt werden.

Sicherheitsupdates einspielen. Hersteller stellen kostenlose Sicherheitsupdates bereit. Betreiber sind in der Pflicht, diese zeitnah einzuspielen, insbesondere wenn sie selbst regulatorischen Anforderungen unterliegen (NIS2, DORA, ISO 27001).

SBOM für das eigene Risikomanagement nutzen. Die SBOMs, die Hersteller bereitstellen, können Betreiber in ihr eigenes Schwachstellenmanagement integrieren. Wenn eine kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird, können Betreiber anhand der SBOMs schnell feststellen, welche ihrer Produkte betroffen sind.

CRA und andere Regulierungen: Das Zusammenspiel

Der CRA fügt sich in ein wachsendes Netz europäischer Cybersicherheitsregulierung ein.

CRA und NIS2. NIS2 adressiert die Sicherheit von Netzwerken und Informationssystemen der Betreiber. Der CRA adressiert die Sicherheit der Produkte, die in diesen Netzwerken eingesetzt werden. Beide Regulierungen ergänzen sich: NIS2 sorgt dafür, dass Betreiber ihre Infrastruktur sichern. Der CRA sorgt dafür, dass die Produkte in dieser Infrastruktur von Anfang an sicher sind.

CRA und DORA. Für den Finanzsektor gelten die DORA-Anforderungen an ICT-Produkte. Der CRA kann zusätzlich relevant sein, wenn ein Finanzunternehmen selbst Produkte mit digitalen Elementen herstellt (zum Beispiel Banking-Apps oder Payment-Terminals).

CRA und AI Act. Hochrisiko-KI-Systeme, die unter den AI Act fallen, müssen auch die CRA-Anforderungen erfüllen, wenn sie Produkte mit digitalen Elementen sind. Die Konformitätsbewertung nach dem AI Act wird in diesen Fällen als ausreichend für den CRA anerkannt, sofern die Cybersicherheitsaspekte abgedeckt sind.

Sanktionen bei Nichteinhaltung

Der CRA sieht erhebliche Bußgelder vor:

• Bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes (je nachdem was höher ist) für Verstöße gegen die grundlegenden Sicherheitsanforderungen
• Bis zu 10 Millionen Euro oder 2 Prozent des Umsatzes für andere Verstöße
• Bis zu 5 Millionen Euro oder 1 Prozent des Umsatzes für die Bereitstellung falscher oder unvollständiger Informationen

Zusätzlich können Marktüberwachungsbehörden den Rückruf oder das Verbot eines nicht konformen Produkts anordnen.

Praktische Umsetzung: Die größten Herausforderungen

Software Bill of Materials (SBOM) erstellen

Die SBOM-Anforderung ist für viele Hersteller Neuland. Eine SBOM dokumentiert alle Software-Komponenten eines Produkts, einschließlich Open-Source-Bibliotheken, Frameworks und deren Versionen. Für ein typisches Softwareprodukt kann das Hunderte von Abhängigkeiten bedeuten, direkte und transitive.

Die gute Nachricht: Es gibt etablierte Formate (SPDX, CycloneDX) und Tools, die SBOMs automatisch aus Build-Prozessen generieren können. Die Herausforderung liegt weniger in der technischen Erstellung als in der fortlaufenden Pflege: Bei jedem Update, bei jeder neuen Version muss die SBOM aktualisiert werden. Und du musst die Komponenten in der SBOM aktiv auf bekannte Schwachstellen überwachen, nicht nur einmalig bei der Erstellung, sondern kontinuierlich über den gesamten Supportzeitraum.

Schwachstellenmanagement über den gesamten Lebenszyklus

Der CRA verlangt, dass Hersteller Schwachstellen in ihren Produkten über den gesamten Supportzeitraum (mindestens fünf Jahre) aktiv managen. Das bedeutet: Du brauchst einen Prozess, der Schwachstellen in deinen eigenen Komponenten und in Drittkomponenten identifiziert, bewertet, behebt und die Korrekturen als Sicherheitsupdates an die Nutzer ausliefert.

Für Unternehmen, die bisher Produkte nach dem Prinzip "Veröffentlichen und vergessen" entwickelt haben, ist das ein Paradigmenwechsel. Du musst Ressourcen für die langfristige Wartung einplanen, und zwar nicht nur für neue Features, sondern explizit für Sicherheitsupdates. Das hat Auswirkungen auf die Produktkalkulation, denn fünf Jahre Sicherheitssupport müssen in den Produktpreis eingerechnet werden.

Coordinated Vulnerability Disclosure

Der CRA verlangt, dass Hersteller einen Prozess für die koordinierte Offenlegung von Schwachstellen einrichten. Das bedeutet: Du brauchst eine öffentlich erreichbare Kontaktadresse (typischerweise security@dein-unternehmen.de), an die Sicherheitsforscher Schwachstellen melden können. Du brauchst einen internen Prozess, der diese Meldungen entgegennimmt, bewertet und zeitnah bearbeitet. Und du brauchst eine Richtlinie, die beschreibt, wie du mit Schwachstellenmeldungen umgehst und wie die Offenlegung koordiniert wird.

Viele mittelständische Hersteller haben bisher keinen solchen Prozess. Die Einrichtung erfordert nicht nur technische Maßnahmen (sichere Kommunikationskanäle für Schwachstellenmeldungen), sondern auch organisatorische Vorbereitung (Wer bearbeitet die Meldungen? Wie schnell muss reagiert werden? Wer entscheidet über die Veröffentlichung?).

Secure by Default

Die Anforderung "Secure by Default" bedeutet, dass Produkte in ihrer Standardkonfiguration sicher sein müssen. Keine offenen Ports, die nicht benötigt werden. Keine Standardpasswörter, die für alle Geräte gleich sind. Keine aktivierten Debug-Schnittstellen in der Produktionsversion. Verschlüsselung standardmäßig aktiviert, wo technisch möglich.

Für Hardware-Hersteller kann das bedeuten, dass die Ersteinrichtung einen Schritt umfassen muss, in dem der Nutzer ein individuelles Passwort setzt, bevor das Gerät nutzbar ist. Für Software-Hersteller kann es bedeuten, dass die Installation standardmäßig die restriktivste Konfiguration wählt und der Administrator bewusst Funktionen freischalten muss, die zusätzliche Angriffsfläche erzeugen.

Was du jetzt tun solltest

Wenn du Produkte mit digitalen Elementen herstellst, beginne jetzt mit der Vorbereitung, auch wenn die vollständigen Anforderungen erst im September 2027 gelten. Die Meldepflichten kommen bereits im Juni 2026, und die Anpassung von Entwicklungsprozessen, die Einführung von SBOM-Management und der Aufbau eines Schwachstellenmanagements brauchen Zeit.

Der erste Schritt: Inventarisiere deine Produkte und klassifiziere sie nach den CRA-Kategorien (Standard, Klasse I, Klasse II). Der zweite Schritt: Führe eine Gap-Analyse gegen die Anforderungen des Anhangs I durch. Der dritte Schritt: Priorisiere die Lücken und erstelle einen Umsetzungsplan mit realistischen Meilensteinen. In ISMS Lite lassen sich CRA-Anforderungen als Controls abbilden und der Umsetzungsfortschritt nachverfolgen.

Weiterführende Artikel

• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• DORA für den Finanzsektor: Was kommt nach NIS2?
• AI Act und Informationssicherheit: Was du über die KI-Verordnung wissen musst
• Schwachstellenmanagement aufbauen: Von der Erkennung bis zur Behebung
• Supply-Chain-Angriffe: Warum deine Lieferkette dein größtes Risiko sein kann