SaaS und der Cyber Resilience Act: Warum „Wir sind doch nur Cloud“ nicht mehr reicht

Von Redaktion codAIx | 16. März 2026

Ab dem 11. Dezember 2027 gelten die Cybersicherheitsanforderungen des EU Cyber Resilience Act (CRA) für alle „Produkte mit digitalen Elementen“ auf dem europäischen Markt. Viele SaaS-Anbieter wiegen sich in Sicherheit: Ihre Software läuft in der Cloud, nicht auf dem Gerät des Kunden — also keine CRA-Pflicht, richtig? Die Antwort ist komplizierter, als die meisten erwarten.

Eine Verordnung, die alles ändert

Der Cyber Resilience Act — offiziell Verordnung (EU) 2024/2847 [1] — ist die erste EU-weite horizontale Regulierung, die verbindliche Cybersicherheitsanforderungen für Software und Hardware festschreibt. Nicht als freiwilliger Standard, nicht als branchenspezifische Richtlinie, sondern als unmittelbar geltendes Recht in allen 27 Mitgliedstaaten.

Die zentrale Idee: Wer ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, muss nachweisen, dass es grundlegende Cybersicherheitsanforderungen erfüllt — von der Entwicklung über den gesamten Lebenszyklus bis zum End-of-Support. Dazu gehören Vulnerability Management, Software Bill of Materials (SBOM), Security by Design und eine dokumentierte Konformitätsbewertung.

Der Zeitplan steht fest: Die Verordnung ist seit 10. Dezember 2024 in Kraft [1, Art. 71 Abs. 1 i. V. m. Veröffentlichung im ABl. vom 20.11.2024]. Das Kapitel IV (Notifizierungsvorschriften, Art. 35–51 CRA) gilt ab dem 11. Juni 2026 [1, Art. 71 Abs. 2 UAbs. 2]. Die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen greifen ab dem 11. September 2026 — das sind zum Stand 20. Mai 2026 noch knapp vier Monate [1, Art. 14 i. V. m. Art. 71 Abs. 2 UAbs. 2]. Die vollständigen Produktanforderungen gelten ab dem 11. Dezember 2027 — also etwa 19 Monate später [1, Art. 71 Abs. 2 UAbs. 1]. Wer dann nicht konform ist, riskiert Bussgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes [1, Art. 64 Abs. 2].

Was genau ist ein „Produkt mit digitalen Elementen“?

Art. 3 Nr. 1 CRA definiert den Schlüsselbegriff: Ein Produkt mit digitalen Elementen ist jedes Software- oder Hardwareprodukt „und dessen Datenfernverarbeitungslösungen, einschliesslich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ [1, Art. 3 Nr. 1].

Zwei Dinge fallen auf. Zunächst: Software allein — ohne jede Hardwarekomponente — kann ein Produkt mit digitalen Elementen sein. Eine Desktop-Anwendung, eine Mobile App, ein Firmware-Update: All das fällt unter den CRA, sobald es auf dem EU-Markt bereitgestellt wird. Art. 3 Nr. 1 CRA stellt dies ausdrücklich klar [1, Art. 3 Nr. 1].

Darüber hinaus ist — und hier wird es für SaaS-Anbieter relevant — der Begriff der „Datenfernverarbeitungslösung“ (im Englischen: Remote Data Processing Solution, kurz RDPS) zu beachten. Art. 3 Nr. 2 CRA definiert die zugrunde liegende „Datenfernverarbeitung“ als jede Datenverarbeitung in der Distanz, für die die Software vom Hersteller oder unter dessen Verantwortung konzipiert und entwickelt wird und deren Fehlen verhindern würde, dass das Produkt mit digitalen Elementen eine seiner Funktionen ausführen kann [1, Art. 3 Nr. 2]. Der Verordnungstext nennt damit drei Tatbestandsmerkmale, die wir nachfolgend in der Reihenfolge des Gesetzeswortlauts erläutern:

