Der Cyber Resilience Act (CRA) ist am 10. Dezember 2024 in Kraft getreten. Vollständig gilt der CRA allerdings erst ab dem 11. Dezember 2027. Nachdem bereits im Dezember 2025 ein FAQ einer Dienststelle der Kommission veröffentlicht wurde, hat die Europäische Kommission nun einen Entwurf für die offiziellen Leitlinien zum CRA nach Art. 26 CRA veröffentlicht.

Bis Ende März kann auf der Website der Kommission zunächst ein Feedback zu den Leitlinien abgegeben werden. Zu einem späteren Zeitpunkt wird die Kommission dann die finalen Leitlinien veröffentlichen. Sie weist in dem Entwurf allerdings bereits darauf hin, dass die Leitlinien nicht verbindlich sind, sondern lediglich der EuGH eine verbindliche Auslegung der Vorschriften des CRA treffen kann. Gleichwohl bieten die Leitlinien eine praktische Hilfe zum besseren Verständnis einzelner Vorschriften und sie werden sicherlich von den mitgliedstaatlichen Behörden bei der Umsetzung einzelner Maßnahmen herangezogen werden.

Nachfolgend möchten wir Ihnen einen Überblick über einige der im Entwurf besprochenen Themen geben.

Wie sich aus Art. 26 Abs. 2 CRA ergibt, soll die Leitlinie insbesondere die Themen Open Source Software, Datenfernverarbeitungslösungen, den Unterstützungszeitraum für Sicherheitsaktualisierungen, das Verhältnis zu anderen Harmonisierungsvorschriften sowie den Begriff der wesentlichen Änderung behandeln.

Open-Source-Software

Im Hinblick auf Open-Source-Software nimmt die Kommission in ihrem Leitlinienentwurf auf die in Art. 3 Nr. 48 CRA und den ErwG 17 und 18 CRA genannten Kriterien Bezug. Nach ErwG 18 CRA fällt Open-Source-Software grds. nur dann in den Anwendungsbereich des CRA, wenn sie im Rahmen einer Geschäftstätigkeit verfügbar gemacht wird. Die in dem Leitlinienentwurf genannten Beispiele geben Aufschluss darüber, wann von einer Geschäftstätigkeit auszugehen ist. Dies ist etwa dann der Fall, wenn die kostenlose Open-Source-Anwendung dazu genutzt werden soll, um andere Produkte darüber zu erwerben oder wenn über diese Software auch kostenpflichtige Dienste angeboten werden.

Für die Eigenschaft als Open-Source-Software komme es darauf an, dass der Quellcode offen geteilt wird und damit öffentlich verfügbar sein muss und dass die Software im Rahmen einer Open-Source-Lizenz als frei zugänglich, nutzbar, veränderbar und weiterverteilbar zur Verfügung gestellt wird. Letzteres bedeutet nach Ansicht der Kommission, dass die Nutzer Zugriff auf den Quellcode haben müssen.

Auch wenn eine Open-Source-Software nicht im Rahmen einer Geschäftstätigkeit zur Verfügung gestellt wird, kann sie dennoch in den Anwendungsbereich des CRA fallen. Dies ist nach Art. 3 Nr. 14 CRA dann der Fall, wenn sie für kommerzielle Tätigkeiten bestimmt ist. Das ist nach Ansicht der Kommission dann der Fall, wenn sie für die Integration in kommerzielle Dienste oder Produkte vorgesehen ist. Dann trägt der Verwalter quelloffener Software die Verantwortung für die Software und hat nach Art. 24 CRA u.a. eine Cybersicherheitsstrategie zu entwickeln.

Datenfernverarbeitungslösungen

Auch in Bezug auf den Begriff der Datenfernverarbeitungslösung gibt die Kommission in ihrem Leitlinienentwurf eine Hilfestellung. Zunächst zeichnet sich die Datenfernverarbeitung dadurch aus, dass Daten nicht lokal auf dem Gerät des Nutzers gespeichert werden, sondern außerhalb, z.B. in einer Cloud, verarbeitet werden. Weiterhin muss die Datenfernverarbeitung erforderlich sein, damit das Produkt eine seiner Funktionen erfüllen kann. Dazu reicht etwa schon das Senden von Befehlen an ein Gerät oder die Synchronisierung von Daten aus. Unerheblich ist es, wenn etwa ein smarter Lichtschalter zusätzlich auch manuell eingeschaltet werden könnte. Denn die Remote-Funktion mittels Datenfernverarbeitungslösung ist eine von mehreren Funktionen des Produkts mit digitalen Elementen, was ausreichend ist. Zudem muss die Datenfernverarbeitungslösung vom Hersteller selbst oder unter seiner Verantwortung konzipiert worden sein. Die Kommission weist allerdings darauf hin, dass auch bei Datenfernverarbeitungslösungen von Dritten eine Risikobewertung zu erfolgen hat, da es sich dann um eine Komponente i.S.v. Art. 3 Nr. 6 CRA handelt, die der Hersteller in sein eigenes Produkt mit digitalen Elementen integriert.

