Von Redaktion codAIx | 9. März 2026

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 beim Produktrecht ansetzen. Der seit dem 10. Dezember 2024 in Kraft befindliche 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 auf zwei juristische Schlüsselbegriffe an: den Produktbegriff und 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. Rechtlich ist der CRA allerdings Produktrecht: Er knüpft an das Inverkehrbringen an und erstreckt die Herstellerpflichten über den Unterstützungszeitraum (Art. 1, Art. 13 CRA). 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 im März 2025 auf, dass mehr als eine Million Verbrauchergerä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 bezifferte im Juli 2025 die Zahl betroffener nicht zertifizierter Android-Geräte auf über zehn Millionen und leitete 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 Marktbezug 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; 9, Nr. 1.5].

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]. Erwägungsgrund (9) nennt als logische Verbindungen insbesondere Netzwerksockets, Pipes, Dateien und Programmierschnittstellen; die Kommentarliteratur zählt dazu auch Datenbankzugriffe [1, ErwGr (9); 2, Wiebe/Jossen, § 4 Rn. 3]. Einwegschnittstellen wie RFID-Tags oder QR-Codes ohne aktive Rückkanal-Komponente dürften nach der Kommentarliteratur dagegen nicht genügen [2, Wiebe/Jossen, § 4 Rn. 3 Fn. 6, unter Verweis auf Schöttle, MMR 2024, 741, 742].

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. Eine Grenze gibt es dennoch: Nach der Auslegungs-Guidance der EU-Kommission — sie ist rechtlich nicht bindend, gibt aber die Auslegung der Kommission wieder — liegt eine Datenverbindung nur vor, wenn digital codierte Information gezielt gesendet und beim Empfänger als Daten gelesen werden kann; ein blosses Ein- und Ausschalten genügt nicht, wenn die Zustände keine Daten darstellen sollen [3, Rn. 26–28]. Die in den FAQs genannten isolierten Firmwarefälle sind Beispiele, keine abschliessende Kategorie. 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 4, 6 und 7 CRA enthält Bereichs- beziehungsweise Produktausnahmen; Abs. 5 ermächtigt die Kommission zu weiteren Einschränkungen durch delegierte Rechtsakte, Abs. 8 begrenzt bestimmte Informationspflichten. 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- oder dreirädrige und vierrädrige Fahrzeuge der Klasse L. 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 für Elektro-Motorroller.

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 der CRA nach Art. 3 Nr. 1 und nach der Auslegungs-Guidance der Kommission [3, Rn. 18] erfassen kann — sofern sie auf dem Markt bereitgestellt werden und ihr bestimmungsgemässer Zweck oder ihre vernünftigerweise vorhersehbare Verwendung eine Datenverbindung einschliesst:

  • 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. Für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, muss zu diesem Zeitpunkt grundsätzlich die Konformität mit den grundlegenden Cybersicherheitsanforderungen aus Anhang I CRA nachgewiesen, das anwendbare Konformitätsbewertungsverfahren abgeschlossen und die CE-Kennzeichnung angebracht sein. Die Meldepflichten aus Art. 14 CRA gelten dagegen bereits seit dem 11. September 2026 auch für erfasste Produkte, die zuvor in Verkehr gebracht wurden [1, Art. 13, 14, 28, 30, 69 Abs. 3 und 71 Abs. 2].

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 verschiebt den massgeblichen Zeitpunkt nicht nach hinten: Schon wenn die Software den Hersteller verlässt, kann 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 Guidance knüpft an das erstmalige Angebot zum Vertrieb oder zur Verwendung an. Alle Kopien eigenständiger Software gelten damit als zeitgleich in Verkehr gebracht — unabhängig davon, wann der einzelne Nutzer sie tatsächlich herunterlädt. Parallel angebotene Varianten, die sich in ihren Komponenten, ihrer Konfiguration oder ihrem Funktionsumfang unterscheiden, sind dagegen jeweils eigene Produkte und getrennt zu betrachten. Nicht wesentliche Folge-Updates lassen das ursprüngliche Datum unverändert; eine wesentlich geänderte Fassung gilt dagegen als neu in Verkehr gebracht [3, Rn. 13–16, Beispiel 2].

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 Guidance hält ausdrücklich daran fest, dass jede Kopie ein eigenes Produkt bleibt (Rn. 14), behandelt aber alle Kopien eigenständiger Software als zeitgleich in Verkehr gebracht — eine auf immaterielle Software zugeschnittene Konkretisierung, die nach Rn. 16 nicht für Software gilt, die mit Hardware ein Produkt bildet. Ob diese Konkretisierung mit der stückbezogenen Grundregel vereinbar ist, ist der Kern der Divergenz zur Kommentarliteratur.

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, den die FAQs in Nr. 7.2 und die Guidance selbst in Rn. 11 zitieren [9, Nr. 7.2; 3, Rn. 11]. Verbindlich geklärt ist die Frage bislang weder durch die Verordnung 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. Das bedeutet nicht zwingend ein Redesign: Zeigt eine aktuelle Risikobewertung nach Art. 13 Abs. 2, dass das Produkt bereits angemessene und wirksame Sicherheitsmassnahmen enthält, kann sich der Hersteller nach der Guidance darauf stützen; historische Entwicklungs- und Testunterlagen muss er nicht nachträglich erstellen. Konformitätsbewertung, EU-Konformitätserklärung, CE-Kennzeichnung und die Prozesse zur Schwachstellenbehandlung nach Anhang I Teil II bleiben aber erforderlich [3, Rn. 33–39, Beispiel 12]. Wer sich auf die Guidance stützt, sollte den Zeitpunkt des ersten Angebots je Produkt beziehungsweise je wesentlich geänderter Fassung belegbar dokumentieren und für Folge-Updates festhalten, warum sie keine wesentliche Änderung sind. Zur Abgrenzung siehe Artikel 11.

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 darauf hinweist, dass sie der Verordnung nicht entspricht und ausser zu Testzwecken nicht auf dem Markt verfügbar sein wird. Gemeint sind Alpha- und Beta-Versionen sowie Release Candidates. Erwägungsgrund (37) CRA ergänzt Bedingungen, die in der Praxis oft untergehen: Die Freigabe soll erst nach einer Risikobewertung erfolgen. Die Software soll die Sicherheitsanforderungen an die Produkteigenschaften (Anhang I Teil I) und die Anforderungen an die Schwachstellenbehandlung so weit wie möglich erfüllen. 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.