Erstens muss die Datenverarbeitung räumlich entfernt stattfinden — also nicht lokal auf dem Gerät des Nutzers. Art. 3 Nr. 2 CRA knüpft dabei ausschliesslich an die Software an: erfasst ist eine „entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird“ [1, Art. 3 Nr. 2]. Der Kommentar von Schröder/Hartl zum CRA betont dabei, dass es um mehr geht als um die blosse Konnektivität des Produkts, also mehr als um die nach Art. 2 Abs. 1 CRA ohnehin geforderte Fähigkeit zur Verbindung mit einem Netz oder Gerät — sonst hätte der Begriff keine eigenständige Bedeutung; „entfernt“ heisst lediglich, dass die Verarbeitung nicht lokal auf dem Produkt stattfindet, praktisch also in einem Cloud-Dienst [10, Hofmann, Art. 3 Rn. 13, 15]. Wem die Server-Infrastruktur selbst gehört, regelt der Wortlaut nicht. Auch Erwägungsgrund 11 stellt nur auf die Funktionserforderlichkeit ab: „die Fernverarbeitung oder -speicherung [fällt] nur insoweit in den Anwendungsbereich dieser Verordnung, als sie notwendig ist, damit ein Produkt mit digitalen Elementen seine Funktionen erfüllen kann“ [1, ErwGr (11)]. Damit kommen eigene Rechenzentren des Herstellers, Hyperscaler-Dienste (AWS, Azure, GCP) und On-Premises-Installationen beim Kunden gleichermassen in Betracht, solange die dort laufende Software vom Hersteller stammt.

Zweitens muss die Software vom Hersteller selbst entwickelt worden sein oder unter dessen Verantwortung stehen. Art. 3 Nr. 13 CRA definiert „Hersteller“ weit: erfasst ist eine Person, die „Produkte mit digitalen Elementen entwickelt oder herstellt oder die Produkte mit digitalen Elementen konzipieren, entwickeln oder herstellen lässt und sie unter ihrem Namen oder ihrer Marke vermarktet, sei es gegen Bezahlung, zur Monetarisierung oder unentgeltlich“ [1, Art. 3 Nr. 13]. Auftragsentwicklung, OEM- und White-Label-Konstruktionen sowie individuell für das Produkt entwickelte SaaS-Komponenten fallen damit in die Verantwortungssphäre des Herstellers, auch wenn er sie nicht selbst codiert. Erwägungsgrund 12 grenzt umgekehrt aus: „Cloud-Dienste, die ausserhalb der Verantwortung eines Herstellers eines Produkts mit digitalen Elementen entworfen und entwickelt wurden, [fallen] nicht in den Anwendungsbereich dieser Verordnung“ [1, ErwGr (12)]. Generische Cloud-Bausteine, die der Hersteller lediglich als Infrastruktur einkauft — etwa Speicherdienste oder ein Standard-Authentifizierungsanbieter —, bleiben damit aussen vor.

Drittens — und das ist der praktisch entscheidende Punkt — würde das Fehlen der entfernten Verarbeitung verhindern, dass das Produkt eine seiner Funktionen ausführen kann. Art. 3 Nr. 2 CRA verlangt ausdrücklich eine Verarbeitung, „ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte“ [1, Art. 3 Nr. 2]. Erwägungsgrund 12 macht das negativ greifbar: „Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen, [fallen] nicht in den Anwendungsbereich dieser Verordnung“ [1, ErwGr (12)] — umgekehrt stellt der Kommentar von Schröder/Hartl an die ausgelagerte Funktion keine hohen Anforderungen: Prinzipiell genügt jede Funktion des Produkts; ausgenommen bleibt nur, was die Funktionalität gar nicht unterstützt, etwa eine blosse Informations-Website des Herstellers [10, Hofmann, Art. 3 Rn. 18]. Für die Praxis folgt daraus: Optionale, hilfreiche, aber für die Kernfunktion entbehrliche Cloud-Komponenten — etwa ein parallel laufendes Telemetrie-Dashboard oder ein reines Service-Portal — lösen für sich genommen keine Pflicht nach dem CRA aus. Ist die entfernte Verarbeitung dagegen funktional unverzichtbar, wird das gesamte Produkt — lokale Komponente plus Cloud-Backend — als Einheit nach dem CRA bewertet.

Hinweis zur Reihenfolge: Die EU-Kommission greift dieselben drei Tatbestandsmerkmale in ihrer Guidance C(2026) 5252 final, Annex, Rn. 184 auf, ordnet sie aber analytisch um: Sie zieht die Funktionsprüfung vor die Herstellerprüfung, weil das die sachlich klarere Prüfungsreihenfolge ergibt. Wir folgen im nächsten Teil dieser Serie der Reihenfolge der Kommission. Die rechtsdogmatische Substanz bleibt identisch — nur die Prüfungsabfolge unterscheidet sich [5].

