Von Redaktion codAIx | 23. März 2026

Eine App auf dem Smartphone, die dazugehörige Verarbeitung in der Cloud: Wo endet das Produkt, wo beginnt der Dienst? Seit dem Inkrafttreten des Cyber Resilience Act am 10. Dezember 2024 beschäftigt diese Frage viele Softwarehersteller. Die am 27. Juli 2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der EU-Kommission übersetzt die Abgrenzung zwischen CRA-pflichtiger Datenfernverarbeitung und reinen Cloud-Diensten in einen strukturierten Test [1]. Wir lesen den Test entlang der Quelle und wenden ihn auf konkrete Produktarchitekturen an.

Warum ein Test nötig wurde

In den beiden vorangegangenen Teilen dieser Serie — dem Auftaktartikel zu Zweck und Anwendungsbereich des CRA und dem ersten Teil dieser Serie zur SaaS-Abgrenzung — haben wir die Grundlinie gezogen: Der CRA erfasst „Produkte mit digitalen Elementen“ einschliesslich ihrer Datenfernverarbeitungslösungen (Remote Data Processing Solutions, RDPS) [2]. Eine reine Browser-SaaS ist nach der Guidance der Kommission für sich genommen kein Produkt mit digitalen Elementen (Rn. 19–21, Beispiel 5); in der Kommentarliteratur wird dasselbe Ergebnis teils zusätzlich mit dem fehlenden Bereitstellen oder Inverkehrbringen begründet [4, Poncza, Art. 3 Rn. 135; Hofmann, Art. 3 Rn. 15]. Für reine Cloud-Dienste kann daneben NIS-2 einschlägig sein, wenn Dienst, Einrichtung und Grössen- oder Sonderkriterien der Richtlinie beziehungsweise des nationalen Umsetzungsrechts erfüllt sind [3]. Über Art. 3 Nr. 2 CRA reicht das Produktrecht gleichwohl in die Cloud hinein: Sobald ein Software- oder Hardwareprodukt im Sinne von Art. 3 Nr. 1 CRA den Marktzugang eröffnet, bildet die RDPS-Konstruktion den regulatorischen Brückenkopf; erst dann stellt sich die Frage, ob eine verbundene Fernverarbeitung als Datenfernverarbeitungslösung Teil dieses Produkts ist.

Wichtig für die Abgrenzung zur NIS-2-Sphäre: Das hauseigene Netz- und Informationssystem des Herstellers — etwa interne IT, Buchhaltungssysteme oder allgemeine Unternehmens-IT — bleibt, soweit es nicht produktnotwendig ist, ausserhalb des CRA-Anwendungsbereichs. Die Guidance stellt das in Rn. 182 ausdrücklich klar: „internal systems relating to the manufacturer's own human resources, payrolls, customer relationship management, continuous integration/continuous delivery (CI/CD) pipelines, the distribution of security updates to edge locations, should not be considered as RDPS“ [1]. Ebenso ausserhalb des RDPS-Anwendungsbereichs liegen laut Rn. 182 Systeme für Audit- und Testaktivitäten wie Penetrationstests, Threat Hunting und Red Teaming. Der CRA adressiert das Produkt und seine produktnotwendigen Bestandteile, nicht die gesamte IT-Landschaft des Herstellers.

An konkreten Architekturen wird die Grenze allerdings schnell unscharf. Wann ist eine Server-Komponente „integraler Bestandteil“ eines lokalen Produkts? Reicht ein optionaler Cloud-Sync? Und zählt ein Browser-Plugin bereits als „lokale Komponente“?

Die EU-Kommission hat auf diese Unsicherheit reagiert. Am 3. März 2026 hatte sie zunächst unter dem Aktenzeichen Ares(2026)2319816 einen Entwurf mit dem Titel „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ zur Konsultation veröffentlicht. Am 27. Juli 2026 veröffentlichte sie die Guidance mit Communication C(2026) 5252 final [1]. Das gut 80 Seiten starke Dokument umfasst neun nummerierte Kapitel — von der Abgrenzung des Anwendungsbereichs über Open-Source-Software, wesentliche Änderungen und Unterstützungszeiträume bis zur Datenfernverarbeitung und dem Zusammenspiel mit anderen EU-Rechtsakten. Kapitel 8 widmet sich der Frage, wann Datenfernverarbeitung als RDPS unter den CRA fällt; die veröffentlichte Fassung umfasst dort Rn. 178–208. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte.

Hinweis zur Quellenlage: Sämtliche Randnummern-Verweise in diesem Artikel beziehen sich auf die am 27. Juli 2026 mit Communication C(2026) 5252 final veröffentlichte Guidance. Herangezogen werden insbesondere Abschnitt 2.2 (Rn. 19–21), Kapitel 7.3 (Rn. 167–173) und Kapitel 8 (Rn. 178–208). Die frühere Entwurfsnummerierung vom 3. März 2026 wird nur noch bei der Darstellung der Quellenentwicklung genannt.

Die Vorfrage: Existiert überhaupt ein CRA-Produkt?

Vor dem Drei-Elemente-Test steht eine andere Frage: Gibt es überhaupt ein Produkt mit digitalen Elementen im Sinne von Art. 3 Nr. 1 CRA? Der Test entscheidet nicht, ob der CRA anwendbar ist. Er bestimmt nur, wie weit die Regulierung von einem bereits feststehenden Produkt aus in die Cloud hineinreicht. Ausgangspunkt ist ein auf dem Unionsmarkt bereitgestelltes Software- oder Hardwareprodukt; häufig, aber nicht zwingend, ist dies ein lokaler Client. Nur bei bejahter Vorfrage stellt sich die hier behandelte Anschlussfrage: Wird die dahinterliegende Server-Verarbeitung als RDPS in die Produktpflichten einbezogen?

Drei Elemente, zwei entscheidende Fragen

