Von Redaktion codAIx | 6. April 2026

Der Drei-Elemente-Test der EU-Kommission — im Kern zwei entscheidende Fragen — klärt viele Fälle. Aber nicht alle. Zwischen dem klaren „RDPS“ und dem klaren „keine RDPS“ liegt eine Grauzone, in der sich zahlreiche Softwarehersteller wiederfinden. Dieser Artikel analysiert die schwierigsten Abgrenzungsfälle — und zeigt, wie Unternehmen auch mit der veröffentlichten Guidance handlungsfähig bleiben.

Die unbequeme Wahrheit

In den ersten drei Teilen dieser Serie haben wir die Grundlagen gelegt: Der CRA erfasst Produkte mit digitalen Elementen einschliesslich ihrer Datenfernverarbeitungslösungen[1]. Reine SaaS-Lösungen ohne lokale Komponente fallen für sich genommen nicht unter den CRA; für ihre Anbieter kann NIS-2 einschlägig sein, wenn Dienst, Einrichtung und Grössen- oder Sonderkriterien der Richtlinie beziehungsweise des nationalen Umsetzungsrechts erfüllt sind[2]. Und der Orientierungsrahmen mit drei Elementen und zwei entscheidenden Fragen der EU-Kommission[3] bietet einen strukturierten Entscheidungsbaum für die Abgrenzung — siehe dazu auch Teil 2 dieser Serie (Drei-Elemente-Test im Detail) und Teil 3 (abgestufte Pflichten nach Art. 13 CRA).

Soweit die Theorie. Die Praxis sieht anders aus.

Moderne Softwareprodukte lassen sich immer seltener sauber in die Kategorien „lokal installiert“ oder „rein Cloud-basiert“ einordnen. Die Realität ist hybrid: Feature-gated SaaS, bei dem Basisfunktionen offline laufen, aber Premium-Features die Cloud benötigen. Electron-Apps, die technisch ein Browser in einer Hülle sind. SDKs, die in Kundenprodukte eingebettet werden und dann mit dem Server des SDK-Herstellers kommunizieren. Browser-Extensions, die lokale Daten auslesen und an ein Cloud-Backend senden.

Für diese Konstellationen liefert der Zwei-Fragen-Test zwar einen Rahmen, aber kein eindeutiges Ergebnis. Und genau hier entscheidet sich, ob die serverseitige Verarbeitung als RDPS Teil des Produkts ist — und damit, wie weit die CRA-Compliance reicht.

Drei Elemente und zwei entscheidende Fragen: Struktur und Ergebnisse

Die veröffentlichte Guidance der Kommission beschreibt in den Rn. 184–188 einen strukturierten Entscheidungsprozess mit drei Elementen und zwei entscheidenden Fragen. Die Kommission prüft die Funktion vor der Herstellerverantwortung; der Wortlaut des Art. 3 Nr. 2 CRA nennt sie in umgekehrter Reihenfolge — näher dazu Teil 2.

Element 1 — Distanz (Rn. 185 f.): Findet die Datenverarbeitung ausserhalb der Betriebsumgebung des Nutzers statt? Rn. 185 nennt das Merkmal „relevant, aber nicht ausreichend“ und verlangt eine Einzelfallprüfung. Nach Rn. 186 ist das der typische Fall, was Verarbeitung nahe am Gerät („at the edge“) nicht ausschliesst. Allein begründet die Distanz keine RDPS. Sie ist aber eine notwendige Voraussetzung und damit ein Ausschlusskriterium: Fehlt die Distanz, ist eine RDPS ausgeschlossen, ohne dass Element 2 und 3 noch geprüft werden.

Element 2 — Funktionalität (Rn. 189–193): Würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausübt? Dies ist die erste entscheidende kumulative Frage. Das ist erheblich breiter als nur „Abhängigkeit“: Nach Rn. 189 ist der Funktionsbegriff nicht auf die Kernfunktionalität oder den bestimmungsgemässen Zweck beschränkt, sondern erfasst auch Funktionen, die die Gesamtleistung des Produkts unterstützen — praktisch zählen damit auch optionale oder Premium-Features.

Element 3 — Herstellerverantwortlichkeit (Rn. 195–202): Wurde die serverseitige Software vom Hersteller des Produkts konzipiert und entwickelt — oder unter seiner Verantwortung? Das ist die zweite entscheidende kumulative Frage. Nach Rn. 195 der veröffentlichten Guidance bedeutet „unter der Verantwortung des Herstellers“, dass die Software ausschliesslich vom Hersteller oder in seinem Auftrag gebaut wird, auf Basis von Entwürfen und Spezifikationen, die er bereitstellt. Diese Auslegung spiegelt die Legaldefinition in Art. 3 Nr. 2 CRA wider, wonach nur Datenverarbeitung erfasst ist, die vom Hersteller oder unter dessen Verantwortung konzipiert und entwickelt wird. Auch Erwägungsgrund 12 CRA bestätigt: Cloud-Dienste, die ausserhalb der Verantwortung eines Herstellers entwickelt wurden, fallen nicht unter den CRA.

Die Kommission bestätigt in Rn. 188 diesen kumulativen Test mit zwei entscheidenden Fragen: Wenn beide Fragen mit „Ja“ beantwortet werden, liegt eine RDPS vor.