In der deutschsprachigen Kommentarliteratur ist umstritten, ob eine Datenfernverarbeitungslösung ein zwingendes Tatbestandsmerkmal des Produktbegriffs ist. Die überwiegende Auffassung verneint dies (so Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3, 5) [8]; eine Mindermeinung (Schöttle, MMR 2024, 741, 742) fasst sie als kumulatives Erfordernis auf. Der Kommentar von Schröder/Hartl stellt beide Auffassungen ausdrücklich gegenüber und verweist für die kumulative Lesart ebenfalls auf Schöttle; er selbst liest das „und“ im Sinne von „einschliesslich“: Fehlt die Datenfernverarbeitungslösung, bleibt das Produkt als „unbegleitetes“ Produkt mit digitalen Elementen erfasst. Ein kumulatives Verständnis würde den Anwendungsbereich empfindlich verkürzen, weil viele Produkte über keine solche Software verfügen — eine Regulierung, die diese von vornherein auslässt, liesse sich kaum als horizontal bezeichnen [10, Hofmann, Art. 3 Rn. 7 f.]. Im Zweifel sollten auch Hersteller reiner Offline-Software die CRA-Anwendbarkeit prüfen.

Warum SaaS systematisch besonders behandelt wird

Bevor wir auf die praktische Falle für SaaS-Anbieter eingehen, lohnt ein Blick auf die rechtliche Systematik. Eine SaaS ist technisch zweifellos „Software“ im Sinne von Art. 3 Nr. 4 CRA — „Teil eines elektronischen Informationssystems, der aus Computercode besteht“ [1, Art. 3 Nr. 4]. Trotzdem fällt eine reine Browser-SaaS nicht unter den CRA. Wo genau sie aus dem Anwendungsbereich herausfällt, ist juristisch nicht zweifelsfrei. In der Kommentarliteratur stehen sich zwei Begründungswege gegenüber, die im Ergebnis zur selben Schlussfolgerung führen.

Lesart A (produktbezogener Begründungsweg) — Scheitern am Produkterfordernis. Nach dieser Auffassung ist eine reine SaaS bereits kein „Produkt“ iSd Art. 3 Nr. 1 CRA. „Produkt“ ist im EU-Produktrecht eine abgrenzbare, in eine einzelne Marktbereitstellung überführbare Einheit — so auch der „Blue Guide on the implementation of EU product rules“ 2022 der EU-Kommission in Abschnitt 2 [9]. Eine SaaS ist ihrem Wesen nach das Gegenteil: kein abgegrenztes Software-Artefakt, sondern ein kontinuierlich erbrachter Dienst. 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“ [8, § 4 Rn. 5]. SaaS ist also technisch Software, aber — solange sie kein Produkt funktional trägt — keine CRA-relevante Software. Erwägungsgrund 12 CRA bekräftigt das, indem er Cloud-Dienstmodelle der NIS-2-Richtlinie zuweist [1, ErwGr (12); 4]; die EU-Kommissions-Guidance bestätigt es in Rn. 183 und verweist dort ergänzend auf die Durchführungsverordnung (EU) 2024/2690, welche die NIS-2-Cybersicherheitsanforderungen für Cloud-Computing-Dienstleister weiter konkretisiert [5, Rn. 183].

Lesart B (bereitstellungsbezogener Begründungsweg) — Scheitern am Bereitstellungserfordernis. Der zweite Weg ordnet SaaS-Code durchaus als „Softwareprodukt“ iSd Art. 3 Nr. 1 CRA ein und lässt ihn erst an der fehlenden „Abgabe“ iSd Art. 3 Nr. 22 CRA ausscheiden. Diese Linie wird im Kommentar von Schröder/Hartl zum CRA von zwei Bearbeitern vertreten. Poncza setzt beim Abgabebegriff an: Bei körperlicher Übergabe auf einem Datenträger sei der Übergang der Sachherrschaft ein taugliches Kriterium; bei unkörperlicher Software fehle es an der Besitzfähigkeit und damit an diesem Anknüpfungspunkt. Eine vereinzelt vertretene Gegenauffassung wolle bereits die Einräumung der Nutzungsmöglichkeit genügen lassen — bei On-Premises-Software durch Bereitstellung der Installationsdateien, bei Cloud-Anwendungen durch Übermittlung von Zugangsdaten oder Freischaltung des Nutzers (zitiert nach dem Kommentar: Wiebe/Daelen, EuZW 2023, 257). Dem hält Poncza entgegen, dass Softwareprodukte bei „off-premise“-Bereitstellung den Einflussbereich des Bereitstellers zu keinem Zeitpunkt verlassen; dieselbe Wertung liege Erwägungsgrund 12 CRA zugrunde, der solche Bereitstellungsformen ausdrücklich aus dem Anwendungsbereich ausnimmt. Massgeblich sei deshalb nicht die Nutzungsmöglichkeit, sondern die Frage, ob das Softwareprodukt in den ausschliesslichen Machtbereich etwa eines Endnutzers übergeht und damit ein „Sachherrschaftsäquivalent“ begründet wird [10, Poncza, Art. 3 Rn. 133–135]. Parallel dazu argumentiert Hofmann: Stammt die Software eines Cloud-Dienstes vom Anbieter selbst, wird sie nicht als Produkt am Markt bereitgestellt, sondern nur vom Hersteller für eigene Zwecke verwendet — genau diese produktbezogene Lücke schliesse die Einbeziehung der Datenfernverarbeitungslösungen in den Produktbegriff [10, Hofmann, Art. 3 Rn. 15].

