Warum der Cyber Resilience Act jetzt auf die Agenda von Geschäftsführungen gehört

Datenschutz, Informationssicherheit, NIS2 und die KI-Verordnung beschäftigen derzeit zahlreiche Unternehmen. Mit dem Cyber Resilience Act (CRA) kommt ein weiteres Regelwerk hinzu – und es gilt in Teilen bereits seit dem 11. September 2026. Der CRA ist ein EU-Gesetz, das Unternehmen, die Software oder vernetzte Geräte herstellen, importieren oder verkaufen, verpflichtet, ihre Produkte über die gesamte Nutzungsdauer gegen Cyberangriffe abzusichern – von der Entwicklung bis zum letzten Sicherheitsupdate. Wer das nicht nachweisen kann, darf sein Produkt ab Dezember 2027 in der EU nicht mehr verkaufen.

Während Datenschutz und Informationssicherheit in vielen Organisationen bereits etablierte Themen sind, wird der CRA häufig noch als reine IT-Anforderung wahrgenommen. Tatsächlich handelt es sich jedoch um weit mehr als eine technische Vorgabe. Der CRA schafft erstmals europaweit verbindliche Anforderungen an die Cybersicherheit von Software und vernetzten Geräten („Produkte mit digitalen Elementen“) und macht deren Einhaltung zur Voraussetzung dafür, dass ein Produkt in der EU überhaupt verkauft werden darf.

Der CRA ist kein Thema nur für die Entwicklung von Softwareprodukten

Auf den ersten Blick scheint der CRA vor allem Entwicklungsabteilungen zu betreffen. Schließlich stehen Anforderungen wie Sicherheit von Anfang an im Produktdesign („Security by Design“), sichere Voreinstellungen ab Werk („Security by Default“), ein geregelter Umgang mit Sicherheitslücken oder regelmäßige Sicherheitsupdates im Mittelpunkt. Bei genauerem Hinsehen wird jedoch deutlich, dass die Umsetzung weit über die Entwicklung hinausgeht.

Geschäftsführungen müssen Verantwortlichkeiten festlegen, Ressourcen bereitstellen und sicherstellen, dass angemessene Prozesse eingerichtet werden. Produktverantwortliche, Qualitätsmanagement, Einkauf, Informationssicherheit und Compliance müssen zusammenarbeiten, um regulatorische Anforderungen nachweisbar umzusetzen.

Die entscheidende Frage lautet daher nicht allein:
„Ist unser Produkt sicher?“

Sondern zunehmend:
„Können wir die Sicherheit unseres Produkts und die Einhaltung der regulatorischen Anforderungen nachvollziehbar nachweisen?“

Genau hier beginnt das eigentliche Compliance-Thema!

Welche Produkte können betroffen sein?

Viele Unternehmen gehen davon aus, dass der CRA ausschließlich klassische Softwarehersteller betrifft. Tatsächlich ist der Anwendungsbereich deutlich breiter – und er trifft nicht nur Hersteller, sondern auch Importeure und Händler, etwa wenn Geräte aus Drittländern unter eigener Marke vertrieben werden. Je nach Ausgestaltung können beispielsweise betroffen sein:

• Branchensoftware und Fachanwendungen
• Mobile Apps
• Cloud-Anbindungen von Produkten (z. B. App und Cloud-Dienst eines vernetzten Geräts)
• IoT-Produkte und vernetzte Geräte
• Smart-Home-Komponenten
• Netzwerk- und Kommunikationslösungen
• Industrielle Steuerungs- und Automatisierungssysteme
• Sicherheitssoftware
• Digitale Gesundheitsprodukte
• Produkte mit eingebetteter Software

Ob ein konkretes Produkt tatsächlich in den Anwendungsbereich des CRA fällt, hängt von der jeweiligen technischen und regulatorischen Einordnung ab und sollte im Einzelfall geprüft werden. Gerade viele mittelständische Unternehmen stellen bei einer ersten Analyse fest, dass sie deutlich stärker betroffen sind als ursprünglich angenommen.

