Von Redaktion codAIx | 16. März 2026

Ab dem 11. Dezember 2027 gelten die Cybersicherheitsanforderungen des EU Cyber Resilience Act (CRA) für „Produkte mit digitalen Elementen“, die auf dem europäischen Markt in Verkehr gebracht werden. 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 bis zum Ende des Unterstützungszeitraums. Dazu gehören Schwachstellenmanagement, Software-Stückliste (englisch 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 seit dem 11. Juni 2026 [1, Art. 71 Abs. 2 UAbs. 2]. Die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten seit dem 11. September 2026 — auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden [1, Art. 14, Art. 69 Abs. 3 und Art. 71 Abs. 2 UAbs. 2]. Die vollständigen Produktanforderungen gelten ab dem 11. Dezember 2027 [1, Art. 71 Abs. 2 UAbs. 1]. Wer dann nicht konform ist, riskiert bei Verstössen gegen Anhang I oder Art. 13 und 14 Geldbussen 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 separat vertriebenes Firmware-Image: All das kann unter den CRA fallen, 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 [9, 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 — auch On-Premises beim Hersteller — und Hyperscaler-Dienste gleichermassen in Betracht [4, Rn. 187]. Software, die der Kunde in seiner eigenen Betriebsumgebung installiert, ist dagegen regelmässig selbst ein bereitgestelltes Produkt und keine Datenfernverarbeitung [4, Rn. 20, 186].

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)]. Solche Standard-Drittdienste sind mangels Herstellerverantwortung keine RDPS. Ihre Auswirkungen auf die Produktsicherheit bleiben nach Art. 13 Abs. 2 zu bewerten. Für funktional notwendige Drittanbieter-Ferndienste erwartet die Guidance der EU-Kommission — sie ist rechtlich nicht bindend, gibt aber die Auslegung der Kommission wieder — zusätzlich eine Art. 13 Abs. 5 entsprechende, risikoproportionale Sorgfalt [4, Rn. 201, 202 lit. c, 207 f.].

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 [9, Hofmann, Art. 3 Rn. 18]. Für die Praxis folgt daraus: Cloud-Komponenten, deren Fehlen keine Funktion des Produkts beeinträchtigt — etwa die rein statistische Auswertung von Telemetriedaten oder ein reines Informationsportal — qualifizieren nach der Guidance nicht als RDPS; ihre Risiken sind aber gegebenenfalls in der Cybersicherheits-Risikobewertung zu berücksichtigen [4, Rn. 192–193; 1, Art. 13 Abs. 2]. Trägt die Cloud-Verarbeitung dagegen auch nur eine — nicht notwendig zentrale — Funktion des Produkts, ist sie Teil des Produkts [4, Rn. 189].

Hinweis zur Reihenfolge: Die EU-Kommission greift dieselben drei Tatbestandsmerkmale in ihrer Guidance C(2026) 5252 final, Annex, Rn. 184 auf, ordnet sie aber um: Sie prüft die Funktion vor der Herstellerverantwortung [4, Rn. 184; Abschnitte 8.1.1–8.1.3]. Eine Begründung gibt die Guidance nicht; didaktisch hat die Reihenfolge den Vorteil, dass die inhaltliche Hürde vor der Verantwortungszurechnung steht. Wir folgen im nächsten Teil dieser Serie dieser Reihenfolge. Die rechtsdogmatische Substanz bleibt identisch — nur die Prüfungsabfolge unterscheidet sich.

