Mit dem Cyber Resilience Act (CRA) hat die Europäische Union erstmals ein umfassendes Regelwerk für Cybersicherheitsanforderungen an Produkte mit digitalen Elementen geschaffen. Auch wenn die Verordnung erst im Dezember 2027 vollständig anwendbar sein wird, sollten Unternehmen die neuen Pflichten nicht auf die lange Bank schieben. Die Umsetzung erfordert teilweise tiefgreifende Anpassungen in Produktentwicklung, Lieferketten, Dokumentation und Vulnerability-Management – Prozesse, die erfahrungsgemäß erhebliche Vorlaufzeiten benötigen. Auf Unionsebene laufen bereits intensive Vorbereitungen und Konkretisierungen der Vorgaben. So hat die Europäische Kommission kürzlich ergänzend zu ihren im Dezember 2025 veröffentlichten FAQs eine erste Guidance zum CRA publiziert. Ihre DORDA CRA Experten haben einige wichtige Erkenntnisse daraus gerne für Sie zusammengefasst:
Klarstellungen zur Produktdefinition
Der CRA lässt eine zentrale Legaldefinition vermissen – jene des Produkts. Die Guidance geht nun teilweise auf dieses Thema ein: Sie stellt klar, dass Software, die dazu dient, eine Hardware zu steuern, zu bedienen, zu konfigurieren oder erforderlich ist, um sie ordentlich nutzen zu können, Teil des gesamthaften (Hardware-)Produkts ist. Das gilt auch dann, wenn sie separat bezogen wird (zB eigener Download). Im Übrigen kann sowohl der Machine- als auch Source Code Software im Sinne des CRA sein – ein zur Produkthaftungs-RL abweichendes weitergehendes Verständnis.
Inverkehrbringen und Bereitstellung
Eine der Grundvoraussetzungen für die Anwendbarkeit des CRA ist außerdem das Inverkehrbringen bzw die Bereitstellung in der Kette am Unionsmarkt. In Bezug auf traditionell vernetzte Hardware stellt die Kommission auf das Angebot des einzelnen individuellen Produkt(stück)s ab. Bei digital bereitgestellter Standalone Software ist die erstmalige Bereitstellung zur Weitergabe oder Nutzung auf dem EU Markt einschlägig. Es ist damit unbeachtlich, wenn ein Kunde den Download erst zu einem späteren Zeitpunkt vornimmt. Spätere Versionen lösen nur dann ein neues Inverkehrbringen – und wiederum die Herstellerpflichten – aus, wenn damit eine wesentliche Änderung einhergeht.
Open-Source-Software (OSS)
Für OSS Software, die entweder unter der FOSS Lizenz verbreitet wird oder dessen Source Code öffentlich geteilt wird, gibt es Spezialregelungen:
- Wird OSS am Markt monetarisiert (zB Bezahlung mit Entgelt oder Daten), gilt der Anbieter grundsätzlich als Hersteller und unterliegt dem weiten Pflichtenspektrum.
- Erfolgt hingegen keine marktbezogene Bereitstellung, kann eine Einstufung als "Verwalter quelloffener Software" in Betracht kommen: Diese Akteure fördern die Entwicklung von OSS systematisch und nachhaltig für kommerzielle Tätigkeiten, ohne selbst Hersteller zu sein. Sie unterliegen nur eingeschränkten Dokumentations- und Meldepflichten. Bußgeldvorschriften gelten für sie nicht.
- Hersteller, die OSS-Komponenten in ihre Produkte integrieren, bleiben auch für die Cybersicherheit verantwortlich. Dies unabhängig davon, ob die OSS selbst unmittelbar unter den CRA fällt. Die OSS unterliegt als Komponente der Due Diligence Pflicht des Herstellers des Endprodukts. Dies ist in der Praxis mit großen Herausforderungen verbunden. Zur Unterstützung der Konformitätsbewertung plant die Kommission freiwillige Programme zur Zertifizierung der Cybersicherheit solcher OSS Komponenten.
Wesentliche Änderungen
Führt ein Händler oder Importeur wesentliche Änderung eines zugekauften Produkts durch, kann er als Hersteller umqualifiziert werden – mit allen dadurch erweiterten Compliance-Anforderungen. Die vorliegende Guidance definiert näher, wann ein solcher Wechsel eintritt. Bei Software Updates ist zB ganz maßgeblich darauf abzustellen, ob sich die Risikobewertung dadurch ändert – zB durch neu geschaffene Angriffsvektoren. Es bedarf dazu stets einer einzelfallbezogenen Beurteilung.
Ihre DORDA Cybersecurity Experten halten Sie zu den weiteren Entwicklungen auf dem Laufenden und unterstützen Sie gerne bei Ihrem CRA-Implementierungsprojekt.