Aber hier wird es spannend: Rn. 202 definiert drei mögliche Ergebnisse:

  1. Stufe A — RDPS (Remote Data Processing Solution): Wenn Frage 8.1.2 = Ja (funktional notwendig) UND Frage 8.1.3 = Ja (vom Hersteller konzipiert und entwickelt oder unter seiner Verantwortung); entspricht Rn. 202 lit. a.
  2. Stufe B — Drittanbieter-Ferndienst, wie eine Komponente zu behandeln (aber nicht RDPS): Wenn Frage 8.1.2 = Ja, aber Frage 8.1.3 = Nein (z. B. weil die serverseitige Software von einem Drittanbieter stammt, der nicht unter der Verantwortung des Herstellers arbeitet); entspricht Rn. 202 lit. c.
  3. Stufe C — Berücksichtigung in der Risikobewertung: Wenn Frage 8.1.2 = Nein; entspricht Rn. 202 lit. b.

Stufe B ist entscheidend für die „CRA-Grauzone“: Die Datenverarbeitung ist keine RDPS, das Produkt unterliegt aber dennoch konkreten CRA-Pflichten — der Risikobewertung nach Art. 13 Abs. 2 und produktseitigen Sicherheitsmassnahmen; zusätzlich erwartet die Guidance eine risikoproportionale Sorgfalt entsprechend Art. 13 Abs. 5 (Rn. 201, 202 lit. c, 207 f.; siehe dazu ausführlich Teil 3 dieser Serie). Die nachfolgend beschriebenen Grenzfälle zeigen, dass die Einstufung stark davon abhängt, wer die serverseitige Software entwickelt hat — und dass die Antwort je nach Feature unterschiedlich ausfallen kann: RDPS für die eigene serverseitige Software, Behandlung als Drittanbieter-Ferndienst für eingebundene Drittanbieter-APIs.

Fünf Grenzfälle, die es in sich haben

Die folgenden Fälle prüfen wir nach einem einheitlichen Schema: zuerst die Vorbedingung — gibt es eine lokale Anknüpfung (ein Produkt mit digitalen Elementen), und findet die Verarbeitung auf Distanz statt? —, dann den Zwei-Fragen-Test — Funktionalität (Element 2) und Herstellerverantwortung (Element 3). Fall 5 folgt einem anderen Prüfpfad; das ist dort erläutert. In den Praxisbeispielen steht „Backend“ als gängige Kurzform für die serverseitige, entfernt stattfindende Datenverarbeitung — also für den Gegenstand, den der Test als mögliche Datenfernverarbeitungslösung prüft.

1. Feature-gated SaaS: Offline-Basis, Cloud-Premium

Ein Softwarehersteller bietet ein Designtool an. Die Basisversion läuft als installierte Desktop-Anwendung und funktioniert offline. Wer jedoch kollaborative Funktionen, Cloud-Speicher oder KI-gestützte Vorschläge nutzen möchte, braucht eine Internetverbindung — die Verarbeitung erfolgt dann auf dem Server des Herstellers.

Vorbedingung:

  • Lokale Anknüpfung: erfüllt — die Basisversion ist eine installierte Desktop-Anwendung und damit ein lokal beim Nutzer ausgeführtes Produkt mit digitalen Elementen.
  • Distanz: erfüllt — die Cloud-Features werden auf dem Server des Herstellers verarbeitet, ausserhalb der Umgebung des Nutzers.

Zwei-Fragen-Test:

  • Funktionalität (Element 2): erfüllt — Cloud-Speicher, Kollaboration und KI-Vorschläge sind Funktionen des Produkts. Rn. 189 stellt ausdrücklich klar, dass der Funktionsbegriff nicht auf die Kernfunktionalität oder den bestimmungsgemässen Zweck beschränkt ist; daraus folgt, dass auch optionale, gekaufte oder freischaltbare Features zählen.
  • Herstellerverantwortung (Element 3): in der Regel erfüllt — hat der Hersteller sein Cloud-Backend (Speicher-, KI- und Kollaborationsserver) selbst konzipiert und entwickelt oder entwickeln lassen, ist Element 3 erfüllt; wer es betreibt, ist nach Rn. 196 unerheblich. Bindet er für einzelne Features einen Drittanbieter-Ferndienst ein (etwa ein externes KI-Modell), ist Element 3 für genau dieses Feature verneint.

Ergebnis: Für die selbst entwickelten Cloud-Komponenten Stufe A, also RDPS (Rn. 202 lit. a); für zugekaufte Drittanbieter-Features Stufe B — Risikobewertung nach Art. 13 Abs. 2 CRA, zusätzlich die von der Guidance erwartete Sorgfalt (Rn. 202 lit. c). Im Zweifel empfiehlt es sich, ein Feature wie eine RDPS zu behandeln und die Abwägung zu dokumentieren. In die SBOM gehören dabei die Komponenten des Produkts einschliesslich einer eigenen RDPS, nicht aber fremde Ferndienste.

2. Electron-Apps und Desktop-Wrapper

Electron-basierte Anwendungen sind allgegenwärtig: Slack, VS Code, Discord, Figma Desktop. Technisch handelt es sich jeweils um einen Chromium-Browser, der in eine native Hülle verpackt ist. Die Anwendungslogik läuft teilweise lokal (JavaScript im Electron-Renderer), teilweise auf dem Server.