Wir folgen in der Darstellung Lesart A, weil sie den Anwendungsbereich unabhängig von der Vertragsgestaltung bestimmt und deshalb nicht durch eine konstruierte Subskriptions-„Abgabe“ umgangen werden kann. Beide Begründungswege sind in der Kommentarliteratur vertreten und schliessen einander nicht aus: Das „Sachherrschaftsäquivalent“ beschreibt der Sache nach dasselbe Kriterium, das auch Lesart A zugrunde liegt — es fehlt an einem abgrenzbaren Produkt-Exemplar, das den Hersteller überhaupt verlassen könnte. Praktisch entscheidend: Beide Lesarten kommen zum selben Ergebnis — eine reine Browser-SaaS fällt nicht unter den CRA, sondern in die NIS-2-Sphäre.

Der Übergangsmoment, an dem das Produktrecht ansetzt, wird in Art. 3 Nr. 22 CRA definiert: „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]. Eine Desktop-App wird mit dem Download in Verkehr gebracht; ein Firmware-Image, sobald es zum Flashen bereitgestellt wird; eine Mobile App, sobald sie im App Store erscheint. Eine reine Browser-SaaS hat diesen Übergangsmoment nicht — der Nutzer erhält keine Software-Kopie, sondern nutzt eine laufende Dienstleistung beim Anbieter.

Anschaulich machen lässt sich dieser Übergangsmoment am Werkstorprinzip — einem Konzept der Bereitstellungs-Ebene, das 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“ [8, § 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 reine SaaS verlässt es nie: Ihr Code bleibt dauerhaft beim Anbieter, der Nutzer greift von aussen über eine Verbindung hinein. Denselben Gedanken formuliert der Kommentar von Schröder/Hartl als Frage nach einem „Sachherrschaftsäquivalent“ — dem Übergang in den ausschliesslichen Machtbereich des Nutzers [10, Poncza, Art. 3 Rn. 135]. Das Werkstorprinzip setzt damit streng genommen am Bereitstellungserfordernis an und gehört dogmatisch zu Lesart B. Der tiefere Grund, warum eine SaaS das Werkstor nie verlässt, ist allerdings, dass es kein abgrenzbares Produkt-Exemplar gibt, das es überhaupt verlassen könnte — insofern macht das Werkstorprinzip zugleich den Befund von Lesart A anschaulich.

Die EU adressiert solche Dienstleistungen in einem parallelen Regulierungsrahmen:

| Sphäre | Anknüpfung | Beispiele | |---|---|---| | Produktrecht | Inverkehrbringen eines Produkts | CRA, Maschinenverordnung, RED, MDR | | Dienstleistungsrecht | Erbringung der Dienstleistung | NIS-2, eIDAS, DORA |

Reine Cloud-Dienste (IaaS, PaaS, SaaS ohne lokale Komponente) gehören in die zweite Sphäre.

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, RDPS) — eine 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 (Art. 3 Nr. 1 CRA: „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen“). Sie wird damit in dieselben CRA-Pflichten einbezogen wie die lokale Komponente — Anhang I, SBOM, Schwachstellenmanagement, Konformitätsbewertung, Meldepflichten. Isoliert betrachtet wäre dieselbe Server-Software eine Cloud-Dienstleistung im NIS-2-Bereich.

Doppelqualifikation: Server-Software, die selbst am Markt bereitgestellt wird. Diese Zuordnung ist nicht exklusiv. Stellt der Hersteller seine Server-Software selbst am Markt bereit, damit ein Dritter sie betreibt, ist sie beides zugleich — eigenständiges Softwareprodukt und Datenfernverarbeitungslösung. Der Kommentar von Schröder/Hartl nennt dafür als Beispiel eine Groupware, bei der neben der Client- auch die Server-Software angeboten wird (Nextcloud); dort greifen allerdings zusätzlich die Besonderheiten für freie und quelloffene Software [10, Hofmann, Art. 3 Rn. 15]. Praktisch relevant ist das für alle Anbieter, die neben ihrem gehosteten Dienst eine selbst hostbare Variante desselben Produkts vertreiben — ein in der DACH-Softwarebranche häufiges Modell. Dieselbe Server-Software wird dann auf zwei Wegen erfasst: als eigenständiges Produkt mit digitalen Elementen, das der Hersteller in Verkehr bringt, und als Datenfernverarbeitungslösung des eigenen gehosteten Angebots. Wer die Selbst-Hosting-Variante nur als „Nebenprodukt“ des SaaS-Geschäfts betrachtet, unterschlägt damit einen eigenständigen Pflichtenkreis.

