CRA für SaaS-Anbieter: Bin ich betroffen?

Die Grundregel: Reine Cloud-Dienste sind ausgenommen

Der Cyber Resilience Act (EU-Verordnung 2024/2847) macht eine wichtige Ausnahme, die für viele SaaS-Anbieter relevant ist: Remote-Data-Processing-Dienste fallen nicht unter den CRA.

Artikel 2 Absatz 7 CRA hält fest, dass Dienste, die ausschließlich remote erbracht werden und keine beim Nutzer installierte Softwarekomponente haben, nicht als “Produkte mit digitalen Elementen” gelten.¹ Dahinter steckt ein klares Konzept: Der CRA reguliert Produkte, die “in Verkehr gebracht” werden — also Softwareprodukte oder Gerätesoftware, die Kunden erwerben und selbst betreiben. Findet die gesamte Verarbeitung beim Anbieter statt und greift der Nutzer nur über den Browser zu, handelt es sich um kein “in Verkehr gebrachtes Produkt” im CRA-Sinne.

Beispiel für eine klare Nicht-Betroffenheit: Ein CRM-System wie eine typische webbasierte Vertriebssoftware ohne Desktop-Client, lokale App oder On-Premise-Option — rein browserbasiert, alle Daten und Logik beim Anbieter — fällt nicht unter den CRA.

Diese Ausnahme ist real und substanziell. Viele SaaS-Anbieter sind tatsächlich nicht CRA-relevant. Aber: Ob man wirklich in der sicheren Ausnahme-Zone liegt, sollte sorgfältig geprüft werden — denn die Grauzone ist größer als sie zunächst erscheint.

Wann SaaS doch unter den CRA fällt: Die Grauzone

Grauzone 1: SaaS mit lokaler Komponente

Der häufigste Fall: Das SaaS-Produkt enthält eine Komponente, die beim Nutzer installiert wird. Das kann sein:

• Eine Desktop-App (Electron-App, .NET-Anwendung, macOS-App)
• Eine Browser-Extension (Chrome Extension, Firefox Add-on)
• Ein lokaler Agent (Background-Prozess, System-Tray-App, CLI-Tool)
• Eine On-Premise-Komponente (Self-hosted Connector, On-Prem-Gateway)

Sobald eine dieser Komponenten existiert, ist das Produkt als Ganzes — nicht nur die lokale Komponente — potenziell CRA-relevant. Die lokale Komponente stellt das “Produkt mit digitalen Elementen” dar, das “in Verkehr gebracht” wird.

Das ist der Punkt, den viele übersehen: Die Ausnahme gilt für den Dienst als solchen, nicht für einzelne Komponenten. Besteht ein SaaS-Produkt aus einem Cloud-Backend plus einer lokal installierten Desktop-App, betrachtet der CRA die Gesamtlösung als ein Produkt — und die lokale Komponente zieht den gesamten Produktumfang in den CRA. Kein Weg daran vorbei.

Ein Hersteller von Workforce-Management-Software — z.B. ein IoT-Startup, das eine Schichtplanungs-App mit lokaler Electron-Desktop-Komponente vertreibt — ist damit CRA-relevant. Nicht wegen des Cloud-Backends. Wegen der 80-MB-Electron-App, die auf dem Rechner des Disponenten läuft.

Grauzone 2: SaaS das physische Geräte ansteuert

IoT-Plattformen, Industrial-Control-SaaS und ähnliche Dienste, die Befehle an physische Geräte senden, befinden sich in einer anderen Grauzone. Nicht wegen der Cloud-Komponente, sondern wegen der Art der Verbindung zwischen Cloud und physischem Gerät.

Ein Hersteller von Industrial-IoT-Monitoring-Software — z.B. eine SaaS-Plattform, die Sensordaten aus Fertigungsanlagen visualisiert — ist wahrscheinlich ein reiner Remote-Dienst. Anders sieht es aus, sobald diese Plattform Befehle an SPS oder vernetzte Maschinen sendet und deren Betriebszustand steuert. In der Praxis erleben wir genau diese Situation bei Industrie-4.0-Anbietern: Die Steuerungslogik läuft in der Cloud, aber der Befehlspfad endet auf einem physischen Gerät beim Kunden — und dann wird es rechtlich eng.