Die Kommission vertritt in ihrer Guidance die Auffassung, dass entfernt ausgeführte Software, die der Nutzer lediglich aufruft, für sich genommen kein Produkt mit digitalen Elementen ist. Das gilt typischerweise für Webanwendungen, die ausschliesslich über den Browser genutzt werden [3, Rn. 19–21, Beispiel 5]. Die FAQs der Kommissionsdienststellen bestätigen diese Orientierung [9, Nr. 1.2]. Nach unserer Einordnung stützt die Kommission damit im Ergebnis die unten als Lesart A dargestellte produktbezogene Begründung. Ihre Kriterien enthalten allerdings auch Elemente der Bereitstellung: Software muss dem Nutzer ‚geliefert‘, von ihm ‚erlangt‘ und auf seiner Seite ausgeführt werden (Rn. 20). Verbindlich sind weder die Guidance noch die FAQs.

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. In diese Richtung weist auch der „Blue Guide on the implementation of EU product rules“ 2022 der EU-Kommission, der Inverkehrbringen und Bereitstellung auf das einzelne Produkt bezieht (Abschnitte 2.2 und 2.3) [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.

Im CRA-Kommentar von Wiebe grenzen Wiebe/Jossen eigenständige Cloud-Dienstmodelle wie SaaS, PaaS und IaaS aus, soweit sie die Produktfunktionalität nicht unterstützen oder für sie nicht erforderlich sind; dann handelt es sich weder um CRA-relevante Software noch um eine Datenfernverarbeitungslösung eines anderen Produkts [2, Wiebe/Jossen, § 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 fehlender funktionaler Unterstützung oder Erforderlichkeit: 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]. Die Kommissions-Guidance verweist in Rn. 183 — unter Wiedergabe von Erwägungsgrund (12) — ebenfalls darauf, dass Cloud-Computing-Dienste und Cloud-Dienstmodelle in den Anwendungsbereich der NIS-2-Richtlinie fallen; deren Cybersicherheitsanforderungen werden für bestimmte Anbieter durch die Durchführungsverordnung (EU) 2024/2690 konkretisiert [3, Rn. 183]. Der ausdrückliche produktbezogene Beleg für reine Browseranwendungen findet sich dagegen in Rn. 19–21. Nach Lesart A kommt es auf die Frage der Bereitstellung 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: Vereinfacht gesagt ist ein Produkt in Verkehr gebracht, wenn es mit dem Willen des Herstellers dessen digitales Werkstor verlässt [2, Wiebe, § 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. Die Übertragung des Werkstorprinzips auf SaaS ist unsere Einordnung; der Kommentar selbst lässt bei unverkörperter Software auch die Übermittlung von Zugangsdaten oder die Freischaltung des Nutzers als Abgabe genügen. Streng genommen setzt das Werkstorprinzip an der Bereitstellung an (Lesart B); es macht aber zugleich anschaulich, dass es bei SaaS kein abgrenzbares Exemplar gibt, das das Werkstor verlassen könnte.

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“ im Sinne des 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 Schröder/Hartl-Kommentar 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. 133, 135]. Ausführlich dazu Artikel 01 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 Pflichten nach dem nationalen NIS-2-Umsetzungsrecht, sofern er als wesentliche oder wichtige Einrichtung 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 und Smart-TV-Apps können eigenständige Produkte sein; die Guidance nennt ausdrücklich Browser-Erweiterungen und Desktop-Anwendungen in Web-Technik, die zur lokalen Ausführung geliefert werden [3, Rn. 20, Beispiel 4]. Progressive Web Apps, die ausschliesslich über einen Browser genutzt werden, sind nach Auffassung der Kommission dagegen für sich genommen kein Produkt [3, Rn. 21, Beispiel 5]. Entscheidend sind Bereitstellung und tatsächliche Ausführung; ein Installationssymbol oder ein Offline-Cache allein beantwortet die Abgrenzung nicht. Echte Hybridfälle sind anhand ihrer konkreten Funktionsweise zu prüfen.

An der Cloud-Grenze soll das Schutzkonzept des CRA dennoch nicht enden. Art. 3 Nr. 2 CRA enthält deshalb die Begriffsbestimmung der Datenfernverarbeitung, auf der die „Datenfernverarbeitungslösung“ aus Art. 3 Nr. 1 aufbaut — 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 oder unter seiner Verantwortung — etwa als Auftragsentwicklung — konzipiert und entwickelt, gilt sie als Bestandteil des CRA-Produkts. Für sie greifen dieselben CRA-Pflichten wie für die lokale Komponente: die grundlegenden Cybersicherheitsanforderungen nach Anhang I, die Software-Stückliste (englisch software bill of materials, SBOM), das Schwachstellenmanagement, die Konformitätsbewertung und die Meldepflichten. Isoliert betrachtet wäre dieselbe Server-Software kein Produkt mit digitalen Elementen; erst ihre funktionale Verbindung mit der lokalen Komponente zieht sie gemeinsam mit dem Produkt in den CRA. Ob daneben NIS-2 auf den Anbieter oder Betreiber anwendbar ist, richtet sich nach dem Anwendungsbereich der Richtlinie und ist gesondert zu prüfen.

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 im Sinne des 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) wurde anwendbar.
  • 11. September 2026: Die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten seit diesem Tag auch für Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden (Art. 69 Abs. 3). Gemeldet wird über die seither betriebene einheitliche Meldeplattform (Single Reporting Platform) der ENISA [1, Art. 16].
  • 11. Dezember 2027: Die vollständigen Produktanforderungen werden anwendbar. Ab diesem Tag dürfen nur noch CRA-konforme Produkte in den EU-Markt gelangen.

