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

Von codAIx GmbH | April 2026

Ist meine Software CRA-pflichtig oder nicht? Diese Frage hat Softwarehersteller seit Inkrafttreten des Cyber Resilience Act am 10. Dezember 2024 beschäftigt. Seit März 2026 gibt es erstmals eine offizielle Orientierungshilfe: Die EU-Kommission hat in einer Draft Communication einen strukturierten Test veröffentlicht, der die Abgrenzung zwischen CRA-pflichtiger Datenfernverarbeitung und reinen Cloud-Diensten erstmals operationalisiert. Bis zum 13. April 2026 besteht noch die Möglichkeit, Feedback an die Kommission zu ihrem Entwurf abzugeben [1]. Wir erklären, wie der Test funktioniert — und spielen ihn an konkreten Praxisbeispielen durch.

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 [3], sofern der Anbieter die dort definierten Schwellenwerte erreicht.

In der Praxis hat sich allerdings schnell gezeigt: Die Grenze zwischen CRA-pflichtiger RDPS und reiner Cloud-Software ist alles andere als trennscharf. Wann genau ist eine Server-Komponente „integraler Bestandteil" eines lokalen Produkts? Reicht ein optionaler Cloud-Sync? Zählt ein Browser-Plugin als „lokale Komponente"?

Die EU-Kommission hat auf diese Unsicherheit reagiert. Am 3. März 2026 veröffentlichte sie unter dem Aktenzeichen Ares(2026)2319816 eine Draft Communication mit dem Titel „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)" [1]. Das 68-seitige Dokument behandelt neun Themengebiete — von Scope über FOSS bis hin zu Meldepflichten. Kapitel 8 widmet sich dabei ausschliesslich der Frage, wann Remote-Datenverarbeitung als RDPS unter den CRA fällt. Die Konsultationsfrist läuft bis zum 13. April 2026. Die finale Version wird voraussichtlich im Sommer 2026 erscheinen — aber schon der Entwurf gibt die Richtung klar vor.

Drei Elemente, zwei entscheidende Fragen

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

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?

Ein wichtiger Punkt, der oft übersehen wird: Die Kommission behandelt diese drei Elemente nicht gleichwertig. Element 1 — die Frage nach der Distanz — wird als „relevant, aber nicht hinreichend" eingestuft (Rn. 169). Die Kommission weist darauf hin, dass angesichts der Vielfalt möglicher Konstellationen eine abschliessende Definition von „auf Distanz" gar nicht möglich sei. Stattdessen sei stets eine Einzelfallbeurteilung erforderlich.

Die eigentlich entscheidenden Fragen sind Element 2 und Element 3. Die Kommission formuliert es in Rn. 172 unmissverständlich: Nur wenn beide Fragen bejaht werden, liegt eine RDPS vor. Es handelt sich also um einen kumulativen Zwei-Fragen-Test mit einer kontextuellen Vorbedingung — nicht um eine streng sequenzielle Dreier-Kaskade.

Element 1: Datenverarbeitung „auf Distanz"

Die Kommission nutzt den Begriff „auf Distanz" bewusst weit (Rn. 170). 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: RDPS muss nicht auf einer Cloud-Infrastruktur eines Drittanbieters laufen. Die Kommission stellt klar (Rn. 171), dass auch eine Lösung auf den eigenen Servern des Herstellers — also on-premises beim Hersteller — als RDPS gelten kann, sofern die Verarbeitung ausserhalb der Umgebung des Nutzers stattfindet.

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

Element 2: Verhindert das Fehlen eine Funktion des Produkts?

Hier liegt der substantielle Kern der Prüfung. Die Kommission definiert „Funktionen" dabei bewusst weit — und das ist eine der wichtigsten Klarstellungen der gesamten Guidance.

Der Gesetzeswortlaut spricht davon, dass das Fehlen der Datenverarbeitung das Produkt daran hindern würde, „eine seiner Funktionen auszuführen." Die Kommission betont (Rn. 173): 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. 174 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
• Empfang 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. 176): 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 das Thema Websites wird adressiert (Rn. 178): Eine reine Informationswebsite zum Produkt ist keine RDPS. Aber eine Website, die eine Produktfunktion ermöglicht oder unterstützt — zum Beispiel ein Authentifizierungsportal, das Zugangsdaten für das Produkt bereitstellt — kann RDPS sein.

