Eine Desktop-Anwendung fällt klar unter den Cyber Resilience Act. Bei einer reinen Browser-SaaS sieht es anders aus — obwohl auch sie vollständig aus Software besteht. Wer diese scheinbare Unstimmigkeit verstehen will, muss nicht bei der Technik, sondern beim Produktrecht ansetzen. Der seit dem 10. Dezember 2024 geltende CRA — Verordnung (EU) 2024/2847 — regelt in Art. 1 seinen Gegenstand, in Art. 2 den Anwendungsbereich und in Art. 3 Nr. 1 das Produkt mit digitalen Elementen. Für die SaaS-Frage kommt es am Ende jedoch auf einen anderen juristischen Schlüsselbegriff an: das Inverkehrbringen.

Warum der CRA überhaupt entstanden ist

Warum es den CRA braucht, hält die Verordnung in ihren Erwägungsgründen selbst fest. Cyberangriffe auf vernetzte Produkte häufen sich — mit kritischen Auswirkungen auf die Wirtschaft und die Demokratie sowie auf die Sicherheit und Gesundheit der Verbraucher [1, ErwGr (1)]. Gleichzeitig fehlte bis 2024 ein einheitlicher EU-weiter Rahmen für die Cybersicherheit von Produkten; was es gab, war sektoral (Funkanlagen, Medizinprodukte, Fahrzeuge), national oder freiwillig. Hersteller konnten deshalb ein Produkt mit ungeklärtem Schutzniveau auf den Binnenmarkt bringen. Anwender hatten keine zuverlässige Informationsgrundlage, nationale Alleingänge drohten den Binnenmarkt zu fragmentieren [1, ErwGr (1) und (4)].

Auf diese Lücke antwortet der CRA mit einer horizontalen, EU-weit unmittelbar geltenden Regulierung der Cybersicherheit von Produkten mit digitalen Elementen — in ihrer Tragweite vergleichbar mit der Datenschutz-Grundverordnung für personenbezogene Daten. Statt eines Flickenteppichs aus Branchenstandards gelten einheitliche Cybersicherheitsanforderungen für die Entwicklung, das Inverkehrbringen und den gesamten Lebenszyklus eines Produkts [1, ErwGr (1), (3) und (4)].

Dass dieses Problem fortbesteht, zeigen Vorfälle aus jüngster Zeit. Sie sind nicht der Auslöser des bereits 2024 verabschiedeten CRA, illustrieren aber, warum eine horizontale Produktregulierung notwendig wurde. Das deutlichste Beispiel ist die Botnet-Operation BadBox 2.0: Sicherheitsforscher von HUMAN Security, Google und Trend Micro deckten auf, dass über zehn Millionen vernetzte Geräte — Smart-TVs, TV-Boxen, Digitalprojektoren, teils In-Car-Infotainment-Systeme — mit Schadsoftware infiziert waren, die bei vielen Geräten bereits ab Werk in der Firmware steckte. Google leitete im Juli 2025 rechtliche Schritte ein [6]. Hier wird der CRA-Grundgedanke greifbar: Produkte gelangten unsicher auf den Markt, lange bevor der Käufer überhaupt eingreifen konnte — genau das adressieren die Anforderungen an Security by Design und Lieferkettensicherheit. Wie schnell und breit zudem eine Schwachstelle in weit verbreiteter Software ausgenutzt wird, zeigte die RondoDox-Kampagne: Das Botnet nahm über Monate hinweg IoT-Geräte und Webanwendungen ins Visier und nutzte ab Ende 2025 die kritische Schwachstelle React2Shell (CVE-2025-55182, CVSS-Höchstwert 10.0) in den weit verbreiteten Software-Frameworks React Server Components und Next.js; Anfang Januar 2026 waren laut der Shadowserver Foundation noch rund 85.000 Systeme angreifbar, davon etwa 3.600 in Deutschland [7]. Und eine Bestandsaufnahme des Sicherheitsunternehmens Forescout aus dem Jahr 2026 nennt eine ernüchternde Grössenordnung: Router und Switches weisen im Durchschnitt fast 32 Schwachstellen pro Gerät auf [8].

Was der CRA regelt — Art. 1 CRA

Art. 1 CRA umreisst den Gegenstand der Verordnung in vier Punkten [1, Art. 1]:

  • Vorschriften für die Bereitstellung von Produkten mit digitalen Elementen auf dem Markt, um deren Cybersicherheit zu gewährleisten;
  • grundlegende Cybersicherheitsanforderungen an die Konzeption, Entwicklung und Herstellung dieser Produkte sowie Pflichten der Wirtschaftsakteure entlang der Lieferkette;
  • grundlegende Cybersicherheitsanforderungen an die Prozesse zur Behandlung von Schwachstellen während der erwarteten Nutzungsdauer;
  • Vorschriften zur Marktüberwachung und Durchsetzung.

In diesen vier Punkten steckt die Grundlogik der Verordnung: Der CRA ist Produktrecht, nicht Dienstleistungsrecht. Er bestimmt, unter welchen Voraussetzungen ein Produkt auf den EU-Markt darf und welche Pflichten Hersteller und andere Wirtschaftsakteure anschliessend erfüllen müssen.

Wer in den Anwendungsbereich fällt — Art. 2 CRA

Art. 2 Abs. 1 CRA legt den positiven Anwendungsbereich fest. Erfasst sind „Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren bestimmungsgemässer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschliesst“ [1, Art. 2 Abs. 1].

Drei Voraussetzungen ergeben sich daraus, die jeweils erfüllt sein müssen:

Am Anfang steht ein Produkt mit digitalen Elementen — also ein Produkt, das die in Art. 3 Nr. 1 CRA festgelegten Voraussetzungen erfüllt (dazu gleich mehr).

Hinzu kommt die Bereitstellung auf dem Markt. Ohne diesen Markt-Bezug greift der CRA nicht: Eine Inhouse-Lösung, die nur intern in einem Unternehmen verwendet und nicht an Dritte abgegeben wird, fällt nicht in den Anwendungsbereich [1, Art. 3 Nr. 22 i. V. m. Art. 2 Abs. 1].