Vorbedingung:

  • Lokale Anknüpfung: erfüllt — der Nutzer installiert die Electron-App auf seinem Gerät; Dateien werden lokal geschrieben, Prozesse lokal ausgeführt. Dass die Technologie unter der Haube ein Chromium-Browser ist, ändert nichts: Massgeblich ist die Bereitstellungsform — Installation auf dem Endgerät bedeutet lokale Komponente und damit ein Produkt mit digitalen Elementen (Art. 3 Nr. 1 CRA).
  • Distanz: fallabhängig — erfüllt, wenn der Server ausserhalb der Umgebung des Nutzers läuft (bei Electron-Apps typischerweise die Cloud des Herstellers). Rn. 187 betrifft Server auf dem Gelände des Herstellers, die ebenfalls RDPS sein können. Betreibt der Kunde den Server in seiner eigenen Umgebung, fehlt in der Regel die Distanz; das ist nach Rn. 185 f. im Einzelfall zu prüfen. Die dem Kunden zum Selbstbetrieb überlassene Server-Software ist dann aber regelmässig selbst Teil des in Verkehr gebrachten Produkts und unterliegt als solche dem CRA.

Zwei-Fragen-Test:

  • Funktionalität (Element 2): fallabhängig — würde die fehlende Serververbindung das Produkt daran hindern, eine seiner Funktionen auszuführen?
  • Herstellerverantwortung (Element 3): fallabhängig — wurde die serverseitige Software vom Hersteller der Electron-App konzipiert und entwickelt oder unter seiner Verantwortung?

Ergebnis: Ist die Distanz erfüllt, entscheidet der Zwei-Fragen-Test. Beide Fragen bejaht → Stufe A, RDPS (Rn. 202 lit. a). Element 2 bejaht, Element 3 verneint — etwa weil die App ausschliesslich nicht vom Hersteller verantwortete Drittanbieter-APIs nutzt — → Stufe B: Risikobewertung nach Art. 13 Abs. 2 CRA, zusätzlich die von der Guidance erwartete Sorgfalt (Rn. 202 lit. c). Element 2 verneint — die Serververbindung trägt keine Produktfunktion, etwa reine Telemetrie — → Stufe C: Berücksichtigung in der Risikobewertung nach Art. 13 Abs. 2 CRA (Rn. 202 lit. b).

3. SDKs und APIs: Wer ist Hersteller, wer ist Integrator?

Ein Unternehmen bietet ein Payment-SDK an, das andere Softwarehersteller in ihre Produkte einbetten. Das SDK wird lokal in der Kunden-App installiert und kommuniziert mit dem Payment-Backend des SDK-Anbieters.

Ein SDK-Szenario hat zwei Beteiligte mit unterschiedlicher CRA-Rolle; es ist deshalb aus zwei Perspektiven zu prüfen.

Perspektive 1 — der Integrator (das Unternehmen, das das SDK in seine eigene App einbettet):

  • Vorbedingung: lokale Anknüpfung erfüllt — die App ist ein lokal installiertes Produkt mit digitalen Elementen; Distanz erfüllt — das Payment-Backend läuft ausserhalb der Umgebung des Nutzers.
  • Zwei-Fragen-Test: Element 2 — trägt das SDK eine Funktion seiner App (die Zahlungsabwicklung)? Regelmässig ja. Element 3 — hat der Integrator das SDK und dessen Backend konzipiert und entwickelt? Nein, es ist ein fremdes SDK.
  • Ergebnis: Das lokal eingebundene SDK ist für den Integrator eine tatsächlich integrierte Komponente: Für sie gilt die Sorgfaltspflicht nach Art. 13 Abs. 5 CRA unmittelbar, und er führt sie als oberste Abhängigkeit in seiner SBOM. Das Payment-Backend des SDK-Anbieters ist für ihn dagegen ein Drittanbieter-Ferndienst der Stufe B (Rn. 202 lit. c): verbindlich ist die Risikobewertung nach Art. 13 Abs. 2, zusätzlich erwartet die Guidance eine entsprechende Sorgfalt.

Perspektive 2 — der SDK-Hersteller (das Unternehmen, das das SDK herstellt und in Verkehr bringt):

Das SDK ist eine Softwarekomponente, die getrennt in Verkehr gebracht wird, und damit nach Art. 3 Nr. 1 CRA ein eigenes Produkt mit digitalen Elementen. Aus dieser Perspektive ist das SDK das zu prüfende Produkt.

  • Vorbedingung: lokale Anknüpfung erfüllt — das SDK wird lokal in der Kunden-App ausgeführt; Distanz erfüllt — das Payment-Backend läuft auf der Infrastruktur des SDK-Herstellers.
  • Zwei-Fragen-Test: Element 2 — würde das Fehlen des Backends das SDK an einer seiner Funktionen hindern? Element 3 — hat der SDK-Hersteller das Backend konzipiert und entwickelt? In aller Regel lauten beide Antworten ja.
  • Ergebnis: Das Backend ist eine RDPS des SDK (Rn. 202 lit. a); der SDK-Hersteller verantwortet die volle CRA-Compliance für das Gesamtsystem aus SDK und Backend.

