Von Redaktion codAIx | 9. März 2026

Der Cyber Resilience Act (CRA) — Verordnung (EU) 2024/2847 — ist seit dem 10. Dezember 2024 in Kraft. Aber für wen gilt er eigentlich? Und warum fällt eine Desktop-Anwendung klar darunter, eine reine Browser-SaaS aber nicht, obwohl beide aus Software bestehen? In diesem Auftaktartikel unserer Serie für Softwarehersteller gehen wir den Verordnungstext systematisch durch. Wir zeigen, was der CRA regelt (Art. 1), wer in den Anwendungsbereich fällt (Art. 2), welche Produkte unstreitig erfasst sind (Art. 3 Nr. 1) — und warum die Antwort auf die SaaS-Frage nicht an der Software-Eigenschaft hängt, sondern an einem juristischen Schlüsselbegriff: dem Inverkehrbringen.

Warum der CRA überhaupt entstanden ist

Die Begründung steht in den Erwägungsgründen der Verordnung selbst. 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)]. Bis 2024 fehlte jedoch ein einheitlicher EU-weiter Rahmen für die Cybersicherheit von Produkten — die wenigen bestehenden Regelungen waren sektoral (Funkanlagen, Medizinprodukte, Fahrzeuge), national oder freiwillig. Hersteller konnten ein Produkt mit ungeklärtem Schutzniveau auf den Binnenmarkt bringen, Anwender hatten keine zuverlässige Informationsgrundlage, und nationale Alleingänge drohten den Binnenmarkt zu fragmentieren [1, ErwGr (1) und (4)].

Der CRA setzt genau hier an: Er schafft eine horizontale, EU-weit unmittelbar geltende Regulierung der Cybersicherheit von Produkten mit digitalen Elementen — vergleichbar in ihrer Tragweite mit der Datenschutz-Grundverordnung im Bereich personenbezogener Daten. Anstelle eines Flickenteppichs aus Branchenstandards definiert er 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.

Die zentrale gedankliche Achse ist damit gesetzt: Der CRA ist ein Produktrecht, kein Dienstleistungsrecht. Er regelt, was passieren muss, damit ein Produkt überhaupt auf den EU-Markt darf — und welche Pflichten danach für die Hersteller und übrigen Wirtschaftsakteure greifen.

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:

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

Zweitens muss das Produkt auf dem Markt bereitgestellt worden sein. 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].

Drittens 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 Verordnung definiert die drei Verbindungsarten selbst: die „logische Verbindung“ als virtuelle Darstellung einer Datenverbindung, die über eine Softwareschnittstelle hergestellt wird (Art. 3 Nr. 8); die „physische Verbindung“ als Verbindung, die mit physikalischen Mitteln wie elektrischen, optischen oder mechanischen Schnittstellen, Drähten oder Funkwellen hergestellt wird (Art. 3 Nr. 9) — daraus lassen sich Beispiele wie NFC, USB oder Ethernet ableiten; und die „indirekte Verbindung“ als Verbindung zu einem Gerät oder Netz, die nicht direkt erfolgt, sondern als Teil eines grösseren Systems, das seinerseits direkt mit diesem Gerät oder Netz verbunden werden kann (Art. 3 Nr. 10) [1, Art. 3 Nr. 8–10]. Die Kommentarliteratur versteht diese Voraussetzung weit: Sie erfasst nach Wiebe/Jossen nicht nur Internet-Verbindungen wie WLAN oder Bluetooth, sondern 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

Für Softwarehersteller ist die dritte Voraussetzung die praktisch folgenreichste Aussage zum Anwendungsbereich überhaupt — und sie wird regelmässig unterschätzt. Verbreitet ist die Annahme, eine Anwendung ohne eigene Netzfunktion falle aus dem CRA heraus. Das trifft nicht zu. Die technischen FAQs der Kommissionsdienststellen führen in Nr. 1.3 aus, dass eine logische Verbindung auch indirekt bestehen kann — nämlich dann, wenn das Produkt die Kommunikation nicht selbst initiiert, aber auf einem Hostsystem läuft, das dies tut. Als Beispiele nennen die FAQs ausdrücklich einen Offline-Texteditor und einen Taschenrechner, die über das Betriebssystem indirekt verbunden sind [9, Nr. 1.3]. Die Verordnung legt dieselbe Linie an: Erwägungsgrund (9) CRA hält fest, dass Hersteller auch die Cybersicherheit jener Produkte mit digitalen Elementen sicherstellen sollen, die nur indirekt mit anderen Geräten oder Netzen verbunden sind — weil sich Cyberbedrohungen über verkettete Schwachstellen fortpflanzen können [1, ErwGr (9)].