Schliesslich muss das Produkt — bestimmungsgemäss oder bei vernünftigerweise vorhersehbarer Verwendung — eine Datenverbindung mit einem Gerät oder Netz einschliessen [1, Art. 2 Abs. 1]. Die drei möglichen Verbindungsarten definiert die Verordnung selbst. Eine „logische Verbindung“ ist die virtuelle Darstellung einer über eine Softwareschnittstelle hergestellten Datenverbindung (Art. 3 Nr. 8). Die „physische Verbindung“ entsteht mit physikalischen Mitteln wie elektrischen, optischen oder mechanischen Schnittstellen, Drähten oder Funkwellen (Art. 3 Nr. 9) — Beispiele wären NFC, USB oder Ethernet. Als „indirekt“ gilt eine Verbindung, die als Teil eines grösseren Systems hergestellt wird, das seinerseits direkt mit dem Gerät oder Netz verbunden werden kann (Art. 3 Nr. 10) [1, Art. 3 Nr. 8–10]. Die Kommentarliteratur versteht dieses Kriterium weit: Nach Wiebe/Jossen umfasst es neben Internet-Verbindungen wie WLAN oder Bluetooth auch rein logische Verbindungen wie Netzwerksockets, Pipes, APIs oder Datenbankzugriffe. Reine Einweg-Datenträger wie RFID-Tags oder QR-Codes ohne aktive Rückkanal-Komponente sind dagegen nicht erfasst [2, § 4 Rn. 3].

Warum fast jede Software auf einem vernetzten Rechner erfasst ist

Gerade das dritte Kriterium hat für Softwarehersteller weitreichende Folgen. Es wird dennoch häufig unterschätzt. Eine Anwendung ohne eigene Netzfunktion, so die verbreitete Annahme, falle aus dem CRA heraus. Das trifft nicht zu. Nach Nr. 1.3 der technischen FAQs der Kommissionsdienststellen kann eine logische Verbindung auch indirekt bestehen: Das Produkt initiiert die Kommunikation zwar nicht selbst, läuft aber auf einem Hostsystem, das dies tut. Ausdrücklich genannt werden ein Offline-Texteditor und ein Taschenrechner, die über das Betriebssystem indirekt verbunden sind [9, Nr. 1.3]. Auch Erwägungsgrund (9) CRA folgt dieser Linie. Hersteller sollen demnach die Cybersicherheit von Produkten sicherstellen, die nur indirekt mit anderen Geräten oder Netzen verbunden sind, weil sich Cyberbedrohungen über verkettete Schwachstellen fortpflanzen können [1, ErwGr (9)].

Die Konsequenz ist bemerkenswert weit: Nahezu jede Software auf einem vernetzten Host erfüllt das Verbindungskriterium. Realistisch verneinen lässt sich die Datenverbindung nur noch bei physisch isolierter, eingebetteter Firmware. Dazu passen die Negativbeispiele der FAQs. Für sie gilt jeweils ausdrücklich die Bedingung, dass keinerlei Fähigkeit zur Verbindung mit anderen Geräten oder Netzen besteht [9, Nr. 1.3]:

  • ein Geschirrspüler mit eingebetteter Firmware, die Spülprogramme steuert;
  • ein einfacher Taschenrechner mit eingebetteter Firmware für Rechenoperationen;
  • ein elektronisches Spielzeug mit eingebetteter Firmware, das vorab aufgezeichnete Licht- und Toneffekte abspielt;
  • eine Kaffeemaschine mit eingebetteter Firmware, die Brühzeit oder Kaffeestärke über ein Bedienfeld einstellt;
  • eine elektrische Zahnbürste mit kabelloser Ladestation.

Beim Lesen der Liste sind zwei Feinheiten zu beachten. Der vermeintliche Widerspruch zwischen den beiden Taschenrechner-Beispielen löst sich über die Umgebung auf: Der Taschenrechner als Anwendung auf einem vernetzten Betriebssystem ist erfasst, als isoliertes Gerät ohne jede Verbindungsfähigkeit dagegen nicht. Auf die Funktion allein kommt es nicht an. Ausserdem kann die genannte Firmware laut einer Fussnote der FAQs gleichwohl in den Anwendungsbereich fallen, wenn sie separat in Verkehr gebracht wird [9, Nr. 1.3 Fn. 1]. Art. 3 Nr. 1 CRA erfasst getrennt in Verkehr gebrachte Komponenten ausdrücklich [1, Art. 3 Nr. 1].

Erstellt wurden die FAQs von den Kommissionsdienststellen. Nach eigener Angabe geben sie keine offizielle Position der Kommission wieder, sind nicht verbindlich und als lebendes Dokument angelegt. Aussagekräftig ist der Befund für die Praxis trotzdem: Die Kommissionsdienststellen ziehen die Untergrenze des Anwendungsbereichs sehr tief. Es gibt sie, aber sie erfasst nur wenige Konstellationen.

Die Ausschlusstatbestände des Art. 2 CRA im Einzelnen

Art. 2 Abs. 2 bis 8 CRA enthält darüber hinaus Ausschlüsse für Bereiche, die bereits durch andere Unionsrechtsakte reguliert sind. Die genaue Zuordnung lohnt sich, weil sie in der Praxis häufig verkürzt wiedergegeben wird [1, Art. 2 Abs. 2–8]:

  • Art. 2 Abs. 2: Produkte, auf die die Verordnung (EU) 2017/745 (Medizinprodukte), die Verordnung (EU) 2017/746 (In-vitro-Diagnostika) oder die Verordnung (EU) 2019/2144 (allgemeine Sicherheit von Kraftfahrzeugen) Anwendung findet.
  • Art. 2 Abs. 3: Produkte, die nach der Verordnung (EU) 2018/1139 zertifiziert worden sind — Anknüpfungspunkt ist also die Zertifizierung, nicht die zivile Luftfahrt als Sektor.
  • Art. 2 Abs. 4: Geräte, die in den Anwendungsbereich der Richtlinie 2014/90/EU über Schiffsausrüstung fallen.
  • Art. 2 Abs. 5: kein eigener Ausschluss, sondern die Ermächtigung der Kommission, den Anwendungsbereich durch delegierte Rechtsakte für Produkte einzuschränken oder auszuschliessen, die anderen Unionsvorschriften mit gleichem oder höherem Schutzniveau unterliegen.
  • Art. 2 Abs. 6: Ersatzteile, die identische Komponenten ersetzen und nach denselben Spezifikationen hergestellt werden wie die Bauteile, die sie ersetzen sollen.
  • Art. 2 Abs. 7: Produkte, die ausschliesslich für Zwecke der nationalen Sicherheit oder für Verteidigungszwecke entwickelt oder geändert wurden, sowie Produkte, die speziell für die Verarbeitung von Verschlusssachen konzipiert sind.
  • Art. 2 Abs. 8: ebenfalls kein Produktausschluss, sondern eine Grenze der Informationspflichten, soweit deren Offenlegung wesentlichen Interessen der Mitgliedstaaten im Bereich der nationalen Sicherheit, der öffentlichen Sicherheit oder der Verteidigung zuwiderliefe.

