Von Redaktion codAIx | 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. Die Konsultation ist am 31. März 2026 abgelaufen; eine finale Version war zum Stand 20. Mai 2026 noch nicht veröffentlicht [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 [5], sofern der Anbieter die dort definierten Schwellenwerte erreicht.

Kurz zur Erinnerung an die rechtliche Systematik aus den beiden vorangegangenen Teilen dieser Serie: Der CRA reguliert nicht Software an sich, sondern das Inverkehrbringen von Produkten (Art. 3 Nr. 21 CRA). Eine reine Browser-SaaS wird im technischen Sinn zwar aus Software gebaut (Art. 3 Nr. 4 CRA), aber sie wird nicht an den Nutzer ausgeliefert — der Nutzer ruft eine laufende Dienstleistung beim Anbieter ab. Damit fehlt der Anknüpfungspunkt der Produktsicherheitslogik. Solche Dienstleistungen adressiert die EU über NIS-2 [5]. Die RDPS-Konstruktion in Art. 3 Nr. 2 CRA ist der regulatorische Brückenkopf, mit dem die Produktregulierung dort doch in die Cloud reicht, wo ein lokales Produkt — als Software- oder Hardwareprodukt im Sinne von Art. 3 Nr. 1 CRA — den Marktzugang eröffnet. Die ausführliche Herleitung dieser Systematik finden Sie 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 Draft Communication stellt das in Rn. 166 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]. Der CRA adressiert das Produkt und seine produktnotwendigen Bestandteile, nicht die gesamte IT-Landschaft des Herstellers.

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 rund 70 Seiten starke Dokument umfasst neun nummerierte Kapitel — von der Scope-Abgrenzung über Open-Source-Software, wesentliche Änderungen und Support-Perioden bis zur Datenfernverarbeitung und dem Zusammenspiel mit anderen EU-Rechtsakten. Die Kommission selbst hebt in ihrer Mitteilung vier inhaltliche Schwerpunkte hervor: Datenfernverarbeitung (RDPS), freie und Open-Source-Software, Support-Perioden sowie das Zusammenspiel des CRA mit anderen EU-Rechtsakten. Einzelne Sekundärpublikationen — etwa Linklaters in ihrem Client Briefing vom März 2026 — strukturieren den Entwurf in zehn Kernpunkten für die Praxis [3]. Kapitel 8 widmet sich ausschliesslich der Frage, wann Remote-Datenverarbeitung als RDPS unter den CRA fällt. Die finale Version wird nach Auswertung der Stakeholder-Rückmeldungen und Übersetzung in alle EU-Amtssprachen erwartet — einen festen Termin hat die Kommission nicht genannt.

Hinweis zur Quellenlage: Sämtliche Randnummern-Verweise in diesem Artikel beziehen sich auf den Entwurfsstand vom 3. März 2026 und stehen unter dem Vorbehalt der noch nicht öffentlich freigegebenen finalen Konsolidierung.

Die Vorfrage: Existiert überhaupt ein CRA-Produkt?

Bevor der Drei-Elemente-Test sinnvoll angewendet werden kann, muss eine ihm logisch vorgelagerte Frage geklärt sein: Liegt überhaupt ein Produkt mit digitalen Elementen im Sinne von Art. 3 Nr. 1 CRA vor? Der Test entscheidet nämlich nicht, ob der CRA anwendbar ist, sondern nur, wie weit er von einem bereits feststehenden Produkt aus in die Cloud hineinreicht. Anknüpfungspunkt ist stets eine lokal beim Nutzer installierte oder ausgeführte Komponente — eine Desktop-App, eine Mobile App, ein Browser-Plugin, ein Agent oder ein SDK. Fehlt eine solche lokale Komponente und handelt es sich um eine reine Browser-SaaS, gibt es kein CRA-Produkt, dem eine Datenfernverarbeitungslösung zugerechnet werden könnte — der Test läuft ins Leere, und die Server-Software bleibt eine reine Cloud-Dienstleistung im Anwendungsbereich der NIS-2-Richtlinie. Erst wenn diese Vorfrage bejaht ist, stellt sich die Anschlussfrage, die dieser Artikel behandelt: 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. 168):

  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. 168 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.