Praktisch heisst das: Nahezu jede Software, die auf einem vernetzten Host läuft, erfüllt das Verbindungskriterium. Realistisch verneinen lässt sich die Datenverbindung nur noch bei physisch isolierter, eingebetteter Firmware. Genau dort liegen auch die Negativbeispiele der FAQs — jeweils ausdrücklich unter der 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.

Zwei Punkte sind an dieser Liste wichtig. Erstens ist der Kontrast zum Taschenrechner-Beispiel oben kein Widerspruch: Der Taschenrechner als Anwendung auf einem vernetzten Betriebssystem ist erfasst, der Taschenrechner als isoliertes Gerät ohne jede Verbindungsfähigkeit nicht. Massgeblich ist die Umgebung, nicht die Funktion. Zweitens weisen die FAQs in einer Fussnote zu dieser Liste darauf hin, dass die genannte Firmware gleichwohl in den Anwendungsbereich fallen kann, wenn sie separat in Verkehr gebracht wird [9, Nr. 1.3 Fn. 1] — Art. 3 Nr. 1 CRA erfasst Komponenten, die getrennt in den Verkehr gebracht werden, ausdrücklich [1, Art. 3 Nr. 1].

Die FAQs sind von den Kommissionsdienststellen erstellt, nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; sie sind zudem als lebendes Dokument angelegt. Für die Praxis bleibt der Befund gleichwohl bedeutsam, weil er erkennen lässt, wie eng die Kommissionsdienststellen die Untergrenze des Anwendungsbereichs auslegen: Sie existiert — aber sie liegt sehr tief.

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.

Diese Liste ist mit dem Verordnungstext allein nicht vollständig. Hinzu kommt eine Ausnahme 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. Ausgenommen von dieser Ausnahme sind Fahrzeuge der Klasse L1e, die für den Pedalantrieb ausgelegt sind; für sie bleibt es beim CRA [9, Nr. 1.9]. Für Softwarehersteller ist das ein Randthema, kann aber etwa Steuerungssoftware von Elektrofahrrädern betreffen.

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].

Für Softwarehersteller, die als Zulieferer in Luftfahrt oder Schiffbau tätig sind, ist das der entscheidende Punkt: Die pauschale Auskunft „unsere Branche ist ausgenommen“ trägt nicht. Massgeblich ist, 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

Was der CRA unter einem Produkt mit digitalen Elementen versteht, definiert Art. 3 Nr. 1 CRA: 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].