Die Kommission zerlegt die RDPS-Prüfung in drei Elemente, die sich aus der Legaldefinition in Art. 3 Nr. 2 CRA ergeben (Rn. 184):

  1. Findet die Datenverarbeitung „auf Distanz“ (at a distance) statt?
  2. Würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausführt?
  3. Wurde die Software vom Hersteller des Produkts konzipiert und entwickelt — oder unter dessen Verantwortung?

Hinweis zur Reihenfolge: Die Kommission ordnet die drei Tatbestandsmerkmale um. Der Wortlaut von Art. 3 Nr. 2 CRA selbst listet sie in der Reihenfolge Distanz → Hersteller → Funktion auf. Die Kommission prüft in Rn. 184 und in der Gliederung der Abschnitte 8.1.1–8.1.3 die Funktion vor der Herstellerverantwortung, ohne dies zu begründen. Didaktisch hat das den Vorteil, dass die inhaltliche Hürde vor der Verantwortungszurechnung steht. Die rechtsdogmatische Substanz bleibt identisch — der Verordnungstext und die Kommissions-Guidance prüfen dieselben drei Voraussetzungen. Wir folgen in diesem Artikel der Kommissionsreihenfolge.

Die drei Elemente haben in der Prüfung nicht dasselbe Gewicht. Element 1 — die Distanz — bezeichnet die Kommission in Rn. 185 als „relevant, aber nicht hinreichend“. Für sich allein begründet die Distanz also keine RDPS; Element 2 und 3 müssen hinzukommen. Entbehrlich ist sie deshalb keineswegs. Vielmehr handelt es sich um eine notwendige Voraussetzung und damit um ein echtes Ausschlusskriterium: Fehlt die Distanz, scheidet eine RDPS aus, ohne dass Element 2 und 3 noch geprüft werden müssten. Eine abschliessende Definition von „auf Distanz“ hält die Kommission angesichts der Vielfalt möglicher Konstellationen zugleich für unmöglich. Es bleibt bei der Einzelfallbeurteilung.

Die eigentliche Prüfungsarbeit liegt in Element 2 und Element 3. Die Kommission formuliert es in Rn. 188 unmissverständlich: Nur wenn beide Fragen bejaht werden, liegt eine RDPS vor. Es handelt sich also um einen kumulativen Zwei-Fragen-Test auf der Grundlage der notwendigen Vorbedingung Distanz — nicht um eine streng sequenzielle Dreier-Kaskade.

Element 1: Datenverarbeitung „auf Distanz“

Die Kommission nutzt den Begriff „auf Distanz“ bewusst weit (Rn. 186). Erwägungsgrund 11 des CRA unterscheidet zwischen Daten, die „lokal auf dem Gerät des Nutzers verarbeitet oder gespeichert“ werden, und solchen, die „aus der Ferne durch den Hersteller verarbeitet oder gespeichert“ werden. Datenfernverarbeitung findet typischerweise ausserhalb der Betriebsumgebung des Nutzers statt — sei es in der Cloud, im Rechenzentrum des Herstellers oder bei einem Dienstleister.

Wichtig dabei: Eine RDPS muss nicht auf der Cloud-Infrastruktur eines Drittanbieters laufen. Die Kommission stellt in Rn. 187 ausdrücklich klar, dass auch eine Verarbeitung auf den eigenen lokalen Servern des Herstellers eine RDPS sein kann. Eine Lösung, die der Hersteller in seinem eigenen Rechenzentrum und auf einer Private Cloud betreibt, qualifiziert ebenso als RDPS wie eine Lösung auf einer Public Cloud bei einem externen Anbieter — der Betriebsort entscheidet nicht.

Worauf es für die „Distanz“ ankommt, ist deshalb nicht, wem die Server gehören, sondern ein einziger Bezugspunkt: die Betriebsumgebung des Nutzers. Datenfernverarbeitung liegt vor, wenn die Verarbeitung ausserhalb dieser Umgebung stattfindet (Rn. 186) — gleichviel, ob die Server dem Hersteller, einem Cloud-Anbieter oder einem sonstigen Dienstleister gehören. Verarbeitung auf den Servern des Herstellers und Verarbeitung bei einem Drittanbieter sind also beide „auf Distanz“; die Eigentümer- und Entwicklerfrage gehört nicht zu Element 1, sondern zu Element 3. Die Kehrseite folgt aus der Definition selbst: Art. 3 Nr. 2 CRA macht die entfernt stattfindende Verarbeitung zum konstitutiven Tatbestandsmerkmal, und Rn. 186 misst „entfernt“ an der Umgebung des Nutzers — beim professionellen Nutzer einschliesslich seiner eigenen betrieblichen Umgebung. Läuft die Software innerhalb dieser Umgebung — etwa eine Lösung, die der Kunde auf seinen eigenen Servern in seiner eigenen Betriebsumgebung installiert und betreibt —, fehlt in aller Regel die Distanz; die überlassene Software ist dann aber selbst Teil des in Verkehr gebrachten Produkts und unterliegt als solche dem CRA.

„Keine RDPS“ bedeutet dabei aber nicht „kein CRA“. Erwägungsgrund 11 CRA stellt ausdrücklich klar, dass Produkte „in ihrer Gesamtheit“ von ihren Herstellern angemessen gesichert werden sollen — „unabhängig davon, ob die Daten lokal auf dem Gerät des Nutzers oder aus der Ferne durch den Hersteller verarbeitet oder gespeichert werden“. Software, die der Hersteller zur Installation beim Kunden in Verkehr bringt, ist selbst ein Produkt mit digitalen Elementen (Art. 3 Nr. 1 CRA) und unterliegt dem CRA unmittelbar als Produkt. Die RDPS-Konstruktion des Art. 3 Nr. 2 CRA ist nur der Brückenkopf für die ferne Verarbeitung; die lokale Verarbeitung braucht diese Brücke nicht, weil sie bereits das Produkt selbst ist.