Beide Rollen bestehen nebeneinander: Der SDK-Hersteller verantwortet sein SDK, der Integrator sein eigenes Produkt einschliesslich des eingebetteten SDK als Komponente. Bettet der Integrator das SDK nur ein, bleibt er Hersteller seiner App und der SDK-Hersteller Hersteller des SDK. Verändert ein Integrator dagegen ein fremdes Produkt oder das SDK selbst wesentlich, kann er nach Art. 22 CRA zum Hersteller des veränderten Produkts werden — dazu ausführlich Artikel 11 dieser Serie zur wesentlichen Änderung.

4. Browser-Extensions und Plugins

Ein Security-Unternehmen bietet eine Browser-Extension an, die Phishing-URLs in Echtzeit erkennt. Die Extension analysiert lokal die besuchten URLs, sendet verdächtige Treffer an ein Cloud-Backend zur Tiefenanalyse und zeigt dem Nutzer eine Warnung an.

Vorbedingung:

  • Lokale Anknüpfung: erfüllt — eine Browser-Extension wird in den Browser des Nutzers installiert; dieser läuft im Regelfall auf dem Gerät des Nutzers, sodass die Extension dort ausgeführte Software mit Zugriff auf lokale Daten (Browsing-Verlauf, Cookies, Seiteninhalt) und damit ein Produkt mit digitalen Elementen ist.
  • Distanz: erfüllt — das Cloud-Backend zur Tiefenanalyse liegt ausserhalb der Umgebung des Nutzers.

Zwei-Fragen-Test:

  • Funktionalität (Element 2): erfüllt — ohne das Cloud-Backend kann die Extension die Tiefenanalyse verdächtiger URLs, also eine ihrer Funktionen, nicht ausführen.
  • Herstellerverantwortung (Element 3): fallabhängig — hat das Security-Unternehmen das Analyse-Backend selbst entwickelt oder entwickeln lassen, ist Element 3 erfüllt; nutzt die Extension ausschliesslich eine Drittanbieter-Threat-Intelligence-API, die nicht unter seiner Verantwortung entwickelt wurde, ist Element 3 verneint.

Ergebnis: Eigenes Backend → Stufe A, RDPS (Rn. 202 lit. a). Drittanbieter-API → Stufe B: Risikobewertung nach Art. 13 Abs. 2 CRA, zusätzlich die von der Guidance erwartete Sorgfalt (Rn. 202 lit. c).

Die Konsequenzen unterscheiden sich je nach Ergebnis — und beide werden von Extension-Entwicklern oft übersehen. Bei Stufe A (eigenes Backend, RDPS): Die SBOM muss Extension und Backend erfassen, Schwachstellen sind während des Unterstützungszeitraums wirksam zu behandeln, einschliesslich Sicherheitsupdates (Art. 13 Abs. 8, Anhang I Teil II CRA), und die Konformitätsbewertung des Produkts muss das Zusammenspiel aus lokaler Extension und Cloud-Analyse abdecken. Bei Stufe B (Drittanbieter-API): Das Backend durchläuft keine eigene Konformitätsbewertung; verbindlich ist die Risikobewertung nach Art. 13 Abs. 2 CRA; zusätzlich erwartet die Guidance eine entsprechende Sorgfalt. In der SBOM erscheint die lokal eingebundene Client-Bibliothek; den externen Dienst selbst dokumentiert der Hersteller in der technischen Dokumentation (vgl. Rn. 204).

5. White-Label und OEM: Wer trägt die CRA-Pflicht?

Dieser Grenzfall folgt bewusst nicht dem Vorbedingung-/Zwei-Fragen-Muster: Es geht nicht um die RDPS-Einordnung einer Datenverarbeitung, sondern um die vorgelagerte Frage, wer von mehreren Beteiligten überhaupt CRA-Hersteller des Produkts ist.

Ein Softwarehersteller entwickelt ein Produkt und vertreibt es unter eigenem Namen — CRA-pflichtig, klar. Aber was, wenn er dasselbe Produkt zusätzlich als White-Label-Lösung an andere Unternehmen verkauft, die es unter deren eigenem Markennamen auf dem EU-Markt anbieten?

Wer Hersteller ist, richtet sich nach Art. 3 Nr. 13 und — bei Einführern oder Händlern — nach Art. 21 CRA sowie nach dem konkreten Marktauftritt. Wer ein Produkt konzipieren, entwickeln oder herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet, ist selbst Hersteller (Art. 3 Nr. 13 CRA); ein Einführer oder Händler, der ein fertiges Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt, gilt als Hersteller (Art. 21 CRA). Ob und in welchem Umfang daneben der ursprüngliche Produzent für ein eigenes, unter seinem Namen vermarktetes Produkt Hersteller bleibt, ist anhand der konkreten Produkt- und Kennzeichnungskonstellation zu prüfen. Eine Kennzeichnung wie „hergestellt für“ oder „vertrieben durch“ ist dabei ein relevantes Indiz, führt aber nicht ohne Einzelfallprüfung automatisch zu einer bestimmten Rollenverteilung.