Mit dem Wortlaut der Verordnung ist der Ausnahmekatalog noch nicht vollständig. Eine weitere Ausnahme folgt aus dem abgeleiteten Recht: Die Delegierte Verordnung (EU) 2025/1535 nimmt Produkte mit digitalen Elementen aus, die in den Anwendungsbereich der Verordnung (EU) Nr. 168/2013 fallen — also zwei- und dreirädrige Fahrzeuge sowie vierrädrige Leichtfahrzeuge. Nicht von dieser Ausnahme erfasst sind Fahrzeuge der Klasse L1e, die für den Pedalantrieb ausgelegt sind; für sie bleibt es beim CRA [9, Nr. 1.9]. Bei Softwareherstellern dürfte das nur am Rand eine Rolle spielen, etwa bei Steuerungssoftware von Elektrofahrrädern.

Zwei Missverständnisse bei den sektoralen Ausnahmen

Die technischen FAQs der Kommissionsdienststellen räumen zwei verbreitete Fehlvorstellungen aus.

Erstens: Dual-Use-Produkte sind erfasst. Der Ausschluss in Art. 2 Abs. 7 CRA greift nur, wenn ein Produkt ausschliesslich für Zwecke der nationalen Sicherheit oder für Verteidigungszwecke entwickelt oder geändert wurde. Produkte mit sowohl ziviler als auch verteidigungsbezogener Verwendung — Dual-Use-Produkte — unterliegen deshalb dem CRA, sobald sie auf dem Markt bereitgestellt werden; etwas anderes gilt nur, wenn sie ausschliesslich für Zwecke der nationalen Sicherheit oder der Verteidigung geändert wurden [9, Nr. 1.8; 1, Art. 2 Abs. 7]. Dass die Mitgliedstaaten nach Art. 5 Abs. 1 CRA für die Beschaffung oder Verwendung zu bestimmten Zwecken zusätzliche Cybersicherheitsanforderungen vorsehen können, ändert daran nichts [9, Nr. 1.8; 1, Art. 5 Abs. 1].

Zweitens: Zulieferer in ausgenommene Sektoren sind regelmässig erfasst. Weil Art. 2 Abs. 3 CRA an die Zertifizierung anknüpft und nicht an den Sektor, können Produkte, die zwar in den Anwendungsbereich der Verordnung (EU) 2018/1139 fallen, aber nicht nach ihr zertifiziert sind, dem CRA unterliegen. Die FAQs nennen als Beispiel Drohnen der „offenen Kategorie“, die den Grossteil der Freizeitnutzung und der gewerblichen Nutzung mit geringem Risiko abdeckt. Dasselbe gilt für Komponenten, die zur Integration in nach der Verordnung (EU) 2018/1139 zertifizierte Produkte bestimmt, selbst aber nicht zertifiziert sind [9, Nr. 2.1.1]. Für die Schiffsausrüstung nach Art. 2 Abs. 4 CRA gilt dieselbe Logik: Komponenten, die zur Integration in Ausrüstung im Anwendungsbereich der Richtlinie 2014/90/EU bestimmt sind, selbst aber nicht in deren Anwendungsbereich fallen, können vom CRA erfasst sein [9, Nr. 2.2.1].

Softwarezulieferer der Luftfahrt oder des Schiffbaus sollten deshalb nicht bei der pauschalen Auskunft „unsere Branche ist ausgenommen“ stehen bleiben. Sie trägt nicht. Zu prüfen ist vielmehr, ob das eigene Produkt selbst zertifiziert ist beziehungsweise selbst in den Anwendungsbereich des sektoralen Rechtsakts fällt.

Das „Produkt mit digitalen Elementen“ — der zentrale Begriff in Art. 3 Nr. 1 CRA

Die Definition des Produkts mit digitalen Elementen steht in Art. 3 Nr. 1 CRA. Gemeint ist ein „Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschliesslich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ [1, Art. 3 Nr. 1].

Aus dieser Definition ergeben sich vier Erscheinungsformen, die nach Art. 3 Nr. 1 CRA und der ersten Auslegungs-Guidance der EU-Kommission [3, Rn. 18] unstreitig in den Anwendungsbereich fallen:

  • Eigenständige Software-Produkte — Desktop-Anwendungen, mobile Apps, Bibliotheken, Firmware-Images, Treiber und vergleichbare Software, die als digitales Produkt an den Nutzer abgegeben wird. Art. 3 Nr. 1 CRA stellt das ausdrücklich klar: Software allein, ohne jede Hardware-Komponente, kann ein Produkt mit digitalen Elementen sein [1, Art. 3 Nr. 1].
  • Hardware mit eingebetteter Software — IoT-Geräte, Industriesteuerungen, Smart-Home-Geräte, Router, vernetzte Haushaltsgeräte, medizintechnische Hilfsmittel ausserhalb der MDR-Sphäre (siehe oben).
  • Eigenständige Hardware-Produkte — integrierte Schaltkreise, Hauptplatinen, Mikrocontroller, USB-Sticks mit Steuersoftware.
  • Kombinationen aus Hardware und Software, die getrennt vermarktet, aber nach ihrem bestimmungsgemässen Zweck zusammenwirken — etwa ein Fitness-Wearable und die zugehörige Smartphone-App des Herstellers.

In allen vier Konstellationen erfasst der CRA das Produkt einschliesslich seiner „Datenfernverarbeitungslösungen“ — der sogenannten Remote Data Processing Solutions, kurz RDPS. Was darunter genau zu verstehen ist und wann eine Cloud-Komponente zur RDPS wird, ist Gegenstand des folgenden Artikels dieser Serie.

Das Inverkehrbringen — der regulatorische Anknüpfungspunkt

Die Frage, ob ein Produkt vom CRA erfasst wird, hängt jedoch nicht nur an der Definition in Art. 3 Nr. 1 CRA, sondern auch an einem zweiten, oft übersehenen Begriff: dem Inverkehrbringen.