Konkret: Ein Maschinenbauer, der seinen Kunden eine SaaS-Plattform zur Fernsteuerung von CNC-Anlagen verkauft, sollte nicht auf die Remote-Dienst-Ausnahme vertrauen, ohne eine belastbare rechtliche Einschätzung eingeholt zu haben.

Grauzone 3: SaaS das als gebündeltes Produkt verkauft wird

Verkauft ein Anbieter seine SaaS-Lösung zusammen mit einer lokalen Hardware- oder Softwarekomponente als Gesamtpaket — z. B. als “Hardware-Appliance plus Cloud-Management-Plattform” — gilt die Gesamtlösung als ein Produkt. Die Hardware-Komponente zieht die Cloud-Komponente in die CRA-Bewertung. Das klingt nach einer Randkonstellation. Ist es aber nicht: Viele Maschinenbauer und IoT-Startups vertreiben genau dieses Modell.

Ein Hersteller von industriellen MQTT-Gateways, der sein Gerät zusammen mit einer Cloud-Managementplattform als “Komplettlösung für Gebäudeautomation” vermarktet, betreibt kein reines SaaS-Geschäft — er bringt ein Produkt mit digitalen Elementen in Verkehr. Beide Teile gemeinsam.

Konkretes Beispiel: MDM-Software wahrscheinlich CRA-relevant

Mobile Device Management (MDM) Software ist ein besonders klares Beispiel für eine wahrscheinlich CRA-relevante SaaS-Kategorie. MDM-Produkte wie Microsoft Intune, Jamf oder ähnliche bestehen typischerweise aus:

• Einem Cloud-Backend für das Gerätemanagement-Dashboard
• Einem lokalen Agenten auf jedem verwalteten Endgerät (Management-Client, der auf dem Gerät des Nutzers läuft)

Der lokale Agent — installiert auf Windows, macOS, iOS oder Android — ist eine beim Nutzer deployete Softwarekomponente. Das macht das MDM-Produkt als Ganzes zu einem potenziellen “Produkt mit digitalen Elementen” nach CRA. Die Cloud-Komponente allein könnte ausgenommen sein — aber in Kombination mit dem lokalen Agenten fällt das Gesamtprodukt unter die CRA-Prüfung.

Konkret bedeutet das: Ein Anbieter von embedded-Software für Endpoint-Management, der seinen Agenten über ein SaaS-Modell ausrollt, ist Hersteller nach CRA — mit allen Pflichten zur technischen Dokumentation, Konformitätsbewertung und CE-Kennzeichnung.

Kontrast-Beispiel: Reine CRM-Software ohne Desktop-Client — alle Daten und Logik im Cloud-Backend, Nutzer arbeiten ausschließlich über den Browser. Keine lokale Installation, kein Agent, keine Browser-Extension die Systemrechte benötigt. Wahrscheinlich ein reiner Remote-Dienst nach Artikel 2 Absatz 7 CRA.¹

Was bedeutet “in Verkehr bringen” für SaaS?

Was viele SaaS-Anbieter an dieser Stelle nicht auf dem Schirm haben: Der Begriff “in Verkehr bringen” stammt ursprünglich aus dem klassischen Produktrecht und beschreibt eine einmalige Transaktion — Kaufvertrag, Lizenzvertrag. SaaS-Abonnements sind keine klassischen Kaufverträge.

Erwägungsgründe 15–18 des CRA klären dieses Konzept für Software.¹ Als “in Verkehr gebracht” gilt eine Software, sobald ein Anbieter sie einem Nutzer in der EU erstmals zur Verfügung stellt — sei es durch Kauf, Abonnement oder unentgeltliche Nutzung. Das Abonnement-Modell als solches schließt die CRA-Relevanz also nicht aus.

Entscheidend ist vielmehr: Führt das Produkt Verarbeitungslogik auf dem Gerät des Nutzers aus? Wenn ja, fällt diese Komponente unter den CRA — auch wenn ein Anbieter sie über ein SaaS-Modell bereitstellt.

Open Source SaaS: Self-hosted Versionen

Ein zunehmend relevanter Sonderfall: Open-Source-Software, die üblicherweise als SaaS angeboten wird, aber auch als Self-hosted Version verfügbar ist. Typische Beispiele: Gitea, Mattermost, n8n, Metabase.

