CRA Remote-Datenverarbeitung: Wann Cloud und SaaS Teil des Produkts werden

Cloud- und SaaS-Dienste fallen nicht allein deshalb unter den Cyber Resilience Act, weil sie Software bereitstellen. Relevant wird eine Remote-Komponente insbesondere dann, wenn sie vom Hersteller oder unter seiner Verantwortung entwickelt wurde und das Produkt ohne diese Datenfernverarbeitung eine seiner Funktionen nicht erfüllen könnte. In diesem Fall kann die Remote-Datenverarbeitung Teil des Produkts mit digitalen Elementen sein.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Grundlagen & Anwendungsbereich. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was ist eine Datenfernverarbeitungslösung im CRA?

Der CRA definiert eine Datenfernverarbeitungslösung als Datenverarbeitung aus der Ferne, für die Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde und ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte.

Diese Definition erweitert den Produktbegriff. Ein Gerät oder eine lokale Anwendung kann also zusammen mit einem notwendigen Backend betrachtet werden, wenn die Voraussetzungen erfüllt sind. Deshalb sollte die CRA-Anwendungsbereichsprüfung nicht nur lokale Software und Hardware erfassen.

Fällt jeder SaaS-Dienst unter den CRA?

Nein. Ein allgemeiner SaaS-Dienst wird nicht automatisch zum Produkt mit digitalen Elementen im Sinne des CRA. Cloud- und SaaS-Dienste können anderen EU-Regelwerken unterliegen und müssen vom speziellen Begriff der Datenfernverarbeitungslösung unterschieden werden.

Für den CRA kommt es auf die funktionale Verbindung zum Produkt an. Ein eigenständiges Projektmanagement-SaaS, das ein Hersteller intern nutzt, wird nicht dadurch Teil seines Geräts. Ein Hersteller-Backend, ohne das eine Kernfunktion des verkauften Produkts nicht funktioniert, kann dagegen in die Produktbetrachtung fallen.

Welche drei Fragen entscheiden über die Einordnung?

Ein praktischer Check kann mit drei Fragen beginnen.

Diese Fragen ersetzen keine Einzelfallprüfung, schaffen aber eine klare technische Struktur.

Wann ist ein Hersteller-Backend typischerweise relevant?

Ein Backend ist besonders relevant, wenn ein Produkt ohne dieses Backend zentrale Funktionen nicht ausführen kann. Das kann beispielsweise Authentifizierung, Gerätesteuerung, Datensynchronisation oder eine zwingend benötigte Verarbeitung betreffen.

Entscheidend ist nicht, ob das Backend in einer Public Cloud, im eigenen Rechenzentrum oder bei einem Dienstleister läuft. Die technische Hostingform beantwortet die CRA-Frage nicht. Maßgeblich bleibt die Funktionsabhängigkeit und Herstellerverantwortung.

Beispiel: Smart-Home-Gerät mit Cloud-Steuerung

Ein smartes Gerät lässt sich ausschließlich über eine Hersteller-App bedienen. Die App kommuniziert mit einem Hersteller-Backend, das Befehle authentifiziert und an das Gerät weiterleitet. Ohne Backend ist die vorgesehene Fernsteuerung nicht möglich.

Hier spricht viel dafür, die Remote-Komponente in die CRA-Produktbetrachtung einzubeziehen. Die Risikobewertung sollte deshalb nicht nur das Gerät, sondern auch Authentifizierung, API, Backend-Komponenten und Kommunikationswege berücksichtigen.

Beispiel: Lokale Anwendung mit optionalem Cloud-Backup

Eine Desktopanwendung funktioniert vollständig lokal. Nutzer können optional ein unabhängiges Cloud-Backup aktivieren. Fällt der Dienst aus, bleiben sämtliche Kernfunktionen der Anwendung verfügbar.

In diesem Fall ist die Verbindung schwächer. Ob eine konkrete Remote-Funktion dennoch als Teil des Produkts zu behandeln ist, hängt von Zweckbestimmung, Herstellerverantwortung und der genauen Funktionsbeschreibung ab. „Cloud vorhanden“ allein reicht nicht.

Beispiel: Lizenzserver und Aktivierung

Ein Lizenzserver kann ein Grenzfall sein. Wenn ein Produkt ohne wiederkehrende Verbindung nach Aktivierung vollständig funktioniert, ist die Einordnung anders als bei einer Anwendung, deren Funktion dauerhaft von einer Herstellerplattform abhängt.

Hersteller sollten dokumentieren, welche Produktfunktion tatsächlich betroffen ist. Eine rein kaufmännische Lizenzprüfung und eine technisch notwendige Remote-Verarbeitung sind nicht ohne Weiteres dasselbe.