Ebenso wenig schliesst Edge Computing eine RDPS-Qualifikation aus: Auch Verarbeitung „nahe am Gerät“ kann „auf Distanz“ stattfinden (Rn. 186).

Element 2: Verhindert das Fehlen eine Funktion des Produkts?

Beim zweiten Element beginnt die eigentliche Sachprüfung. Den Begriff „Funktionen“ versteht die Kommission bewusst weit. Diese Klarstellung prägt den gesamten Test.

Der Gesetzeswortlaut verlangt eine Verarbeitung, „ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte“. Die Kommission betont (Rn. 189): Dieser Begriff ist nicht auf die Kernfunktionalität oder den bestimmungsgemässen Zweck des Produkts beschränkt. Der CRA kennt eine solche Einschränkung nicht. Erfasst sind sowohl Funktionen, die den Hauptzweck des Produkts unmittelbar erfüllen, als auch solche, die die Gesamtleistung des Produkts unterstützen.

Die Kommission listet in Rn. 190 konkrete Beispiele für Funktionen auf, deren Fehlen eine RDPS-Qualifikation begründen kann:

  • Senden von Steuerbefehlen an ein Gerät
  • Synchronisierung von Dateien
  • Onboarding des Nutzers
  • Konfiguration und Personalisierung des Produkts
  • Automatisierte Verteilung von Updates, einschliesslich Feature-Updates und Sicherheitspatches
  • Identitäts- und Zugriffsverwaltung

Damit ist auch die eingangs gestellte Frage nach dem optionalen Cloud-Sync beantwortet: Die Synchronisierung von Dateien ist eine Funktion im Sinne des Tests (Rn. 190); dass sich dieselbe Funktion auch lokal ausführen lässt, schliesst die RDPS-Qualifikation nicht aus (Rn. 191).

Die Erwähnung von Updates ist bemerkenswert: Ein Produkt, das seinen Update-Mechanismus über einen Server des Herstellers abwickelt, kann allein dadurch eine RDPS-Komponente haben — wenn das Fehlen dieses Mechanismus verhindert, dass das Produkt Sicherheits- oder Funktionsupdates erhält. Nicht dazu gehören nach Rn. 182 die interne Build- und Auslieferungskette (CI/CD) und die Verteilung von Sicherheitsupdates an Edge-Standorte (etwa Knoten eines Content-Delivery-Netzes). Nach unserer Lesart von Rn. 205 kommt als RDPS nur der Dienst in Betracht, mit dem das Produkt für Update-Abfrage und -Auslieferung unmittelbar interagiert; die Guidance grenzt beides nicht ausdrücklich ab.

Umgekehrt gibt es eine klare Ausschlussregel (Rn. 192): Datenverarbeitung, die nicht dazu dient, eine Produktfunktion zu erfüllen, ist keine RDPS. Das betrifft insbesondere die rein statistische Analyse von Telemetriedaten oder die Verarbeitung von Nutzungsdaten für zukünftige Produktentwicklung.

Auch hier lässt die Kommission den Hersteller nicht vollständig aus der Verantwortung: Selbst wenn eine Datenverarbeitung keine Produktfunktion trägt, muss der Hersteller aufgrund von Art. 13 Abs. 2 CRA die von der Datenverbindung ausgehenden Cyberrisiken in seiner Cybersicherheits-Risikobewertung berücksichtigen und gegebenenfalls durch produktseitige Massnahmen mindern [2, Art. 13 Abs. 2; 1, Rn. 193].

Auch das Thema Websites wird adressiert (Rn. 194): Eine reine Informationswebsite zum Produkt ist keine RDPS — auch dann nicht, wenn das Produkt auf diese Website verweist. Aber eine Website, die eine Produktfunktion ermöglicht oder unterstützt — zum Beispiel ein Authentifizierungsportal, das Zugangsdaten oder Tokens für den Betrieb des Produkts bereitstellt — kann RDPS sein (sofern auch die übrigen Kriterien der Definition erfüllt sind).

Ein weiterer praxisrelevanter Hinweis (Rn. 191): Auch wenn eine Funktion sowohl lokal als auch ferngesteuert ausgeführt werden kann (z. B. eine smarte Glühbirne, die per App und per Schalter bedienbar ist), schliesst die Möglichkeit der lokalen Nutzung die RDPS-Qualifikation nicht aus. Die Remote-Funktionalität bleibt eine Funktion, die das Produkt anbietet.

Element 3: Vom Hersteller konzipiert und entwickelt?

Die dritte Frage zielt auf die Verantwortlichkeit. Die Guidance präzisiert in Rn. 195 den Begriff „unter der Verantwortung“: Erfasst sind Datenfernverarbeitungslösungen, die massgeschneidert für den Hersteller sind. Es reicht nicht aus, lediglich ein bestehendes Produkt eines Drittanbieters zu lizenzieren, das der Anbieter auch anderen Kunden zur Verfügung stellt, oder eine geringfügig angepasste Version davon zu nutzen. Rn. 195 legt dafür in der veröffentlichten Annex-Fassung folgende Kriterien an:

  • Die Software ist massgeschneidert („tailor-made“) für den Hersteller.
  • Sie wird ausschliesslich vom Hersteller selbst oder in dessen Auftrag entwickelt.
  • Sie basiert auf den vom Hersteller vorgegebenen Spezifikationen und Designs.

Hinweis zur Quellenentwicklung: Der Entwurf vom 3. März 2026 hatte an dieser Stelle (dort Rn. 179) noch ein viertes Kriterium genannt — den eigentumsrechtlichen Erwerb der Technologie durch den Hersteller im Gegensatz zu blosser Lizenzierung. Die veröffentlichte Annex-Fassung (Rn. 195) enthält dieses Eigentums-/Lizenzkriterium nicht mehr; sie beschränkt sich auf die drei oben genannten, kumulativ zu lesenden Kriterien. Für die Praxis ändert das wenig an der entscheidenden Trennlinie: massgeschneiderte Auftragsentwicklung nach Vorgaben des Herstellers einerseits, Lizenzierung eines am Markt angebotenen Standardprodukts andererseits — nur eben ohne die (in der Praxis ohnehin schwer nachweisbare) Eigentumsfrage als eigenständiges Prüfkriterium.