Konkretisierung „herstellen“ / „vermarkten“ für Software (Wiebe, § 4 Rn. 28)[5]: Bei Software umfassen Herstellungshandlungen typischerweise Kompilieren, Versionieren, Packen und das Kopieren auf Datenträger; als Herstellungshandlung zählen nach dem Kommentar allerdings nur Tätigkeiten, die sich auf die Cybersicherheit auswirken können. „Vermarkten“ ist ein Sammel- und Auffangbegriff, etwa für Streckengeschäfte, bei denen der Hersteller an der Abgabe nicht unmittelbar beteiligt ist. Diese weite Auslegung hilft gerade in der White-Label-Abgrenzung, weil sie verhindert, dass durch geschickte Vertriebsketten Verantwortlichkeitslücken entstehen.

Warum die Pflicht beim Auftraggeber landet: das Sachherrschaftsäquivalent

Für die Auftragsfertigung — der Markeninhaber lässt das Produkt nach eigenen Vorgaben entwickeln oder herstellen (Art. 3 Nr. 13 Alt. 2 CRA) — ist die Herstellerrolle des Auftraggebers klar; offen ist nur die dogmatische Begründung. Dass der Auftraggeber und nicht der tatsächliche Produzent CRA-Hersteller ist, wirkt auf den ersten Blick ergebnisorientiert. Der 2026 erschienene artikelweise CRA-Kommentar von Schröder/Hartl liefert dafür eine dogmatische Begründung, die gerade für White-Label- und OEM-Modelle einschlägig ist (NK-CRA/Mehnert Art. 3 Rn. 123)[8].

Ausgangspunkt ist, dass für das Inverkehrbringen nach herrschender Meinung auf die Übertragung der Sachherrschaft abgestellt wird. Dieser Ansatz stösst in zwei Konstellationen an seine Grenzen: bei Software, weil mangels Körperlichkeit keine Besitzübertragung stattfinden kann — und in genau der hier behandelten Konstellation, in der jemand ein Produkt durch einen Dritten entwickeln und fertigen lässt, seinen Namen oder seine Marke anbringt und es direkt an den Händler oder Endkunden liefern lässt.

Hersteller im Sinne der Verordnung ist in solchen Konstellationen der Auftraggeber, unter dessen Namen oder Marke das Produkt vermarktet wird. Damit entsteht ein Zurechnungsproblem: Er kann die Besitzübertragung nicht selbst vollziehen, weil er das Produkt nie im eigenen tatsächlichen Besitz hat. Auf das Eigentum lässt sich ebenfalls nicht ausweichen — die Ausgestaltung des Eigentumsrechts fällt in den Mitgliedstaaten zu unterschiedlich aus, um als einheitlicher Anknüpfungspunkt zu taugen.

Das Inverkehrbringen stattdessen dem tatsächlichen Produzenten zuzuschreiben, ist keine Lösung. Nach Art. 13 Abs. 1 CRA[1] sind Hersteller nur dann zur Einhaltung der grundlegenden Anforderungen verpflichtet, wenn sie ein Produkt in den Verkehr bringen. Bräche man Herstellereigenschaft und Inverkehrbringen auseinander, träfen die Pflichten mangels Einführer im Ergebnis niemanden — genau die Verantwortungslücke, die der CRA vermeiden will.

Der Kommentar löst das über ein Sachherrschaftsäquivalent: Spätestens seit Software durch die Produkthaftungsrichtlinie (EU) 2024/2853[6] und durch den CRA unter den Produktbegriff fällt, muss dort, wo eine Anknüpfung an den Besitz nicht möglich ist, ein funktionales Äquivalent an die Stelle der Sachherrschaft treten. Den Besitz übt zwar der Produzent aus; die alleinige Verfügungsmacht über das Ob, das Wie und die Frage, an wen abgegeben wird, liegt aber beim Hersteller. In dieser alleinigen Entscheidungshoheit liegt das Sachherrschaftsäquivalent. Ergebnis: Das Produkt wird auch in dieser Konstellation durch den Auftraggeber in den Verkehr gebracht — er verschafft durch die Beauftragung des Produzenten und dessen Lieferung nicht nur die Nutzungsmöglichkeit, sondern verantwortet allein das Ob und Wie der Übergabe (NK-CRA/Mehnert Art. 3 Rn. 123)[8].

Derselbe Begriff begegnet in Teil 1 dieser Serie bei der Abgrenzung von Cloud-Software — dort für die Frage, ob eine unkörperliche Software überhaupt in den ausschliesslichen Machtbereich des Nutzers übergeht. Hier geht es um die Anschlussfrage, wem dieser Übergang zuzurechnen ist. In beiden Fällen tritt das Sachherrschaftsäquivalent an die Stelle einer Besitzübertragung, die hier wie dort nicht möglich ist — dort, weil unkörperliche Software nicht besitzfähig ist, hier, weil der Auftraggeber das Produkt nie in eigenem Besitz hat.

Einordnend ist festzuhalten: Der Kommentar folgt der herrschenden Meinung, nach der das Bereitstellen einen Wechsel der Sachherrschaft voraussetzt; für die Gegenauffassung verweist er auf Ziffer 2.2 des „Blue Guide“ der EU-Kommission (NK-CRA/Mehnert Art. 3 Rn. 123 Fn. 75)[8]. Die Herleitung baut also auf einer Prämisse auf, die nicht unumstritten ist. Am Befund selbst ändert das wenig: Dass der Markeninhaber Hersteller ist, folgt je nach Konstellation aus Art. 3 Nr. 13 bzw. Art. 21 CRA[1]. Umstritten ist allein, wie sich das dazugehörige Inverkehrbringen dogmatisch konstruieren lässt — relevant wird das, wenn die Zurechnung im Einzelfall bestritten wird.