Wichtig dabei ist die juristische Konstruktion: Die Server-Komponente wird nicht zu einem eigenen Produkt, das gesondert in Verkehr gebracht werden müsste. Die Bereitstellung iSd Art. 3 Nr. 22 CRA erfolgt einmal — durch die Auslieferung der lokalen Komponente — und trägt regulatorisch beide Teile (lokal und Server) gemeinsam. Das begrenzt zugleich die Reichweite: Erfasst wird die Datenfernverarbeitungslösung nicht als komplexe Dienstleistung, sondern nur mit denjenigen Aspekten, die gälten, wenn sie als eigenständiges Produkt bereitgestellt worden wäre. Die Risiken des IT-Systems, auf dem der Hersteller sie betreibt, bleiben aussen vor — sie werden gegebenenfalls von der NIS-2-Richtlinie erfasst, sofern der Betreiber deren Schwellenwerte überschreitet [10, Hofmann, Art. 3 Rn. 19; 4].

Diese Systematik erklärt auch, warum sich Hersteller dem CRA nicht entziehen können, indem sie die sicherheitsrelevanten Funktionen in die Cloud auslagern: Sobald ein lokales Produkt existiert, das ohne die Cloud-Verarbeitung nicht funktioniert, zieht die RDPS-Konstruktion die Cloud automatisch mit hinein.

Die Falle: Wann SaaS doch CRA-pflichtig wird

Hier liegt das Missverständnis, das in der DACH-Softwarebranche immer noch weit verbreitet ist. Viele Unternehmen kategorisieren ihr Produkt pauschal als „SaaS“ und schlussfolgern: Cloud-basiert, also kein lokales Produkt, also kein CRA.

Diese Schlussfolgerung ist in vielen Fällen falsch.

Der Grund: Viele moderne SaaS-Produkte sind nicht mehr „rein“ browserbasiert. Denken Sie an eine Projektmanagement-Software, die auch eine Desktop-App und eine Mobile App anbietet. Oder an ein Monitoring-Tool, das einen Agenten auf dem Server des Kunden installiert. Oder an eine Collaboration-Plattform mit einem Browser-Plugin für die E-Mail-Integration.

In jedem dieser Fälle existiert eine lokale Softwarekomponente — eine App, ein Agent, ein Plugin — die typischerweise über Datenverbindungen mit dem Cloud-Backend interagiert. Solche Datenverbindungen werden technisch über Netzwerksockets, Pipes, APIs oder Datenbankzugriffe realisiert (vgl. Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3) [8]. Reine Einweg-Schnittstellen wie RFID-Tags oder QR-Codes lösen die CRA-Anwendbarkeit als Datenverbindung dagegen nicht aus (vgl. Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3) [8]. Sobald die lokale Komponente ihre Funktion ohne die Server-Verarbeitung des Herstellers nicht erfüllen kann, liegt eine Datenfernverarbeitungslösung im Sinne des CRA vor. Das gesamte Produkt — lokale Komponente plus Cloud-Backend — wird dann nach dem CRA bewertet.

Dahinter steht eine Prüfung in zwei Stufen, die man auseinanderhalten sollte. Die lokale Komponente ist der Anker: Sie allein entscheidet, ob überhaupt ein „Produkt mit digitalen Elementen“ vorliegt und damit der CRA dem Grunde nach greift. Ohne lokale Komponente kein Produkt, kein CRA. Die Server-Abhängigkeit entscheidet dagegen über die Reichweite — also darüber, wie weit der CRA in die Cloud hineinreicht. Funktioniert die lokale Komponente auch ohne den Server, bleibt der Server ausserhalb der RDPS-Qualifikation; funktioniert sie ohne ihn nicht, wird die Server-Seite als RDPS in den Pflichtenkreis des Produkts gezogen. Kurz: Die lokale Komponente beantwortet die Frage „ob überhaupt CRA“, die Server-Abhängigkeit die Frage „wie weit der CRA in die Cloud reicht“.

Der Kommentar von Schröder/Hartl illustriert genau diese Aufteilung an einem Speicherdienst, der Daten mit dem lokalen Gerät synchronisiert — etwa Dropbox: Softwareprodukt ist die lokal installierte Anwendung, ausdrücklich nicht die Web-Oberfläche; deren Gegenstück auf dem Server des Anbieters ist die Datenfernverarbeitungslösung. Datenfernverarbeitungslösungen sind damit auch nicht auf die Unterstützung von Hardware beschränkt [10, Hofmann, Art. 3 Rn. 21].

