SaaS, Cloud und Fernverarbeitung: Wann ein Online-Dienst zum Produkt gehört

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 (Leitlinie der Kommission, Rn. 21); für sie gilt nach Erwägungsgrund 12 die NIS2-Richtlinie, soweit der Anbieter deren Schwellen erreicht.

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 Abschnitt 8 ihres Annex (Rn. 181 bis 208 und Fallbeispiele 8.3). Die Angaben dieser Seite stammen aus diesem Text.

• Kriterium 1, entfernt: Public Cloud, Private Cloud oder eigene Server des Herstellers, alles gilt als entfernt (Rn. 186 und 187). Mobilfunknetz und Router sind nur Kommunikationsweg, keine Verarbeitung (Abschnitt 8.3.5). Die Leitlinie sieht dieses Merkmal als relevant, aber nicht hinreichend an; entscheidend sind die beiden folgenden Fragen, die zusammen erfüllt sein müssen (Rn. 185 und 188).
• Kriterium 2, Funktion: Mindestens eine Produktfunktion fällt ohne den Dienst aus; gemeint sind alle Funktionen, nicht nur die Kernfunktion (Rn. 189). Beispiele: Befehle an ein Gerät senden, Dateien synchronisieren, Nutzer einrichten, Konfiguration, automatische Verteilung von Updates an das Produkt, Identitäts- und Zugangsverwaltung (Rn. 190). Nachgelagerte Systeme, mit denen das Produkt nicht direkt interagiert, etwa Personalverwaltung, Kundenverwaltung, Build-Umgebung oder die interne Verteilung von Updates an Auslieferungsstandorte, sind nicht erfasst (Rn. 182 und 205).
• Kriterium 3, Verantwortung: Die Software stammt vom Hersteller oder wurde unter seiner Verantwortung entwickelt, also von einem Dienstleister nach seinen Vorgaben und Spezifikationen (Rn. 195). Wer die Infrastruktur betreibt, entscheidet nicht: Herstellersoftware auf gemieteter Infrastruktur ist Fernverarbeitung (Rn. 196 und 198). Eingekaufte Dritt-SaaS, die das Produkt integriert, ist keine Fernverarbeitung, sondern wie eine Komponente zu behandeln, mit einer Sorgfaltspflicht entsprechend Artikel 13 Absatz 5 (Rn. 200 und 201).

Drei Beispiele aus der Leitlinie (Abschnitt 8.3): 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?

Die Zeilen zur Fernwartung sind Ableitungen aus dem Wortlaut der Verordnung, keine Einordnungen der Kommission. Die Leitlinie nennt Fernwartung nicht, enthält aber zwei vergleichbare Fälle: Ein vom Hersteller entwickelter Dienst, der Befehle an einen Industrieroboter schickt, ist Fernverarbeitung (Abschnitt 8.3.4); ein zugekaufter Support-Dienst eines Drittanbieters ist es nicht und wird wie eine Komponente behandelt (Abschnitt 8.3.1). Für den häufigen Mischfall, dass Servicetechniker über ein selbst gebautes Portal zugreifen, ohne dass eine Produktfunktion davon abhängt, gibt es kein Beispiel; nach Rn. 192 und 193 wäre das keine Fernverarbeitung, gehört aber in die Risikobewertung. Zum Lizenzserver nennt die Leitlinie nur den vergleichbaren Fall eines Berechtigungsportals. 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?

1. 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.
2. 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.
3. 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.
4. Dritt-SaaS braucht Sorgfalt, keine KonformitätFür eingekaufte Dienste gilt eine Sorgfaltspflicht entsprechend Artikel 13 Absatz 5 (Leitlinie Rn. 201): prüfen, in der technischen Dokumentation beschreiben (Rn. 204), bei Schwachstellen den Anbieter informieren (Absatz 6). Eine CE-Kennzeichnung des Dienstes gibt es nicht.
5. Änderungen am Backend können wesentlich seinNeue von außen erreichbare Schnittstellen oder der Ersatz lokaler Verschlüsselung durch einen Fern-Dienst gelten nach der Leitlinie als wesentliche Änderung (Rn. 109 und 110, Beispiele 49 und 50). 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, überwacht CRA Response Center die Meldeadressen für Client und Backend an einer Stelle, stuft die Meldungen ein und benachrichtigt die zuständigen Personen. Die Meldung an die ENISA-Plattform reicht der Hersteller selbst ein.

Kostenlose VorlagenCRA-Meldepflicht-KitMelde-Playbook, Kenntnisvermerk, Meldevorlagen für die ENISA-Plattform, Rufkette und Fristenrechner. Sechs Word-Vorlagen, zwei Excel-Mappen und ein Handbuch, kostenlos per E-Mail.Kit anfordern

Häufige Fragen

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.
• Leitlinie der Kommission C(2026) 5252, Annex, Rn. 17 bis 21, 109, 110 und Abschnitt 8 (Rn. 181 bis 208, Fallbeispiele 8.3.1 bis 8.3.5), Europäische Kommission, 27. Juli 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.