Art. 3 Nr. 22 CRA definiert die „Bereitstellung auf dem Markt“ als „die entgeltliche oder unentgeltliche Abgabe eines Produkts mit digitalen Elementen zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit“ [1, Art. 3 Nr. 22]. Art. 3 Nr. 21 CRA ergänzt: „Inverkehrbringen“ ist die erstmalige Bereitstellung eines Produkts mit digitalen Elementen auf dem Unionsmarkt [1, Art. 3 Nr. 21].

Der juristische Mechanismus lässt sich damit zeitlich verorten: Entscheidend ist der Moment, in dem ein Produkt aus der Sphäre des Herstellers in die des Marktes übergeht — typischerweise mit der Auslieferung an einen Vertriebspartner oder Endkunden. Ab diesem Augenblick muss das Produkt den grundlegenden Cybersicherheitsanforderungen aus Anhang I CRA entsprechen, eine Konformitätsbewertung durchlaufen haben und eine CE-Kennzeichnung tragen. Zugleich treffen den Hersteller die Lebenszykluspflichten zur Schwachstellenbehandlung [1, Art. 13, 28, 30].

Das ist dieselbe Logik, der auch andere EU-Produktverordnungen folgen — von der Maschinenverordnung über die Funkanlagen-Richtlinie bis zur Medizinprodukteverordnung. Der CRA reiht sich in die EU-Produktsicherheitslogik ein und nutzt deren etablierten Anknüpfungspunkt.

Wer ein Produkt überhaupt in den Verkehr bringen kann

Aus der Definition folgt eine Rollenabgrenzung, die in der Praxis regelmässig unterschätzt wird. Der artikelweise CRA-Kommentar von Schröder/Hartl hält fest, dass ein Produkt nur vom Hersteller und vom Einführer in den Verkehr gebracht werden kann. Ein Händler kann das nicht: Damit er ein Produkt weitergeben kann, muss es ihn zunächst erreichen — und spätestens damit hat es der Hersteller oder der Einführer bereits in den Verkehr gebracht. Bezieht ein Händler das Produkt hingegen ausserhalb der Union und gibt er es erstmals in der Union ab, so wird er allein dadurch selbst zum Einführer und trägt dessen Pflichten [10, Mehnert, Art. 3 Rn. 122].

Für Softwarehersteller folgen daraus zwei praktische Punkte. Die Auslieferung über einen Vertriebspartner schiebt die Herstellerpflichten nicht weiter: Verlässt die Software den Hersteller, kann bereits ein Inverkehrbringen vorliegen. Und wer Software von einem Anbieter ausserhalb der EU bezieht und in der Union anbietet, sollte seine Rolle genau prüfen. Möglicherweise handelt das Unternehmen als Einführer — mit deutlich weiterreichenden Pflichten als ein Händler.

Ab wann eine Softwareversion als in Verkehr gebracht gilt — eine offene Auslegungsfrage

Für reine Software-Produkte ist damit noch nicht geklärt, wann genau der massgebliche Moment eintritt. Diese Frage ist für die EU-Kommission so zentral, dass sie ihr in Abschnitt 2.1 ihrer Auslegungs-Guidance ein eigenes Kapitel widmet (Rn. 10–16) und dort speziell für Software bestimmt, ab welchem Moment sie als „placed on the market“ gilt (Rn. 13–16) [3, Abschnitt 2.1]. Die Antwort der Guidance ist versionsbezogen: Eine Softwareversion gilt mit dem erstmaligen Angebot zum Vertrieb oder zur Verwendung als in Verkehr gebracht. Alle Kopien dieser Version gelten damit als zeitgleich in Verkehr gebracht — unabhängig davon, wann der einzelne Nutzer sie tatsächlich herunterlädt. Varianten, die sich in ihren Komponenten, ihrer Konfiguration oder ihrem Funktionsumfang unterscheiden, sind dagegen jeweils eigene Produkte und getrennt zu betrachten [3, Rn. 13–16].

Der 2026 erschienene artikelweise CRA-Kommentar von Schröder/Hartl legt den Begriff enger aus. Mehnert stellt in der Kommentierung zu Art. 3 Nr. 21 CRA darauf ab, dass sich das Inverkehrbringen auf jedes einzelne Exemplar einer Produktart bezieht und nicht auf eine ganze Produktserie; er stützt sich dafür auf den „Blue Guide“ der EU-Kommission von 2022, Ziffer 2.3 [10, Mehnert, Art. 3 Rn. 122; 5]. Poncza zieht in der Kommentierung zu Art. 3 Nr. 22 CRA die Konsequenz für Software: Weil das Produktsicherheitsrecht stets auf das jeweilige Einzelprodukt und nicht auf eine Produktreihe abstelle, sei bei reinen Softwareprodukten die Frage der Abgabe — und damit der Bereitstellung — für jede Kopie gesondert zu beantworten. Der Auffassung, bereits die blosse Downloadmöglichkeit genüge, hält er entgegen, dass die betreffende Kopie vor dem Download noch gar nicht existiere: Der Vervielfältigungsvorgang finde erst im Rahmen des Downloads statt. Tauglicher Anknüpfungspunkt für eine Abgabe könne deshalb nur die Durchführung des Downloads sein [10, Poncza, Art. 3 Rn. 135].

Warum das praktisch zählt. Die beiden Auffassungen führen bei einer sehr konkreten Frage auseinander: Eine Softwareversion wird vor dem 11. Dezember 2027 erstmals zum Download angeboten; ein Nutzer lädt sie erst nach diesem Stichtag herunter. Nach der Guidance ist die Version bereits mit dem ersten Angebot in Verkehr gebracht — und zwar für alle Kopien; der spätere Download begründet kein neues Inverkehrbringen. Nach der Kommentarauffassung wäre jeder einzelne Download ein eigener Anknüpfungspunkt, sodass der Download nach dem Stichtag ein Inverkehrbringen unter der dann vollständig anwendbaren Verordnung wäre.

