Von Redaktion codAIx | 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 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]. Darüber hinaus lassen sich aus der Definition der physischen Verbindung in Art. 3 Nr. 9 CRA weitere Beispiele wie NFC, USB oder Ethernet ableiten [1, Art. 3 Nr. 9].

Art. 2 Abs. 2 bis 8 CRA enthält darüber hinaus Ausschlüsse für Bereiche, die bereits durch andere Unionsrechtsakte abschliessend reguliert sind: Medizinprodukte nach den Verordnungen (EU) 2017/745 (MDR) und (EU) 2017/746, nach der Verordnung (EU) 2018/1139 zertifizierte Produkte der zivilen Luftfahrt, bestimmte Kraftfahrzeuge nach der Verordnung (EU) 2019/2144, Schiffsausrüstung nach der Richtlinie 2014/90/EU sowie Produkte, die ausschliesslich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt werden. Auch für Ersatzteile gelten nach Art. 2 Abs. 6 CRA Sonderregelungen [1, Art. 2 Abs. 2–8].

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, eine CE-Kennzeichnung tragen und mit den Lebenszyklus-Pflichten zur Schwachstellenbehandlung versehen sein [1, Art. 13, 28, 30].

Das ist die gleiche 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.

Für die Auslegungs-Guidance der EU-Kommission ist dieses Inverkehrbringen so zentral, dass sie ihm in Abschnitt 2.1 ihres Entwurfs ein eigenes Kapitel widmet (Rn. 10–16) und dort speziell für reine Software-Produkte klärt, ab welchem Moment sie als „placed on the market" gelten (Rn. 13–16) [3, Abschnitt 2.1].

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 (herrschende Lesart)

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 Ares Rn. 167: „cloud computing services and cloud service models fall within the scope of Directive (EU) 2022/2555 (NIS 2)" [3, Rn. 167]. 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 (theoretisch denkbare Alternativauslegung)

Denkbar ist auch eine andere Konstruktion: SaaS-Code erfüllt die Software-Definition aus Art. 3 Nr. 4 CRA; man könnte ihn deshalb als „Softwareprodukt" iSd Art. 3 Nr. 1 CRA einordnen und das Ausscheiden aus dem CRA erst am Bereitstellungserfordernis des Art. 3 Nr. 22 CRA festmachen — es fehle die „Abgabe" einer Kopie. Diese Auslegung bleibt enger am isolierten Wortlaut des Art. 3 Nr. 22, der die „Abgabe" als ausdrückliches Tatbestandsmerkmal nennt. Sie wird in der deutschsprachigen Kommentarliteratur allerdings nicht als eigenständige herrschende oder verbreitete Gegenposition vertreten — die einschlägigen Kommentatoren folgen einheitlich Lesart A. Wir führen Lesart B daher nur der Vollständigkeit halber an; im Ergebnis kommt sie ohnehin zum gleichen Schluss.

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 systematisch tragfähiger und manipulationsfester ist und der herrschenden Kommentarliteratur entspricht.

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: 21.03.2026. Zuletzt geprüft am: 03.07.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, 21, 22; Art. 13, Art. 14, Art. 28, Art. 30, Art. 64, Art. 71; Erwägungsgründe (1), (3), (4), (11), (12). 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, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", 3. März 2026. Auslegungs-Guidance der EU-Kommission, insbesondere Abschnitt 2.1 zum Inverkehrbringen (Rn. 13–16). Konsultation der EU-Kommission abgelaufen am 31. März 2026; finale Version zum Stand 20. Mai 2026 noch nicht veröffentlicht. Verfügbar unter: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en

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

Hinweis zur Methodik

Dieser Artikel basiert primär auf der Verordnung (EU) 2024/2847 (CRA) und dem Entwurf der EU-Kommissions-Auslegungs-Guidance Ares(2026)2319816 vom 3. März 2026 (Stand der Konsultation: am 31. März 2026 abgelaufen; finale Version zum Stand 20. Mai 2026 noch nicht veröffentlicht). Ergänzend wurden der „Blue Guide" der EU-Kommission von 2022 zum allgemeinen EU-Produktrecht und der CRA-Kommentar von Wiebe (Nomos 2025) herangezogen. Alle Artikel-, Erwägungsgrund- und Randnummern-Verweise wurden gegen die Primärquellen abgeglichen. Stand: 20.05.2026 (v4 — Wiebe-Bedingungssatz und Werkstorprinzip ergänzt, Lesart B als theoretische Alternativauslegung eingeordnet; Vorfallbeispiel auf belegte RondoDox/React2Shell-Angabe korrigiert; Wiebe-Fundstelle § 4 Rn. 5).