In der deutschsprachigen Kommentarliteratur ist umstritten, ob eine Datenfernverarbeitungslösung ein zwingendes Tatbestandsmerkmal des Produktbegriffs ist. Wiebe/Jossen verneinen dies (Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3 mit Fn. 1, Rn. 5 Fn. 12) [7]; die Gegenauffassung (Schöttle, MMR 2024, 741, 742) fasst sie als kumulatives Erfordernis auf. Der Schröder/Hartl-Kommentar 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 [9, Hofmann, Art. 3 Rn. 7 f.]. Hersteller von Software ohne eigenes Cloud-Backend sollten sich deshalb nicht auf die Gegenauffassung verlassen: Auch die Guidance zählt eigenständige Software wie Apps und Computerprogramme zu den erfassten Produkten, ohne eine Datenfernverarbeitungslösung vorauszusetzen [4, Rn. 18].

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“ im Sinne von Art. 3 Nr. 1 CRA. „Produkt“ ist im EU-Produktrecht eine abgrenzbare, in eine einzelne Marktbereitstellung überführbare Einheit; in diese Richtung weist auch der „Blue Guide on the implementation of EU product rules“ 2022 der EU-Kommission, der Inverkehrbringen und Bereitstellung auf das einzelne Produkt bezieht (Abschnitte 2.2 und 2.3) [8]. Eine SaaS ist ihrem Wesen nach das Gegenteil: kein abgegrenztes Software-Artefakt, sondern ein kontinuierlich erbrachter Dienst. Im CRA-Kommentar von Wiebe ordnen Wiebe/Jossen eigenständige Cloud-Dienstmodelle wie SaaS, PaaS und IaaS nicht als CRA-relevante Software ein, wenn sie die Produktfunktionalität nicht unterstützen oder für sie nicht erforderlich sind [7, Wiebe/Jossen, § 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 die Zuordnung von Cloud-Diensten zur NIS-2-Richtlinie [1, ErwGr (12); 3]. Für die Produkteigenschaft sind jedoch Rn. 19–21 der Kommissions-Guidance einschlägig: Eine ausschliesslich über den Browser genutzte Webanwendung ist danach für sich genommen kein Produkt mit digitalen Elementen [4, Rn. 19–21, Beispiel 5]. Die FAQ der Kommissionsdienststellen bestätigen diese Orientierung [10, Nr. 1.2]. Nach unserer Einordnung stützt die Guidance damit im Ergebnis Lesart A.

Lesart B (bereitstellungsbezogener Begründungsweg) — Scheitern am Bereitstellungserfordernis. Der zweite Weg ordnet SaaS-Code durchaus als „Softwareprodukt“ im Sinne von Art. 3 Nr. 1 CRA ein und lässt ihn erst an der fehlenden „Abgabe“ im Sinne von 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; derselben Wertung liege nach seiner Auffassung auch Erwägungsgrund 12 CRA zugrunde. 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 [9, 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 [9, 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 nach der Guidance für sich genommen nicht unter den CRA. NIS-2 kann einschlägig sein, wenn Dienst, Einrichtung und Grössen- oder Sonderkriterien der Richtlinie beziehungsweise des nationalen Umsetzungsrechts erfüllt sind.

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]. Nach Auffassung der Kommission ist eigenständige Software in Verkehr gebracht, sobald sie erstmals zum Vertrieb oder zur Verwendung angeboten wird — eine Desktop-App etwa mit dem ersten Angebot zum Download, eine mobile App mit dem ersten Angebot im App Store [4, Rn. 13–16]. Für ein separat vertriebenes Firmware-Image dürfte dasselbe gelten, soweit es als eigenständige Software angeboten wird (Rn. 16). Zur abweichenden Kommentarauffassung siehe Artikel 00. 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 von Wiebe zur Bestimmung des Inverkehrbringens heranzieht: Vereinfacht gesagt ist ein Produkt in Verkehr gebracht, wenn es mit dem Willen des Herstellers dessen digitales Werkstor verlässt [7, Wiebe, § 4 Rn. 18]. Eine heruntergeladene Desktop-App verlässt dieses Werkstor — die Kopie wandert auf das Gerät des Nutzers, der Hersteller verliert die unmittelbare Kontrolle über sie. Eine reine SaaS verlässt es nie: Ihr Code bleibt dauerhaft beim Anbieter, der Nutzer greift von aussen über eine Verbindung hinein. Die Übertragung auf SaaS ist unsere Einordnung; der Kommentar selbst lässt bei unverkörperter Software auch die Übermittlung von Zugangsdaten oder die Freischaltung des Nutzers als Abgabe genügen. Denselben Gedanken formuliert der Kommentar von Schröder/Hartl als Frage nach einem „Sachherrschaftsäquivalent“ — dem Übergang in den ausschliesslichen Machtbereich des Nutzers [9, 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 und SaaS ohne ein bereitgestelltes Software- oder Hardwareprodukt) sind nach der Kommissions-Guidance für sich genommen keine Produkte mit digitalen Elementen.

Damit das Schutzkonzept des CRA nicht an der Cloud-Grenze endet, enthält Art. 3 Nr. 2 CRA die Begriffsbestimmung der Datenfernverarbeitung, auf der die Datenfernverarbeitungslösung aus Art. 3 Nr. 1 aufbaut — eine regulatorische Brücke zwischen Produktrecht und Dienstleistungsrecht. Wenn ein in Verkehr gebrachtes Software- oder Hardwareprodukt ohne eine bestimmte Server-Software auch nur eine seiner Funktionen nicht mehr ausführen kann und wenn der Hersteller diese Server-Software selbst oder unter seiner Verantwortung konzipiert und entwickelt hat, gilt die Server-Software als 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 das bereitgestellte Produkt — Anhang I, SBOM, Schwachstellenmanagement, Konformitätsbewertung, Meldepflichten. Isoliert betrachtet wäre dieselbe Server-Software kein Produkt mit digitalen Elementen.

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 [9, 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 bei Softwareherstellern in Deutschland und der Schweiz 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: Soweit der Hersteller die Server-Software nicht zusätzlich selbst am Markt bereitstellt, wird sie nicht zu einem eigenen Produkt, das gesondert in Verkehr gebracht werden müsste. Die Bereitstellung im Sinne von Art. 3 Nr. 22 CRA erfolgt einmal — durch die Auslieferung des bereitgestellten Produkts — und trägt regulatorisch das Produkt und seine Datenfernverarbeitungslösung gemeinsam. Das begrenzt zugleich die Reichweite: Erfasst wird die Datenfernverarbeitungslösung nicht als komplexe Dienstleistung, sondern nur mit denjenigen Aspekten, die für ein eigenständig bereitgestelltes Produkt gelten. Die Risiken des IT-Systems, auf dem der Hersteller sie betreibt, bleiben aussen vor; die Anforderungen an Datenfernverarbeitungslösungen umfassen ausdrücklich keine Massnahmen zur Sicherheit der Netz- und Informationssysteme des Herstellers insgesamt [1, ErwGr (11); 4, Rn. 181–182; ebenso 9, Hofmann, Art. 3 Rn. 19]. In der produktbezogenen Risikobewertung sind solche Abhängigkeiten gleichwohl zu berücksichtigen und durch Massnahmen am Produkt selbst zu mindern [4, Rn. 206]. Die Risiken des IT-Systems können zudem von NIS-2 erfasst sein, sofern deren Anwendungsvoraussetzungen erfüllt sind [3].

Diese Systematik erklärt auch, warum sich Hersteller dem CRA nicht allein dadurch entziehen können, dass sie Produktfunktionen in die Cloud auslagern: Sobald Funktionsabhängigkeit und Herstellerverantwortung vorliegen, bezieht die RDPS-Konstruktion die ausgelagerte Verarbeitung in das Produkt ein.

Die Falle: Wann SaaS doch CRA-pflichtig wird

Hier liegt das Missverständnis, das bei Softwareherstellern in Deutschland und der Schweiz 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 kann ein bereitgestelltes Softwareprodukt vorliegen — eine App, ein Agent oder ein Plugin —, das über Datenverbindungen mit dem Cloud-Backend interagiert. Erwägungsgrund 9 nennt als logische Verbindungen insbesondere Netzwerksockets, Pipes, Dateien und Programmierschnittstellen; die Kommentarliteratur zählt dazu auch Datenbankzugriffe [1, ErwGr (9); 7, Wiebe/Jossen, § 4 Rn. 3]. Reine Einweg-Schnittstellen wie RFID-Tags oder QR-Codes dürften als Datenverbindung dagegen nicht genügen [7, Wiebe/Jossen, § 4 Rn. 3 Fn. 6, unter Verweis auf Schöttle]. Liegen Funktionsabhängigkeit und Herstellerverantwortung vor, ist das Backend Datenfernverarbeitungslösung im Sinne des CRA. Das Gesamtprodukt einschliesslich dieser Datenfernverarbeitungslösung wird dann nach dem CRA bewertet.

Dahinter steht eine Prüfung in zwei Stufen, die man auseinanderhalten sollte. Das auf dem Unionsmarkt bereitgestellte Software- oder Hardwareprodukt ist der Anker; häufig, aber nicht zwingend, ist dies ein lokaler Client. Für die Reichweite in die Cloud sind anschliessend sowohl die Funktionsabhängigkeit als auch die Herstellerverantwortung für die entfernte Software zu prüfen. Kann das Produkt sämtliche Funktionen auch ohne den Server ausführen oder wurde die entfernte Software nicht vom Produkthersteller oder unter seiner Verantwortung konzipiert und entwickelt, liegt insoweit keine RDPS vor. Im zweiten Fall bleiben jedoch die Risikobewertung des eigenen Produkts und die von der Guidance erwartete risikoproportionale Sorgfalt für den Drittanbieter-Ferndienst relevant. Kurz: Das bereitgestellte Produkt beantwortet die Frage „ob überhaupt CRA“; Funktionsabhängigkeit und Herstellerverantwortung bestimmen gemeinsam, ob die entfernte Verarbeitung als RDPS einbezogen wird.

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 [9, Hofmann, Art. 3 Rn. 21].

Entscheidend für diese Bewertung ist der Drei-Elemente-Test der EU-Kommission [4], 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 eine CRA-pflichtige RDPS sein, ein Drittanbieter-Ferndienst, für den die Guidance eine Behandlung wie eine Komponente erwartet, oder eine Verbindung, die nur in der Risikobewertung zu berücksichtigen ist. 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 verläuft oft mitten durch das Produktportfolio eines einzelnen Unternehmens.

Reine SaaS: Was wirklich aussen vor bleibt

Nach der Kommissions-Guidance sind Lösungen für sich genommen nicht CRA-pflichtig, wenn sie ausschliesslich über den Browser genutzt werden und kein Software- oder Hardwareprodukt auf dem Unionsmarkt bereitgestellt wird. Ein klassisches Beispiel ist eine reine Webmail-Oberfläche, die vollständig serverseitig läuft. Der Nutzer öffnet einen Browser und interagiert mit der Anwendung; der im Browser ausgeführte Webcode macht die Anwendung nach Auffassung der Kommission nicht zum Produkt [4, Rn. 19–21].

Solche reinen SaaS-Lösungen fallen nach dieser Auslegung für sich genommen nicht unter den CRA. NIS-2 kann daneben einschlägig sein, wenn der Anbieter deren sachliche und persönliche Anwendungsvoraussetzungen erfüllt [3]. Die Abgrenzung stützt sich auf Erwägungsgrund 12 in Verbindung mit Art. 3 Nr. 1 und 2 CRA; die Kommission ordnet eine ausschliesslich über den Browser genutzte Webanwendung in ihrer Guidance nicht als Produkt mit digitalen Elementen ein [4, Rn. 19–21, Beispiel 5; ebenso 10, Nr. 1.2].

Die Abgrenzung klingt einfacher, als sie ist: Was gilt für eine Progressive Web App, für einen offline-fähigen Browser-Tab oder für einen optionalen Desktop-Wrapper, den nur ein kleiner Teil der Kunden nutzt? Einige dieser Fragen beantwortet die Guidance: Progressive Web Apps, die ausschliesslich über den Browser genutzt werden, sind für sich genommen kein Produkt; ein Desktop-Wrapper, der zur lokalen Installation geliefert wird, ist dagegen ein Produkt mit digitalen Elementen [4, Rn. 20–21, Beispiele 4 und 5]. Wie viele Kunden ihn nutzen, spielt nach unserer Auffassung keine Rolle, weil Art. 3 Nr. 1 CRA auf das bereitgestellte Produkt abstellt. Offen bleiben echte Hybridfälle, etwa offline-fähige Browser-Anwendungen mit lokaler Zwischenspeicherung; sie sind nach ihrer konkreten Funktionsweise zu prüfen.

Was das für Softwarehersteller in Deutschland und der Schweiz bedeutet

Für Softwarehersteller in Deutschland und der Schweiz hat die CRA-Abgrenzung weitreichende Konsequenzen. Die entscheidende Frage lautet nicht „Sind wir ein SaaS-Unternehmen?“, sondern zunächst: „Stellen wir ein Software- oder Hardwareprodukt auf dem Unionsmarkt bereit?“ Ist das zu bejahen, folgen zwei weitere Fragen: „Benötigt dieses Produkt eine entfernte Verarbeitung für eine seiner Funktionen, und wurde die dort eingesetzte Software von uns oder unter unserer Verantwortung konzipiert und entwickelt?“

Viele Unternehmen, die sich als reine Cloud-Anbieter verstehen, bieten parallel Desktop-Apps, mobile Apps, Browser-Extensions, CLI-Tools oder Agents an. Jede dieser bereitgestellten Komponenten kann den produktbezogenen Anknüpfungspunkt des CRA eröffnen. Ob das Cloud-Backend zusätzlich als Datenfernverarbeitungslösung einbezogen wird, hängt von Funktionsnotwendigkeit und Herstellerverantwortung ab. Diese Abgrenzung ist im Einzelfall schwierig. Sie kann mitten durch das Produktportfolio eines einzelnen Unternehmens verlaufen.

Ob rein browserbasierte Lösungen bei Softwareherstellern in Deutschland und der Schweiz die Mehrheit oder Minderheit darstellen, ist mangels belastbarer empirischer Studien offen. Für die rechtliche Einordnung genügt deshalb kein Branchenetikett: Wer eine Desktop-App zum Download anbietet, ein Software Development Kit (SDK) für Kundenintegrationen bereitstellt oder Agents für Monitoring oder Deployment verteilt, muss diese Artefakte und ihre Marktbereitstellung jeweils gesondert prüfen. Dass das Kernangebot „in der Cloud läuft“, schliesst die CRA-Anwendbarkeit nicht aus.

Was jetzt zu tun ist

Für Softwareunternehmen in Deutschland und der Schweiz 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 (BSI), die deutsche Cybersicherheitsbehörde mit Sitz in Bonn, bietet mit der Technischen Richtlinie TR-03183 eine nicht bindende Einstiegshilfe, die den CRA-Anwendungsbereich und technische Anforderungen systematisch aufbereitet [5].

Der zweite: Verstehen Sie den Zeitplan. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten bereits seit dem 11. September 2026 [1, Art. 14 i. V. m. Art. 71 Abs. 2 UAbs. 2]. Unternehmen brauchen deshalb einen funktionierenden Prozess für die koordinierte Offenlegung von Schwachstellen und die Meldung von Sicherheitsvorfällen. Gemeldet wird über die seit diesem Tag betriebene einheitliche Meldeplattform (Single Reporting Platform) der ENISA. Zuständig ist das als Koordinator benannte CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung in der Union hat — in Deutschland CERT-Bund im BSI. Für Hersteller ohne Hauptniederlassung in der Union, etwa aus der Schweiz, bestimmt Art. 14 Abs. 7 CRA eine Reihenfolge: Mitgliedstaat des Bevollmächtigten, hilfsweise des Einführers, des Händlers oder der meisten Nutzer [1, Art. 14 Abs. 7, Art. 16]. Details erläutert der Artikel zu den CRA-Meldepflichten.

Der dritte: Beginnen Sie jetzt mit der Lückenanalyse. Die vollständigen Produktanforderungen — SBOM, Security by Design, Konformitätsbewertung — gelten ab dem 11. Dezember 2027. Die Erfahrung mit vergleichbaren Regulierungen wie der DSGVO zeigt: Unternehmen, die spät beginnen, geraten unter erheblichen Druck. Bitkom hält in seinem Positionspapier den Konformitätsbewertungsprozess „für die überwiegende Mehrheit der KMU, aber auch für grössere Unternehmen“ wegen des Aufwands nicht für zugleich rechtskonform und wirtschaftlich umsetzbar. Der Verband fordert zugleich, die Mehrheit der Dokumentationspflichten zu streichen. Das ist eine Verbandsposition, kein geprüfter Befund [6, S. 13 f., eigene Übersetzung].

Das Wichtigste für Hersteller

  • Eine reine Browser-SaaS ist nach der Guidance für sich genommen kein Produkt mit digitalen Elementen; für ihren Anbieter kann daneben NIS-2 gelten.
  • Den Zugang zum CRA öffnet jedes bereitgestellte Software- oder Hardwareprodukt — etwa eine Desktop-App, eine mobile App, ein Agent, ein Plugin oder ein SDK.
  • Das Cloud-Backend wird als Datenfernverarbeitungslösung Teil des Produkts, wenn das Produkt ohne die entfernte Verarbeitung eine seiner Funktionen nicht ausführen kann und die Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde.
  • Standard-Drittdienste sind keine Datenfernverarbeitungslösung, bleiben aber in der Risikobewertung nach Art. 13 Abs. 2 relevant.
  • Wer eine selbst hostbare Variante seiner Server-Software vertreibt, bringt damit zusätzlich ein eigenständiges Produkt in Verkehr.

Sie möchten wissen, ob Ihr Produkt unter den CRA fällt? Der CRA-Quick-Check liefert in wenigen Minuten eine kostenlose und unverbindliche Ersteinschätzung zur Anwendbarkeit, Produktklasse, CRA-Bereitschaft und möglichen Abdeckung durch crAIready.

Hinweis zur Methodik

Dieser Artikel stützt sich primär auf die Verordnung (EU) 2024/2847 [1] sowie die am 27. Juli 2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der EU-Kommission [4]. Sie ersetzt für diese Auswertung den vorherigen Entwurf Ares(2026)2319816 vom 3. März 2026, ist nicht verbindlich und schafft keine zusätzlichen Pflichten. Für die Auslegungsfragen zum Produktbegriff, zur Datenfernverarbeitung und zum Abgabebegriff wurden der CRA-Kommentar von Wiebe (Nomos 2025) [7] sowie der artikelweise Kommentar von Schröder/Hartl (Nomos, 1. Auflage 2026) [9] herangezogen. Ergänzend dienen die FAQ der Kommissionsdienststellen [10], die Technische Richtlinie BSI TR-03183 [5] und weitere ausgewiesene Quellen.

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

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

[4] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026. Die Guidance ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sie ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Abschnitte 2.1 und 2.2 (Rn. 10–21) sowie 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).

[5] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products. Teil 1: General Requirements, Version 1.0.0 (Stand gemäss Deckblatt 31.07.2026), als „Living Document“ gekennzeichnet; Teil 2: Software Bill of Materials (SBOM), Version 2.1.0; Teil 3: Vulnerability Reports and Notifications, Version 1.0.0. Nicht bindende technische Orientierung. 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.

[6] Bitkom e.V., „Cyber Resilience Act: An updated position paper on the transposition at the European Level“, Positionspapier 2026. S. 13 f.: „For the vast majority of SMEs, but also for larger companies, this process is not both legally compliant and economically feasible due to the effort involved.“ Als Lösung fordert der Verband: „Essentially, the majority of the documentation requirements need to be eliminated.“ Verfügbar unter: https://www.bitkom.org/sites/main/files/2026-02/bitkom-position-paper-cyber-resilience-act-transposition-at-european-level.pdf.

[7] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe/Jossen, § 4 Rn. 3–5 (Produktbegriff, Datenverbindung, Datenfernverarbeitungslösung); Wiebe, § 4 Rn. 18 (Abgabe unverkörperter Software, Werkstorprinzip).

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

[9] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Hofmann, Art. 3 Rn. 7 f., 13, 15, 18, 19, 21; Poncza, Art. 3 Rn. 133–135.

[10] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026, insbesondere Nr. 1.2. Von den Kommissionsdienststellen erstellt; nicht verbindlich und nach eigener Angabe keine offizielle Position der Kommission. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 16.03.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: Drei-Elemente-Test: Wann Cloud-Verarbeitung unter den CRA fällt — 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.