Der Drei-Elemente-Test der EU-Kommission: So prüfen Sie, ob Ihre Remote-Datenverarbeitung unter den CRA fällt

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. Für unsere Auswertung tritt sie an die Stelle des Entwurfs Ares(2026)2319816 vom 3. März 2026 [1]. Wir lesen den Test entlang der Quelle und wenden ihn auf konkrete Produktarchitekturen an.

Warum ein Test nötig wurde

Im ersten Teil dieser Serie haben wir die grundlegende Abgrenzung dargestellt: Der CRA erfasst „Produkte mit digitalen Elementen“ einschliesslich ihrer Datenfernverarbeitungslösungen (Remote Data Processing Solutions, RDPS) [2]. Reine Cloud-Dienste ohne lokale Produktkomponente fallen nicht unter den CRA, sondern unter die NIS-2-Richtlinie [5], sofern der Anbieter die dort definierten Schwellenwerte erreicht.

Zur Einordnung hilft ein kurzer Rückblick auf die ersten beiden Serienteile. Der CRA reguliert nicht Software an sich, sondern das Inverkehrbringen von Produkten (Art. 3 Nr. 21 CRA). Eine reine Browser-SaaS besteht technisch zwar aus Software (Art. 3 Nr. 4 CRA), sie wird jedoch nicht an den Nutzer ausgeliefert; dieser ruft beim Anbieter eine laufende Dienstleistung ab. Der Produktsicherheitslogik fehlt damit ihr Anknüpfungspunkt. Solche Dienstleistungen adressiert die EU über NIS-2 [5]. Über Art. 3 Nr. 2 CRA reicht das Produktrecht gleichwohl in die Cloud hinein: Die RDPS-Konstruktion bildet den regulatorischen Brückenkopf, sobald ein lokales Produkt — ein Software- oder Hardwareprodukt im Sinne von Art. 3 Nr. 1 CRA — den Marktzugang eröffnet. Ausführlich hergeleitet ist diese Systematik im Auftaktartikel zu Zweck und Anwendungsbereich des CRA und im ersten Teil dieser Serie zur SaaS-Abgrenzung.

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 rund 70 Seiten starke Dokument umfasst neun nummerierte Kapitel — von der Abgrenzung des Anwendungsbereichs über Open-Source-Software, wesentliche Änderungen und Support-Zeiträume bis zur Datenfernverarbeitung und dem Zusammenspiel mit anderen EU-Rechtsakten. Kapitel 8 widmet sich der Frage, wann Remote-Datenverarbeitung 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 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 stets eine beim Nutzer lokal installierte oder ausgeführte Komponente — etwa Desktop-App, Mobile App, Browser-Plugin, Agent oder SDK. Fehlt sie und liegt lediglich eine Browser-SaaS vor, gibt es kein CRA-Produkt, dem eine Datenfernverarbeitungslösung zugerechnet werden könnte. Der Test läuft dann ins Leere; die Server-Software bleibt eine reine Cloud-Dienstleistung im Anwendungsbereich der NIS-2-Richtlinie. 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 entworfen und entwickelt — oder unter dessen Verantwortung?

Hinweis zur Reihenfolge: Die Kommission ordnet die drei Tatbestandsmerkmale analytisch um. Der Wortlaut von Art. 3 Nr. 2 CRA selbst listet sie in der Reihenfolge Distanz → Hersteller → Funktion auf. Die Kommission zieht in Rn. 184 die Funktionsprüfung vor die Herstellerprüfung, weil das die sachlich klarere Prüfungsreihenfolge ergibt: zuerst wird die substantielle Hürde (Funktion) geprüft, dann die Verantwortungszurechnung (Hersteller). Die rechtsdogmatische Substanz bleibt identisch — der Verordnungstext und die Kommissions-Guidance prüfen dieselben drei Voraussetzungen. Wir folgen in diesem Artikel der Kommissionsreihenfolge, weil sie didaktisch klarer ist.

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.