Wichtig zur Abgrenzung gegenüber dem Produkthaftungsrecht: Im neuen Produkthaftungsrecht (Richtlinie (EU) 2024/2853)[6] können mehrere Haftungsadressaten parallel stehen. Wer CRA-rechtlich nicht Hersteller ist, kann im Schadensfall trotzdem produkthaftungsrechtlich in Anspruch genommen werden. Die CRA-Rollenverteilung befreit also nicht automatisch von zivilrechtlicher Haftung.

In der Praxis wird die CRA-Pflichtverteilung durch Vertrag, Kennzeichnung und Marktauftritt mitgeprägt. Diese Faktoren ersetzen jedoch nicht die rechtliche Einordnung nach Art. 3 Nr. 13, Art. 21 und gegebenenfalls Art. 22 CRA.

Weitere Grenzfälle aus der Guidance

Telemetrie

Daten, die rein zu statistischen Zwecken erhoben werden, sind keine RDPS — selbst wenn sie auf einem Server des Herstellers verarbeitet werden (Rn. 192). Der Grund liegt im Test selbst: Die erste Frage des Zwei-Fragen-Tests — würde das Fehlen dieser Datenverarbeitung das Produkt daran hindern, eine seiner Funktionen auszuführen? — wird hier verneint. Nutzungsmetriken oder Crash-Reports, die zu keiner Produktfunktion beitragen, ergeben damit ein negatives Ergebnis bei Element 2; die Stufen A und B sind ausgeschlossen, es liegt Stufe C vor — mit der Pflicht zur Berücksichtigung in der Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2 CRA (Rn. 193).

Website-Differenzierung

Rn. 194 unterscheidet: Eine Website, auf die das Produkt lediglich für Informationen und Anleitungen weiterleitet, ist keine RDPS. Eine Website, die eine Produktfunktion ermöglicht — etwa ein Authentifizierungsportal, das die für den Betrieb nötigen Zugangsdaten oder Tokens ausgibt —, kann RDPS sein, sofern die übrigen Merkmale erfüllt sind. Ob weitere Portale, etwa Konfigurations- oder Dashboard-Seiten, dazugehören, ist nach demselben Massstab zu prüfen.

Sonderanfertigung ist nicht dasselbe wie Anpassbarkeit

Ein Begriff, den B2B-Anbieter in der Grauzone gerne für sich reklamieren, ist die Sonderanfertigung. Der deutsche Verordnungstext spricht vom „massgeschneiderten Produkt mit digitalen Elementen“, die englische Fassung von tailor-made product. Verankert ist er in Anhang I Teil I Nr. 2 lit. b und in Anhang I Teil II Nr. 8 CRA; Erwägungsgrund 64 CRA erläutert den Gedanken: Hersteller sollen von den grundlegenden Anforderungen nur abweichen können, wenn es sich um Produkte handelt, die für einen bestimmten gewerblichen Nutzer auf einen bestimmten Zweck zugeschnitten sind und bei denen sowohl der Hersteller als auch der Nutzer ausdrücklich anderen Vertragsbedingungen zugestimmt haben[1].

Die Rechtsfolge ist eng. Betroffen sind genau zwei Anforderungen: die sichere Standardkonfiguration (Anhang I Teil I Nr. 2 lit. b) und die Kostenlosigkeit der Sicherheitsaktualisierungen (Anhang I Teil II Nr. 8). Von diesen beiden — und nur von diesen — darf abgewichen werden, wenn die Vertragsbedingungen das ausdrücklich vorsehen. Alle übrigen grundlegenden Anforderungen bleiben unberührt.

Wo die Grenze verläuft. Die FAQ der Kommissionsdienststellen grenzt den Begriff in Nr. 4.2.5 mit Beispielen ab, die genau die hier behandelten Konstellationen treffen[7]: Eine Kundenbeziehungs-Plattform (CRM), die an mehrere Unternehmen verkauft wird, ist keine Sonderanfertigung — auch dann nicht, wenn der Hersteller geringfügige Anpassungen ermöglicht. Ebenso wenig sind es Plattformen, die sich über Plugins oder Schnittstellen anpassen lassen, im Kern aber für jeden Kunden dasselbe Produkt bleiben. Umgekehrt kommt eine Sonderanfertigung etwa in Betracht bei eigens für einen bestimmten gewerblichen Nutzer entwickelter Hard- oder Software oder bei Produkten, die für die Einbettung in dessen streng kontrollierte Umgebung — geschlossene oder physisch getrennte Netze — entwickelt und mit eigenen Vertragsbedingungen versehen werden. Den Sonderanfertigungs-Charakter muss der Hersteller nach Art. 31 CRA zudem in seiner technischen Dokumentation belegen. Die FAQ ist nicht verbindlich, zeigt aber die Auslegungsrichtung.