Die CRA-Betroffenheitsprüfung

Der CRA gilt nach Art. 2 Abs. 1 für Produkte mit digitalen Elementen, die in der EU auf den Markt kommen und mit einem Gerät oder Netzwerk verbunden werden können.

Daraus ergeben sich drei zentrale Prüffragen:

1. Handelt es sich um ein Produkt mit digitalen Elementen (z. B. Software, Hardware oder zugehörige digitale Komponenten)?
2. Wird das Produkt auf dem EU-Markt bereitgestellt?
3. Besteht eine direkte oder indirekte Verbindung zu Geräten oder Netzwerken?

Werden diese Voraussetzungen erfüllt, fällt das Produkt grundsätzlich in den Anwendungsbereich des CRA. Anschließend ist zu prüfen, ob besondere europäische Regelungen oder Ausnahmen eine abweichende Einordnung vorsehen.

Ausnahmen

Produkte mit eigenen EU-Sicherheitsregeln
Für einige Branchen hat der europäische Gesetzgeber bereits eigene Sicherheits- und Zulassungsregeln geschaffen. In diesen Bereichen tritt der CRA ganz oder teilweise in den Hintergrund.

Beispiele:

• Medizinprodukte und In-vitro-Diagnostika (MDR/IVDR)
• Fahrzeuge und Fahrzeugkomponenten
• Luftfahrtprodukte
• einzelne weitere hochregulierte Produktgruppen

Rein nicht-kommerzielle Open-Source-Software
Wer Software als Open Source entwickelt und veröffentlicht, ohne dabei eine kommerzielle Tätigkeit auszuüben, fällt grundsätzlich nicht unter den CRA. Sobald jedoch Support-, Hosting-, Wartungs- oder Vertriebsmodelle mit kommerziellem Bezug hinzukommen, ist eine erneute Prüfung erforderlich.

Produkte für nationale Sicherheit und Verteidigung
Produkte, die ausschließlich für Verteidigungs- oder Sicherheitszwecke bestimmt sind, unterliegen regelmäßig besonderen Regelungen außerhalb des CRA.

Was verlangt der CRA konkret?

Der CRA verfolgt das Ziel, Cybersicherheit über den gesamten Lebenszyklus eines Produkts hinweg sicherzustellen.

Dazu gehören unter anderem:

• Prüfung, welche Sicherheitslücken ein Produkt haben könnte und welche Schutzmaßnahmen erforderlich sind
• Sicherheit von Anfang an in Entwicklung und Design einplanen
• Sichere Grundeinstellungen
• Ein geregelter Umgang mit Sicherheitslücken, inklusive Meldeweg
• Sicherheitsupdates während der gesamten Nutzungsdauer – mindestens fünf Jahre
• Eine „Stückliste“ aller Software-Bausteine im Produkt (Software Bill of Materials, SBOM)
• Bereitstellung sicherheitsrelevanter Informationen für Anwenderinnen und Anwender

Viele dieser Anforderungen erinnern an bereits bekannte Compliance-Themen. Neu ist jedoch, dass die Cybersicherheit des Produkts selbst regulatorisch in den Mittelpunkt rückt.

Ein Beispiel: Ein Anbieter von Zeiterfassungssoftware liefert dazu ein Terminal für den Eingangsbereich. Software, Gerät, Netzwerkverbindung – das Produkt fällt unter den CRA. Der Anbieter muss ab Ende 2027 belegen können, dass er die Risiken bewertet hat, wie er Sicherheitsupdates ausliefert, welche Software-Bausteine im Produkt stecken und auf welchem Weg Sicherheitslücken gemeldet und behoben werden. 

CRA und Zertifizierung: Das häufigste Missverständnis