Was die FAQs der Kommissionsdienststellen ergänzen. Zu dieser Frage liefern die technischen FAQs einen Befund, der die Darstellung schärft. In Nr. 7.2 halten sie unter ausdrücklichem Verweis auf Abschnitt 2.2 des „Blue Guide“ fest, dass die Harmonisierungsrechtsvorschriften der Union — und damit auch der CRA — für einzelne Produkte gelten und nicht für Produkttypen. Vom CRA ausgenommen sind deshalb nur diejenigen einzelnen Exemplare, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Produkte, die nach einem nicht CRA-konformen Typ hergestellt werden, dürfen ab diesem Datum nicht mehr in Verkehr gebracht werden — auch dann nicht, wenn das erste Exemplar dieses Typs vorher in Verkehr gebracht wurde. Das Beispiel der FAQs: Ein Hersteller bringt 10.000 Exemplare eines nicht CRA-konformen Routertyps vor dem Stichtag in Verkehr; diese muss er nicht nachrüsten, selbst wenn sie den Endnutzer noch nicht erreicht haben. Weitere 5.000 Exemplare desselben Typs darf er nach dem Stichtag jedoch nicht mehr in Verkehr bringen [9, Nr. 7.2, mit Verweis auf Nr. 1.4].

Das ist für die obige Divergenz kein Nebenschauplatz. Für Hardware ist die stückbezogene Betrachtung damit unstreitig, und die FAQs bestätigen sie als allgemeine Regel des EU-Produktrechts. Die versionsbezogene Aussage der Kommissions-Guidance steht daneben: Sie ist die speziellere Regel für Softwareversionen, bewegt sich damit aber in einem Spannungsverhältnis zu der allgemeinen Regel, die die FAQs zugrunde legen. Wer sich auf die Guidance stützt, stützt sich also auf eine Spezialauslegung, die von der allgemeinen Linie abweicht.

Wie sich das einordnen lässt. Beide Positionen haben nachvollziehbare Gründe. Die veröffentlichte Guidance zeigt die Auslegung der Kommission und kann Marktüberwachungsbehörden als Orientierung dienen. Deren Entscheidungen müssen sich jedoch auf den CRA und andere verbindliche Rechtsakte stützen; auch Gerichte sind an die Guidance nicht gebunden. Der Kommentar bleibt demgegenüber näher an der klassischen produktsicherheitsrechtlichen Betrachtung, die auf das einzelne Exemplar abstellt, und kann sich dafür auf den Blue Guide als allgemeine Auslegungsgrundlage des EU-Produktrechts stützen — auf denselben Blue Guide, auf den auch die FAQs der Kommissionsdienststellen in Nr. 7.2 zurückgreifen [9, Nr. 7.2]. Verbindlich geklärt ist die Frage bislang weder durch die Verordnung selbst noch durch die Rechtsprechung.

Was das für die Praxis heisst. Der FAQ-Befund verstärkt die vorsorgliche Linie: Wer auf Nummer sicher gehen will, behandelt Versionen, die über den 11. Dezember 2027 hinaus zum Download angeboten werden, wie neu in Verkehr gebrachte Produkte — mit vollständiger Konformitätsbewertung, CE-Kennzeichnung und technischer Dokumentation. Wer sich auf die Guidance stützt, sollte den Zeitpunkt des ersten Angebots je Version belegbar dokumentieren, weil dieser Zeitpunkt dann das entscheidende Tatbestandsmerkmal ist. In beiden Fällen gilt: Sobald sich Komponenten, Konfiguration oder Funktionsumfang ändern, liegt nach der Guidance ohnehin ein eigenes Produkt vor — die Frage stellt sich dann neu.

Zwei praxisnahe Sonderregelungen: Testversionen und Software-Archive

Zwei Vorschriften rund um das Bereitstellen sind für Softwarehersteller unmittelbar operativ und werden in der Diskussion um den Anwendungsbereich leicht übersehen.

Unfertige Software zu Testzwecken. Nach Art. 4 Abs. 3 CRA dürfen die Mitgliedstaaten die Bereitstellung unfertiger Software auf dem Markt nicht verhindern, auch wenn diese der Verordnung noch nicht entspricht — vorausgesetzt, sie wird nur für den zu Testzwecken erforderlichen, begrenzten Zeitraum zur Verfügung gestellt und trägt eine sichtbare Kennzeichnung, die deutlich auf die fehlende Konformität hinweist. Gemeint sind Alpha- und Beta-Versionen sowie Release Candidates. Erwägungsgrund (37) CRA ergänzt zwei Bedingungen, die in der Praxis oft untergehen: Die Freigabe soll erst nach einer Risikobewertung erfolgen, und Nutzer dürfen nicht zu einer Aktualisierung auf reine Testversionen gezwungen werden [1, Art. 4 Abs. 3 und ErwGr (37); 9, Nr. 1.6].

Öffentliche Software-Archive. Nach Art. 13 Abs. 11 CRA dürfen Hersteller öffentliche Softwarearchive unterhalten, die den Nutzern den Zugang zu historischen Versionen erleichtern. Bedingung ist, dass die Nutzer klar und in leicht zugänglicher Form über die Risiken informiert werden, die aus der Verwendung nicht mehr unterstützter Software entstehen [1, Art. 13 Abs. 11; 9, Nr. 1.7]. Wer ein Download-Archiv betreibt, braucht also keinen Rückbau — wohl aber einen sichtbaren Risikohinweis.

Warum SaaS nicht „einfach Software“ ist

Hier widerspricht die Systematik der Verordnung zunächst der technischen Intuition. SaaS-Anwendungen bestehen aus Software — Art. 3 Nr. 4 CRA definiert diese als „den Teil eines elektronischen Informationssystems, der aus Computercode besteht“ [1, Art. 3 Nr. 4]. Eine in der Cloud betriebene Webanwendung ist nach dieser technischen Definition selbstverständlich Software.

Trotzdem fällt eine reine SaaS-Lösung — also eine Anwendung, die ausschliesslich über den Browser genutzt wird und auf dem Gerät des Nutzers keinen Code des Anbieters installiert — nicht unter den CRA. Wo sie genau aus dem Anwendungsbereich herausfällt, ist juristisch nicht zweifelsfrei. In der Kommentarliteratur stehen sich zwei Lesarten gegenüber. Im Ergebnis kommen beide zum selben praktischen Schluss; die Wahl zwischen ihnen ist eher dogmatisch als praktisch.

Lesart A — Scheitern am Produkterfordernis (produktbezogener Begründungsweg)

Nach dieser Auffassung ist eine reine SaaS schon kein „Produkt“ im Sinne von Art. 3 Nr. 1 CRA. Die Argumentation: Im EU-Produktrecht — und der CRA reiht sich ausdrücklich in dieses ein — ist „Produkt“ eine abgrenzbare, einer einzelnen Marktbereitstellung zugängliche Einheit, die der Hersteller herstellt, prüft und auf den Markt bringt. So definiert es auch der „Blue Guide on the implementation of EU product rules“ 2022 der EU-Kommission in Abschnitt 2 [5]. Eine SaaS ist ihrem Wesen nach das Gegenteil: kein abgegrenztes Software-Artefakt, sondern ein kontinuierlich erbrachter Dienst, der täglich gepatcht und skaliert wird und den der Nutzer nie als „seine Kopie“ erhält.