Die entscheidende Frage: Wer bringt die Self-hosted Version in Verkehr?

• Nicht-kommerzieller Open-Source-Entwickler, der die Software unter einer Open-Source-Lizenz ohne kommerzielle Absicht veröffentlicht → fällt unter die Open-Source-Ausnahme nach Artikel 16 CRA.¹
• Kommerzielles Unternehmen, das eine Self-hosted Version als Teil eines bezahlten Produkts anbietet (inklusive Support, Managed Installation) → ist Hersteller nach CRA.

Ein konkretes Szenario: Ein deutsches SaaS-Unternehmen, das neben dem Cloud-Dienst auch eine “Enterprise Self-hosted Edition” vertreibt, ist für die Self-hosted Edition als Hersteller nach CRA zu betrachten. Die Cloud-Edition könnte unter die Remote-Dienst-Ausnahme fallen — die Self-hosted Edition nicht. Was viele CRA-Berater an dieser Stelle nicht klar genug sagen: Wer beide Varianten im Portfolio hat, braucht zwei getrennte Compliance-Bewertungen.

Praktischer Portfolio-Check für SaaS-Anbieter

Drei Fragen helfen, das eigene Produktportfolio schnell einzuordnen:

Frage 1: Gibt es eine lokale Komponente? Wird irgendein Teil des Produkts auf dem Gerät des Nutzers installiert oder ausgeführt — Desktop-App, mobiler Client, Browser-Extension, lokaler Agent, CLI-Tool? Wenn ja: CRA-Prüfung erforderlich.

Frage 2: Steuert das Produkt physische Geräte? Sendet das Produkt Befehle an physische Geräte (Maschinen, IoT-Sensoren, Gebäudetechnik)? Wenn ja: Rechtliche Einschätzung zur CRA-Relevanz empfehlenswert.

Frage 3: Wird eine Self-hosted Version kommerziell vertrieben? Bieten Sie eine On-Premise- oder Self-hosted Version des Produkts an? Wenn ja und wenn kommerziell: Wahrscheinlich CRA-relevant — auch wenn die Cloud-Version es nicht ist.

Wer alle drei Fragen mit Nein beantwortet, ist ein starker Kandidat für die Remote-Dienst-Ausnahme nach Artikel 2 Absatz 7 CRA. Eine formale rechtliche Bestätigung empfiehlt sich dennoch — insbesondere wenn das Produkt in regulierten Märkten eingesetzt wird oder Großkunden in der EU bedient.

Weiterführende Themen

• Bin ich nach CRA Hersteller, Importeur oder Händler? → CRA: Hersteller, Importeur oder Händler?
• Was trifft auf mein Produkt zu — welche Risikoklasse? → CRA Risikoklassen: Default, Important, Critical
• Bin ich überhaupt vom CRA betroffen? → CRA: Bin ich betroffen?

Für eine erste indikative Einschätzung Ihrer Produktkonstellation nutzen Sie den kostenlosen CRA-Check. Wenn Sie festgestellt haben dass Ihr SaaS-Produkt CRA-relevant ist, bietet das Evidence Pack strukturierte Templates für die technische Dokumentation nach CRA-Standard — auch für SaaS-Anbieter mit lokalem Agenten oder Desktop-Client.

Quellen

1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2 (Absatz 1, Absatz 7), Artikel 16, Erwägungsgründe 15–18: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. ENISA — CRA-Guidance für Software-as-a-Service und Cloud-Produkte: https://www.enisa.europa.eu/topics/cyber-resilience-act
3. BSI — CRA: Anwendungsbereich und Ausnahmen für Cloud-Dienste: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
4. EU-Kommission — Q&A zum Anwendungsbereich des Cyber Resilience Act: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14241-Cyber-resilience-act

Hinweis: Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Die Einschätzungen basieren auf dem Stand der EU-Verordnung 2024/2847 und öffentlich verfügbaren Auslegungshilfen. Die Grauzonenfälle im SaaS-Bereich sind noch nicht vollständig durch Behördenentscheidungen oder Gerichtsurteile geklärt. Für eine verbindliche Einschätzung empfehlen wir rechtliche Fachberatung.