Auf dieser Grundlage differenziert die Kommission zwischen verschiedenen Cloud-Servicemodellen (Rn. 197–200):

Infrastructure as a Service (IaaS): Der Hersteller betreibt eigene Software auf der Infrastruktur eines Cloud-Anbieters (z. B. AWS, Azure). Die Software ist vom Hersteller konzipiert und entwickelt — sie kann als RDPS qualifizieren, wenn die übrigen Elemente erfüllt sind (Rn. 198). Dass die Infrastruktur von einem Dritten stammt, ist unerheblich.

Platform as a Service (PaaS): Der Hersteller entwickelt eine eigene Anwendung auf der Plattform eines Drittanbieters. Da der Hersteller die Kontrolle über die Anwendung hat, gilt sie als unter seiner Verantwortung konzipiert und entwickelt — sie kann als RDPS qualifizieren (Rn. 199).

Software as a Service (SaaS) von Drittanbietern: Hier bietet ein SaaS-Anbieter eine fertige Anwendung an, die der Hersteller in sein Produkt integriert. Der Hersteller hat nur begrenzten Einfluss auf die Konfiguration. Die Anwendung ist nicht vom Hersteller konzipiert und entwickelt — sie ist daher keine RDPS (Rn. 200). Eine Drittanbieter-SaaS könnte nur dann unter die Herstellerverantwortung fallen, wenn sie nach den drei oben genannten Kriterien tatsächlich massgeschneidert für den Hersteller entwickelt wurde — also faktisch eine Auftragsentwicklung in fremder Betriebsumgebung. Standardisierte Mehrmandanten-SaaS, die der Anbieter beliebigen Kunden anbietet, etwa Zahlungs-, Identitäts- oder Speicherdienste, fallen danach regelmässig nicht darunter.

Für die RDPS-Qualifikation kommt es nach Rn. 196 nicht darauf an, wer die Lösung betreibt (operates). Gefragt wird vielmehr, wer sie konzipiert und entwickelt hat. Ein Hersteller bleibt daher Entwickler seiner Server-Software, wenn AWS lediglich deren Betrieb übernimmt.

Wo endet die RDPS im Systemverbund?

Die Guidance ergänzt in Rn. 205–206 einen eigenständigen Abgrenzungsgrundsatz, der über den Zwei-Fragen-Test hinausgeht und für die Praxisbeispiele im nächsten Abschnitt wichtig ist: Die RDPS, die Teil des Produkts sind und damit dessen Konformitätsbewertung unterliegen, beschränken sich auf diejenigen Softwaremodule, die für die Funktion des Produkts verantwortlich sind, sowie auf die Schnittstellen, über die diese Module mit externen Diensten kommunizieren (Rn. 205). Weitere, nachgelagerte Backend-Systeme, die die Verarbeitung fortsetzen und mit denen das Produkt nicht direkt interagiert, gelten nicht als RDPS.

Aus der Verantwortung des Herstellers verschwinden diese nachgelagerten Systeme damit nicht. Sie bleiben externe Abhängigkeiten, sind in der Cybersicherheits-Risikobewertung zu berücksichtigen und durch produktseitige Massnahmen abzusichern (Rn. 206). So erklärt sich auch das Banking-Beispiel weiter unten: Kontoverwaltungs- und Ledger-System der Bank sind keine RDPS, obwohl sie zur selben Systemlandschaft gehören wie die Banking-Schnittstelle, mit der die App direkt kommuniziert.

Die drei Ergebnisse des Tests

Die Kommission definiert in Rn. 202 drei mögliche Ergebnisse — und das ist eine weitere wichtige Klarstellung, die über ein schlichtes „ja/nein“ hinausgeht:

Alle drei Ergebnisse setzen voraus, dass die Verarbeitung auf Distanz stattfindet (Element 1); unterschieden wird nur danach, wie Element 2 und Element 3 ausfallen. Fehlt schon die Distanz, liegt keine Datenfernverarbeitung im Sinne des Tests vor.

Ergebnis A — Element 2 und 3 bejaht: Die Datenverarbeitung qualifiziert als RDPS. Sie muss in die Cybersicherheits-Risikobewertung einbezogen werden, die Software-Stückliste (englisch software bill of materials, SBOM) muss nach unserer Auffassung auch die Softwarekomponenten der RDPS erfassen, weil diese Teil des Produkts ist (Art. 3 Nr. 1 i. V. m. Anhang I Teil II Nr. 1 CRA), und die grundlegenden Cybersicherheitsanforderungen des Anhangs I gelten für das Gesamtprodukt.