Ein weiterer praxisrelevanter Hinweis (Rn. 175): 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 Kommission differenziert hier sorgfältig zwischen verschiedenen Cloud-Servicemodellen (Rn. 181–184):

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. 182). 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. 183).

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. 184).

Entscheidend ist dabei (Rn. 180): Wer die Lösung betreibt (operates), ist für die RDPS-Qualifikation nicht massgeblich. Massgeblich ist allein, wer sie entworfen und entwickelt hat. Ein Hersteller, der seine Server-Software bei AWS hosten lässt, bleibt der Entwickler — auch wenn AWS den Betrieb übernimmt.

Die Kommission erklärt auch den Begriff „unter der Verantwortung" (Rn. 179): Dies umfasst massgeschneiderte Lösungen, die ein externer Dienstleister im Auftrag des Herstellers auf dessen Spezifikationen hin entwickelt. Es reicht aber nicht aus, lediglich ein bestehendes Produkt eines Drittanbieters zu lizenzieren oder geringfügig anzupassen.

Die drei Ergebnisse des Tests

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

Ergebnis A — Beide Fragen bejaht: Die Datenverarbeitung qualifiziert als RDPS. Sie muss in die Cybersicherheits-Risikobewertung einbezogen werden, die SBOM muss sie abdecken, und die wesentlichen Cybersicherheitsanforderungen des Annex 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. 186(b)). 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. Die Draft Communication (Rn. 155) nennt konkrete Mittel: technische Spezifikationen des Anbieters einholen, Sicherheitsdokumentation prüfen, Konformitätsnachweise anfordern, und bei Bedarf eigene Funktionstests durchführen.
• Produktseitige Massnahmen: Der Hersteller muss Risiken, die er beim Drittanbieter nicht kontrollieren kann, durch eigene produktseitige Sicherheitsmassnahmen kompensieren (Rn. 153–154) — etwa durch kryptographische Absicherung der Kommunikation, Integritätsprüfungen oder Fallback-Mechanismen bei Ausfall des Dienstes.

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. 177). 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.

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:

Entscheidend ist: Auch Ergebnis B und C sind CRA-Pflichten — keine freiwilligen Empfehlungen. Wer glaubt, durch Outsourcing an SaaS-Anbieter oder durch Verlagerung in die Cloud der CRA-Regulierung vollständig zu entkommen, verkennt die Systematik der Verordnung.

Vier Praxisbeispiele aus der Draft Communication

Die Kommission selbst illustriert den Test in Abschnitt 8.3 an fünf Szenarien. Die folgenden vier sind besonders lehrreich:

Beispiel 1: Banking-App mit eigenem Backend (Rn. 8.3.1). Ein Finanzinstitut stellt eine Banking-App bereit. Das Backend — die Banking-API — wurde vom Hersteller selbst entwickelt und verarbeitet Transaktionen. Ohne die API funktionieren die Kernfunktionen der App nicht. Element 2: Ja. Element 3: Ja. Ergebnis: Die Banking-API ist RDPS. Kontoverwaltung und Ledger-System hingegen, die nicht direkt mit der App interagieren, sind keine RDPS — bleiben aber externe Abhängigkeiten, die in der Risikobewertung berücksichtigt werden müssen.

Beispiel 2: Smart Thermostat mit Cloud (Rn. 8.3.2). Ein Smart-Thermostat-Hersteller betreibt die Steuerungssoftware auf einer IaaS-Infrastruktur eines Drittanbieters. Ohne die Cloud-Verarbeitung funktioniert der Thermostat nicht (keine Temperatursteuerung via App). Die Software wurde vom Hersteller entwickelt. Element 2: Ja. Element 3: Ja. Ergebnis: RDPS. Auch die IaaS-Abhängigkeit muss in der technischen Dokumentation und Risikobewertung erfasst werden.