Unterstützungszeitraum

Die Kommission erläutert die in Art. 13 Abs. 10 CRA genannte Privilegierungsregelung für den Hersteller hinsichtlich der Bereitstellung von Sicherheitsaktualisierungen bei unterschiedlichen Softwareversionen anhand von mehreren Beispielen. Wenn der Hersteller eines Smartphones den Unterstützungszeitraum mit 8 Jahren angibt und regelmäßig Updates und wesentlich veränderte Versionen des Betriebssystems bereitstellt, die der Nutzer kostenlos installieren kann, muss er die Sicherheitsaktualisierungen nur für die neueste Version des Betriebssystems bereitstellen.

Verhältnis zu anderen Harmonisierungsvorschriften

Der Leitlinienentwurf stellt unter anderem klar, dass der CRA gemäß Art. 2 Abs. 2 lit. c) CRA nicht für Kraftfahrzeuge gilt, die bereits Gegenstand der Verordnung (EU) 2019/2144 (Typengenehmigung für Kfz) und der Verordnung (EU) 168/2013 für Fahrzeuge der Klasse L (z.B. Motorräder) sind. Letzteres wurde nachträglich durch den delegierten Rechtsakt der Kommission (EU) 2025/1535 hinzugefügt.

Im Hinblick auf die Komponenten für solche Fahrzeugprodukte, die ihrerseits ein Produkt mit digitalen Elementen i.S.d. Art. 3 Nr. 1 CRA sein können, gilt nach Ansicht der Kommission folgendes: Sind diese Komponenten ausschließlich für den Einbau in die von den genannten Verordnungen adressierten Fahrzeuge bestimmt, gilt der CRA für diese Komponenten nicht. Handelt es sich hingegen um generische Komponenten, die auch in andere Produkte (z.B. Computer) integriert werden können, gilt die Ausnahme nach Art. 2 Abs. 2 lit. c) CRA nicht und die Komponente fällt als Produkt mit digitalen Elementen unter den CRA. Interessant ist, dass die Kommission für die Frage nach dem Verwendungszweck der Komponente nicht auf die Beschreibung, sondern auf den Vertriebskanal abstellt. Beispielsweise soll eine Komponente, die nach der Beschreibung zwar für den Einbau in Kraftfahrzeuge bestimmt ist, aber über einen Vertriebskanal angeboten wird, der für die breite Öffentlichkeit und nicht nur für die Automobilzuliefererkette bestimmt ist, dem CRA unterfallen. Denn aufgrund dieses offenen Vertriebskanals soll wohl davon ausgegangen werden, dass sie nicht ausschließlich für den Einbau in die von den oben genannten Verordnungen adressierten Kraftfahrzeuge bestimmt ist.

Begriff der wesentlichen Änderung

Die Kommission konkretisiert in ihrem Leitlinienentwurf auch den in Art. 3 Nr. 30 CRA definierten Begriff der wesentlichen Änderung eines Produkts mit digitalen Elementen. Im Hinblick auf die Bereitstellung von Softwareupdates stellt die Kommission klar, dass die wesentliche Änderung mit einer Erhöhung des Cybersicherheitsrisikos einhergehen muss, die zuvor in der Risikobewertung des Herstellers bei der Konzeption des Produkts mit digitalen Elementen nicht berücksichtigt worden ist. Dies kann laut ErwG 39 CRA bei der Einführung neuer Funktionalitäten eines Produkts der Fall sein. In ihrem Leitlinienentwurf weist die Kommission jedoch darauf hin, dass neue Funktionen nicht als wesentliche Änderung gelten, wenn diese Funktionen bei der ursprünglichen Risikobewertung des Herstellers bereits berücksichtigt und mit entsprechenden Maßnahmen adressiert wurden. Schließlich werden die folgenden beispielhaften Anhaltspunkte zur Bestimmung der Wesentlichkeit einer Änderung genannt: Entstehen aufgrund der Änderung neue Bedrohungsvektoren (z.B. zusätzliche Schnittstellen oder Kommunikationskanäle)? Werden neue Angriffsszenarien ermöglicht (z.B. neue Wege, die einen unbefugten Zugriff auf das Produkt oder seine Daten ermöglichen)? Erhöht sich die Wahrscheinlichkeit der zuvor identifizierten Angriffsszenarien (wenn etwa bestehende Schutzmaßnahmen geschwächt werden) oder verändern sich deren potenzielle Auswirkungen (z.B. größerer Umfang der betroffenen Daten). Sind aufgrund der Änderung eine oder mehrere dieser Fragen zu bejahen, wird von einer wesentlichen Änderung auszugehen sein. Die Konsequenz einer wesentlichen Änderung ist, dass das Produkt ab diesem Zeitpunkt als neu in Verkehr gebracht gilt. Dies hätte nach Art. 69 Abs. 2 CRA z.B. zur Folge, dass der CRA auch für ein wesentlich verändertes Altprodukt anwendbar wäre. Unabhängig davon weist die Kommission darauf hin, dass jegliche Änderungen ggf. im Rahmen der Risikobewertung und der technischen Dokumentation zu berücksichtigen und somit dort zu dokumentieren sind. Insbesondere dann, wenn eine Änderung nicht als wesentlich eingestuft wird, sollten die Gründe dafür argumentativ belegbar sein, da die Beweislast hierfür den Hersteller trifft und die Aufsichtsbehörde sich im Zweifel die Nachweise vorlegen lassen kann.