Ergebnis B — Element 2 bejaht, Element 3 verneint: Die Drittanbieter-Lösung ist funktional notwendig, wurde aber nicht vom Hersteller entwickelt. In diesem Fall ist sie keine RDPS — regulatorisch irrelevant ist sie aber nicht. Aus dem CRA selbst folgt, dass der Hersteller die von ihr ausgehenden Risiken in seiner Risikobewertung berücksichtigen und am eigenen Produkt beherrschen muss (Art. 13 Abs. 2, Anhang I). Die Guidance erwartet darüber hinaus, dass er die Lösung wie eine Drittanbieter-Komponente behandelt (Rn. 201, 202 lit. c). Das bedeutet konkret:

  • Risikobewertung nach Art. 13 Abs. 2 CRA: Die von der Drittanbieter-Lösung ausgehenden Risiken müssen in die produktbezogene Cybersicherheits-Risikobewertung einfliessen — insbesondere die Frage, was passiert, wenn der Dienst ausfällt, kompromittiert wird oder seine Sicherheitseigenschaften ändert.
  • Sorgfalt entsprechend Art. 13 Abs. 5 CRA: Die Guidance erwartet bei der Drittanbieter-Lösung eine der Due Diligence nach Art. 13 Abs. 5 entsprechende, risikoproportionale Sorgfalt [1, Rn. 201, 202 lit. c, 207 f.]. Als wiederverwendbare Nachweise nennt Rn. 207 unter anderem Nachweise nach der Durchführungsverordnung (EU) 2024/2690 oder DORA, Zertifikate nach dem Cybersecurity Act sowie ISO/IEC 27017 beziehungsweise 27001.
  • Produktseitige Massnahmen: Risiken aus externen Diensten oder Infrastrukturen, die nicht Teil des Produkts sind, muss der Hersteller nach Rn. 168–169 durch Massnahmen am eigenen Produkt behandeln. Genannt werden beispielsweise kryptografische Authentifizierung entfernter Befehle, Integritätsprüfungen, sicherheitsrelevante Protokolle oder Warnungen sowie ein sicherer Zustand des Produkts bei Ausfall des externen Dienstes.
  • Dokumentation: Die Drittanbieter-Lösung ist in der technischen Dokumentation anzugeben und zu beschreiben [1, Rn. 204]. In die SBOM gehören die im Produkt enthaltenen Client-Bibliotheken, SDKs und sonstigen Softwarekomponenten. Der entfernte Dienst selbst ist mangels Enthaltensein keine SBOM-Komponente; er ist mit Schnittstelle, Funktion und Abhängigkeit in der technischen Dokumentation zu beschreiben [2, Art. 3 Nr. 39, Anhang I Teil II Nr. 1; 1, Rn. 204]. Die SaaS selbst durchläuft keine eigene CRA-Konformitätsbewertung.

Ob daneben insbesondere NIS-2 auf den Dienstanbieter anwendbar ist, muss gesondert geprüft werden.

Ergebnis C — Element 2 verneint: Die Datenverarbeitung dient keiner Produktfunktion (z. B. reine Telemetrie für Nutzungsstatistiken). Sie ist weder RDPS noch Komponente. Liefert der Hersteller dafür eine Telemetrie-Bibliothek im Produkt mit, gehört diese als Softwarebestandteil in die Software-Stückliste (Anhang I Teil II Nr. 1 CRA). Stammt sie von einem Dritten, gilt zusätzlich die Sorgfaltspflicht nach Art. 13 Abs. 5 CRA. Aber auch hier entlässt der CRA den Hersteller nicht vollständig aus der Verantwortung: Er muss die von dieser Datenverbindung ausgehenden Risiken in seiner allgemeinen Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2 CRA berücksichtigen (Rn. 193). Der Grund: Auch eine nicht-funktionale Datenverbindung kann Angriffsfläche schaffen — etwa wenn ein Telemetrie-Endpunkt kompromittiert wird und als Einfallstor in das Produkt dient.

Element 3 spielt für Ergebnis C keine Rolle. Anders als bei A und B kommt es hier allein auf Element 2 an: Sobald die Funktionsnotwendigkeit verneint ist, steht das Ergebnis fest — die Prüfung erreicht Element 3 (wurde die Software vom Hersteller entwickelt?) gar nicht mehr. Die Kommission bringt das in Rn. 202 ausdrücklich zum Ausdruck: Ergebnis A verlangt die Bejahung beider entscheidenden Fragen, Ergebnis B die Bejahung der Funktionsfrage bei verneinter Herstellerfrage — Ergebnis C dagegen knüpft allein an die verneinte Funktionsfrage an; die Herstellerfrage wird in der Beschreibung von Ergebnis C (Rn. 202 lit. b) nicht mehr genannt. Die praktische Folge: Kategorie C umfasst beide Konstellationen — herstellereigene nicht-funktionale Datenverbindungen ebenso wie solche von Drittanbietern, etwa Webanalyse- oder Crash-Reporting-Dienste.

Die drei Stufen im Überblick

Für die Fernverarbeitung kennt die Kommissions-Guidance kein binäres „CRA-pflichtig oder nicht“. Sie unterscheidet drei Ergebnisse:

| Ergebnis | Einstufung | CRA-Pflichten hinsichtlich der Fernverarbeitung | |----------|-----------|---------------| | A (Element 2 + 3 bejaht) | RDPS | Volle CRA-Compliance: Anhang I, SBOM mit RDPS-Abdeckung, Schwachstellenmanagement, Konformitätsbewertung für das Gesamtprodukt inkl. Server-Komponente | | B (Element 2 bejaht, Element 3 verneint) | Drittanbieter-Ferndienst, keine RDPS | Risikobewertung (Art. 13 Abs. 2), nach der Guidance Sorgfalt entsprechend Art. 13 Abs. 5, produktseitige Sicherheitsmassnahmen, technische Dokumentation und SBOM-Eintrag tatsächlich eingebundener Client-Komponenten | | C (Element 2 verneint) | Weder RDPS noch Komponente | Berücksichtigung in der allgemeinen Risikobewertung (Art. 13 Abs. 2) |

Die Stufen betreffen allein die Einordnung der Fernverarbeitung; das lokale Produkt selbst unterliegt in allen drei Fällen uneingeschränkt dem CRA.

Outsourcing an einen SaaS-Anbieter oder die Verlagerung in die Cloud lässt die regulatorische Verantwortung deshalb nicht einfach verschwinden.

Konkrete Beispiele für die Ergebnisse A, B und C

Wie unterschiedlich diese Ergebnisse aussehen können, zeigen je drei Beispiele aus der Praxis:

Ergebnis A — RDPS (volle CRA-Pflicht):

  • Eine Smart-Türschloss-App, deren Fernöffnung und Vergabe von Zugriffsrechten aus der Ferne über eine vom Hersteller entwickelte Cloud laufen. Auch wenn das Schloss zusätzlich lokal per Bluetooth bedienbar ist, trägt die Cloud eine eigene Produktfunktion [1, Rn. 191].
  • Eine Banking-App einer konkreten Bank mit deren eigener Banking-Schnittstelle, die die Authentifizierung und die Anbahnung der Transaktionen abwickelt (Primärbeispiel der Kommission, Abschnitt 8.3.1). Das Kontoverwaltungs- und Ledger-System der Bank, das nicht direkt mit der App kommuniziert, ist nach Abschnitt 8.3.1 selbst keine RDPS — bleibt aber eine externe Abhängigkeit für die Risikobewertung.
  • Eine Plattform für elektronische Signaturen, deren Desktop-Plugin nur mit dem herstellereigenen Signaturserver funktioniert.

Ergebnis B — Drittanbieter-Ferndienst, keine RDPS:

  • Eine Branchensoftware, die für die Anmeldung einen standardisierten Identitätsdienst eines Drittanbieters nutzt — die Authentifizierung ist produktnotwendig, der Identitätsdienst aber ein Standard-Drittprodukt.
  • Eine E-Reader-Software, die gekaufte Bücher bei einem SaaS-Speicherdienst eines Drittanbieters ablegt und abrufbar macht (Beispiel der Kommission, Abschnitt 8.3.3).
  • Eine Fuhrpark- oder Logistik-App mit lokalem Smartphone-Client, die für die Routenführung auf einen Karten- und Navigationsdienst eines Drittanbieters zugreift. Ohne den Kartendienst kann die App diese Funktion nicht ausführen — er ist also funktional notwendig, aber als Standardprodukt des Drittanbieters nicht vom Hersteller entwickelt.

Ergebnis C — nur Risikobewertung:

  • Software, die Absturzberichte an einen Crash-Reporting-Dienst schickt, damit der Hersteller Fehler analysieren kann — nicht produktfunktional.
  • Software mit Integration eines Webanalyse-Dienstes zur reinen Nutzungsstatistik.
  • Hersteller-Telemetrie, mit der Nutzungsdaten zur Produktverbesserung gesammelt werden.

Bei fast jedem nicht-trivialen Produkt finden sich mehrere Ergebnisse nebeneinander. Eine Banking-App erreicht A für die Banking-Schnittstelle, B für einen integrierten Drittanbieter-Ferndienst — etwa eine Identitätsprüfung beim Onboarding — und C für das Crash-Reporting. Der Drei-Elemente-Test wird so zu einer differenzierten Inventur der Datenströme.

Fünf Praxisbeispiele aus der Guidance

Die Kommission selbst illustriert den Test in Abschnitt 8.3 an fünf Szenarien. Wir stellen sie im Folgenden alle fünf vor:

Beispiel 1: Banking-App mit zwei Datenströmen (Abschnitt 8.3.1). Das Kommissionsszenario zeigt eine Banking-App mit zwei verschiedenen Datenströmen — und damit zugleich, dass ein einziges Produkt mehrere Ergebnisse nebeneinander tragen kann.

Datenstrom 1 — selbst entwickelte Banking-Schnittstelle für Transaktionen. Die Banking-Schnittstelle wurde vom Finanzinstitut selbst entwickelt und selbst betrieben; sie authentifiziert den Kunden und wickelt die Transaktionen ab.

  • Element 1 (Distanz): erfüllt — die Verarbeitung läuft auf den Servern des Instituts, ausserhalb des Geräts.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die Banking-Schnittstelle kann die App ihre Kernfunktion, die Abwicklung von Transaktionen, nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Schnittstelle wurde vom Finanzinstitut selbst konzipiert und entwickelt.

Ergebnis: Die Banking-Schnittstelle ist RDPS und in die CRA-Pflichten des Gesamtprodukts einbezogen. Das Kontoverwaltungs- und das Ledger-System hingegen sind logisch getrennt und interagieren nicht direkt mit der App — sie sind keine RDPS (vgl. den Abgrenzungsgrundsatz aus Rn. 205–206 oben), bleiben aber externe Abhängigkeiten, deren Risiken (etwa eine Manipulation von Transaktionsergebnissen) in die Risikobewertung einfliessen und durch produktseitige Massnahmen abzusichern sind.

Datenstrom 2 — Drittanbieter-SaaS für den Support-Chat. Für die Kundenbetreuung integriert das Institut eine Chat-Lösung, die ein Drittanbieter entwickelt, gestaltet und betreibt (SaaS-Modell).

  • Element 1 (Distanz): erfüllt — der Chat läuft auf der Infrastruktur des Drittanbieters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — die Kommission ordnet den Support-Chat ausdrücklich einer Funktion des Produkts zu.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt — die Chat-Software stammt vollständig vom Drittanbieter.

Ergebnis: Keine RDPS; die Guidance erwartet aber eine Behandlung wie eine Drittanbieter-Komponente — mit risikoproportionaler Sorgfalt und produktseitigen Massnahmen wie der Abschottung des Chats von den Kern-Bankfunktionen, der Kontrolle der Datenflüsse und der Validierung von Inhalten.

Schon dieses eine Beispiel umfasst somit drei unterschiedliche Konstellationen: eine RDPS (Banking-Schnittstelle), eine Drittanbieter-Komponente (Support-Chat) und externe Abhängigkeiten ohne eigenen RDPS-Charakter (Kontoverwaltungs- und Ledger-System). Solche Mischbilder prägen die Praxis.

Beispiel 2: Smart-Thermostat mit Cloud (Abschnitt 8.3.2). Ein Smart-Thermostat-Hersteller lässt die Steuerungssoftware, über die die mobile App und der Thermostat Daten austauschen und speichern, auf einer IaaS-Infrastruktur eines Drittanbieters laufen.

  • Element 1 (Distanz): erfüllt — die Verarbeitung findet in der Cloud statt, ausserhalb des Geräts.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die ferne Verarbeitung kann der Thermostat seine smarten Funktionen, etwa die Temperatursteuerung per App, nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Steuerungssoftware wurde vom Hersteller konzipiert und entwickelt; dass sie auf fremder IaaS läuft, ist unerheblich.