Nicht verwechseln mit „massgeschneidert“ im RDPS-Test. Beide Begriffe klingen im Deutschen fast gleich, betreffen aber verschiedene Prüfungen. „Massgeschneidert“ in Rn. 195 der Guidance beschreibt, wann eine von Dritten entwickelte serverseitige Software noch „unter der Verantwortung“ des Herstellers steht und damit Element 3 des Zwei-Fragen-Tests erfüllt — es geht dort also um die vorgelagerte Frage, ob überhaupt eine RDPS vorliegt (siehe Teil 2 dieser Serie). Die Sonderanfertigung nach Anhang I betrifft dagegen die nachgelagerte Frage, ob ein Hersteller von zwei einzelnen Anforderungen abweichen darf. Ein Produkt kann massgeschneidert im Sinne von Rn. 195 sein, ohne eine Sonderanfertigung nach Anhang I zu sein — und umgekehrt.

Die strategische Antwort auf Unsicherheit

Für Unternehmen in der Grauzone gibt es drei strategische Ansätze.

Der erste Ansatz ist die konservative Einstufung: Im Zweifel die serverseitige Verarbeitung als RDPS behandeln. Das ist der teuerste, aber sicherste Weg. Die Investition in SBOM-Management, Schwachstellenüberwachung und Konformitätsdokumentation ist in keinem Fall verschwendet — sie verbessert die Produktsicherheit unabhängig von der regulatorischen Einstufung.

Der zweite Ansatz ist die architektonische Entkopplung: Produkte so umzugestalten, dass lokale und entfernte Funktionen unabhängig voneinander angeboten werden. Entscheidend ist jedoch nicht nur der Kernzweck: Frage 8.1.2 ist erst dann mit „Nein“ zu beantworten, wenn das Fehlen der entfernten Verarbeitung keine einzige Produktfunktion verhindert, also auch keine optionale oder unterstützende Funktion. Dann entfällt die RDPS-Problematik; verbleibende Risiken der Datenverbindung sind im Rahmen der Risikobewertung nach Art. 13 Abs. 2 CRA zu berücksichtigen. Das ist ein technisch aufwendiger, aber regulatorisch eleganter Weg.

Der dritte Ansatz ist die differenzierte Bereitstellung: Verschiedene Produktvarianten — eine rein webbasierte (nicht CRA) und eine mit lokaler Komponente (CRA-pflichtig) — mit jeweils eigener Compliance-Strategie anbieten. Das erfordert saubere Produktabgrenzung und transparente Kommunikation gegenüber Kunden.

Stand der Auslegungshilfen

Am 27. Juli 2026 veröffentlichte die Kommission ihre Guidance mit Communication C(2026) 5252 final[3]. Sie ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Für deutsche Unternehmen bietet zudem die BSI TR-03183-H[4] eine praxisnahe Orientierungshilfe zur CRA-Konformitätsbewertung nach Modul H — basierend auf einem ISO/IEC 27001-konformen ISMS. Die Technische Richtlinie liegt inzwischen in Version 1.1.0 vor (Stand: 30.05.2026).

Interessant ist die Richtlinie auch für die Abgrenzungsfrage dieses Artikels: In Kapitel 2 legt das BSI eine eigene Arbeitsdefinition der Datenfernverarbeitungslösung zugrunde — darunter fällt zumindest Software, die vom Hersteller oder in seinem Auftrag entworfen, entwickelt und betrieben wird und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte (unter Verweis auf Art. 3 Nr. 2 CRA). Zugleich stellt das BSI ausdrücklich klar, dass die genaue Abgrenzung von der Guidance der Kommission abhängt[4]. Das zusätzliche Merkmal „betrieben“ der BSI-Arbeitsdefinition hat die finale Guidance nicht übernommen: Nach Rn. 196 kommt es auf den Betreiber nicht an.

Die finale Guidance präzisiert die Grauzone in beide Richtungen. Sie verengt sie durch Klarstellungen: Interne Systeme des Herstellers sind nicht erfasst (Rn. 182), und RDPS umfasst nur die für die Produktfunktion verantwortlichen Softwaremodule und deren Schnittstellen (Rn. 205). Sie erweitert sie durch den weiten Funktionsbegriff, der auch unterstützende Funktionen einschliesst (Rn. 189). Unternehmen in der Grauzone sollten ihre Einstufung deshalb dokumentieren und bei neuen Auslegungshilfen überprüfen.

Das Wichtigste für Hersteller

  • In allen fünf Grenzfällen liegt ein Produkt mit digitalen Elementen vor. Die Grauzone betrifft die Frage, ob die serverseitige Verarbeitung als RDPS Teil des Produkts ist — nicht, ob der CRA überhaupt gilt.
  • Die Einstufung erfolgt je Funktion: Eigene serverseitige Software ist RDPS (Stufe A), eingebundene Drittanbieter-Ferndienste sind Stufe B, Verbindungen ohne Produktfunktion Stufe C. Wer das Backend betreibt, ist unerheblich (Rn. 196).
  • Bei White-Label und OEM ist Hersteller, wer ein Produkt unter eigenem Namen oder eigener Marke vermarktet (Art. 3 Nr. 13, Art. 21 CRA).
  • Eine Sonderanfertigung erlaubt nur Abweichungen von zwei Anforderungen; anpassbare Standardplattformen sind keine Sonderanfertigung.
  • Die Einstufung ist zu dokumentieren und bei neuen Auslegungshilfen zu überprüfen.