Der CRA-Kommentar von Wiebe formuliert das präzise — und mit einer wichtigen Bedingung. Cloud-Dienstmodelle wie SaaS, PaaS und IaaS, „welche die Produktfunktionalität — etwa als Backend — nicht unterstützen bzw. für diese nicht erforderlich sind, stellen folglich keine CRA-relevante Software dar und werden als solche auch nicht einem anderen Produkt als dessen Datenfernverarbeitungslösungen zugerechnet“ [2, § 4 Rn. 5]. Zwei Dinge sind daran wichtig: Erstens bestreitet der Kommentar nicht, dass SaaS technisch Software ist — er sagt nur, dass eine eigenständige SaaS keine CRA-relevante Software ist. Zweitens steht die Aussage unter der Bedingung „nicht unterstützt / nicht erforderlich“: Eine SaaS, die als Backend ein Produkt funktional trägt, wird sehr wohl CRA-relevant — dann allerdings nicht als eigenes Produkt, sondern als Datenfernverarbeitungslösung des unterstützten Produkts. Genau das ist die RDPS-Brücke, auf die wir im nächsten Abschnitt zurückkommen.

Diese kategoriale Einordnung wird durch Erwägungsgrund (12) CRA bekräftigt, der Cloud-Dienstmodelle der NIS-2-Richtlinie (EU) 2022/2555 zuweist [1, ErwGr (12); 4]. Auch die EU-Kommissions-Guidance bestätigt das in Rn. 183: „cloud computing services and cloud service models fall within the scope of Directive (EU) 2022/2555 (NIS 2)“, welche Anforderungen an das Cybersicherheits-Risikomanagement für Anbieter von Cloud-Computing-Diensten festlegt — näher spezifiziert durch die Durchführungsverordnung (EU) 2024/2690 [3, Rn. 183]. Nach dieser Lesart kommt es auf die Frage der Bereitstellung gar nicht mehr an — eine Dienstleistung kann schon kategorial nicht als Produkt bereitgestellt werden.

Anschaulich machen lässt sich das am Werkstorprinzip, das auch der CRA-Kommentar zur Bestimmung des Inverkehrbringens heranzieht: Ein Produkt ist in Verkehr gebracht, wenn es „das (digitale) Werkstor des Herstellers mit seinem Willen verlässt“ [2, § 4 Rn. 18]. Eine heruntergeladene Desktop-App verlässt dieses Werkstor — die Kopie wandert auf das Gerät des Nutzers, der Hersteller verliert die unmittelbare Kontrolle über sie. Eine SaaS verlässt das Werkstor nie: Der Code bleibt dauerhaft auf den Servern des Anbieters, der Nutzer greift von aussen über eine Verbindung hinein. Es überschreitet kein Produkt das Werkstor — und der Hersteller behält die fortlaufende Kontrolle.

Ein gewichtiges systematisches Argument für Lesart A: Sie ist manipulationsfest. Würde SaaS nur am Bereitstellungserfordernis scheitern, könnte ein Anbieter über vertragliche Konstruktionen — eine Subskriptions-„Abgabe“, besondere Lizenzformen, die Übermittlung von Zugangsdaten — versuchen, einen „Abgabe“-Akt zu konstruieren und damit über die CRA-Pflicht zu disponieren. Lesart A schliesst das aus, weil sie die Abgrenzung am Wesen der Sache festmacht: Solange kein Produkt vorliegt, ist gleichgültig, welche Rechte vertraglich übertragen werden.

Lesart B — Scheitern am Bereitstellungserfordernis (zweiter Begründungsweg)

Der zweite Begründungsweg ordnet SaaS-Code durchaus als „Softwareprodukt“ iSd Art. 3 Nr. 1 CRA ein und lässt ihn erst am Bereitstellungserfordernis des Art. 3 Nr. 22 CRA ausscheiden — es fehle die „Abgabe“ einer Kopie. Diese Auslegung bleibt enger am Wortlaut des Art. 3 Nr. 22, der die „Abgabe“ als ausdrückliches Tatbestandsmerkmal nennt. Sie wird im artikelweisen Kommentar von Schröder/Hartl vertreten: Poncza hält bei unkörperlicher Software den Übergang der Sachherrschaft für keinen tauglichen Anknüpfungspunkt mehr und fragt stattdessen, ob das Softwareprodukt in den ausschliesslichen Machtbereich des Nutzers übergeht und damit ein „Sachherrschaftsäquivalent“ begründet wird — was bei einer beim Anbieter verbleibenden Cloud-Anwendung gerade nicht der Fall ist [10, Poncza, Art. 3 Rn. 135]. Ausführlich dazu Artikel 1 dieser Serie.

Was beide Lesarten gemeinsam haben — und was folgt

Im Ergebnis sind sich beide Lesarten einig: Eine reine Browser-SaaS fällt nicht unter den CRA, sondern — wenn die Schwellenwerte der NIS-2-Richtlinie erfüllt sind — in die NIS-2-Sphäre. Der Unterschied liegt allein in der dogmatischen Konstruktion. Für die Praxis genügt es zu wissen, dass eine reine SaaS aus dem CRA herausfällt — und dass diese Einordnung an mehreren Stellen der Verordnung verankert ist. Wir folgen in den nachfolgenden Artikeln Lesart A, weil sie den Anwendungsbereich unabhängig von der Vertragsgestaltung bestimmt und deshalb manipulationsfester ist; beide Begründungswege schliessen einander aber nicht aus.

Die EU schafft damit ein zweiteiliges Schutzkonzept für die IT-Sicherheit:

  • Produktrecht (CRA, Maschinenverordnung, RED, MDR und weitere): Anknüpfungspunkt ist das Inverkehrbringen eines Produkts. Adressaten sind Hersteller, Einführer und Händler.
  • Dienstleistungsrecht (NIS-2-Richtlinie, DORA, eIDAS): Anknüpfungspunkt ist die Erbringung einer Dienstleistung. Adressaten sind Diensteanbieter, die bestimmte Grössen- oder Sektorenkriterien erfüllen.