Wo die eigentliche Prüfungsarbeit liegt, ist 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.

Auch die Kommentarliteratur liest die Definitionsmerkmale des Art. 3 Nr. 2 CRA kumulativ (Wiebe/Jossen, § 4 Rn. 3, 5) [4].

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 werden, und solchen, die „vom Hersteller fernverarbeitet“ werden. Remote-Datenverarbeitung 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. Remote-Datenverarbeitung 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 die Distanz, und eine RDPS scheidet schon an Element 1 aus.

„Keine RDPS“ bedeutet dabei aber nicht „kein CRA“. Erwägungsgrund 11 CRA stellt ausdrücklich klar, dass ein Produkt „in seiner Gesamtheit“ gesichert sein muss — „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 spricht davon, dass das Fehlen der Datenverarbeitung das Produkt daran hindern würde, „eine seiner Funktionen auszuführen.“ 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

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.

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 prüfen, ob die betreffenden Remote-Komponenten Risiken einführen, und diese im Rahmen seiner Cybersicherheits-Risikobewertung berücksichtigen und gegebenenfalls durch produktseitige Massnahmen mindern (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 entworfen und entwickelt?

Die dritte Frage zielt auf die Verantwortlichkeit. Die Guidance präzisiert in Rn. 195 den Begriff „unter der Verantwortung“: Erfasst sind Remote-Datenverarbeitungslö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 im Auftrag des Herstellers oder unter dessen Verantwortung 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 — die eigentumsrechtliche Erwerbung 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 entworfen 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 entworfen 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 entworfen 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. Klassische Multi-Tenant-SaaS wie Stripe, Auth0, Okta, Salesforce oder Dropbox API fallen nie darunter, weil sie als Standardprodukte für viele Kunden vermarktet werden.

Für die RDPS-Qualifikation kommt es nach Rn. 196 nicht darauf an, wer die Lösung betreibt (operates). Gefragt wird vielmehr, wer sie entworfen 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:

Allen drei Ergebnissen ist dabei eines gemeinsam: Element 1 ist erfüllt — die Verarbeitung findet auf Distanz statt. Die drei Ergebnisse klassifizieren ausschliesslich Datenverarbeitung, die diese Vorbedingung bereits erfüllt; unterschieden wird auf dieser Stufe nur noch danach, wie Element 2 und Element 3 ausfallen. Fehlt schon die Distanz, wird keines dieser Ergebnisse erreicht — dann liegt bereits 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 SBOM muss sie abdecken, 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 — aber der Hersteller unterliegt trotzdem konkreten CRA-Pflichten. Er muss die Drittanbieter-Lösung wie eine integrierte Komponente behandeln (Rn. 201 i. V. m. Rn. 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.
• Due Diligence nach Art. 13 Abs. 5 CRA: Der Hersteller muss aktiv prüfen, ob die Drittanbieter-Lösung den Sicherheitsanforderungen genügt. Rn. 170–171 der veröffentlichten Annex-Fassung unterscheiden diese Pflicht von der allgemeinen Risikobewertung und nennen als mögliche Nachweise insbesondere technische Spezifikationen, Sicherheitsdokumentation sowie einschlägige Konformitäts- oder Assurance-Dokumentation des Komponentenherstellers. Soweit angemessen, kann der Hersteller zusätzlich eigene Tests durchführen.
• 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.
• SBOM: Die Drittanbieter-Komponente erscheint in der SBOM des Produkts als oberste Abhängigkeit (Top-Level-Abhängigkeit; Anhang I Teil II Nr. 1 i. V. m. Art. 13 Abs. 24 CRA; BSI TR-03183-2). Die SaaS selbst durchläuft aber keine eigene CRA-Konformitätsbewertung — sie wird nur als Komponente beschrieben.

Wichtig: Diese Pflichten kommen ausschliesslich aus dem CRA — nicht aus der NIS-2-Richtlinie oder einem anderen Gesetz. Der CRA ist herstellerzentriert: Wer ein Produkt auf den EU-Markt bringt, ist für dessen Sicherheit verantwortlich, einschliesslich aller Abhängigkeiten, die er nicht selbst entwickelt hat.

Ergebnis C — Element 2 verneint: Die Datenverarbeitung dient keiner Produktfunktion (z. B. reine Telemetrie für Nutzungsstatistiken). Sie ist weder RDPS noch Komponente. 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 (etwa eigene Nutzungstelemetrie) ebenso wie solche von Drittanbietern (etwa Google Analytics oder ein Crash-Reporting-Dienst).

Die drei Stufen im Überblick

Der CRA kennt also kein binäres „CRA-pflichtig oder nicht“. Stattdessen gibt es drei abgestufte Pflichtniveaus, die alle aus dem CRA selbst stammen:

• Ergebnis A (Element 2 + 3 bejaht) — Einstufung: RDPS. Volle CRA-Compliance: Anhang I, SBOM mit RDPS-Abdeckung, Schwachstellenmanagement, Konformitätsbewertung für das Gesamtprodukt inkl. Server-Komponente.
• Ergebnis B (Element 2 bejaht, Element 3 verneint) — Einstufung: Komponente. Eingeschränkte CRA-Pflichten: Risikobewertung (Art. 13 Abs. 2), Due Diligence (Art. 13 Abs. 5), produktseitige Sicherheitsmassnahmen, SBOM-Eintrag als oberste Abhängigkeit.
• Ergebnis C (Element 2 verneint) — Einstufung: weder RDPS noch Komponente. Minimale CRA-Pflicht: Berücksichtigung in der allgemeinen Risikobewertung (Art. 13 Abs. 2).

Alle drei Stufen setzen dabei Element 1 (Distanz) als erfüllt voraus; sie unterscheiden sich allein darin, wie Element 2 und Element 3 ausfallen.

Auch die Ergebnisse B und C lösen CRA-Pflichten aus; es handelt sich nicht um freiwillige Empfehlungen. 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 Arbeitswelt einer Juristin oder eines Compliance-Beauftragten:

Ergebnis A — RDPS (volle CRA-Pflicht):

• Eine Smart-Türschloss-App (z. B. August, Nuki) mit Hersteller-App auf dem Smartphone und Hersteller-Cloud, die die Zugriffsrechte prüft. Ohne die Cloud lässt sich die Tür nicht per App öffnen, und die Cloud-Software stammt vom Hersteller.
• 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 DocuSign-ähnliche Plattform, deren Desktop-Plugin nur mit dem hauseigenen Signaturserver funktioniert.

Ergebnis B — Drittanbieter-Komponente (Komponentenpflichten):

• Eine Branchensoftware, die für die Login-Anmeldung Auth0 oder Okta nutzt — die Authentifizierung ist produktnotwendig (ohne sie kann der Nutzer das Produkt nicht öffnen), aber Auth0 und Okta sind Standard-Drittprodukte.
• Ein e-Reader, der bei einem Drittanbieter-Cloudspeicher (z. B. Dropbox-API) Bücher synchronisiert (Primärbeispiel der Kommission, Abschnitt 8.3.3).
• Eine Fuhrpark- oder Logistik-App mit lokalem Smartphone-Client, die für ihre Kernfunktion — die Routenführung — auf einen Karten- und Navigationsdienst eines Drittanbieters (z. B. Google Maps Platform, Mapbox) zugreift. Ohne den Kartendienst kann die App ihre zentrale 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 Sentry oder Bugsnag schickt, damit der Hersteller Fehler analysieren kann — nicht produktfunktional.
• Software mit Matomo- oder Google-Analytics-Integration 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-Dienst — 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 self-hosted; 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 entworfen 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, aber Behandlung wie eine Drittanbieter-Komponente — Due Diligence und produktseitige Massnahmen wie die Abschottung des Chats von den Kern-Bankfunktionen, die Kontrolle der Datenflüsse und die 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 Mobile App und 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 funktioniert der Thermostat nicht (keine Temperatursteuerung via App).
• Element 3 (Hersteller-Verantwortung): erfüllt — die Steuerungssoftware wurde vom Hersteller entworfen 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 mit Drittanbieter-Speicher (Abschnitt 8.3.3). Ein e-Reader 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 der e-Reader eine seiner Funktionen nicht ausführen.
• Element 3 (Hersteller-Verantwortung): nicht erfüllt — der SaaS-Speicherdienst wurde nicht vom Hersteller entworfen und entwickelt; der Anbieter stellt ihn beliebigen Kunden für beliebige Zwecke bereit.

Ergebnis: Keine RDPS. Der Hersteller muss den SaaS-Dienst aber wie eine Drittanbieter-Komponente behandeln — mit Risikobewertung, Due Diligence 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 entworfenen 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 Due Diligence ausüben — etwa durch Einholung eines Nachweises der NIS-2-Konformität des Anbieters. Für Hersteller aus dem Maschinen- und Anlagenbau ist dieses Beispiel besonders anschlussfähig, weil es die RDPS-Prüfung mit der parallel zu beachtenden Maschinenverordnung verknüpft.

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 entworfen, 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.

Progressive Web Apps (PWAs): Eine PWA wird über den Browser installiert, kann offline arbeiten und lokal Daten speichern. Ist sie ein „Produkt mit digitalen Elementen“ mit eigener RDPS? Die Guidance adressiert PWAs nicht explizit. Aus der Logik der Guidance (Rn. 194 zu Websites) lässt sich ableiten: Sobald eine PWA über eine reine Informationswebsite hinausgeht und aktive Produktfunktionen bereitstellt, dürfte sie als lokale Komponente gelten — mit der Konsequenz, dass verbundene Server-Verarbeitung die RDPS-Prüfung auslöst.

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 diese 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 von einer CRA-Pflicht auszugehen.

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 abgestuften Pflichten aus Ergebnis B und C (siehe oben), dass jede Form der Server-Kommunikation regulatorische Konsequenzen haben kann — selbst ohne RDPS. In Produkten mit vielen integrierten Drittanbieter-Diensten wird deshalb die Due-Diligence-Pflicht nach Art. 13 Abs. 5 CRA zu einem zentralen Compliance-Thema.

Welche der drei Konstellationen liegt bei Ihrem Produkt vor? Der CRA-Quick-Check unterstützt bei der ersten Einordnung der RDPS-Regeln — auch bei Grenzfällen wie reinen SaaS-Lösungen und beim Verbindungskriterium. Für eine abschliessende Beurteilung bleibt eine individuelle Prüfung erforderlich. Keine Rechtsberatung im Sinne des RDG.

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. Veröffentlicht am: 23.03.2026. Zuletzt geprüft am: 13.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

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

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. 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) und Art. 3 Nr. 2 (Definition: Datenfernverarbeitungslösung) sowie Erwägungsgrund 11. ABl. L, 20.11.2024. Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[3] Linklaters, „EU Cyber Resilience Act: Commission issues first draft guidance – 10 key points you need to know“, Client Briefing März 2026. Verfügbar unter: https://techinsights.linklaters.com/post/102mmlo/eu-cyber-resilience-act-commission-issues-first-draft-guidance-10-key-points-y. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; bezieht sich auf den zwischenzeitlich durch den veröffentlichten Annex zu C(2026) 5252 als aktuelle Auswertungsgrundlage abgelösten Entwurf vom März 2026.

[4] Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3, 5. Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025.

[5] 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

Hinweis zur Methodik

Dieser Artikel basiert auf der Analyse der am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichten Guidance (rund 70 Seiten), insbesondere auf Kapitel 7.3 (Rn. 167–173) und Kapitel 8 (Rn. 178–208), sowie auf dem Verordnungstext (EU) 2024/2847. Ergänzend wurde die deutsche Kommentarliteratur herangezogen, insbesondere Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten.