Mit dem Inkrafttreten des Cyber Resilience Act (Verordnung (EU) 2024/2847, im Folgenden: CRA) rückt für viele Unternehmen die Frage in den Fokus, ob eigene Produkte unter den Anwendungsbereich dieser neuen EU-Verordnung fallen. Die Beantwortung dieser Frage erfordert eine strukturierte, mehrstufige Prüfung. Im Folgenden wird ein systematisches Prüfungsschema dargestellt, das sich als Compliance-Werkzeug oder als Bestandteil eines technischen Produktworkflows eignet.
1. Sachlicher Anwendungsbereich: Produkt mit digitalen Elementen (PDE)
Erste Voraussetzung für die Anwendbarkeit des CRA ist, dass es sich um ein Produkt mit digitalen Elementen (PDE) im Sinne des Art. 3 Nr. 1 CRA handelt. Die Legaldefinition erfasst Software- und Hardwareprodukte (legaldefiniert in Art. 3 Nr. 4 bzw. Nr. 5 CRA), einschließlich getrennter Komponenten. Entscheidend ist, dass das Produkt digitale Logik enthält oder auf Software bzw. Firmware basiert.
Systematisch hiervon zu unterscheiden sind Datenfernverarbeitungslösungen im Sinne des Art. 3 Nr. 2 CRA. Diese betreffen entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird und ohne die das PDE eine seiner Funktionen nicht erfüllen könnte. Typisches Beispiel: Eine smarte Türklingel, deren Personenerkennung auf den Cloud-Servern des Herstellers ausgeführt wird. Die Datenfernverarbeitungslösung unterliegt einem eigenen, eingeschränkten Pflichtenregime (Art. 12 CRA) und sollte bei der Compliance-Prüfung gesondert erfasst werden.
Wichtig: Auch Software oder Hardware, die nicht vom Hersteller selbst erstellt wurde, ist vom Anwendungsbereich erfasst – das gilt ausdrücklich auch für integrierte Open-Source-Komponenten. Art. 13 Abs. 5 CRA verpflichtet den Hersteller, die CRA-Konformität solcher Drittkomponenten sicherzustellen.
Abgrenzung: Reine SaaS-Lösungen
Reine SaaS-Lösungen (Software as a Service), die kein Backend eines PDE bilden, sind nach aktuellem Meinungsstand nicht vom CRA erfasst. Sofern die Cloud-Lösung jedoch integraler Bestandteil eines PDE ist – also als Datenfernverarbeitungslösung im Sinne des Art. 3 Nr. 2 CRA fungiert –, unterfallen die cloud-seitigen Komponenten dem CRA. Eigenständige Cloud-Dienste dürften hingegen regelmäßig der NIS-2-Richtlinie (umgesetzt im BSI-Gesetz) unterfallen.
2. Datenverbindung: Direkte oder indirekte Konnektivität
Ein PDE unterfällt dem CRA nur, wenn es eine direkte oder indirekte Datenverbindung im bestimmungsgemäßen Gebrauch oder der vorhersehbaren Nutzung aufweist. Der CRA definiert den Begriff „Datenverbindung“ nicht abschließend; Auslegungsgrundlage sind Art. 3 Nr. 1 i. V. m. ErwGr 9 CRA. Folgende Konstellationen kommen in Betracht:
- Direkte physische Verbindung: Das Produkt stellt eine Datenverbindung mit physikalischen Mitteln her, d. h. über elektrische, optische oder mechanische Anschlüsse, Kabel oder Funk (z. B. Ethernet, USB, CAN, SPI, RS485, WiFi, BLE, Zigbee, LoRa).
- Direkte logische Verbindung über Softwareschnittstellen: Software-APIs, Protokolle (z. B. HTTPS/REST-API, MQTT, OPC UA) oder sonstige softwarebasierte Anbindungen, auch wenn diese derzeit inaktiv sind.
- Indirekte Verbindung (Art. 3 Nr. 10 CRA): Das Produkt stellt eine Verbindung nicht direkt her, sondern als Teil eines größeren Systems, das seinerseits direkt verbunden werden kann. Beispiel: Ein Sensor funkt nur an ein Gateway; das Gateway hängt am Internet – der Sensor ist damit indirekt verbunden.
- Cloud-Bezug: Cloudbasierte Datenverarbeitung, die zur Produktfunktionalität erforderlich ist, begründet ebenfalls eine Verbindung (vgl. Art. 3 Nr. 2 CRA).
Sind keine dieser Verbindungen einschlägig, ist der CRA nicht anwendbar.
Hinweis: Ob eine rein passive Schnittstelle (z. B. ein Debug-Port, der im Normalbetrieb nicht aktiviert ist) bereits eine relevante Datenverbindung begründet, ist dogmatisch nicht abschließend geklärt. Entscheidend dürfte sein, ob die Verbindung im bestimmungsgemäßen Gebrauch oder bei vernünftigerweise vorhersehbarer Verwendung (Art. 3 Nr. 24 CRA) zum Tragen kommt – hierzu sogleich.
3. Zweckbezug: Bestimmungsgemäßer Gebrauch / vorhersehbare Nutzung
Eine Datenverbindung ist nur dann CRA-relevant, wenn sie Teil des bestimmungsgemäßen Produktzwecks oder der vernünftigerweise vorhersehbaren Verwendung ist. Die „vernünftigerweise vorhersehbare Verwendung“ definiert Art. 3 Nr. 24 CRA als eine Verwendung, die sich – auch wenn sie nicht der Zweckbestimmung entspricht – aus vernünftigerweise vorhersehbarem menschlichem Verhalten oder aus technischen Vorgängen oder Wechselwirkungen wahrscheinlich ergibt.
Dies ist nach ErwGr 9 und 10 CRA weit auszulegen. Erfasst sind daher auch optional aktivierbare Schnittstellen, sofern sie im Produkt angelegt sind. Entscheidend ist, ob die Schnittstelle im Produkt tatsächlich vorhanden ist – nicht, ob eine Verbindung lediglich theoretisch denkbar wäre.
4. Ausnahmen: Branchenspezifisch, funktional oder regulatorisch
Auch wenn der CRA dem Grunde nach anwendbar wäre, können einzelne Tatbestände zu einer Ausnahme vom Anwendungsbereich führen:
Sektorspezifische Ausnahmen (Art. 2 Abs. 2 CRA)
- Medizinprodukte (Verordnung (EU) 2017/745)
- In-vitro-Diagnostika (Verordnung (EU) 2017/746)
- Typgenehmigung von Kraftfahrzeugen (Verordnung (EU) 2019/2144)
- Zivile Luftfahrt (Verordnung (EU) 2018/1139)
- Schiffsausrüstung (Richtlinie 2014/90/EU)
Verwendungszweckspezifische Ausnahmen
- Nationale Sicherheit / Verteidigung (Art. 2 Abs. 2 CRA): Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt oder verändert wurden.
- Ersatzteile (Art. 2 Abs. 5 CRA): Produkte, die auf dem Markt bereitgestellt werden, um identische Komponenten in PDE zu ersetzen, und die nach denselben Spezifikationen hergestellt werden wie die Bauteile, die sie ersetzen sollen.
Regulatorische Überschneidung
Sofern für ein Produkt gleichwertige Cybersicherheitsanforderungen durch andere EU-Vorschriften bestehen (z. B. sektorspezifische Cybersicherheitsvorgaben), kann dies ebenfalls zum Ausschluss aus dem CRA-Anwendungsbereich führen.
5. Open-Source-Software: Kommerzielle Nutzung entscheidend
Die FOSS-Ausnahme (Free and Open Source Software) ist eng begrenzt. Die normative Grundlage bildet Art. 2 Abs. 3–6 CRA; die Erwgr 15 und 18 CRA dienen der Auslegung.
FOSS unterfällt dann nicht dem CRA, wenn sie nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Der Maßstab ist dabei nicht die Gewinnerzielungsabsicht als solche, sondern der breitere Begriff der kommerziellen Tätigkeit. Indikatoren für eine kommerzielle Tätigkeit sind nach ErwGr 18 CRA insbesondere:
- Erhebung eines Entgelts für das Produkt
- Anbieten kostenpflichtigen Supports oder kostenpflichtiger Dienstleistungen (einschließlich Spenden, die die reinen Kosten übersteigen)
- Verarbeitung personenbezogener Daten zu anderen Zwecken als der Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software
Dabei handelt es sich um Indizien für eine kommerzielle Tätigkeit, nicht um absolute Kriterien. Die Bewertung erfordert eine Gesamtbetrachtung des Bereitstellungskontextes.
Hinweis: Auch wenn die FOSS-Ausnahme greift und kein voller Herstellerstatus vorliegt, kann der Anbieter als Verwalter quelloffener Software (Art. 3 Nr. 14 CRA) eingeschränkten Pflichten nach Art. 24 CRA unterliegen. Diese Figur flankiert die FOSS-Ausnahme und sollte in der Compliance-Prüfung nicht übersehen werden.
6. Zeitlicher Anwendungsbereich
Die CRA-Verordnung entfaltet ihre Wirkung in gestaffelter Weise:
- Bereitstellung vor dem 11.12.2027: Grundsätzlich keine CRA-Pflichten. Ausnahme: Die Meldepflichten nach Art. 14 CRA gelten bereits ab dem 11.09.2026.
- Bereitstellung nach dem 11.12.2027: Voller CRA-Pflichtenrahmen.
- Wesentliche Veränderungen (Art. 3 Nr. 30 CRA): Änderungen an einem Bestandsprodukt nach dem 11.12.2027, die sich auf die Konformität mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I auswirken oder zu einer Änderung des bestimmungsgemäßen Zwecks führen, können eine Neubereitstellung und damit die volle CRA-Anwendbarkeit auslösen.
Abgestellt wird bei der Bewertung auf jedes Einzelmodell, nicht auf den Erstvertrieb einer Produktlinie. „Bereitstellung auf dem Markt“ im Sinne des Art. 3 Nr. 22 CRA meint die entgeltliche oder unentgeltliche Abgabe eines PDE zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit. Es ist daher möglich, dass Teile einer Produktlinie noch nicht unter den CRA fallen, andere Einheiten derselben Linie jedoch erfasst werden, wenn diese zwar vor der Deadline produziert, aber erst danach auf dem EU-Markt bereitgestellt werden.