Beispiel: Mobile App mit API

Eine mobile App, die praktisch nur als Oberfläche für eine Hersteller-API dient, kann eng mit der Remote-Verarbeitung verbunden sein. Fällt die API aus, kann die App ihre Hauptfunktion möglicherweise nicht erfüllen.

Dann gehören API-Authentifizierung, Autorisierung, Eingabevalidierung, Rate Limiting, Mandantentrennung und sichere Kommunikation in die Sicherheitsbetrachtung. Die App allein zu testen, wäre unvollständig.

Was bedeutet „unter Verantwortung des Herstellers entwickelt“?

Ein Hersteller kann Verantwortung auch dann tragen, wenn die Software nicht ausschließlich von eigenen Mitarbeitern programmiert wurde. Auftragsentwicklung oder andere Entwicklungsmodelle können unter seiner Verantwortung erfolgen.

Deshalb beseitigt Outsourcing die CRA-Verantwortung nicht automatisch. Wer ein Backend durch einen Dienstleister entwickeln lässt und es als notwendigen Teil seines Produkts betreibt, sollte die Lieferantenbeziehung, Entwicklungsanforderungen und Sicherheitsnachweise in den Herstellerprozess integrieren.

Ist ein externer Cloudanbieter automatisch Teil des Produkts?

Nein. Ein Infrastrukturprovider, auf dem die Herstelleranwendung läuft, ist nicht allein durch das Hosting selbst ein Teil der Produktfunktion im selben Sinne. Der Hersteller muss jedoch die Risiken und Abhängigkeiten seiner Remote-Lösung berücksichtigen.

Cloudregion, IAM, Secrets, Netzwerkarchitektur, Backup, Verfügbarkeit und Updateprozesse können sicherheitsrelevant sein. Der CRA nimmt dem Hersteller die Verantwortung nicht ab, nur weil Infrastruktur von einem Dritten bezogen wird.

Welche Risiken entstehen durch Remote-Komponenten?

Remote-Komponenten erweitern die Angriffsfläche. Zusätzlich zu lokalen Angriffen entstehen Risiken durch APIs, Benutzerkonten, Server, Administrationszugänge, Abhängigkeiten und zentrale Datenverarbeitung.

Ein Fehler im Backend kann gleichzeitig viele Produkte oder Nutzer betreffen. Deshalb sollte die Risikobewertung systemische Auswirkungen berücksichtigen: Was passiert bei kompromittierten Administratorzugängen, fehlerhafter Mandantentrennung oder gestohlenen Signierschlüsseln?

Wie verändert Remote-Verarbeitung die technische Dokumentation?

Die technische Dokumentation sollte die für die Produktfunktion relevante Remote-Architektur nachvollziehbar abbilden. Dazu gehören Schnittstellen, Datenflüsse, Vertrauensgrenzen, Authentifizierungsmechanismen und wesentliche Softwarekomponenten.

Bei einer Cloudarchitektur genügt ein Satz wie „Backend läuft in der Cloud“ nicht. Prüfer müssen verstehen können, wie die sicherheitsrelevanten Teile zusammenarbeiten.

Gehören Backend-Komponenten in die SBOM?

Soweit Softwarekomponenten Teil der relevanten Produkt- und Schwachstellenbetrachtung sind, sollte die SBOM-Strategie auch Remote-Komponenten angemessen berücksichtigen. Entscheidend ist, dass eine neue Schwachstelle zuverlässig einem betroffenen Produkt und Dienst zugeordnet werden kann.

Bei kontinuierlich ausgelieferten Backend-Releases entsteht dabei eine andere Versionierungsfrage als bei statischer Firmware. Hersteller brauchen einen nachvollziehbaren Zusammenhang zwischen Produktversion, Backendstand und Sicherheitsereignissen.

Wie funktionieren Sicherheitsupdates bei einem Cloud-Backend?

Ein Vorteil zentraler Remote-Komponenten ist, dass Hersteller Sicherheitsfixes häufig selbst ausrollen können. Gleichzeitig darf die Updategeschwindigkeit nicht zu fehlender Nachweisführung führen.

Änderungen sollten getestet, freigegeben und rückverfolgbar sein. Bei sicherheitsrelevanten Änderungen muss geprüft werden, ob Risikobewertung und technische Dokumentation aktualisiert werden müssen.

Kann eine Backend-Änderung eine wesentliche Änderung sein?

Ja. Wenn eine Remote-Komponente Teil des Produkts ist und eine Änderung Zweckbestimmung, Angriffsfläche oder Konformität beeinflusst, kann die wesentliche Änderung relevant werden.