In Gesprächen mit Geschäftsführungen taucht regelmäßig dieselbe Frage auf:
„Müssen wir unser Produkt jetzt zertifizieren lassen?“
Die kurze Antwort lautet:
Nicht zwangsläufig.
Der CRA sieht verschiedene Verfahren vor, mit denen die Einhaltung der Anforderungen geprüft wird (die sogenannte Konformitätsbewertung). Für die meisten Produkte darf der Hersteller diese Prüfung selbst durchführen. Nur für besonders kritische Produktkategorien – etwa Passwortmanager, Firewalls oder Smart-Meter-Komponenten – ist eine externe Prüfstelle vorgeschrieben.

Entscheidend ist jedoch ein anderer Punkt:
Es reicht nicht, die Einhaltung der Anforderungen zu erklären. Der CRA verlangt Nachweise, die eine Behörde im Zweifel prüfen kann.
Unternehmen müssen dokumentieren können,

• wie Risiken bewertet wurden,
• welche Sicherheitsmaßnahmen umgesetzt wurden,
• wie mit Schwachstellen umgegangen wird,
• welche Software-Bausteine von Dritten im Produkt stecken,
• und wie die Einhaltung der regulatorischen Anforderungen sichergestellt wird.

Ist diese Prüfung abgeschlossen, erhält das Produkt die CE-Kennzeichnung – Cybersicherheit wird damit Teil des CE-Zeichens, das viele Geschäftsführungen bereits aus anderen Produktvorschriften kennen. Die eigentliche Herausforderung ist daher häufig nicht die Frage einer Zertifizierung, sondern die Dokumentation, mit der ein Unternehmen die Einhaltung belegen kann.

Die Fristen sollten ernst genommen werden

Die Pflicht, aktiv ausgenutzte Sicherheitslücken und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden zu melden, gilt bereits seit dem 11. September 2026. Die wesentlichen Anforderungen des CRA müssen ab dem 11. Dezember 2027 eingehalten werden. Verstöße können mit Bußgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden; zudem können Produkte vom Markt genommen werden.

Auch wenn der Dezember 2027 noch weit entfernt erscheint, zeigen Erfahrungen mit DSGVO und NIS2, dass die organisatorische Umsetzung, Prozessgestaltung und Dokumentation häufig deutlich mehr Zeit beanspruchen als erwartet. 

Warum der CRA ein Compliance-Thema ist

Aus unserer Beratungspraxis zeigt sich zunehmend, dass regulatorische Anforderungen enger zusammenwachsen. Datenschutz verlangt Verzeichnisse, Verantwortlichkeiten und Nachweise. Informationssicherheit fordert Risikomanagement und geeignete Schutzmaßnahmen. NIS2 stellt Anforderungen an Governance und Sicherheitsstrukturen. Der Cyber Resilience Act ergänzt diese Entwicklung um verbindliche Anforderungen an die Cybersicherheit digitaler Produkte. Die gemeinsame Herausforderung besteht nicht allein in der Technik, sondern darin, dass eine Organisation solche Anforderungen dauerhaft umsetzt und das auch belegen kann.

Fazit

Der Cyber Resilience Act sollte nicht als reines IT-Projekt verstanden werden.

Für viele Unternehmen wird er zu einem neuen Baustein ihrer Compliance-Organisation. Geschäftsführungen, Produktverantwortliche, Entwicklungsabteilungen und Compliance-Verantwortliche sollten frühzeitig prüfen, ob eigene Produkte betroffen sind und welche Nachweise künftig erforderlich werden.

Nicht die technische Umsetzung einzelner Sicherheitsmaßnahmen dürfte für viele Organisationen die größte Herausforderung darstellen. Entscheidend wird sein, Cybersicherheit strukturiert zu organisieren, Verantwortung zuzuweisen und die Einhaltung der Anforderungen nachvollziehbar dokumentieren zu können.

Genau darin liegt die eigentliche Bedeutung des Cyber Resilience Act: Er macht Cybersicherheit zu einer Management- und Compliance-Aufgabe.

Sie sind unsicher, ob Ihre Produkte betroffen sind? In einem kurzen Erstgespräch klären wir gemeinsam, ob der CRA für Sie gilt und welche Nachweise Sie ab 2027 vorhalten müssen.