Unsicher, ob Ihr Produkt in der CRA-Grauzone liegt? Der CRA-Quick-Check bietet eine kostenlose und unverbindliche Ersteinschätzung zur CRA-Anwendbarkeit, Produktklasse, CRA-Bereitschaft und möglichen Abdeckung durch crAIready. Eine abschliessende Beurteilung erfordert fachkundige Einzelfallprüfung.

Hinweis zur Methodik

Die rechtlichen Aussagen dieses Artikels wurden gegen die Primärquellen geprüft: die Verordnung (EU) 2024/2847 (einschliesslich Anhang I und Erwägungsgrund 64) und die am 27.07.2026 veröffentlichte Communication C(2026) 5252 final mit Annex, Kapitel 8 (Rn. 178–208). Ergänzend herangezogen wurden die FAQ der Kommissionsdienststellen (Version 1.4 vom 04.09.2026, Nr. 4.2.4 und 4.2.5) — von den Kommissionsdienststellen erstellt, nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich — sowie die Technische Richtlinie BSI TR-03183-H, der CRA-Kommentar von Wiebe (2025) und das NK-CRA (Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026); alle drei werden in den jeweiligen Abschnitten als solche ausgewiesen. Die Aussagen zur Hersteller-Zurechnung in Grenzfall 5 (White-Label und OEM) stützen sich auf die Legaldefinition in Art. 3 Nr. 13 und Art. 21 CRA sowie auf die Kommentarliteratur; die dort dargestellte Herleitung über ein Sachherrschaftsäquivalent (NK-CRA/Mehnert Art. 3 Rn. 123) beruht auf einer Prämisse, für deren Gegenauffassung der Kommentar auf Ziffer 2.2 des „Blue Guide“ der EU-Kommission verweist (Fn. 75), und ist als Auffassung der Kommentarliteratur gekennzeichnet, nicht als gesicherte Auslegung. Die Struktur mit drei Elementen und zwei entscheidenden Fragen entspricht dem in Rn. 184–188 beschriebenen Ansatz; die drei möglichen Ergebnisse folgen Rn. 202.

Quellen

[1] 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). ABl. L, 20.11.2024. Hier insbesondere Art. 3 Nr. 1, 2 und 13, Art. 13, Art. 21, Art. 22, Art. 31 sowie Anhang I Teil I Nr. 2 lit. b, Anhang I Teil II Nr. 8 und Erwägungsgrund 64. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[2] 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. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[3] 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).

[4] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie BSI TR-03183-H: „Cyber Resilience Requirements for Manufacturers and Products: Conformity based on full quality assurance (Module H)“, Version 1.1.0 vom 30.05.2026 (Deckblatt und Dokumentenhistorie). Hier insbesondere Kapitel 2 (Arbeitsdefinition der Datenfernverarbeitungslösung unter Verweis auf Art. 3 Nr. 2 CRA). Zur Vorfassung: Ein Community Draft v1.0.0 vom Februar 2026 mit öffentlicher Kommentierung bis zum 31. März 2026 wird auf der BSI-Konsultationsseite genannt; die Dokumentenhistorie der Version 1.1.0 weist ihn nicht aus. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-H_v1_1_0.html?nn=1106058

[5] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 4 Rn. 26–28 (Herstellerbegriff, Quasi-Hersteller und Bedeutung des Marktauftritts, Praxishinweis Rn. 27; Konkretisierung von „herstellen“ und „vermarkten“ bei Software, Rn. 28); Wiebe, § 4 Rn. 29 (wesentliche Änderung nach Art. 22 CRA, etwa durch IT-Dienstleister). Die Rollenverteilung ist anhand der konkreten Produkt- und Kennzeichnungskonstellation zu prüfen.

[6] Richtlinie (EU) 2024/2853 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte und zur Aufhebung der Richtlinie 85/374/EWG. ABl. L, 18.11.2024. https://eur-lex.europa.eu/eli/dir/2024/2853/oj

[7] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026, hier Nr. 4.2.5 (Abgrenzung der Sonderanfertigung) und Nr. 4.2.4 (sichere Standardkonfiguration). Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; lebendes Dokument. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions

[8] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Mehnert, Art. 3 Rn. 123 mit Fn. 75 (Sachherrschaftsäquivalent als Anknüpfungspunkt des Inverkehrbringens bei unkörperlicher Software und in Auftragsfertigungs-/White-Label-Konstellationen; Fn. 75 verweist für die Gegenauffassung zum Sachherrschaftswechsel als Voraussetzung des Bereitstellens auf Ziffer 2.2 des „Blue Guide“ der EU-Kommission 2022). Art. 3 Nr. 21 kommentiert von Mehnert.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 06.04.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: AI Act trifft CRA: Was Art. 12 CRA für KI-Produkte bedeutet — wenn Ihr Produkt nicht nur ein Produkt mit digitalen Elementen, sondern zugleich ein KI-System ist, greifen zwei EU-Verordnungen nebeneinander. Was Art. 12 CRA und Art. 42 Abs. 3 KI-VO für Ihre Compliance-Strategie bedeuten.