Damit ist der zentrale juristische Mechanismus des CRA benannt: Anknüpfungspunkt ist der Moment, in dem ein Produkt vom Hersteller in die Sphäre des Marktes übergeht — also typischerweise an den Vertriebspartner oder den Endkunden ausgeliefert wird. 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 muss der Hersteller die Lebenszykluspflichten zur Schwachstellenbehandlung erfüllen [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 hat das zwei konkrete Folgen. Erstens lassen sich die Herstellerpflichten nicht dadurch abschichten, dass man die Auslieferung einem Vertriebspartner überlässt — der Vorgang, mit dem die Software den Hersteller verlässt, ist bereits das Inverkehrbringen. Zweitens sollten Unternehmen, die Software von Anbietern ausserhalb der EU beziehen und in der Union anbieten, prüfen, ob sie damit in die Einführerrolle geraten; die Pflichten des Einführers sind deutlich weitreichender als die des Händlers.

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. Der gegenwärtig veröffentlichte Annex zeigt, welche Auslegung des CRA die Kommission förmlich annehmen will. Nach der förmlichen Annahme können Marktüberwachungsbehörden diese Auslegung als Orientierung berücksichtigen. Ihre Entscheidungen müssen sie 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

Genau an dieser Stelle stösst die intuitive Erwartung an die Verordnungssystematik. SaaS-Anwendungen bestehen technisch aus Software — Art. 3 Nr. 4 CRA definiert Software 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 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, Importeure 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.

Damit das Schutzkonzept des CRA nicht an der Cloud-Grenze endet, hat der Gesetzgeber in Art. 3 Nr. 2 CRA eine zweite Definition geschaffen: die Datenfernverarbeitungslösung — Remote Data Processing Solution, kurz RDPS. Sie wirkt als regulatorische Brücke zwischen Produktrecht und Dienstleistungsrecht. Wenn eine in Verkehr gebrachte lokale Komponente eines Produkts ohne eine bestimmte Server-Software auch nur eine ihrer Funktionen nicht mehr ausführen kann, und wenn der Hersteller diese Server-Software selbst entworfen und entwickelt hat, gilt die Server-Software als untrennbarer Bestandteil des CRA-Produkts. Sie wird in dieselben CRA-Pflichten einbezogen wie die lokale Komponente — also in 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 würde unter NIS-2 fallen. Durch die funktionale Verbindung mit der lokalen Komponente wird sie aber gemeinsam mit dem Produkt vom CRA erfasst.

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

Für Softwarehersteller in Deutschland, Österreich und der Schweiz ergibt sich aus diesem Auftakt eine klare Handlungslinie. Die Frage „Sind wir vom CRA betroffen?“ lässt sich nicht pauschal beantworten und auch nicht aus dem eigenen Selbstverständnis als „Cloud-Anbieter“ ableiten. Sie ist eine produktbezogene Prüfung, die an drei Stellen ansetzt:

  • 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.

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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026. Der Annex ist die aktuelle veröffentlichte Textgrundlage und ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten (Stand 12.08.2026). 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 dem im Annex zu Communication C(2026) 5252 final veröffentlichten Guidance-Entwurf, dessen Inhalt am 27.07.2026 von der Kommission gebilligt wurde. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden; erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten. Der Annex ersetzt für die Auswertung den zuvor zitierten Entwurf Ares(2026)2319816 vom 3. März 2026. 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. Der veröffentlichte Annex dokumentiert die von der Kommission zur förmlichen Annahme vorgesehene Auslegung, bindet aber 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.

Stand: 12.08.2026 (v11 — Erscheinungsdatum im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 09.03.2026 gesetzt; zeitabhängige Formulierungen unverändert. v10 — Status der Guidance nach C(2026) 5252 präzisiert; die Bezeichnung als finale Guidance und die Aussage einer für den Vollzug massgeblichen Auslegung korrigiert; Bindungswirkung von CRA und sonstigen verbindlichen Rechtsakten gegenüber der nur orientierenden Guidance klargestellt. Die historischen Versionshinweise bleiben unverändert).

Stand: 13.08.2026 (v12 — freigegebene Schlusskorrektur: Grammatik, Zeichensetzung, Zitier- und Gedankenstriche sowie präzisere Zuordnung der Lebenszykluspflichten zum Hersteller. Vorherige Fassung: v11; zeitabhängige Formulierungen unverändert.)

Stand: 06.08.2026 (v9 — drei Ergänzungen aus den FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026) und dem Verordnungstext: erstens neuer Unterabschnitt „Warum fast jede Software auf einem vernetzten Rechner erfasst ist“ zur Reichweite der Datenverbindung — Legaldefinitionen der logischen, physischen und indirekten Verbindung in Art. 3 Nr. 8–10 CRA, Erfassung indirekt verbundener Software am Beispiel eines Offline-Texteditors oder Taschenrechners auf einem vernetzten Betriebssystem (FAQ Nr. 1.3), Erwägungsgrund (9) CRA, Negativbeispiele ohne jede Verbindungsfähigkeit sowie die Fussnote zu separat in Verkehr gebrachter Firmware; zweitens Ausnahmekatalog des Art. 2 CRA absatzweise aufgeschlüsselt (Abs. 2 bis 8, einschliesslich der Klarstellung, dass Art. 2 Abs. 3 an die Zertifizierung nach der Verordnung (EU) 2018/1139 anknüpft und nicht an den Luftfahrtsektor) und neuer Unterabschnitt „Zwei Missverständnisse bei den sektoralen Ausnahmen“ zu Dual-Use-Produkten (FAQ Nr. 1.8) und zu nicht zertifizierten Zulieferkomponenten und Drohnen der offenen Kategorie (FAQ Nr. 2.1.1, Nr. 2.2.1); drittens Ergänzung der Passage zum Inverkehrbringen von Softwareversionen um FAQ Nr. 7.2 — Bestandsschutz gilt nur für die einzelnen vor dem 11.12.2027 in Verkehr gebrachten Exemplare, nicht für den Produkttyp (Router-Beispiel 10.000/5.000), mit der Einordnung, dass die versionsbezogene Auslegung der Guidance insoweit eine Spezialregel gegenüber der allgemeinen produktrechtlichen Regel ist, und mit entsprechend verstärkter Handlungsempfehlung; Quellenverzeichnis: Eintrag [1] um Art. 3 Nr. 8–10, Art. 5 Abs. 1 und Erwägungsgrund (9) ergänzt, Eintrag [9] um die neu verwendeten FAQ-Ziffern erweitert). Vorherige Fassung (v8, Stand 06.08.2026): Abschnitt „Das Inverkehrbringen — der regulatorische Anknüpfungspunkt“ um zwei Unterabschnitte erweitert: „Wer ein Produkt überhaupt in den Verkehr bringen kann“ (nur Hersteller und Einführer; Händler wird bei erstmaliger Abgabe in der Union von ausserhalb bezogener Produkte selbst zum Einführer — NK-CRA/Mehnert, Art. 3 Rn. 122) und „Ab wann eine Softwareversion als in Verkehr gebracht gilt — eine offene Auslegungsfrage“ mit der Gegenüberstellung der versionsbezogenen Auslegung der Kommissions-Guidance (Rn. 13–16) und der exemplarbezogenen Auffassung des Kommentars von Schröder/Hartl (Mehnert, Art. 3 Rn. 122; Poncza, Art. 3 Rn. 135), einschliesslich der praktischen Tragweite für Downloads nach dem 11.12.2027 und einer Handlungsempfehlung; Abschnitt „Lesart B“ korrigiert und in Übereinstimmung mit Artikel 01 (v16) gebracht: Der bereitstellungsbezogene Begründungsweg wird in der Kommentarliteratur sehr wohl vertreten — von Poncza über das „Sachherrschaftsäquivalent“ (Art. 3 Rn. 135) —, er wird deshalb nicht mehr als blosse theoretische Alternativauslegung dargestellt; Quellenverzeichnis um Eintrag [10] (Schröder/Hartl, Nomos 2026) erweitert; Methodik-Hinweis um die Darstellung der Divergenz ergänzt. Vorherige Fassung (v7, Stand 06.08.2026): Ausnahmeliste zu Art. 2 CRA um die Delegierte Verordnung (EU) 2025/1535 ergänzt: Ausnahme für Produkte im Anwendungsbereich der Verordnung (EU) Nr. 168/2013 — zwei- und dreirädrige Fahrzeuge sowie vierrädrige Leichtfahrzeuge —, mit Rückausnahme für Fahrzeuge der Klasse L1e, die für den Pedalantrieb ausgelegt sind; neuer Abschnitt „Zwei praxisnahe Sonderregelungen: Testversionen und Software-Archive“ zu Art. 4 Abs. 3 CRA in Verbindung mit Erwägungsgrund (37) — unfertige Software befristet und mit sichtbarer Kennzeichnung, vorherige Risikobewertung, kein Zwang zum Wechsel auf Testversionen — und zu Art. 13 Abs. 11 CRA — öffentliche Softwarearchive mit klarem, leicht zugänglichem Risikohinweis; Quellenverzeichnis um Eintrag [9] (FAQs der Kommissionsdienststellen) erweitert und Eintrag [1] um Art. 4 Abs. 3 und Erwägungsgrund (37) ergänzt; Stichtagsangaben auf 06.08.2026 aktualisiert. Vorherige Fassung (v6, Stand 05.08.2026): Fussnote [3] und Fliesstext-Zitate auf die finale EU-Kommissions-Guidance C(2026) 5252 final umgestellt, die den bisher zitierten Entwurf Ares(2026)2319816 ersetzt; Randnummern zum Inverkehrbringen von Software in Abschnitt 2.1 (Rn. 13–16) gegen den finalen Wortlaut geprüft und inhaltlich unverändert bestätigt; Verweis auf Cloud-Dienste/NIS-2 von „Ares Rn. 167“ auf „Rn. 183“ aktualisiert und um den Hinweis der Guidance auf die Durchführungsverordnung (EU) 2024/2690 ergänzt. Vorherige Fassung (v4, Stand 20.05.2026): Wiebe-Bedingungssatz und Werkstorprinzip ergänzt, Lesart B als theoretische Alternativauslegung eingeordnet; Vorfallbeispiel auf belegte RondoDox/React2Shell-Angabe korrigiert; Wiebe-Fundstelle § 4 Rn. 5.