Ergebnis: RDPS. Der Hersteller muss die RDPS und die Abhängigkeit von der Drittanbieter-IaaS in der technischen Dokumentation und der Risikobewertung erfassen.

Beispiel 3: E-Reader-Software mit Drittanbieter-Speicher (Abschnitt 8.3.3). Eine E-Reader-Software nutzt einen SaaS-Speicherdienst eines Drittanbieters, um die gekauften Bücher der Kunden zu speichern und zugänglich zu machen.

  • Element 1 (Distanz): erfüllt — die Speicherung erfolgt auf den Servern des SaaS-Anbieters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den Speicherdienst kann die E-Reader-Software eine ihrer Funktionen nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt — der SaaS-Speicherdienst wurde nicht vom Hersteller konzipiert und entwickelt; der Anbieter stellt ihn beliebigen Kunden für beliebige Zwecke bereit.

Ergebnis: Keine RDPS. Die Guidance erwartet, dass der Hersteller den SaaS-Dienst wie eine Drittanbieter-Komponente behandelt — mit Risikobewertung, risikoproportionaler Sorgfalt und produktseitigen Sicherheitsmassnahmen wie sicherer Authentifizierung, Verschlüsselung und Integritätsschutz der Kommunikation.

Beispiel 4: Industrieroboter mit kamerabasierter Teileerkennung (Abschnitt 8.3.4). Ein Industrieroboter hat die Aufgabe, Teile aufzunehmen. Er sendet über Kameras erfasste Bilddaten an einen vom Hersteller konzipierten und entwickelten Remote-Dienst, der auf der IaaS-Infrastruktur eines Drittanbieters läuft. Der Cloud-Dienst berechnet anhand der Kamerabilder die Position eines Teils und sendet Befehle an den Roboter zurück, damit dieser das Teil aufnehmen kann.

  • Element 1 (Distanz): erfüllt — die Bildverarbeitung findet auf der Cloud-Infrastruktur statt, ausserhalb des Roboters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne diese Verarbeitung kann der Roboter keine Teile aufnehmen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Software wurde vom Hersteller entwickelt; dass sie auf der IaaS eines Drittanbieters läuft, ist unerheblich (vgl. Element 3 und die IaaS-Fallgruppe oben).

Ergebnis: RDPS. Der Hersteller muss die RDPS sowie die Abhängigkeit von der Dritt-IaaS in der technischen Dokumentation erfassen und bei der Auswahl des IaaS-Anbieters Sorgfalt ausüben — etwa durch Nachweise, dass der Anbieter seine NIS-2-Pflichten erfüllt (Abschnitt 8.3.4; vgl. Rn. 207). Für Hersteller aus dem Maschinen- und Anlagenbau ist dieses Beispiel besonders anschlussfähig, weil sich bei solchen Produkten parallel die Fragen der Maschinenverordnung stellen.

Beispiel 5: Smartphone mit Mobilfunknetz (Abschnitt 8.3.5). Ein Smartphone benötigt ein Mobilfunknetz (z. B. 5G) für Internet, Telefonie und Nachrichten. Die Kommission stellt klar: Das Netz ist kein RDPS. Entlang der drei Elemente wird deutlich, warum:

  • Element 1 (Distanz): wäre erfüllt — die Netzverarbeitung findet ausserhalb des Geräts statt. Damit ist aber nur die notwendige Vorbedingung erfüllt; ob eine RDPS vorliegt, entscheidet sich an Element 2 und 3.
  • Element 2 (Funktionsnotwendigkeit): nicht erfüllt. Das Netz ist ein blosser Kommunikationskanal, kein vom Produkt benötigter Verarbeitungsdienst. Sein Fehlen hindert das Smartphone nicht daran, die Funktion „sich korrekt mit einem Netz verbinden“ auszuführen — das Gerät arbeitet korrekt, es hat lediglich keine Verbindung.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt. Das Mobilfunknetz wird von den Telekommunikationsbetreibern konzipiert, entwickelt und betrieben — nicht vom Smartphone-Hersteller. Art. 3 Nr. 2 CRA verlangt aber Software, die der Hersteller des Produkts selbst entwickelt oder verantwortet.

Ergebnis: Da der Test kumulativ Element 2 und 3 verlangt und hier beide fehlen, liegt keine RDPS vor. Das Netz ist auch keine Drittanbieter-Komponente — es ist keine Software in das Produkt integriert, das Produkt nutzt das Netz lediglich. Es besteht daher keine Due-Diligence-Pflicht gegenüber dem Netzbetreiber. Gleiches gilt für Ethernet-Kabel, Router und WLAN.

Was der Test nicht klärt

So hilfreich die Guidance als Orientierungshilfe ist — einige Konstellationen bleiben offen.

Browser-Erweiterungen: Die eingangs gestellte Frage beantwortet die Guidance ausdrücklich: Eine Browser-Erweiterung, die dem Nutzer geliefert wird und auf seinem Gerät läuft, ist ein Produkt mit digitalen Elementen [1, Rn. 20].

Progressive Web Apps (PWAs): Die Guidance behandelt PWAs ausdrücklich: Werden sie ausschliesslich über einen Browser genutzt, sind sie kein Produkt mit digitalen Elementen [1, Rn. 21]. Anders liegt es bei Anwendungen in Web-Technik, die zur lokalen Ausführung geliefert werden, etwa als installierbares Desktop-Paket [1, Rn. 20, Beispiel 4]. Bei PWAs, die zwar über einen Browser „installiert“ werden, aber weiterhin in dessen Laufzeitumgebung arbeiten, ist daher nicht das Installationslabel, sondern die konkrete Bereitstellung und Ausführung entscheidend.