Reine SaaS-Lösungen gehören systematisch in die zweite Sphäre. Wer eine reine Browser-Anwendung anbietet und keine lokal installierte Komponente verteilt, hat keine CRA-Pflichten — wohl aber NIS-2-Pflichten, sofern er als wesentliche oder wichtige Einrichtung im Sinne der Richtlinie eingestuft wird.

Die Brücke: Wenn SaaS doch in den CRA hineinwirkt

So eindeutig die Trennung systematisch ist — in der Praxis ist sie selten so sauber. Viele Anbieter, die sich als reine SaaS-Unternehmen verstehen, verteilen parallel eine Desktop-App, eine Mobile App, ein Browser-Plugin, einen Monitoring-Agent oder ein SDK. Diese Aufzählung ist nicht abschliessend: Auch CLI-Tools, IDE-Plugins, Sync-Daemons, VPN-Clients, Game-Launcher, Authenticator-Apps mit Cloud-Backup, Smart-TV-Apps und installierbare Progressive Web Apps (PWAs) zählen dazu. Mit jeder dieser lokal installierten Komponenten entsteht erneut ein Auslieferungsmoment — und damit ein Anknüpfungspunkt des CRA.

An der Cloud-Grenze soll das Schutzkonzept des CRA dennoch nicht enden. Deshalb enthält Art. 3 Nr. 2 CRA eine zweite Definition: die Datenfernverarbeitungslösung — Remote Data Processing Solution, kurz RDPS. Sie bildet die regulatorische Brücke zwischen Produktrecht und Dienstleistungsrecht. Kann eine in Verkehr gebrachte lokale Produktkomponente ohne eine bestimmte Server-Software auch nur eine ihrer Funktionen nicht mehr ausführen und hat der Hersteller diese Server-Software selbst entworfen und entwickelt, gilt sie als untrennbarer Bestandteil des CRA-Produkts. Für sie greifen dieselben CRA-Pflichten wie für die lokale Komponente: die grundlegenden Cybersicherheitsanforderungen nach Anhang I, die SBOM, das Schwachstellenmanagement, die Konformitätsbewertung und die Meldepflichten. Isoliert betrachtet wäre dieselbe Server-Software eine Cloud-Dienstleistung und fiele unter NIS-2. Ihre funktionale Verbindung mit der lokalen Komponente zieht sie jedoch gemeinsam mit dem Produkt in den CRA.

Wichtig dabei ist die juristische Konstruktion: Die Server-Komponente wird nicht zu einem eigenen Produkt, das gesondert in Verkehr gebracht werden müsste. Sie wird vielmehr als Bestandteil des „Produkts mit digitalen Elementen“ definiert (Art. 3 Nr. 1 CRA — „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen“). Die Bereitstellung iSd Art. 3 Nr. 22 CRA erfolgt damit einmal — durch die Auslieferung der lokalen Komponente. Diese eine Bereitstellung trägt dann die regulatorische Behandlung beider Teile (lokal und Server) gemeinsam.

Wie genau dieser Brückenkopf funktioniert, ab wann eine Server-Komponente als RDPS qualifiziert und welche drei abgestuften Ergebnisse die EU-Kommission in ihrer Auslegungs-Guidance vorsieht, klären wir in den folgenden Artikeln dieser Serie. Beginnen werden wir mit einer praktischen Frage, die viele Anbieter überrascht hat: Was passiert, wenn ein vermeintlich reines Cloud-Produkt eine lokal installierte Komponente mitliefert?

Der Zeitplan im Blick

Bevor wir in die Detailfragen gehen, ein Blick auf die Daten, an denen sich jeder Hersteller orientieren muss [1, Art. 71]:

  • 10. Dezember 2024: Inkrafttreten der Verordnung. Ab diesem Tag läuft die Übergangsfrist.
  • 11. Juni 2026: Kapitel IV der Verordnung (Notifizierungsvorschriften für Konformitätsbewertungsstellen) wird wirksam.
  • 11. September 2026: Die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle greifen.
  • 11. Dezember 2027: Die vollständigen Produktanforderungen werden anwendbar. Ab diesem Tag dürfen nur noch CRA-konforme Produkte in den EU-Markt gelangen.

Sanktionen bei Verstössen reichen nach Art. 64 Abs. 2 CRA bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist [1, Art. 64 Abs. 2].

Wer jetzt klären sollte, ob er betroffen ist

Softwarehersteller in Deutschland und der Schweiz sollten die Frage „Sind wir vom CRA betroffen?“ produktbezogen beantworten. Eine pauschale Einordnung — oder das eigene Selbstverständnis als „Cloud-Anbieter“ — reicht dafür nicht. Die Prüfung setzt an drei Stellen an:

  • Erfüllt unser Produkt die Definition eines „Produkts mit digitalen Elementen“ nach Art. 3 Nr. 1 CRA?
  • Wird es im Sinne von Art. 3 Nr. 21 und 22 CRA in Verkehr gebracht — also als Kopie an den Nutzer abgegeben, sei es lokal oder über einen App Store?
  • Schliesst der bestimmungsgemässe Zweck oder die vernünftigerweise vorhersehbare Verwendung eine Datenverbindung mit einem Gerät oder Netz ein (Art. 2 Abs. 1 CRA)?

Sind alle drei Fragen mit Ja zu beantworten, ist das Produkt grundsätzlich erfasst. Bleibt eine der drei Antworten negativ, lohnt sich vor der endgültigen Einordnung der Blick in die Ausschlusstatbestände und in die RDPS-Frage des Folgeartikels.

Sie möchten in wenigen Minuten klären, ob Ihr Produkt unter den CRA fällt? Der CRA-Quick-Check führt Sie systematisch durch die Eingangsprüfung — von der Produktdefinition über die Inverkehrbringen-Frage bis zur Einordnung möglicher Datenfernverarbeitungslösungen. Das Ergebnis ist eine kostenlose und unverbindliche Orientierung. Keine Rechtsberatung im Sinne des RDG.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Veröffentlicht am: 09.03.2026. Zuletzt geprüft am: 13.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: SaaS und der Cyber Resilience Act — warum „wir sind doch nur Cloud“ als Argument nicht mehr reicht, sobald eine lokale Komponente mitgeliefert wird und wie die Datenfernverarbeitungslösung (RDPS) den Brückenkopf zwischen Produktrecht und Cloud schlägt.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyberresilienz-Verordnung). ABl. L, 20.11.2024. Insbesondere Art. 1, Art. 2, Art. 3 Nr. 1, 2, 4, 8, 9, 10, 21, 22; Art. 4 Abs. 3, Art. 5 Abs. 1, Art. 13, Art. 14, Art. 28, Art. 30, Art. 64, Art. 71; Erwägungsgründe (1), (3), (4), (9), (11), (12), (37). Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/deu

