Der Cyber Resilience Act („CRA“) stellt eine zentrale europäische Produktsicherheitsverordnung dar, die den regulatorischen Rahmen für die Cybersicherheit von Produkten mit digitalen Elementen festlegt. Er reiht sich ein in eine Serie jüngst verabschiedeter europäischer Digitalgesetze, die auf eine Stärkung der IT-Sicherheit abzielen. Allerdings scheint sich der CRA im Schatten der übrigen Digitalgesetze zu bewegen, obwohl er bereits in Kraft getreten ist. Der Fokus der meisten Unternehmen liegt auf dem NIS2-Umsetzungsgesetz (NIS: Schutz von Netzwerk- und Informationssystemen), dessen Verabschiedung nach Bundestags- und Bundesratsbefassung für Ende 2025/Anfang 2026 erwartet wird, und dem Digital Operational Resilience Act („DORA“), der seit dem 17.01.2025 anwendbar ist und von der Finanz- sowie Versicherungswirtschaft einen einheitlichen – gesteigerten – IT-Sicherheitsstandard fordert.
Im Spannungsfeld zwischen Data Act, KI-Verordnung und den klassischen Fragen der DSGVO müssen sich betroffene Unternehmen zusätzlich mit dem CRA auseinandersetzen. Da ein erheblicher Teil der Anforderungen des CRA erst Ende 2027 umfassend anwendbar sein werden, liegt bei vielen Unternehmen der Fokus auf der etwaigen Erfüllung der noch vorher für sie verpflichtend werdenden Gesetze. Angesichts begrenzter personeller und finanzieller Ressourcen sowie einer zunehmenden Digitalrechtsumsetzungsfatigue erscheint dies nachvollziehbar. Dennoch ist in Anbetracht langer Entwicklungszyklen eine frühzeitige Auseinandersetzung mit den Anforderungen des CRA erforderlich, um sicherzustellen, dass die eigenen Produkte ab Ende 2027 in der Europäischen Union vertrieben werden können. Daneben müssen Hersteller schon ab dem 11.09.2026 Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit von Produkten mit digitalen Elementen beachten. Um die kurze Frist von 24 Stunden für eine Frühwarnung einhalten zu können und währenddessen kurzfristig die richtigen Instanzen im Unternehmen einzubinden, ohne dass es zu Stillstand oder Fehlentscheidungen kommt, müssen Eskalationsprozesse bestehen, die nicht nur formal existieren, sondern auch gelebt werden. Sofern schon eingeübte Eskalationsprozesse für den Umgang mit Meldungen und Benachrichtigungen bei Datenpannen existieren, können die CRA-Meldepflichten hieran angelehnt werden.
Anforderungen nach dem CRA
Der CRA folgt in Anlehnung an die DSGVO und andere Digitalgesetze wie DORA und NIS2 dem sogenannten risikobasierten Ansatz. Danach muss ein Unternehmen, das CRA-regulierte Produkte vertreibt, einen umfassenden Risikomanagementrahmen aufsetzen. Betroffene Unternehmen müssen dafür die eigenen Risiken kennen, angemessene risikoverringernde Maßnahmen ergreifen und deren Wirksamkeit überprüfen. Dieser Zyklus von Risikoerkennung, Maßnahmenengreifung und Maßnahmenüberprüfung muss dabei regelmäßig wiederholt werden.
Diese Verpflichtung gilt dabei für „Produkte mit digitalen Elementen“, die in der Europäischen Union in Verkehr gebracht werden. Nach dem CRA sind „Produkte mit digitalen Elementen“ solche, die über eingebaute digitale Komponenten Funktionen ausführen oder Daten verarbeiten. Dazu zählen beispielsweise Geräte oder Maschinen mit Softwaresteuerung, Produkte mit Vernetzungsschnittstellen sowie Hardware, in die Software integriert ist und die für den Betrieb des Produkts wesentlich ist. Kurz gesagt umfasst die Verordnung alle physischen Produkte, deren Funktionalität direkt oder indirekt von digitalen Elementen abhängt.
Grundlegende Sicherheitsanforderungen
Im Kern verlangt der CRA in seinem Anhang I die Erfüllung grundlegender Sicherheitsanforderungen, die die Minimierung bekannter Schwachstellen, den Schutz der Vertraulichkeit, Integrität und Verfügbarkeit sowie die Einführung wirksamer Zugriffsbeschränkungen und Authentifizierungssysteme zum Gegenstand haben. Teil hiervon ist auch die Implementierung eines Schwachstellenmanagements. Angesichts immer komplexer werdender Technik und der damit stetig wachsenden Gefahr des Bestehens und Ausnutzens von Sicherheitslücken gewinnt das Schwachstellenmanagement immer mehr an Relevanz.
Systematische Risikobewertung und „Softwarestückliste“
Für jedes CRA-regulierte Produkt muss eine systematische Risikobewertung nach Art. 13 Abs. 2 bis 3 CRA vorgenommen werden, wobei die potentiellen Cyberrisiken bereits in der Konzeptionierungsphase des Produkts und sodann fortlaufend bewertet werden müssen.
Hinzu tritt die Verantwortlichkeit für in den Produkten eingesetzte Drittkomponenten, insbesondere Open-Source-Bibliotheken. Aus diesem Grund muss für jedes Produkt eine sogenannte Softwarestückliste geführt werden. Diese „Software Bill of Materials“ (SBOM) ermöglicht es, bei Bekanntwerden von Schwachstellen umgehend nachzuvollziehen, inwiefern die eigenen Produkte betroffen sind, so dass angemessene Gegenmaßnahmen eingeleitet werden können. Dies ist auch relevant in Bezug auf die Meldepflichten bei Schwachstellen und Sicherheitsvorfällen (vgl. Art. 13 und Art. 14 CRA).
Neben Informationspflichten gegenüber Nutzern, zum Beispiel Anleitungen für die sichere Installation und Inbetriebnahme, müssen Hersteller sicherstellen, dass das Produkt für die gesamte erwartetet Nutzungsdauer, mindestens jedoch fünf Jahre, Sicherheitsupdates erfährt.
Wie Unternehmen vorgehen können
Ein häufiges Problem bei der Umsetzung vieler Digitalakte liegt – gemessen am Maßstab dieser neuen Gesetze – in der oftmals unvollständigen und inkonsistenten Dokumentation in den Unternehmen.
Der risikobasierte Ansatz verlangt von den Unternehmen, die Risiken sowie die sie mitigierenden Maßnahmen zu dokumentieren und sie regelmäßig einer dokumentierten Wirksamkeitsprüfung zu unterziehen. Es reicht nicht mehr aus, standardisierte Checklisten abzuarbeiten. Vielmehr muss man die unternehmensindividuellen Risiken ermitteln und entsprechend maßgeschneiderte Sicherheitsmaßnahmen implementieren, um eine Abstimmung auf das jeweilige Produkt zu gewährleisten. Da diese Herangehensweise für viele der betroffenen Unternehmen – jedenfalls im Bereich der Produktsicherheit digitaler Produkte – ein Umdenken erfordert, muss auch hier ein Risikomanagementrahmen etabliert werden.
Ein ähnliches Defizit zeigt sich beim Schwachstellenmanagement: Unternehmen haben teils keine oder nur unzureichende Dokumentationen darüber, wie Schwachstellen identifiziert, bewertet und behandelt werden. Zudem ist oft unklar, welche Stelle im Unternehmen für das Schwachstellenmanagement verantwortlich ist.
Sicherlich können viele Unternehmen ad hoc reagieren und Schwachstellen bei Gefahr in Verzug identifizieren. Allerdings erfolgt dies meist ohne Einbettung in einen formalisierten Prozess, die in Zukunft vom CRA vorausgesetzt wird.
Im ersten Schritt empfiehlt sich eine umfassende Bestandsaufnahme mit anschließender Lückenanalyse (Gap-Analyse), um zu ermitteln, in welchen Fachabteilungen bereits verwertbare Dokumentationen vorliegen, die lediglich angepasst oder erweitert werden müssen, und wo ein vollständiger Neuaufbau erforderlich ist. Sodann sollten die Rollen und Verantwortlichkeiten im CRA-Umsetzungsprojekt geklärt und interdisziplinäre Teams – bestehend aus Entwicklung, IT, Recht und Management – gebildet werden, die über den Fortschritt regelmäßig berichten.
Inhaltliche Umsetzung des CRA
Einer der ersten inhaltlichen Schritte dürfte die Klassifizierung der einzelnen Produkte entsprechend dem Anhang III zum CRA zum Gegenstand haben. Das Ergebnis entscheidet darüber, ob nur die grundlegenden Cybersicherheitsanforderungen für einzelne Produkte gelten oder weitergehende Pflichten. Letzteres ist beispielsweise der Fall, wenn es sich um kritische Produkte wie Firewalls oder Intrusion-Detection-Systeme handelt.
Die Anforderungen des CRA sollten tief in die Produktentwicklung eingreifen und Sicherheit durch Gestaltung und entsprechende Voreinstellungen gewährleisten. Daher müssen aktuelle Einstellungen überprüft, bei Bedarf angepasst und dokumentiert werden. Dabei ist an die Integration einer Bedrohungsmodellierung („Threat Modeling“) und umfassender Risikoanalysen in der Produktentwicklung zu denken. Auch sollten sichere Entwicklungsstandards, zum Beispiel OWASP (Open Web Application Security Project), und automatisierte Tests zum Pflichtrepertoire gehören. All das wird zwangsläufig zur Stärkung der DevSecOps-Kultur, das heißt der Integration von Sicherheit in alle Phasen der Softwareentwicklung, führen. Dann wird, so das Ziel des EU-Gesetzgebers, die Sicherheit kein nachgelagerter Schritt mehr sein, sondern von Anfang an integriert werden.
Eine weitere gesetzliche Anforderung ist die Einführung eines strukturierten Schwachstellenmanagements. Es müssen dokumentierte Prozesse zur Erkennung, Bewertung und Behebung von Sicherheitslücken vorhanden sein, und die Behebung von Schwachstellen darf nicht dem Zufall überlassen werden.
Daneben lohnt es sich, eine Kommunikationsstrategie zu entwickeln, um transparent über Schwachstellen und Updates zu informieren, ohne hierbei die Reputation des Unternehmens zu beschädigen. Schließlich ist das Auftreten von Schwachstellen normal, es geht daher vielmehr um die Frage, wie man damit rechtskonform und reputationswahrend umgeht.
Angesichts der Tatsache, dass Softwarebestandteile nicht ausschließlich unternehmensintern entwickelt werden, sondern häufig aus Auftragsentwicklungen stammen, ist eine sorgfältige Prüfung der entsprechenden Verträge unerlässlich. Im besten Fall verpflichten die Verträge den Entwickler schon, die Software nicht nur gemäß den beauftragten Spezifikationen, sondern auch unter Einhaltung der regulatorischen Anforderungen des Auftraggebers zu entwickeln. Sollte dies nicht der Fall sein, empfiehlt es sich, frühzeitig Vertragsanpassungen vorzunehmen und neue Vereinbarungen mit entsprechenden Verpflichtungen abzuschließen. Der Auftragnehmer sollte unbedingt eine detaillierte SBOM erstellen, um dem Auftraggeber die Erfüllung seiner Pflichten gemäß dem CRA zu ermöglichen.
Auch eine Schulungsstrategie ist unerlässlich, damit Entwickler sichere Programmierpraktiken anwenden, die IT-Teams das Schwachstellenmanagement beherrschen und im Fall eines Incidents entsprechend den aufgestellten Richtlinien darauf reagieren. Die Umsetzung des CRA ist nicht nur Aufgabe der erweiterten IT-Abteilung, sondern Chefsache. Daher müssen sowohl die Geschäftsführung als auch der Einkauf und Vertrieb zu den rechtlichen und geschäftlichen Implikationen des CRA geschult werden. Eine wertvolle Hilfestellung, insbesondere für KMU, bietet die dreiteilige technische Richtlinie TR-03183 des BSI.
Fazit
Obwohl die Umsetzung des CRA angesichts der Vielzahl neuer digitalrechtlicher Regelwerke derzeit bei vielen Unternehmen in den Hintergrund tritt, dürfen die Anforderungen und Pflichten des CRA keinesfalls vernachlässigt werden. Damit Produkte mit digitalen Elementen künftig in der EU vertrieben werden können, ist an verschiedenen Stellen ein strategisches Umdenken erforderlich.
Der Grundstein für eine erfolgreiche Umsetzung darf angesichts langer Entwicklungszyklen nicht erst im Jahr 2027 gelegt werden, sondern muss bereits jetzt vorbereitet werden. Unternehmen, die frühzeitig mit der Analyse, Planung und Anpassung ihrer Prozesse beginnen, sichern sich nicht nur regulatorische Compliance, sondern schaffen zugleich Wettbewerbsvorteile und stärken damit ihre Resilienz in einem zunehmend komplexen digitalen Umfeld.