Entscheidend für diese Bewertung ist der neue Drei-Elemente-Test der EU-Kommission [5], den wir im nächsten Artikel dieser Serie im Detail vorstellen. Zunächst sei nur erwähnt: Die Bewertung ist nicht binär — das Ergebnis kann entweder eine CRA-pflichtige RDPS sein, oder eine Drittanbieter-Komponente mit abgestuften Compliance-Anforderungen, oder eine blosse Risikobewertung. Welches dieser drei Ergebnisse für Ihr Produkt relevant ist, hängt von Architektur und Design ab.

Die internationale Wirtschaftskanzlei DLA Piper bezeichnete diese Abgrenzung in einer Mandanteninformation vom Februar 2026 als „fine line“ [2]. Die Grenze zwischen CRA-pflichtiger RDPS und reiner Cloud-Software, die unter die NIS-2-Richtlinie fällt, verläuft oft mitten durch das Produktportfolio eines einzelnen Unternehmens. Auch Linklaters kommt in einem Briefing vom März 2026 zu einem ähnlichen Befund [3].

Reine SaaS: Was wirklich aussen vor bleibt

Tatsächlich nicht CRA-pflichtig sind Lösungen, die ausschliesslich über den Browser genutzt werden, keine lokale Installation erfordern und bei denen der Hersteller keine Software auf dem Gerät des Nutzers ausführt. Ein klassisches Beispiel: Eine reine Webmail-Oberfläche, die vollständig serverseitig läuft. Der Nutzer öffnet einen Browser, interagiert mit der Anwendung, aber auf seinem Gerät wird keine herstellereigene Software installiert oder ausgeführt.

Solche reinen SaaS-Lösungen fallen nicht unter den CRA, sondern unter das NIS-2-Regime (Richtlinie (EU) 2022/2555) [4], sofern der Anbieter als wesentliche oder wichtige Einrichtung eingestuft wird. Erwägungsgrund (12) des CRA stellt klar, dass reine Cloud-Dienste ohne verbundenes lokales Produkt nicht in den Anwendungsbereich fallen [1, ErwGr (12)].

Die Abgrenzung klingt einfacher, als sie in der Praxis ist. Was ist mit einem SaaS-Produkt, das Progressive Web App (PWA)-Funktionalität bietet? Was, wenn der Browser-Tab offline-fähig ist und lokale Daten zwischenspeichert? Was, wenn ein optionaler Desktop-Wrapper existiert, den nur 5 Prozent der Kunden nutzen? Diese Fragen sind Stand 20. Mai 2026 nicht abschliessend geklärt — aber die EU-Kommission hat mit einem neuen Orientierungsrahmen einen wichtigen Massstab geschaffen [5], den wir im nächsten Artikel dieser Serie im Detail vorstellen.

Was das für die DACH-Softwarebranche bedeutet

Für Softwarehersteller in Deutschland, Österreich und der Schweiz hat die CRA-Abgrenzung weitreichende Konsequenzen. Die entscheidende Frage lautet nicht „Sind wir ein SaaS-Unternehmen?“, sondern: „Hat unser Produkt eine lokale Komponente, die ohne Server-Verarbeitung nicht funktioniert?“

Viele Unternehmen, die sich als reine Cloud-Anbieter verstehen, bieten parallel Desktop-Apps, Mobile Apps, Browser-Extensions, CLI-Tools oder Agents an. Jede dieser lokalen Komponenten kann dazu führen, dass das Cloud-Backend als Datenfernverarbeitungslösung unter den CRA fällt. DLA Piper beschreibt diese Abgrenzung als „fine line“ [2]. Sie verläuft oft mitten durch das Produktportfolio eines einzelnen Unternehmens.

Tatsächlich rein browserbasierte Lösungen — ohne jede lokale Installation — dürften in der DACH-Softwarebranche die Minderheit darstellen. Belastbare empirische Studien zum genauen Anteil existieren bisher nicht. Aber die Produktrealität spricht eine deutliche Sprache: Wer eine Desktop-App im Download-Bereich anbietet, wer ein Software Development Kit (SDK) für Kundenintegrationen bereitstellt, wer Agents für Monitoring oder Deployment verteilt, ist mit hoher Wahrscheinlichkeit CRA-pflichtig — auch wenn das Kernprodukt „in der Cloud läuft“.

Was jetzt zu tun ist

Für Softwareunternehmen in der DACH-Region gibt es drei unmittelbare Handlungsschritte.