Der Begriff des Inverkehrbringens und der Geltungsbeginn

Wie sich bereits aus dem Blue Guide der EU als Leitlinie für Verordnungen im Zusammenhang mit Produkten ergibt, beziehen sich die Begriffe der Bereitstellung und des Inverkehrbringens auf dem Unionsmarkt stets auf jedes individuelle Produktexemplar, und nicht auf eine Produktsparte oder Produktserie. Das bedeutet in der Praxis, dass jedes angebotene Exemplar eines „physischen“ Produkts mit digitalen Elementen (z.B. Laptops oder Smartphones) eigenständig in Verkehr gebracht wird (z.B. werden 10.000 Exemplare eines bestimmten Modells am 01.01.2026 zum Verkauf angeboten und damit zu diesem Zeitpunkt in den Verkehr gebracht, während weitere 10.000 Exemplare desselben Modells nochmals am 01.01.2028 zum Verkauf angeboten und damit erst dann in den Verkehr gebracht werden). Dies hat enorme Auswirkungen darauf, ob der CRA auf das Produkt anwendbar ist, da sich im Umkehrschluss aus Art. 69 Abs. 2 CRA ergibt, dass die Verordnung grundsätzlich nur für Produkte mit digitalen Elementen gilt, die ab dem 11.12.2027 in Verkehr gebracht werden.

Im Hinblick auf digitale Produkte, wie z.B. Software, stellt die Kommission in ihren Leitlinien nun klar, dass etwa eine hergestellte App eine unbegrenzte Anzahl von Kopien desselben Softwareprodukts umfasst. Ein eigenständiges Softwareprodukt gilt demnach als in Verkehr gebracht, wenn es im Rahmen einer gewerblichen Tätigkeit erstmals zum Vertrieb oder zur Nutzung auf dem EU-Markt bereitgestellt wird. Daraus folgt im Gegensatz zu den physischen Produkten, dass etwa die erstmalige Bereitstellung einer App in einem Appstore das Inverkehrbringen für sämtliche Kopien dieser App bewirkt, unabhängig davon, zu welchem Zeitpunkt ein Nutzer sich diese App auf sein Smartphone herunterlädt. Diese Differenzierung geht aus dem Wortlaut des CRA nicht hervor, sodass der Leitlinienentwurf diesbezüglich Klarheit schafft.

Fazit

Der Leitlinienentwurf der Europäischen Kommission bietet eine nützliche Auslegungshilfe, um einzelne Schwerpunkte des CRA und die damit verknüpften Rechtsfragen besser zu verstehen. Insbesondere die aufgeführten Beispiele veranschaulichen die teilweise sehr abstrakt und eher undurchsichtig formulierten Regelungen der Verordnung. Da bislang jedoch nur der Entwurf vorliegt, sollte das weitere Verfahren beobachtet werden, da es noch größere Anpassungen an den Leitlinien geben kann. Auch wenn die Kommission darauf verweist, dass die Ausführungen in den Leitlinien nicht verbindlich sind, bieten sie dennoch wichtige Anknüpfungspunkte für die Auslegung der Vorschriften des CRA. Angesichts der noch nicht vorhandenen Rechtsprechung ist die Bedeutung dieses Dokuments in der noch jungen Geschichte des CRA zum jetzigen Zeitpunkt umso größer, auch wenn einzelne Standpunkte bis zur richterlichen Klärung durchaus auch anders vertreten werden können.