Ein reiner Sicherheitsfix, der Risiko reduziert, ist anders zu bewerten als die Einführung einer neuen öffentlichen API, eines neuen Authentifizierungsmodells oder einer Funktion, die völlig neue Daten verarbeitet.

Welche Rolle spielt der Supportzeitraum bei Cloudprodukten?

Auch bei Produkten mit Remote-Komponenten muss der Hersteller einen angemessenen Supportzeitraum festlegen. Das betrifft nicht nur lokale Firmware, sondern die Fähigkeit, die notwendigen Remote-Funktionen sicher aufrechtzuerhalten.

Ein Produkt, das technisch zehn Jahre genutzt werden soll, dessen notwendiges Backend aber nach drei Jahren abgeschaltet wird, wirft erhebliche Produkt- und Kundenfragen auf. Produktlebensdauer und Backendstrategie müssen zusammenpassen.

Was passiert, wenn der Hersteller den Cloud-Dienst abschaltet?

Das hängt von Produktversprechen, Zweckbestimmung und Supportmodell ab. Für die CRA-Perspektive ist entscheidend, ob das Produkt dadurch eine vorgesehene Funktion verliert und wie Nutzer über Supportende und sichere weitere Nutzung informiert werden.

Hersteller sollten bereits in der Produktplanung einen Exit-Pfad vorsehen: lokale Fallback-Funktion, Migration, Export, geordnete Außerbetriebnahme oder andere technische Lösung. Ein plötzliches Abschalten ohne Produktstrategie ist riskant.

Wie beeinflusst Remote-Verarbeitung die Meldepflichten?

Eine Schwachstelle oder ein Sicherheitsvorfall in einer notwendigen Remote-Komponente kann Auswirkungen auf Produkte mit digitalen Elementen haben. Dann muss geprüft werden, ob die Kriterien der CRA-Meldepflichten erfüllt sind.

Incident Response sollte daher Produkt- und Cloudteams verbinden. Eine zentrale Backend-Schwachstelle darf nicht nur als allgemeiner IT-Betriebsincident behandelt werden, wenn sie die Sicherheit des Produkts beeinflusst.

Welche Rolle spielen SaaS-Drittanbieter im Lieferantenmanagement?

Nutzen Hersteller Drittanbieter für Entwicklungs-, Betriebs- oder Sicherheitsfunktionen, brauchen sie ausreichend Informationen für ihre eigene Risikobewertung. Verträge sollten insbesondere Sicherheitskontakte, Schwachstelleninformation, Änderungsmanagement und Reaktionszeiten berücksichtigen.

Das bedeutet nicht, dass jeder eingesetzte SaaS-Anbieter zum CRA-Produkt gehört. Lieferantenmanagement und Produktabgrenzung sind zwei getrennte Fragen, die beide notwendig sein können.

Welche typischen Fehler gibt es bei der Einordnung?

„SaaS ist immer außerhalb des CRA“

Zu pauschal. Eine notwendige Remote-Komponente kann Teil des Produkts sein.

„Alles in der Cloud gehört automatisch zum Produkt“

Ebenfalls falsch. Funktionsnotwendigkeit und Herstellerverantwortung müssen geprüft werden.

Nur das lokale Gerät dokumentieren

Wenn Backend oder API für eine Produktfunktion notwendig sind, kann eine rein lokale Sicherheitsbetrachtung wesentliche Risiken übersehen.

Hosting mit Verantwortungsübertragung verwechseln

Ein Cloudprovider übernimmt nicht automatisch die Herstellerpflichten für das Produkt.

Continuous Deployment ohne CRA-Change-Check

Häufige Backend-Releases brauchen einen leichten, aber belastbaren Sicherheits- und Dokumentationsprozess.

Wie sieht ein praktischer Remote-Check aus?

1. Alle Remote-Dienste des Produkts auflisten.
2. Für jeden Dienst prüfen, welche Funktion er ermöglicht.
3. Festhalten, ob das Produkt ohne ihn diese Funktion erfüllen kann.
4. Verantwortung für Entwicklung und Betrieb klären.
5. Schnittstellen und Datenflüsse dokumentieren.
6. Risiken und Abhängigkeiten in die Produkt-Risikobewertung übernehmen.
7. Komponenten- und Schwachstellenmanagement verbinden.
8. Support- und Abschaltstrategie definieren.
9. Änderungen der Remote-Komponente in den CRA-Change-Prozess aufnehmen.

Wo erklärt die EU die Abgrenzung?

Die Europäische Kommission fasst Produktbegriff, Datenfernverarbeitung und die Abgrenzung zu eigenständigen Cloud-Diensten in ihrer Zusammenfassung des Cyber Resilience Act und den aktuellen CRA-Leitlinien zusammen.