Der erste: Klären Sie, ob Ihr Produkt unter den CRA fällt. Nicht auf Basis einer pauschalen Einschätzung, sondern anhand der konkreten Produktarchitektur. Hat Ihre Lösung eine lokale Komponente — eine App, einen Agenten, ein Plugin, ein SDK? Dann ist die Wahrscheinlichkeit hoch, dass Sie CRA-pflichtig sind. Das Bundesamt für Sicherheit in der Informationstechnik – die deutsche Cybersicherheitsbehörde mit Sitz in Bonn (BSI) – bietet mit der Technischen Richtlinie TR-03183 eine Einstiegshilfe, die den CRA-Anwendungsbereich und die Anforderungen systematisch aufbereitet [6].

Der zweite: Verstehen Sie den Zeitplan. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten bereits ab dem 11. September 2026 — also in knapp vier Monaten (Stand 20. Mai 2026) [1, Art. 14 i. V. m. Art. 71 Abs. 2 UAbs. 2]. Spätestens dann brauchen Sie einen funktionierenden Prozess für Vulnerability Disclosure und Incident Reporting — die ENISA wird dafür eine zentrale Meldeplattform betreiben [1, Art. 16].

Der dritte: Beginnen Sie jetzt mit der Gap-Analyse. Die vollständigen Produktanforderungen — SBOM, Security by Design, Konformitätsbewertung — gelten ab dem 11. Dezember 2027, also etwa in 19 Monaten (Stand 20. Mai 2026). Das klingt weit weg, aber die Erfahrung mit vergleichbaren Regulierungen wie der DSGVO zeigt: Unternehmen, die erst ein Jahr vor der Deadline starten, geraten unter erheblichen Druck. Bitkom stellt in seinem aktuellen Positionspapier zum CRA fest, dass der Konformitätsbewertungsprozess so komplex sei, dass er „für die grosse Mehrheit der KMU, aber auch für grössere Unternehmen, nicht zugleich rechtskonform und wirtschaftlich umsetzbar“ sei [7].

Methodik und Quellenlage

Dieser Artikel stützt sich primär auf die Verordnung (EU) 2024/2847 [1] sowie die Guidance der EU-Kommission C(2026) 5252 final, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ [5]. Am 27. Juli 2026 hat die Kommission den Inhalt des im Annex veröffentlichten Guidance-Entwurfs gebilligt. Der Annex ersetzt für die Auswertung den vorherigen Entwurf Ares(2026)2319816 vom 3. März 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. August 2026). Für die Auslegungsfragen zum Produktbegriff, zur Datenfernverarbeitungslösung und zum Abgabebegriff werten wir zwei juristische Kommentare aus: den CRA-Kommentar von Wiebe (Nomos 2025) [8] sowie den artikelweisen Kommentar von Schröder/Hartl (Nomos, 1. Auflage 2026) [10], dessen Kommentierungen zu Art. 3 Nr. 1 und Nr. 2 von Hofmann und zu Art. 3 Nr. 22 von Poncza stammen. Als ergänzende Quellen dienen Fachpublikationen von DLA Piper [2] und Linklaters [3], die Technische Richtlinie BSI TR-03183 [6] sowie das Bitkom-Positionspapier [7].

