Die EU bezeichnet seit längerem die Sicherung der Cybersicherheit als eine der größten Herausforderungen. Im Bereich der Produktsicherheit will sie ihn durch den Cyber Resilience Act (VO 2024/2847, kurz CRA) stärken. Der CRA setzt einen umfassenden Rechtsrahmen, den Produkte mit digitalen Elementen zum Schutz der Cybersicherheit einhalten müssen. 2024 ist der CRA bereits in Kraft getreten und findet nun ab September 2026 in Teilen Anwendung. Ab Dezember 2027 ist er vollständig umzusetzen. Betroffene Unternehmen stecken damit aktuell in der “heißen” Umsetzungsphase – oder sollten es jedenfalls sein.
Einordnung in die Regulatorik
Als Teil der EU-Digitalregulierungsoffensive steht der CRA im engen Zusammenhang mit anderen Gesetzgebungsvorhaben zur Stärkung der Cybersicherheit, der Resilienz kritischer Einrichtungen und zur Regulierung künstlicher Intelligenz. Einerseits gehört er damit in einen Zusammenhang mit der NIS-2-Richtlinie, der Critical Entities Resilience-Richtlinie (CER-Richtlinie) und dem Digital Operational Resilience Act (DORA). Andererseits hat der CRA als Regulierung unter dem sogenannten New Legislative Framework (NLF) der EU Überschneidungen mit produktbezogenen Regulierungen wie dem AI Act (KI-Verordnung) oder der Maschinen-Verordnung. Entsprechend richtet er sich an die typischen Wirtschaftsakteure der Marktüberwachung – Hersteller, Händler, Einführer und Bevollmächtigte. Eine Besonderheit ist die sog. “Light touch”-Regulierung für Verwalter quelloffener Software (Open Source Stewards).
Inhaltlich gilt der CRA für alle Produkte mit digitalen Elementen, soweit sie nicht spezielleren Regulierungen unterfallen, beispielsweise in den Bereichen Automotive, Luftfahrt, Medizin oder nationale Sicherheit. Generell dürfen Produkte mit digitalen Elementen ab dem 11. Dezember 2027 nur noch auf dem EU-Markt vermarktet werden, wenn sie eine CE-Kennung aufweisen und dazu ein Konformitätsbewertungsverfahren durchlaufen haben. “Cybersecurity by Design” und “by Default” werden verbindliche Prinzipien, von denen nur im B2B-Bereich individuell und begrenzt abgewichen werden kann. Flankiert wird dies durch strenge Meldepflichten, die ein umfassendes Lagebild über Cyberangriffe in der EU ermöglichen sollen.
Der umfangreiche Pflichtenkatalog stellt betroffene Unternehmen dabei operativ vor Herausforderungen, von denen nachstehend ein paar typische Aspekte herausgegriffen werden:
Was sind Produkte mit digitalen Elementen?
Der sachliche Anwendungsbereich des CRA erfasst „Produkte mit digitalen Elementen, deren … Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.“ Der CRA verwendet insofern einen bewusst weiten, technologieneutralen Produktbegriff. Erfasst wird jedes Software- oder Hardwareprodukt, das auf dem EU-Markt bereitgestellt wird, einschließlich seiner zugehörigen Datenfernverarbeitungslösungen und separat vermarkteter Software- oder Hardwarekomponenten. So ist etwa ein Drucker mit der dazugehörigen Software ein solches CRA-Produkt. Gleiches gilt für Smart-Home-Geräte und die dazugehörigen Apps. Erforderlich ist stets, dass der vom Hersteller vorgesehene Verwendungszweck Konnektivität umfasst oder zumindest vorhergesehen werden kann. Ein Interface, das zwar nach dem Willen des Herstellers nicht genutzt werden soll, aber die Nutzung durch den Verwender nicht unwahrscheinlich ist, fällt wegen des immanenten Cybersicherheitsrisikos auch in den Anwendungsbereich des CRA.
Keine Anwendung findet der CRA dagegen grundsätzlich auf Webseiten oder Cloud-Angebote. Wenn aber Webseiten oder Cloud-Angebote die Produktfunktion unterstützen (und keine Third-Party-Standardlösung sind, wie z.B. CRM- und ERP-Software), sind diese als Datenfernverarbeitungslösung Teil des Produkts und damit durch den CRA reguliert.
Unternehmen stellt sich damit beispielsweise regelmäßig die Frage, wie weitgehend Softwarelösungen im Backend als eine direkte Produktfunktion unterstützen und damit vom CRA erfasst sind. Von der Antwort hängt ab, ob auch die Backend-Lösungen als Teil des Produktes den Pflichtenkatalog des CRA erfüllen müssen oder nicht. Auch externe Standard-Clients, die nur zum Zugriff auf eine eigene Anwendung genutzt werden, müssen im Einzelfall betrachtet werden.
Supply Chain & Due Diligence
Zu den operativen Herausforderungen gehört auch, dass den Hersteller bei der Integration von Drittkomponenten in sein Produkt mit digitalen Elementen spezifische Due Diligence Pflichten treffen. Entsprechend des risikobasierten Ansatzes richtet sich der Umfang der Pflichten nach dem Ausmaß des Cybersicherheitsrisikos und umfasst mindestens die Prüfung, ob für die Komponente selbst der Konformitätsnachweis erbracht wird und eine CE-Kennung vorliegt. Zwar unterliegt jeder Hersteller für sich den Pflichten des CRA, aber der Hersteller eines integrierten Produkts ist für dieses einschließlich der verwendeten Komponenten verantwortlich.
Unternehmen müssen die Cyber Due Diligence damit zum integralen Teil ihres Third-Party Risk Managements machen, das von der Planungsphase, dem RfP und der Lieferantenauswahl, den Vertragsverhandlungen über das Monitoring im Betrieb bis hin zum Offboarding des Lieferanten reicht und sich auch in das Compliance Management System im Übrigen einfügen muss. Im Hinblick auf den CRA wird ein CRA-konformes Cyber Security Supplier Agreement zur genauen Abgrenzung der Rollen und Zuständigkeiten und Festlegung von Service Leveln vorzuhalten sein.
Meldepflichten ab September 2026
Ab dem 11. September 2026 müssen Hersteller außerdem aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle ihrer Produkte melden. Wann genau die Meldepflicht greift, ist Gegenstand aktueller Diskussionen. Ein ganz aktuelles Beispiel ist, dass bisher offen war, ob aktiv ausgenutzte Schwachstellen auch dann zu melden sind, wenn die Ausnutzung “in the wild” in fremden Systemen erfolgt ist. Diese Frage ist hat die aktuelle KMU-Leitlinie zum CRA dahingehend beantwortet, dass die Ausnutzung in einem eigenen Produkt des Herstellers erfolgt sein muss, was die Zahl der meldepflichtigen Vorgänge deutlich reduziert.
Der Meldeprozess sieht entsprechend des etwa aus NIS-2 bekannten Schemas bis zu drei Meldungen, zeitlich gestaffelt vom Early Warning bis zur Abschlussmeldung, vor. Für die Zwecke der Meldungen und zur Vereinfachung der Meldepflichten der Hersteller hat die ENISA online die “CRA Single Reporting Platform” (SRP) eingerichtet. Eine Meldung hat auch gegenüber den Nutzern zu erfolgen. Dabei unterscheidet der CRA zwischen „betroffenen Nutzern“ und „allen Nutzern“ des Produkts. Letztere sind nur „gegebenenfalls“ zu informieren. Wann dieser Fall eintritt und ein Nutzer als betroffen gilt, wirft vielen Fragen auf und muss von Unternehmen intern in Verfahrensanweisungen konkretisiert werden.
Technische Umsetzung der Cybersicherheit
Auch bei der technischen Umsetzung zeigen sich erhebliche operative Herausforderungen. So sind Security Tests und technische Cybersecurity Risikoanalysen künftig als Teil der normalen Entwicklungstätigkeit und im gesamten Lebenszyklus zu verankern. Damit steigt beispielsweise der Betriebsaufwand.
Die Durchführung oder Aktualisierung von Risikoanalysen und notwendige Maßnahmen zur Risiko-Mitigation führen zu erheblichen Mehraufwänden. Hersteller sollten ihren Entwicklern daher klare Anweisungen im Hinblick auf die Änderungen an Produkten und Updates geben, damit stets klar ist, wann durch eine Änderung eine neue Risikoanalyse ausgelöst wird. Beispielsweise ist empfehlenswert, präzise Schwellwerte zu definieren, ab denen eine veränderte Softwarebibliothek oder ein anderes Bauteil als wesentliche Änderung gilt.
Hersteller von im Markt befindlichen Produkte sind nicht zwingend vom CRA ausgenommen. Wenn die Produkte “wesentlich geändert“ werden, fallen sie nachträglich in den Anwendungsbereich. Besonders betrifft dies langlebige Produkte wie industriellen Anlagen. Gerade Anlagen- und Maschinenbauer sehen sich besondere neuen Herausforderungen gegenüber, weil Anforderungen wie die Erstellung von SBOMs in den dort üblichen Entwicklungsumgebungen oft schwieriger umzusetzen sind als z.B. in der Software- oder FinTech-Branche, wo CI/CD Pipelines üblich sind.
Best Practice und Hilfestellung
Im Markt hat sich als Best Practice bei der Implementierung ein interdisziplinärer Ansatz bewährt, bei dem rechtliche, cybersicherheits-technische und Compliance-Management-Expertise im Projekt integraler Bestandteil sind.
Zudem hat die Kommission für Normadressaten ein FAQ und Ende Juli 2026 eine Leitlinie für kleine und mittlere Unternehmen veröffentlicht (KMU-Leitlinie). In technischer Hinsicht können Unternehmen auf die Technische Richtlinie des BSI sowie als horizontaler harmonisierter Standard die DIN EN 40000-1-1-3 (im Entwurf) zugreifen. Hinzu werden vertikale harmonisierte Standards für die wichtigen und kritischen Produkte der Anhänge III und IV kommen.
Kernaussagen
- Der CRA schafft einen einheitlichen europäischen Rechtsrahmen für Cybersicherheitsanforderungen an digitale Produkte und steht als Teil der EU-Digitalregulierungsoffensive in einem engen Wirkungszusammenhang mit NIS-2, DORA, KI-VO und der neuen Maschinen-VO.
- Bei der Integration von Drittkomponenten treffen Hersteller spezifische Due-Diligence-Pflichten. Die vertragliche Absicherung gegenüber Lieferanten – insbesondere durch CRA-konforme Cyber Security Supplier Agreements – ist essenziell für das Third-Party Risk Management
- Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die ENISA Single Reporting Platform melden.
- Besonders im Mittelstand und im Maschinenbau ist die Umsetzung anspruchsvoll, da er sich z.B. wesentlich auf die tägliche Entwicklungsarbeit und den gesamten Lebenszyklus auswirkt und auch technische Änderungen an Produkten nach sich zieht.