Bei Verstössen gegen die grundlegenden Anforderungen nach Anhang I oder die Pflichten aus Art. 13 und 14 drohen nach Art. 64 Abs. 2 CRA Geldbussen von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist. Für andere Verstösse gelten niedrigere Höchstbeträge [1, Art. 64 Abs. 2–4].

Zwei Ausnahmen enthält Art. 64 Abs. 10 CRA: Gegen Kleinst- und Kleinunternehmen werden keine Geldbussen nach den Absätzen 2 bis 9 verhängt, soweit es allein um die versäumte 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 lit. a oder Abs. 4 lit. a geht (lit. a). Gegen Verwalter quelloffener Software werden für keinen Verstoss Geldbussen verhängt (lit. b) [1, Art. 64 Abs. 10]. Mehr dazu in Artikel 08.

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. 22 CRA auf dem Markt bereitgestellt — also dem Nutzer zur Ausführung auf seiner Seite geliefert, etwa per Download, auf Datenträger 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 — vorbehaltlich der Ausschlüsse in Art. 2 Abs. 2 bis 4, 6 und 7 CRA sowie der auf Art. 2 Abs. 5 CRA gestützten Delegierten Verordnung (EU) 2025/1535. Fehlt es mangels lokaler Komponente bereits am Produkt, bleibt zu prüfen, ob die Server-Software als Datenfernverarbeitung eines anderen Produkts desselben Herstellers erfasst wird; dazu der Folgeartikel.

