SaaS, Cloud und Fernverarbeitung: Wann ein Online-Dienst zum Produkt gehört
Ein Produkt mit digitalen Elementen umfasst nach dem Cyber Resilience Act auch seine Fernverarbeitung. Welche Cloud-Dienste das sind, entscheidet Artikel 3 Nummer 2 mit drei Kriterien. Reine Software aus dem Browser ist dagegen kein Produkt, sondern ein Dienst nach NIS2.
Ein Online-Dienst gehört zum Produkt, wenn drei Bedingungen zugleich erfüllt sind (Artikel 3 Nummer 2). Die Datenverarbeitung findet entfernt statt. Ohne sie könnte das Produkt eine seiner Funktionen nicht erfüllen. Und die Software dafür wurde vom Hersteller selbst oder unter seiner Verantwortung entwickelt. Dann ist der Dienst "Datenfernverarbeitung" und Teil des Produkts mit digitalen Elementen (Artikel 3 Nummer 1). Er muss die Anforderungen aus Anhang I erfüllen und fällt unter die Meldepflicht nach Artikel 14. Eine Website, die die Produktfunktion nicht trägt, und ein Cloud-Dienst außerhalb der Verantwortung des Herstellers gehören nicht dazu. Reine Software-as-a-Service ohne Installation beim Nutzer ist kein Produkt im Sinne des CRA; sie fällt nach Erwägungsgrund 12 unter NIS2.
Das Wichtigste
- Drei Kriterien, alle zugleich: entfernte Verarbeitung, Produktfunktion hängt davon ab, Software vom Hersteller oder unter seiner Verantwortung (Artikel 3 Nummer 2).
- Wer die Server betreibt, ist unerheblich. Herstellersoftware auf gemieteter Infrastruktur ist Fernverarbeitung; eingekaufte Dritt-SaaS ist keine, sondern eine Komponente mit Sorgfaltspflicht.
- Erfasst ist nur, was für die Produktfunktion nötig ist (Erwägungsgrund 11). Websites ohne Produktfunktion und die allgemeine IT des Herstellers bleiben außen vor (Erwägungsgrund 12).
- Reine SaaS-Anwendungen im Browser sind kein Produkt; für sie gilt NIS2 ab mittlerer Unternehmensgröße (Erwägungsgrund 12).
- Folge: Das Backend muss Anhang I erfüllen, steht in der Risikobewertung und der Dokumentation, und ein Vorfall dort kann die 24-Stunden-Frist auslösen.
Was sagt die Verordnung?
Artikel 3 Nummer 1 definiert das Produkt mit digitalen Elementen als Software- oder Hardwareprodukt einschließlich seiner Datenfernverarbeitungslösungen. Artikel 3 Nummer 2 definiert diese Fernverarbeitung als Datenverarbeitung, die entfernt stattfindet. Die Software dafür muss vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt sein, und ohne sie könnte das Produkt eine seiner Funktionen nicht erfüllen. Alle drei Teile müssen zusammenkommen. Fehlt einer, ist der Dienst nicht Teil des Produkts.
Erwägungsgrund 11 grenzt ein: Die Fernverarbeitung ist nur insoweit erfasst, als sie für die Produktfunktion notwendig ist. Das Beispiel dort: Eine App braucht Zugang zu einer Schnittstelle oder Datenbank über einen vom Hersteller entwickelten Dienst, dann ist der Dienst erfasst. Nicht erfasst sind Maßnahmen für die Sicherheit der Netz- und Informationssysteme des Herstellers insgesamt. Erwägungsgrund 12 ergänzt für die Cloud: Cloud-Lösungen sind nur dann Fernverarbeitung, wenn sie der Definition entsprechen. Erfasst ist etwa eine Cloud-Funktion zur Fernsteuerung eines Smart-Home-Geräts. Nicht erfasst sind Websites, die die Produktfunktion nicht unterstützen, und Cloud-Dienste außerhalb der Verantwortung des Herstellers. Software-, Plattform- und Infrastrukturdienste (SaaS, PaaS, IaaS) fallen unter NIS2, soweit deren Schwellen erreicht sind.
Wie wendet die Leitlinie der Kommission die drei Kriterien an?
Die Leitlinie C(2026) 5252 vom 27. Juli 2026 behandelt die Fernverarbeitung in einem eigenen Abschnitt. Ihr Originaltext wurde für diese Seite nicht direkt ausgewertet; die Beispiele stammen aus übereinstimmenden Sekundärquellen.
- Kriterium 1, entfernt: Public Cloud, Private Cloud oder eigene Server des Herstellers, alles gilt als entfernt. Mobilfunknetz und Router sind nur Kommunikationsweg, keine Verarbeitung.
- Kriterium 2, Funktion: Mindestens eine Produktfunktion fällt ohne den Dienst aus. Nachgelagerte Systeme, mit denen das Produkt nicht direkt interagiert, etwa Buchhaltung, Personalverwaltung, Kundenverwaltung, Build-Umgebung oder Update-Verteilung, sind nicht erfasst.
- Kriterium 3, Verantwortung: Die Software stammt vom Hersteller oder wurde unter seiner Verantwortung entwickelt. Wer die Infrastruktur betreibt, entscheidet nicht: Herstellersoftware auf gemieteter Infrastruktur ist Fernverarbeitung. Eingekaufte Dritt-SaaS, die das Produkt integriert, ist keine Fernverarbeitung, sondern Komponente mit Sorgfaltspflicht nach Artikel 13 Absatz 5.
Drei Beispiele aus der Leitlinie, nach Sekundärquellen: Ein Smart-Thermostat, dessen Cloud-Software der Hersteller entwickelt hat und auf gemieteter Infrastruktur betreibt, hat Fernverarbeitung, die zum Produkt gehört. Ein Industrieroboter, dessen Hersteller einen Pick-Service in der Cloud betreibt, ohne den der Roboter nicht greifen kann: ebenfalls erfasst. Eine Mobile-Banking-App, die eine eingekaufte Chat-Lösung eines Drittanbieters einbindet: Der Chat ist nicht erfasst, die App selbst bleibt Produkt.
Welche Beispiele gehören zum Produkt, welche nicht?
| Fall | Gehört zum Produkt? | Begründung |
|---|---|---|
| App zur Maschine mit Backend des Herstellers, ohne das Fernüberwachung und Fernsteuerung nicht funktionieren | ja | Erwägungsgrund 12; Leitlinienbeispiel Thermostat (Sekundärquelle) |
| Industrieroboter mit Pick-Service des Herstellers in der Cloud | ja | Leitlinienbeispiel (Sekundärquelle) |
| Lizenzserver des Herstellers, ohne den die Software nicht startet | ja, abgeleitet | Alle drei Kriterien aus Artikel 3 Nummer 2 liegen vor; ein Leitlinienbeispiel dazu wurde nicht gefunden |
| Fernwartungszugang mit Software des Herstellers, Fernwartung ist beworbene Produktfunktion | ja, abgeleitet | Aus Artikel 3 Nummer 2 abgeleitet, nicht als Leitlinienbeispiel belegt |
| Fernwartung als optionaler Service mit einem Werkzeug eines Drittanbieters | nein | Komponente mit Sorgfaltspflicht nach Artikel 13 Absatz 5 (Ableitung) |
| Eingekaufte Dritt-SaaS, in das Produkt integriert (Chat, Karten, Analyse) | nein | Komponente, nicht Fernverarbeitung; Leitlinienbeispiel Banking-App (Sekundärquelle) |
| Kundenportal, Dokumentation, Bestellung im Web, trägt keine Produktfunktion | nein | Erwägungsgrund 12: Websites ohne Produktfunktion |
| Update-Server, Build-System, Kundenverwaltung des Herstellers | nein | Erwägungsgrund 11; nachgelagerte Systeme (Sekundärquelle) |
| Reine SaaS-Anwendung im Browser ohne lokale Installation | kein Produkt | Erwägungsgrund 12: NIS2 statt CRA |
| Browser-Erweiterung, Desktop-Client, heruntergeladene App | Produkt | Software wird dem Nutzer bereitgestellt und installiert (Sekundärquelle) |
Die Zeilen zu Lizenzserver und Fernwartung sind Ableitungen aus dem Wortlaut der Verordnung, keine belegten Einordnungen der Kommission. Wer einen dieser Fälle hat, sollte die Einordnung dokumentieren und bei Bedarf rechtlich prüfen lassen.
Was gilt für lokal installierte Software plus Cloud?
Das ist der häufigste Fall bei Softwareherstellern im Mittelstand: Ein Client wird beim Kunden installiert, ein Teil der Funktionen läuft über ein Backend des Herstellers. Der Client ist Produkt. Das Backend ist Fernverarbeitung und damit Teil desselben Produkts, soweit der Client ohne das Backend eine Funktion verliert und der Hersteller die Backend-Software selbst entwickelt hat oder entwickeln ließ. Nicht erfasst sind Backend-Teile, die der Client nicht braucht, und eingekaufte Dienste Dritter, die das Backend seinerseits nutzt.
Die Grenze verläuft also nicht zwischen "lokal" und "Cloud", sondern zwischen "Produktfunktion" und "alles andere". Für jedes Backend-Modul sollten die drei Fragen beantwortet und in der technischen Dokumentation festgehalten sein. Wer Software ausschließlich im Browser betreibt, ist dagegen kein Hersteller nach CRA; für ihn kann NIS2 gelten, siehe CRA und NIS2 im Vergleich.
Welche Folgen hat die Einordnung?
- Anhang I gilt für das BackendDie grundlegenden Anforderungen aus Anhang I Teil I (Produkteigenschaften) und Teil II (Schwachstellenbehandlung) gelten für das Produkt einschließlich seiner Fernverarbeitung. Die Risikobewertung nach Artikel 13 Absatz 2 und 3 muss das Backend einschließen.
- Die Dokumentation umfasst das BackendTechnische Dokumentation, SBOM und Konformitätsbewertung beziehen sich auf das gesamte Produkt. Eine Konformitätserklärung nur für den Client greift zu kurz.
- Die Meldepflicht umfasst das BackendEine aktiv ausgenutzte Schwachstelle im Backend oder ein schwerwiegender Vorfall dort ist ein Fall nach Artikel 14, mit Frühwarnung binnen 24 Stunden ab Kenntnis. Die Überwachung des Backends gehört damit in dieselbe Bereitschaft wie die Meldeadresse für das Produkt.
- Dritt-SaaS braucht Sorgfalt, keine KonformitätFür eingekaufte Dienste gilt Artikel 13 Absatz 5: prüfen, dokumentieren, bei Schwachstellen den Anbieter informieren (Absatz 6). Eine CE-Kennzeichnung des Dienstes gibt es nicht.
- Änderungen am Backend können wesentlich seinEine neue Fernkonnektivität oder der Ersatz lokaler Verschlüsselung durch einen Fern-Dienst gilt nach der Leitlinie (Sekundärquelle) als wesentliche Änderung. Details unter Wesentliche Änderung.
Typische Fehler
- "Unser Backend ist nur SaaS, also außerhalb." Wenn das Backend Produktfunktionen trägt und vom Hersteller stammt, ist es Teil des Produkts.
- Umgekehrt: Dritt-Cloud als eigene Fernverarbeitung führen. Ein eingekaufter Dienst ist Komponente mit Sorgfaltspflicht, nicht Teil der eigenen Konformitätsbewertung.
- Die ganze Hersteller-IT als Produkt behandeln. Erwägungsgrund 11 nimmt die allgemeine Sicherheit der Herstellersysteme aus; erfasst sind die Module, mit denen das Produkt direkt arbeitet.
- Backend-Vorfälle nicht in die Meldeorganisation einbeziehen. Wer nur die Meldeadresse für den Client überwacht, verpasst die Frist, wenn das Backend angegriffen wird.
- Keine Dokumentation der Einordnung. Für jedes Backend-Modul sollte festgehalten sein, ob und warum es zum Produkt gehört.
Ob ein Produkt überhaupt unter den CRA fällt und wie die Cloud-Anteile einzuordnen sind, lässt sich mit dem Betroffenheitscheck vorab klären. Für Hersteller, deren Produkt Fernverarbeitung umfasst, führt CRA Response Center Meldungen zum Client und zum Backend an einer Stelle zusammen, prüft sie und weckt die Rufkette. Die Meldung an die ENISA-Plattform reicht der Hersteller selbst ein.
Häufige Fragen
Gehört mein Cloud-Backend zum Produkt?
Ja, wenn Sie es selbst entwickelt haben oder entwickeln ließen und das Produkt ohne das Backend eine Funktion verliert (Artikel 3 Nummer 2, Erwägungsgründe 11 und 12). Wo die Server stehen, spielt keine Rolle.
Ist reines SaaS vom CRA erfasst?
Nein. Software, die ausschließlich im Browser läuft und nicht beim Nutzer installiert wird, ist kein Produkt mit digitalen Elementen. Für solche Dienste gilt NIS2, soweit das Unternehmen die Schwellen erreicht (Erwägungsgrund 12).
Mein Backend läuft bei einem Cloud-Anbieter. Ändert das etwas?
Nein. Entscheidend ist, wer die Software entwickelt hat, nicht wer die Infrastruktur betreibt. Herstellersoftware auf gemieteter Infrastruktur ist nach der Leitlinie (Sekundärquelle) Fernverarbeitung.
Zählt die Fernwartung durch meinen Service?
Nur, wenn die Fernwartungssoftware von Ihnen stammt und eine Produktfunktion davon abhängt. Nutzen Sie ein Werkzeug eines Drittanbieters, gilt die Sorgfaltspflicht nach Artikel 13 Absatz 5. Diese Einordnung ist aus Artikel 3 Nummer 2 abgeleitet und nicht als Leitlinienbeispiel belegt.
Ist mein Lizenzserver Teil des Produkts?
Wenn die Software ohne ihn nicht startet und Sie ihn selbst entwickelt haben, liegen die drei Kriterien vor. Ein Beispiel der Kommission dazu wurde nicht gefunden; die Einordnung ist eine Ableitung aus dem Wortlaut.
Was ist mit eingekauften Diensten, die mein Produkt nutzt?
Sie sind Komponenten, keine Fernverarbeitung. Dafür gilt die Sorgfaltspflicht nach Artikel 13 Absatz 5 und die Pflicht, dem Anbieter gefundene Schwachstellen zu melden (Absatz 6). Für das Endprodukt bleiben Sie verantwortlich.
Muss ich einen Vorfall im Backend melden?
Wenn das Backend zum Produkt gehört, ja: Ein schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit oder eine aktiv ausgenutzte Schwachstelle löst die Frühwarnung binnen 24 Stunden nach Artikel 14 aus.
Weiterlesen
- CRA und NIS2 im VergleichProdukt oder Einrichtung, zwei Meldepflichten.
- Wesentliche ÄnderungWann ein Backend-Update ein neues Produkt ist.
- CRA für Agenturen und IndividualsoftwareWer Hersteller ist, wenn das Backend ein Dienstleister baut.
- Schwerwiegender SicherheitsvorfallWann ein Vorfall im Backend meldepflichtig ist.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 3 Nummer 1 und 2, Artikel 13 Absatz 2, 3, 5 und 6, Artikel 14, Erwägungsgründe 11 und 12, Amt für Veröffentlichungen der EU, abgerufen am 7. Oktober 2026.
- Remote data processing solution (RDPS), eucybersecurity.org, Glossar mit Beispielen aus der Leitlinie C(2026) 5252, 2026.
- Cyber Resilience Act guidance: products and obligations, Gamingtechlaw, 5. August 2026.
- CRA: the fine line between SaaS and digital products, DLA Piper, 16. Februar 2026.
- FAQ: The Cyber Resilience Act, cyberresilienceact.eu, 2026.