[2] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Juristischer Kommentar zur Auslegung des Anwendungsbereichs und der Begriffsbestimmungen des CRA, insbesondere § 4 Rn. 3–5 zur Frage, ob eine Datenfernverarbeitungslösung Tatbestandsmerkmal des Produktbegriffs ist.

[3] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026. Die Guidance ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sie ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Abschnitt 2.1 zum Inverkehrbringen (Rn. 13–16). Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation (Annex-Download: https://ec.europa.eu/newsroom/dae/redirection/document/131456).

[4] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Massnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). ABl. L 333, 27.12.2022. Verfügbar unter: https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[5] Europäische Kommission, „The ‚Blue Guide‘ on the implementation of EU product rules 2022“, Mitteilung der Kommission, ABl. C 247, 29.6.2022. Allgemeine Anleitung der EU-Kommission zur Auslegung des EU-Produktrechts (New Legislative Framework), insbesondere Abschnitt 2 zum Produktbegriff und Abschnitt 2.3 zum Inverkehrbringen. Verfügbar unter: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:52022XC0629%2804%29

[6] HUMAN Security, „Satori Threat Intelligence Disruption: BADBOX 2.0“, Threat-Intelligence-Bericht 2025, sowie Google, „Taking legal action against the BadBox 2.0 botnet“, Unternehmensmitteilung vom Juli 2025. Berichte zur Botnet-Operation BadBox 2.0 mit über 10 Millionen infizierten vernetzten Geräten. Verfügbar unter: https://www.humansecurity.com/learn/blog/satori-threat-intelligence-disruption-badbox-2-0/ und https://blog.google/technology/safety-security/google-taking-legal-action-against-the-badbox-20-botnet/. Hinweis: Industrie- und Unternehmensquellen, herangezogen als Beleg für einen aktuellen Vorfall.

[7] The Hacker News, „Weekly Recap: IoT Exploits, Wallet Breaches, Rogue Extensions, AI Abuse & More“, 5. Januar 2026, zur RondoDox-Kampagne und zur Schwachstelle React2Shell (CVE-2025-55182) in React Server Components und Next.js; Zahlen zu angreifbaren Systemen nach der Shadowserver Foundation. Verfügbar unter: https://thehackernews.com/2026/01/weekly-recap-iot-exploits-wallet.html. Hinweis: Fachmedien-Quelle, herangezogen als Beleg für einen aktuellen Vorfall.

[8] Forescout Technologies, „Die riskantesten vernetzten Geräte 2026“, Branchenbericht 2026. Erhebung zur Schwachstellendichte vernetzter Geräte. Hinweis: Herstellerbericht eines Sicherheitsunternehmens, herangezogen als Beleg für die aktuelle Bedrohungslage.

[9] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.2026, hier Nr. 1.3 (direkte und indirekte Datenverbindung, Positiv- und Negativbeispiele, Fn. 1 zu separat in Verkehr gebrachter Firmware), Nr. 1.4 (Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden), Nr. 1.6 (unfertige Software zu Testzwecken), Nr. 1.7 (öffentliche Softwarearchive), Nr. 1.8 (nationale Sicherheit und Verteidigung, Dual-Use), Nr. 1.9 (Ausnahmen aufgrund anderer Unionsrechtsakte, einschliesslich der Delegierten Verordnung (EU) 2025/1535), Nr. 2.1.1 (Verordnung (EU) 2018/1139, nicht zertifizierte Produkte und Komponenten), Nr. 2.2.1 (Richtlinie 2014/90/EU, nicht erfasste Komponenten) und Nr. 7.2 (Bestandsschutz bezogen auf das einzelne Exemplar, nicht auf den Produkttyp). Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; lebendes Dokument. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions

[10] Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 21 kommentiert von Mehnert, Art. 3 Nr. 22 von Poncza. Hier insbesondere Art. 3 Rn. 122 (Inverkehrbringen bezogen auf das einzelne Exemplar; nur Hersteller und Einführer können in den Verkehr bringen) und Art. 3 Rn. 135 (Abgabe bei reinen Softwareprodukten erst mit Durchführung des Downloads).

Hinweis zur Methodik

Dieser Artikel basiert primär auf der Verordnung (EU) 2024/2847 (CRA) und der am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichten Guidance der Kommission. Sie ersetzt für diese Auswertung den zuvor zitierten Entwurf Ares(2026)2319816 vom 3. März 2026, ist jedoch nicht verbindlich und schafft keine zusätzlichen Pflichten. Ergänzend wurden der „Blue Guide“ der EU-Kommission von 2022 zum allgemeinen EU-Produktrecht, der CRA-Kommentar von Wiebe (Nomos 2025), der artikelweise CRA-Kommentar von Schröder/Hartl (Nomos, 1. Auflage 2026) sowie die technischen FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026) herangezogen; die FAQs sind nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich. Zur Frage, ab wann eine Softwareversion als in Verkehr gebracht gilt, stellt dieser Artikel eine Auslegungsdivergenz ausdrücklich dar: Die Kommissions-Guidance stellt versionsbezogen auf das erstmalige Angebot ab und behandelt alle Kopien einer Version als zeitgleich in Verkehr gebracht (Rn. 13–16); der Kommentar von Schröder/Hartl stellt demgegenüber auf das einzelne Exemplar ab (Mehnert, Art. 3 Rn. 122, unter Verweis auf den Blue Guide, Ziffer 2.3) und sieht die Abgabe bei reinen Softwareprodukten erst mit der Durchführung des Downloads als vollzogen an (Poncza, Art. 3 Rn. 135). Die Frage ist weder durch den Verordnungstext noch durch Rechtsprechung geklärt; der Artikel bewertet keine der beiden Auffassungen als unvertretbar. Die Guidance bindet weder Marktüberwachungsbehörden noch Gerichte. Ergänzend sind die Aussagen der technischen FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026) unmittelbar am dortigen Wortlaut geprüft und mit der jeweiligen Gliederungsziffer belegt; die dort geschilderten Beispiele sind paraphrasiert. Alle Artikel-, Erwägungsgrund- und Randnummern-Verweise wurden gegen die Primärquellen abgeglichen.