Ein wichtiger Punkt, der oft übersehen wird: Die Kommission behandelt diese drei Elemente nicht gleichwertig. Element 1 — die Frage nach der Distanz — wird in Rn. 169 als „relevant, aber nicht hinreichend" eingestuft. „Nicht hinreichend" bedeutet: Die Distanz allein begründet noch keine RDPS — es müssen Element 2 und 3 hinzukommen. „Nicht hinreichend" bedeutet aber nicht „entbehrlich": Die Distanz ist eine notwendige Voraussetzung und damit ein echtes Ausschlusskriterium. Fehlt sie, ist eine RDPS ausgeschlossen, ohne dass es auf Element 2 und 3 überhaupt noch ankäme. Die Kommission weist zugleich darauf hin, dass angesichts der Vielfalt möglicher Konstellationen eine abschliessende Definition von „auf Distanz" nicht möglich ist — erforderlich ist stets eine Einzelfallbeurteilung.

Wo die eigentliche Prüfungsarbeit liegt, ist in 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 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. 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: Eine RDPS muss nicht auf der Cloud-Infrastruktur eines Drittanbieters laufen. Die Kommission stellt in Rn. 171 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. 170) — 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. 170 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. 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 präzisiert in Rn. 179 zunächst den Begriff „unter der Verantwortung": Erfasst sind massgeschneiderte Lösungen, die ein externer Dienstleister im Auftrag des Herstellers auf dessen Spezifikationen hin entwickelt. Es reicht nicht aus, lediglich ein bestehendes Produkt eines Drittanbieters zu lizenzieren oder geringfügig anzupassen. Die Draft Communication legt in Rn. 179 vier kumulative Kriterien dafür an:

  • Die Software ist massgeschneidert („tailor-made") für den Hersteller.
  • Sie wird ausschliesslich im Auftrag des Herstellers entwickelt.
  • Sie basiert auf den Spezifikationen und Designs des Herstellers.
  • Die Technologie ist vom Hersteller eigentumsrechtlich erworben, nicht lizenziert („the technology developed by the service provider is owned, not licensed, by the manufacturer").

Blosses Lizenzieren oder geringfügiges Anpassen eines bestehenden Drittprodukts genügt nicht.

Auf dieser Grundlage differenziert die Kommission 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). Eine Drittanbieter-SaaS könnte nur dann unter die Herstellerverantwortung fallen, wenn sie nach den vier oben genannten Kriterien tatsächlich massgeschneidert für den Hersteller entwickelt wurde und in seinem Eigentum steht — also faktisch eine White-Label-Eigenentwicklung 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.

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 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:

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. 185 i. V. m. Rn. 186 lit. 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.
  • SBOM: Die Drittanbieter-Komponente erscheint in der SBOM des Produkts als 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. 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.

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. 186 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. 186 lit. c) 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 | Einstufung | CRA-Pflichten | |----------|-----------|---------------| | 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) | Komponente | Eingeschränkte CRA-Pflichten: Risikobewertung (Art. 13 Abs. 2), Due Diligence (Art. 13 Abs. 5), produktseitige Sicherheitsmassnahmen, SBOM-Eintrag als Top-Level-Abhängigkeit | | C (Element 2 verneint) | 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.

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.

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

Damit die Abgrenzung greifbar wird, hier je drei Beispiele pro Ergebnis aus der Lebenswelt 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-API, die die Authentifizierung und die Anbahnung der Transaktionen abwickelt (Primärbeispiel der Kommission, Abschnitt 8.3.1). Das Kernbanken-Ledger 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.

In der Praxis hat fast jedes nicht-triviale Produkt einen Mix aus allen drei Ergebnissen: Eine Banking-App ist A für die Banking-API + B für einen integrierten Drittanbieter-Dienst (etwa eine Identitätsprüfung beim Onboarding) + C für das Crash-Reporting. Die Drei-Elemente-Prüfung wird damit zu einer differenzierten Inventur aller Datenströme.

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 drei Datenströmen (Abschnitt 8.3.1). Das Kommissionsszenario zeigt eine Banking-App mit drei verschiedenen Datenströmen — und damit zugleich, dass ein einziges Produkt mehrere Ergebnisse nebeneinander tragen kann.

Datenstrom 1 — selbst entwickelte Banking-API für Transaktionen. Die Banking-API 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-API kann die App ihre Kernfunktion, die Abwicklung von Transaktionen, nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die API wurde vom Finanzinstitut selbst entworfen und entwickelt.

Ergebnis: Die Banking-API ist RDPS und in die CRA-Pflichten des Gesamtprodukts einbezogen. Das Kontoverwaltungs- und das Ledger-System hingegen interagieren nicht direkt mit der App und unterstützen keine ihrer Funktionen — sie sind keine RDPS, 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.