Für Schweizer Hersteller ist der CRA massgeblich für jedes erfasste Produkt, das sie in der EU bereitstellen. Der Bundesrat hat am 25. September 2026 zudem ein eigenes, am CRA orientiertes Cybersicherheitsgesetz in Auftrag gegeben; die Vernehmlassungsvorlage ist bis Juni 2027 geplant [11].

Das Wichtigste für Hersteller

  • Ob ein Produkt erfasst ist, entscheidet sich produktbezogen an drei Voraussetzungen: Produkt mit digitalen Elementen (Art. 3 Nr. 1), Bereitstellung auf dem Markt und Datenverbindung (Art. 2 Abs. 1). Schon eine indirekte Verbindung über ein vernetztes Betriebssystem genügt.
  • Die Ausnahmen des Art. 2 sind eng: Dual-Use-Produkte sowie nicht zertifizierte Produkte und Komponenten für Luftfahrt oder Schiffsausrüstung können dem CRA unterliegen.
  • Eine reine Browser-SaaS ist für sich genommen kein Produkt mit digitalen Elementen. Wird eine lokale Komponente mitgeliefert, kann die herstellereigene Server-Software als Datenfernverarbeitungslösung Teil des Produkts werden.
  • Wann Software in Verkehr gebracht ist, ist umstritten: Die Guidance stellt auf das erste Angebot ab, der Kommentar von Schröder/Hartl auf jede einzelne Kopie. Wer vorsichtig plant, behandelt Versionen, die nach dem 11. Dezember 2027 noch angeboten werden, wie neu in Verkehr gebrachte Produkte; wer sich auf die Guidance stützt, dokumentiert den Zeitpunkt des ersten Angebots je Fassung.
  • Die Meldepflichten nach Art. 14 gelten seit dem 11. September 2026 auch für bereits in Verkehr gebrachte Produkte; die vollständigen Produktanforderungen ab dem 11. Dezember 2027.