Änderungshinweis zu dieser Fassung (v19, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 16.03.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Änderungshinweis zur Fassung v18 (12.08.2026): Der Verfahrensstatus der im Annex zu C(2026) 5252 final veröffentlichten Guidance wurde präzisiert: Der Inhalt ist von der Kommission gebilligt, die förmliche Annahme steht bis zum Vorliegen aller Sprachfassungen noch aus. Erst danach soll die Guidance als offizielle, weiterhin unverbindliche Auslegungshilfe der Kommission verwendet werden. Die Bezeichnung des Drei-Elemente-Tests als „offizielles Instrument“ wurde entsprechend korrigiert. Die historischen Versionshinweise bleiben unverändert.

Änderungshinweis zu dieser Fassung (v17, 06.08.2026): Ergänzt wurde die Doppelqualifikation herstellereigener Server-Software: Wird sie selbst am Markt bereitgestellt, damit ein Dritter sie betreibt, ist sie zugleich eigenständiges Softwareprodukt und Datenfernverarbeitungslösung; hinzu kommt der Hinweis auf die Besonderheiten für freie und quelloffene Software sowie die praktische Bedeutung für Anbieter mit selbst hostbarer Produktvariante (NK-CRA/Hofmann, 1. Aufl. 2026, CRA Art. 3 Rn. 15).

Änderungshinweis zur Fassung v16 (06.08.2026): Korrigiert wurde die Aussage der Vorfassung, der bereitstellungsbezogene Begründungsweg (dort „Lesart B“) werde in der Kommentarliteratur nicht als eigenständige Position vertreten. Das trifft nicht zu: Im Kommentar von Schröder/Hartl (Nomos, 1. Aufl. 2026) [10] wird diese Linie von zwei Bearbeitern vertreten — von Poncza über das „Sachherrschaftsäquivalent“ beim Abgabebegriff (Art. 3 Rn. 133–135) und von Hofmann für herstellereigene Cloud-Software (Art. 3 Rn. 15). Die beiden Lesarten werden nun als gleichrangige Begründungswege dargestellt; die Sachaussage — eine reine Browser-SaaS fällt nicht unter den CRA — bleibt unverändert. Ergänzt wurden ausserdem Belege zum Streit um das kumulative Erfordernis (Art. 3 Rn. 7 f.), zur Abgrenzung von blosser Konnektivität (Rn. 13, 15), zu den Anforderungen an die ausgelagerte Funktion (Rn. 18), zur Reichweite der RDPS-Einbeziehung (Rn. 19) sowie das Beispiel eines synchronisierenden Speicherdienstes (Rn. 21).

Änderungshinweis zur Fassung v15 (05.08.2026): Die bislang zitierte Draft Communication Ares(2026)2319816 vom 3. März 2026 wurde durch die von der Kommission am 27. Juli 2026 gebilligte finale Guidance C(2026) 5252 final, Annex, ersetzt. Angepasst wurden die Zitatstellen zum Drei-Elemente-Test (neu: Rn. 184 statt Rn. 168) sowie zur NIS-2-Einordnung von Cloud-Diensten (neu: Rn. 183 statt Rn. 167, ergänzt um den Verweis auf die Durchführungsverordnung (EU) 2024/2690). Die inhaltlichen Aussagen und Schlussfolgerungen des Artikels blieben unverändert; die von der Kommission gewählte Prüfungsreihenfolge (Distanz → Funktion → Hersteller) wird durch die finale Fassung bestätigt.

Sie möchten wissen, ob Ihr Produkt unter den CRA fällt? Mit dem kostenlosen CRA-Quick-Check auf craiready.com erhalten Sie in wenigen Minuten eine erste Einschätzung — einschliesslich der relevanten Produktkategorie und der für Sie geltenden Fristen.

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: 16.03.2026. Zuletzt geprüft am: 13.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Der Drei-Elemente-Test der EU-Kommission — die von der Kommission veröffentlichte Prüfstruktur, mit der Sie systematisch prüfen können, ob Ihre Software eine Datenfernverarbeitungslösung im Sinne des CRA darstellt.

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 (Cyber Resilience Act). ABl. L, 20.11.2024. Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[2] DLA Piper, „Cyber Resilience Act: the fine line between SaaS and digital products“, Mandanteninformation Februar 2026. Verfügbar unter: https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-the-fine-line-between-saas-and-digital-products. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; Primärquelle ist [1] und [5].

[3] Linklaters, „EU Cyber Resilience Act: Commission issues first draft guidance – 10 key points you need to know“, Client Briefing März 2026. Verfügbar unter: https://techinsights.linklaters.com/post/102mmlo/eu-cyber-resilience-act-commission-issues-first-draft-guidance-10-key-points-y. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; Primärquelle ist [1] und [5].

[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, 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 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). Kapitel 8 „Remote data processing“, Rn. 178–208. 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).

[6] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products. Teil 1: General Requirements, Teil 2: Software Bill of Materials (SBOM), Teil 3: Vulnerability Reports and Notifications. Verfügbar unter: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/tr-03183.html.

[7] Bitkom e.V., „Cyber Resilience Act: An updated position paper on the transposition at the European Level“, Positionspapier 2026. Bitkom stellt fest, der Konformitätsbewertungsprozess sei für die Mehrheit der KMU „not both legally compliant and economically feasible due to the effort involved“. Verfügbar unter: https://www.bitkom.org/sites/main/files/2026-02/bitkom-position-paper-cyber-resilience-act-transposition-at-european-level.pdf.

[8] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Juristischer Kommentar zu Auslegungsfragen des CRA, insbesondere zum Produktbegriff und zur Datenfernverarbeitungslösung (§ 4 Rn. 3–5).

[9] 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. Verfügbar unter: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:52022XC0629%2804%29

[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. 1 und Nr. 2 kommentiert von Hofmann, Art. 3 Nr. 22 von Poncza.

Stand: 13.08.2026 (v20 — freigegebene Schlusskorrektur: fehlendes Prädikat ergänzt; Kasus-, Genus-, Komma- und Flexionsfehler korrigiert; Anglizismen verständlicher gefasst. Vorherige Fassung: v19; zeitabhängige Formulierungen unverändert.)