Datenstrom 3 — Drittanbieter-PaaS für Transaktionsbenachrichtigungen. Den selbst entwickelten Code für Echtzeit-Benachrichtigungen betreibt das Institut auf der PaaS eines Cloud-Anbieters.

  • Element 1 (Distanz): erfüllt — die Verarbeitung findet in der Cloud statt.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den Benachrichtigungs-Code fehlt die Funktion der Transaktionsbenachrichtigung.
  • Element 3 (Hersteller-Verantwortung): für den selbst entwickelten Benachrichtigungs-Code erfüllt, für die PaaS-Dienste selbst nicht.

Ergebnis: Der vom Institut entwickelte Benachrichtigungs-Code ist RDPS. Die zugrunde liegende PaaS ist keine RDPS, wird aber wie eine Komponente behandelt (Due Diligence, produktseitige Absicherung). Damit vereint schon dieses eine Beispiel eine RDPS, eine Drittanbieter-Komponente und externe Abhängigkeiten — genau den Mix, den die Praxis prägt.

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: 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 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 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. 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 wissen, ob Ihr Produkt unter die RDPS-Regeln fällt? Der CRA-Quick-Check unterstützt Sie bei der orientierenden Einordnung — einschliesslich Grenzfällen wie reinen SaaS-Lösungen und dem Verbindungskriterium. Die abschliessende Beurteilung erfordert eine individuelle Einschätzung.

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: 01.04.2026. Zuletzt geprüft am: 03.07.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, 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 am 31. März 2026 abgelaufen; eine finale Version war zum Stand 20. Mai 2026 noch nicht veröffentlicht. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act sowie 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 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.

[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.

Hinweis zur Methodik

Dieser Artikel basiert auf der Analyse des Primärtextes der Draft Communication Ares(2026)2319816 (rund 70 Seiten, Kapitel 8, Rn. 162–192) sowie des Verordnungstextes (EU) 2024/2847. Ergänzend herangezogen wurde die deutsche Kommentarliteratur, insbesondere Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Alle Randnummern-Verweise auf die Draft Communication beziehen sich auf den Entwurfsstand vom 3. März 2026 und stehen unter dem Vorbehalt der noch nicht öffentlich freigegebenen finalen Konsolidierung. Da es sich um einen Entwurf handelt, können sich Formulierungen und Nummerierungen in der finalen Version ändern. Stand: 23.05.2026 (v9 — Vorfrage nach dem Produkterfordernis ergänzt; Querverweis auf Artikel 00 und 01 präzisiert und Art.-3-Nr.-1-Zitat korrigiert; Ergebnis-B-Beispiel ersetzt; alle vier Praxisbeispiele einheitlich entlang der drei Elemente strukturiert; Beispiel 1 um die Datenströme Support-Chat (SaaS) und Transaktionsbenachrichtigungen (PaaS) aus Abschnitt 8.3.1 erweitert. v10 — Klarstellung ergänzt, dass Ergebnis C allein an Element 2 anknüpft und Element 3 dort nicht mehr geprüft wird, Rn. 186 lit. c. v11 — Element 1 präzisiert: Bezugspunkt der „Distanz" ist die Betriebsumgebung des Nutzers, nicht die Eigentümerschaft an der Infrastruktur (Art. 3 Nr. 2 CRA, Rn. 170/171); klargestellt, dass Software, die in der Umgebung des Nutzers läuft, mangels Distanz keine RDPS ist, als vom Hersteller in Verkehr gebrachtes Produkt mit digitalen Elementen nach Art. 3 Nr. 1 CRA und Erwägungsgrund 11 aber gleichwohl dem CRA unterliegt; den mehrdeutigen Begriff „On-Premises" in der Element-1-Darstellung vermieden, da Rn. 171 ihn von den Räumlichkeiten des Herstellers aus denkt; klargestellt, dass die Distanz zwar „nicht hinreichend", aber eine notwendige Voraussetzung ist und ihr Fehlen eine RDPS ausschliesst; in der Übersicht der drei Ergebnisse ergänzt, dass A, B und C die erfüllte Distanz (Element 1) voraussetzen; das Stufe-C-Label in der Übersichtstabelle von „Weder noch" auf „Weder RDPS noch Komponente" vereinheitlicht, konsistent mit Artikel 03).