Optionale Komponenten: Wenn ein Produkt eine lokale Komponente anbietet, die nur ein Teil der Kunden nutzt — wird das gesamte Produkt CRA-pflichtig? Die Guidance geht auf diesen Fall nicht direkt ein. Die Definition in Art. 3 Nr. 1 CRA stellt allerdings auf das Produkt ab, das auf dem Markt bereitgestellt wird — nicht auf die individuelle Nutzung durch einzelne Kunden.

Telemetrie-Grauzone: Rn. 192 schliesst rein statistische Telemetrie von der RDPS-Qualifikation aus. Aber was ist mit Telemetrie, die indirekt eine Produktfunktion ermöglicht — etwa wenn Nutzungsdaten zur Personalisierung des Produkterlebnisses verwendet werden? Hier bleibt Interpretationsspielraum.

Auch die veröffentlichte Annex-Fassung beantwortet die übrigen Punkte nicht abschliessend. Konkretere Linien dürften sich erst aus nachfolgenden Leitlinien oder aus der Praxis der Marktüberwachungsbehörden entwickeln. Bis dahin empfiehlt sich eine vorsichtige Einordnung: Im Zweifel ist die konkrete Bereitstellungs- und Funktionsweise vertieft zu prüfen. Typische Grenzfälle analysiert Teil 4 dieser Serie.

Der strategische Blick

Für Softwareunternehmen in Deutschland und der Schweiz reicht die Bedeutung des Tests über die reine Compliance hinaus.

Zunächst schafft eine sauber dokumentierte Prüfung Planungssicherheit. Führt sie zu einem klaren Ergebnis, lässt sich die Compliance-Strategie auf einer belastbaren Grundlage aufbauen — sei es als Vorbereitung auf den CRA oder mit Blick auf NIS-2.

Zugleich werden regulatorische Folgen von Architekturentscheidungen sichtbar. Ob eine Funktion lokal oder serverseitig implementiert wird, ist nicht länger nur eine technische Entscheidung. Es ist auch eine Compliance-Entscheidung. Dasselbe gilt, besonders bei Element 3, für die Wahl zwischen Eigenentwicklung und SaaS-Integration.

Und schliesslich zeigen die Ergebnisse B und C, dass Server-Kommunikation auch ohne RDPS regulatorisch relevant sein kann. In Produkten mit vielen Drittanbieter-Ferndiensten wird deshalb die von der Guidance erwartete, risikoproportionale Sorgfalt entsprechend Art. 13 Abs. 5 CRA zu einem zentralen Compliance-Thema.

Das Wichtigste für Hersteller

  • Der Drei-Elemente-Test setzt ein bereitgestelltes Produkt voraus. Er klärt nicht, ob der CRA anwendbar ist, sondern wie weit er von diesem Produkt aus in die Cloud hineinreicht.
  • Eine Datenfernverarbeitungslösung liegt vor, wenn die Verarbeitung auf Distanz stattfindet, ihr Fehlen eine Funktion des Produkts verhindern würde und die Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde. „Funktion“ ist weit zu verstehen und umfasst etwa Updates, Synchronisierung und Identitätsverwaltung.
  • Wo die Software betrieben wird, ist unerheblich: Eigene Rechenzentren kommen ebenso in Betracht wie fremde IaaS- oder PaaS-Infrastruktur. Standardisierte Drittanbieter-SaaS ist dagegen keine RDPS.
  • Auch ohne RDPS bleiben Pflichten: Funktional notwendige Drittanbieter-Ferndienste und nicht funktionale Verbindungen sind in der Risikobewertung nach Art. 13 Abs. 2 zu berücksichtigen; für Drittanbieter-Ferndienste erwartet die Guidance zusätzlich eine Sorgfalt entsprechend Art. 13 Abs. 5.
  • Meist liegen in einem Produkt mehrere Ergebnisse nebeneinander vor. Sinnvoll ist deshalb eine Inventur aller Datenströme.

Fällt Ihr Produkt überhaupt unter den CRA? Der CRA-Quick-Check liefert eine kostenlose und unverbindliche Ersteinschätzung zur CRA-Anwendbarkeit, Produktklasse, CRA-Bereitschaft und möglichen Abdeckung durch crAIready. Für die Einordnung einzelner Datenströme nach dem Drei-Elemente-Test bleibt eine individuelle Prüfung erforderlich.

Hinweis zur Methodik

Dieser Artikel basiert auf der Analyse der am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichten Guidance (gut 80 Seiten), insbesondere auf Kapitel 7.3 (Rn. 167–173) und Kapitel 8 (Rn. 178–208), sowie auf dem Verordnungstext (EU) 2024/2847; für die Kommentarliteratur ergänzend auf den artikelweisen Kommentar von Schröder/Hartl [4]. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten. Die zuvor noch nach dem Entwurf zitierten Sorgfalts- und Produktmassnahmen sind anhand der veröffentlichten Fassung aktualisiert.

Quellen

[1] 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. Abschnitt 2.2 (Rn. 19–21), Kapitel 7.3 (Rn. 167–173) und 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).

[2] 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), insbesondere Art. 3 Nr. 1 (Definition: Produkt mit digitalen Elementen), Nr. 2 (Definition: Datenfernverarbeitung) und Nr. 39 (SBOM), Art. 13 Abs. 2 und 5, Anhang I Teil II Nr. 1 sowie Erwägungsgrund 11. ABl. L, 20.11.2024. Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[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), insbesondere Art. 2 und 3 sowie Anhang I Nr. 8 und 9 zu Cloud-Computing- und Rechenzentrumsdiensten. ABl. L 333 vom 27.12.2022. Verfügbar unter: https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[4] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Poncza, Art. 3 Rn. 135; Hofmann, Art. 3 Rn. 15.

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 23.03.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: Kein RDPS, trotzdem CRA-pflichtig? Die Pflichten nach Art. 13 — was Hersteller bei Risikobewertung, Sorgfalt und produktseitigen Sicherheitsmassnahmen konkret leisten müssen, auch wenn keine RDPS vorliegt.