Sie möchten in wenigen Minuten einschätzen, ob Ihr Produkt unter den CRA fallen könnte? Der CRA-Quick-Check führt Sie 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 Ersteinschätzung.

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 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.4 vom 04.09.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 Guidance stellt bei eigenständiger Software auf das erstmalige Angebot ab, behandelt alle Kopien als zeitgleich in Verkehr gebracht und knüpft ein neues Inverkehrbringen bei Folge-Updates an eine wesentliche Änderung (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 Aussagen der FAQs wurden unmittelbar am Wortlaut geprüft und mit der jeweiligen Gliederungsziffer belegt; die dort geschilderten Beispiele sind paraphrasiert.

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. 16, Art. 28, Art. 30, Art. 64, Art. 69 Abs. 2 und 3, Art. 71, Anhang I Teil I; Erwägungsgründe (1), (3), (4), (9), (11), (12), (37). Art. 64 Abs. 10 in der Fassung der Berichtigung ABl. L 2025/90555 vom 02.07.2025. 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 — Wiebe/Jossen, § 4 Rn. 3 (Datenverbindung) und Rn. 5 (Cloud-Dienstmodelle); Wiebe, § 4 Rn. 18 (Abgabe unverkörperter Software, Werkstorprinzip).

[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 (Rn. 10–16), Abschnitt 2.2 (Rn. 17–21), Abschnitt 2.5 (Rn. 26–28), Abschnitt 2.7 (Rn. 33–39) und Kapitel 8 (insbesondere Rn. 183). 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 Abschnitte 2.2 und 2.3 zu Bereitstellung und 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 Targets Consumer Devices with Multiple Fraud Schemes“, Threat-Intelligence-Bericht vom 05.03.2025, sowie Google, „We’re taking legal action against the BadBox 2.0 botnet“, Unternehmensmitteilung vom Juli 2025. Berichte zur Botnet-Operation BadBox 2.0: HUMAN Security nennt mehr als eine Million betroffene Verbrauchergeräte, Google über zehn Millionen betroffene nicht zertifizierte Android-Geräte. Ergänzend: Federal Bureau of Investigation (FBI), Internet Crime Complaint Center, „Home Internet Connected Devices Facilitate Criminal Activity“, Public Service Announcement I-060525-PSA vom 05.06.2025, unter anderem zu nachgerüsteten Infotainment-Systemen in Fahrzeugen. Verfügbar unter: https://www.humansecurity.com/learn/blog/satori-threat-intelligence-disruption-badbox-2-0/, https://blog.google/technology/safety-security/google-taking-legal-action-against-the-badbox-20-botnet/ und https://www.ic3.gov/PSA/2025/PSA250605. Hinweis: Industrie- und Unternehmensquellen sowie ein Behördenhinweis, 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, „The Riskiest Devices of 2026“, Branchenbericht 2026. Erhebung zur Schwachstellendichte vernetzter Geräte; der Bericht nennt für Router und Switches im ausgewerteten Datenbestand durchschnittlich nahezu 32 Schwachstellen je Gerät. Hinweis: Herstellerbericht eines Sicherheitsunternehmens, herangezogen als Beleg für die aktuelle Bedrohungslage. Verfügbar unter: https://www.forescout.com/research-labs/the-riskiest-devices-of-2026/.

[9] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026, hier Nr. 1.2 (eigenständige SaaS), 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.5 (Eigengebrauch), 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/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Mehnert, Art. 3 Rn. 122 (Inverkehrbringen bezogen auf das einzelne Exemplar; nur Hersteller und Einführer können in den Verkehr bringen); Poncza, Art. 3 Rn. 133, 135 (Sachherrschaft und Sachherrschaftsäquivalent; Abgabe bei reinen Softwareprodukten erst mit Durchführung des Downloads).

[11] Der Bundesrat, „Bundesrat will neues Cybersicherheitsgesetz schaffen“, Medienmitteilung vom 25.09.2026.

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. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 09.03.2026, zuletzt geändert am 18.10.2026.

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