Beispiel 3: e-Reader mit Drittanbieter-Speicher (Rn. 8.3.3). Ein e-Reader nutzt einen SaaS-Speicherdienst eines Drittanbieters für die Buchbibliothek. Ohne den Speicherdienst funktioniert der e-Reader nicht vollständig — aber der Dienst wurde nicht vom Hersteller entworfen und entwickelt. Element 2: Ja. Element 3: Nein. Ergebnis: Keine RDPS — aber der Hersteller muss den SaaS-Dienst wie eine Drittanbieter-Komponente behandeln (Risikobewertung, Due Diligence, produktseitige Sicherheitsmassnahmen).

Beispiel 4: Smartphone mit Mobilfunknetz (Rn. 8.3.5). Ein Smartphone benötigt ein 5G-Netz für Internet, Telefonie und Nachrichten. Die Kommission stellt klar: Das Netz ist kein RDPS. Es ist ein Kommunikationskanal, dessen Fehlen die Funktion „mit einem Netz verbinden" nicht verhindert — das Produkt funktioniert korrekt, es hat lediglich keine Verbindung. Gleiches gilt für Ethernet, Router und WLAN. Ergebnis: Keine RDPS, auch keine Drittanbieter-Komponente — keine Due-Diligence-Pflicht gegenüber dem Netzbetreiber.

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 Draft Communication adressiert PWAs nicht explizit. Aus der Logik der Guidance (Rn. 178 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 Abs. 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. 176 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.

Diese offenen Punkte werden voraussichtlich in der finalen Version der Guidance oder durch nachfolgende Leitlinien adressiert. Bis dahin gilt: Im Zweifel konservativ einstufen und CRA-Pflicht annehmen.

Der strategische Blick

Für Softwareunternehmen in der DACH-Region hat der Test eine unmittelbare strategische Bedeutung, die über Compliance hinausgeht.

Zum einen schafft er Planungssicherheit. Wer den Test durchspielt und zu einem klaren Ergebnis kommt, kann seine Compliance-Strategie auf einer belastbaren Grundlage aufbauen — sei es die Vorbereitung auf die CRA-Anforderungen oder die Ausrichtung auf NIS-2.

Zum anderen macht der Test sichtbar, dass Produktarchitektur-Entscheidungen jetzt regulatorische Konsequenzen haben. Die Entscheidung, ob eine Funktion lokal oder serverseitig implementiert wird, ist nicht mehr nur eine technische — sie ist eine Compliance-Entscheidung. Besonders relevant: Auch die Wahl zwischen Eigenentwicklung und SaaS-Integration (Element 3) hat direkte regulatorische Auswirkungen.

Ein dritter Punkt verdient besondere Aufmerksamkeit: Die abgestuften Pflichten aus Ergebnis B und C (siehe oben) bedeuten, dass jede Form der Server-Kommunikation regulatorische Konsequenzen hat — selbst wenn das Ergebnis keine RDPS ist. Für Unternehmen, die viele Drittanbieter-Dienste integrieren, wird die Due-Diligence-Pflicht nach Art. 13 Abs. 5 CRA zum zentralen Compliance-Thema.

Sie wollen den RDPS-Test für Ihr Produkt durchspielen? Der crAIready Quick Check führt Sie systematisch durch alle Schritte — einschliesslich der Grenzfälle, bei denen eine individuelle Einschätzung erforderlich ist.

Im nächsten Artikel dieser Serie: Kein RDPS — und trotzdem CRA-pflichtig? Was die abgestuften Pflichten nach Art. 13 CRA für die Ergebnisse B und C des Drei-Elemente-Tests konkret bedeuten.

Quellen

[1] Europäische Kommission, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", 3. März 2026. Kapitel 8: Remote data processing, Rn. 162–192. Konsultation verfügbar unter: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en — Dokument-Download über CIRCABC.

[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 Abs. 1 (Definition: Produkt mit digitalen Elementen) und Art. 3 Abs. 2 (Definition: Datenfernverarbeitungslösung). 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). ABl. L 333, 27.12.2022. Verfügbar unter: https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Hinweis zur Methodik

Dieser Artikel basiert ausschliesslich auf der Analyse des Primärtextes der Draft Communication Ares(2026)2319816 (68 Seiten, Kapitel 8, Rn. 162–192) sowie des Verordnungstextes (EU) 2024/2847. Alle Randnummern-Verweise beziehen sich auf die Draft Communication. Da es sich um einen Entwurf handelt, können sich Formulierungen und Nummerierungen in der finalen Version ändern. Stand: April 2026.