Die CRA-Grauzone: Hybrid-SaaS, Plugins und die RDPS-Falle

Von Redaktion codAIx | 6. April 2026

Der Zwei-Fragen-Test der EU-Kommission klärt viele Fälle. Aber nicht alle. Zwischen dem klaren „CRA-pflichtig“ und dem klaren „nur NIS-2“ liegt eine Grauzone, in der sich zahlreiche Softwarehersteller wiederfinden. Dieser Artikel analysiert die schwierigsten Abgrenzungsfälle — und zeigt, wie Unternehmen auch mit dem veröffentlichten Guidance-Entwurf 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 nicht unter den CRA, sondern unter das NIS-2-Regime[2], sofern der Anbieter die dort definierten Grössenschwellen erreicht. 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 ein Unternehmen CRA-Compliance aufbauen muss — oder nicht.

Drei Elemente und zwei entscheidende Fragen: Struktur und Ergebnisse

Der veröffentlichte Guidance-Entwurf der Kommission beschreibt in den Rn. 184–188 einen strukturierten Entscheidungsprozess mit drei Elementen und zwei entscheidenden Fragen:

Element 1 — Distanz (Rn. 185): Findet die Datenverarbeitung ausserhalb der Betriebsumgebung des Nutzers statt? Dieses Element ist nach Rn. 185 „relevant, aber nicht ausreichend“ für sich allein — die Distanz begründet also keine RDPS im Alleingang. 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 entworfen und entwickelt — oder unter seiner Verantwortung? Das ist die zweite entscheidende kumulative Frage. Nach Rn. 195 des veröffentlichten Guidance-Entwurfs 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. Sie spiegelt direkt die Legaldefinition in Art. 3 Nr. 2 CRA wider, wonach nur Datenverarbeitung erfasst ist, die der Hersteller selbst entwirft und entwickelt oder unter seiner Verantwortung entwickeln lässt. 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. RDPS (Remote Data Processing Solution): Wenn Frage 8.1.2 = Ja (funktional notwendig) UND Frage 8.1.3 = Ja (vom Hersteller entworfen/entwickelt oder unter seiner Verantwortung)
2. Komponente mit Sorgfaltspflichten nach Art. 13 Abs. 5 (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)
3. Nur Risikobewertung erforderlich: Wenn Frage 8.1.2 = Nein

Ergebnis 2 ist entscheidend für die „CRA-Grauzone“: Das Produkt ist nicht als RDPS reguliert, unterliegt aber dennoch konkreten CRA-Pflichten — Risikobewertung nach Art. 13 Abs. 2, Due Diligence nach Art. 13 Abs. 5 und produktseitige Sicherheitsmassnahmen (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, Pflichten nach Art. 13 Abs. 5 für integrierte 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 — auch optionale, gekaufte oder freischaltbare Features zählen.
• Herstellerverantwortung (Element 3): in der Regel erfüllt — betreibt der Hersteller sein eigenes Cloud-Backend (Speicher-, KI-, Kollaborationsserver) als integralen Bestandteil des Produkts, hat er es entworfen und entwickelt. Bindet er für einzelne Features einen Drittanbieter-Dienst ein (etwa ein externes KI-Modell), ist Element 3 für genau dieses Feature verneint.

Ergebnis: Für die selbst entwickelten Cloud-Komponenten RDPS (Rn. 202 lit. a); für zugekaufte Drittanbieter-Features Komponente — Risikobewertung nach Art. 13 Abs. 2 und Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 202 lit. c). Die konservative Empfehlung bleibt: im Zweifel CRA-Pflicht annehmen und die SBOM entsprechend aufbauen.

2. Electron-Apps und Desktop-Wrapper

Electron-basierte Anwendungen sind allgegenwärtig: Slack, VS Code, Discord, Figma Desktop. Technisch handelt es sich 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). Betreibt der Kunde den Server in seiner eigenen Umgebung, fehlt die Distanz und eine RDPS scheidet schon hier aus.

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 entworfen und entwickelt oder unter seiner Verantwortung?

Ergebnis: Ist die Distanz erfüllt, entscheidet der Zwei-Fragen-Test. Beide Fragen bejaht → RDPS (Rn. 202 lit. a). Element 2 bejaht, Element 3 verneint — etwa weil die App ausschliesslich nicht vom Hersteller verantwortete Drittanbieter-APIs nutzt — → Komponente mit Risikobewertung nach Art. 13 Abs. 2 und Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 202 lit. c). Element 2 verneint — die Serververbindung trägt keine Produktfunktion, etwa reine Telemetrie — → Kategorie 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 entworfen und entwickelt? Nein, es ist ein fremdes SDK.
• Ergebnis: Für den Integrator ist das SDK eine Komponente (Stufe B) — er trägt dafür eine Risikobewertung nach Art. 13 Abs. 2 und eine Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 202 lit. c) und führt das SDK als Top-Level-Abhängigkeit in seiner SBOM.

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 entworfen und entwickelt? In aller Regel ja auf beide Fragen.
• 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 ist die Kernfunktion der Extension, die Phishing-Erkennung, stark eingeschränkt.
• Herstellerverantwortung (Element 3): fallabhängig — betreibt das Security-Unternehmen sein eigenes Analyse-Backend, 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 → RDPS (Rn. 202 lit. a). Drittanbieter-API → Komponente mit Risikobewertung nach Art. 13 Abs. 2 und Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 202 lit. c).

Die Konsequenzen unterscheiden sich je nach Ergebnis — und beide werden von Extension-Entwicklern oft übersehen. Bei Kategorie A (eigenes Backend, RDPS): Die SBOM muss Extension und Backend erfassen, Sicherheitsupdates sind über den gesamten Lebenszyklus bereitzustellen, und die Konformitätsbewertung des Produkts muss das Zusammenspiel aus lokaler Extension und Cloud-Analyse abdecken. Bei Kategorie B (Drittanbieter-API): Das Backend durchläuft keine eigene Konformitätsbewertung; es gelten Risikobewertung und Due Diligence nach Art. 13 Abs. 2 und 5 CRA, und das Backend erscheint als Top-Level-Abhängigkeit in der SBOM.

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?

Art. 3 Nr. 13 CRA[1] definiert den Hersteller als die natürliche oder juristische Person, die ein Produkt mit digitalen Elementen entwickelt oder herstellt — oder ein bereits entwickeltes Produkt unter ihrem Namen oder ihrer Handelsmarke vermarktet. Der CRA kennt damit pro Produkt nur einen Hersteller: entweder den faktischen Hersteller, der das Produkt gestaltet und herstellt, oder den Quasi-Hersteller, der ein fremdes Produkt unter eigener Marke in Verkehr bringt. Die beiden Rollen stehen alternativ-exklusiv zueinander, nicht kumulativ (Wiebe § 4 Rn. 26)[5].

Welche der beiden Rollen greift, hängt entscheidend von der Marktauftritts- und Kennzeichnungspraxis ab. Wiebe § 4 Rn. 27[5] weist auf eine in der Praxis sehr relevante Differenzierung hin: Eine klare Kennzeichnung wie „hergestellt für: …“ oder „vertrieben durch: …“ verhindert die Quasi-Hersteller-Stellung des Markeninhabers. Tritt der Markeninhaber damit erkennbar nur als Vertriebspartner auf, bleibt der faktische Hersteller alleiniger Adressat der Herstellerpflichten. Fehlt eine solche Kennzeichnung und erscheint das Produkt am Markt allein unter der Marke des Vertriebspartners, rutscht dieser hingegen in die Quasi-Hersteller-Position — und der ursprüngliche Entwickler ist dann nicht mehr CRA-Hersteller dieses Produkts.

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. Der Begriff „vermarkten“ ist als Auffangbegriff zu verstehen, der auch Streckengeschäfte und reine Distributionsmodelle erfasst. 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

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.

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 weicht mit dieser Begründung ausdrücklich vom „Blue Guide“ der EU-Kommission ab, auf dessen Ziffer 2.2 er als abweichende Auffassung verweist[8]. Die Herleitung ist also nicht unumstritten. Am Befund selbst ändert das wenig: Dass der Markeninhaber Hersteller ist, folgt bereits aus Art. 3 Nr. 13 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] gilt dies ausdrücklich anders — dort können mehrere Haftungsadressaten parallel stehen. Wer also CRA-rechtlich nicht Hersteller ist, kann im Schadensfall trotzdem produkthaftungsrechtlich in Anspruch genommen werden. Die alternative Hersteller-Zuordnung im CRA befreit also nicht automatisch von zivilrechtlicher Haftung.

In der Praxis lässt sich die CRA-Pflichtverteilung damit über Vertrag und Marktauftritt steuern. Aber: Genau einer der Beteiligten ist CRA-Hersteller — und dieser muss die CRA-Anforderungen vollständig erfüllen.

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 Ergebnisse A und B sind ausgeschlossen, es liegt Kategorie C vor — mit der Pflicht zur Berücksichtigung in der Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2 CRA (Rn. 193).

Website-Differenzierung

Websites sind nicht pauschal RDPS. Rn. 194 unterscheidet:

• Informative Website: Nur statische Inhalte (Produktbeschreibungen, FAQs, Downloads). Nicht RDPS.
• Funktionale Website: Authentifizierungsportale, datengesteuerte Dashboards, Benutzerkonfigurationstools. Diese können RDPS sein, wenn die Datenverarbeitung des Servers für eine Produktfunktion notwendig ist.

Eine reine Marketing- oder Informationswebsite zu einem separaten Produkt ist keine RDPS (Rn. 194). Eine Website dagegen, die eine Produktfunktion trägt — etwa ein Portal, über das der Nutzer das für den Produktbetrieb nötige Konto verwaltet —, kann eine RDPS sein. Ob sie es ist, ist mit dem Zwei-Fragen-Test (Funktionalität und Herstellerverantwortung) zu klären.

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 technischen FAQs der Kommissionsdienststellen grenzen 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 FAQs sind von den Kommissionsdienststellen erstellt und nach eigener Angabe weder eine offizielle Position der Kommission noch verbindlich; sie zeigen 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 CRA-Pflicht annehmen. Das ist der teuerste, aber sicherste Weg. Die Investition in SBOM-Management, Vulnerability Monitoring 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.

Was kommt als Nächstes

Am 27. Juli 2026 hat die Kommission den Inhalt des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs gebilligt[3]. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten. Diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten. Ob der Wortlaut bis zur förmlichen Annahme unverändert bleibt, lässt C(2026) 5252 offen. 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); eine Vorfassung als Community Draft v1.0.0 vom Februar 2026, öffentlich kommentierbar bis zum 31. März 2026, ist eine Angabe der BSI-Konsultationsseite — die Dokumentenhistorie der Version 1.1.0 selbst führt keine Vorfassung auf.

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]. Auch eine nationale Behörde arbeitet an dieser Stelle also mit einer Behelfsdefinition.

Die bisherige Tendenz deutet darauf hin, dass die Grauzone mit jeder neuen Guidance-Veröffentlichung enger wird. Jede Interpretation durch die Kommission oder nationale Behörden hat bislang den CRA-Anwendungsbereich eher ausgedehnt als eingeschränkt. Unternehmen, die sich heute in der Grauzone wähnen, sollten sich nicht darauf verlassen, dass sie dort bleiben.

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

Im nächsten Artikel dieser Serie: AI Act trifft CRA — wenn Ihr Produkt nicht nur ein Produkt mit digitalen Elementen, sondern gleichzeitig ein KI-System ist, greifen zwei EU-Verordnungen gleichzeitig. Was Art. 12 CRA und Erwägungsgrund 77 AI Act für Ihre Compliance-Strategie bedeuten.

Unsicher, ob Ihr Produkt in der CRA-Grauzone liegt? Der CRA-Quick-Check unterstützt Sie bei der Identifikation potenzieller Grenzfälle — mit orientierenden Hinweisen und Verweisen auf die relevante EU-Guidance. Eine abschliessende Beurteilung erfordert fachkundige Einzelfallprüfung.

Hinweis zur Methodik

Alle Aussagen in diesem Artikel sind direkt gegen die Primärquellen verifiziert: die Verordnung (EU) 2024/2847 (einschliesslich Anhang I und Erwägungsgrund 64) und die Communication C(2026) 5252 final, Annex, Kapitel 8 (Rn. 178–208). Ergänzend herangezogen wurden die technischen FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026, Nr. 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 Nomos-Kommentar zum CRA von Wiebe (2025) und der artikelweise CRA-Kommentar von Schröder/Hartl (Nomos, 1. Auflage 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 CRA sowie auf die Kommentarliteratur; die dort dargestellte Herleitung über ein Sachherrschaftsäquivalent (NK-CRA/Mehnert, Art. 3 Rn. 123) weicht nach eigener Angabe des Kommentars von Ziffer 2.2 des „Blue Guide“ der EU-Kommission ab und ist als Auffassung der Kommentarliteratur gekennzeichnet, nicht als gesicherte Auslegung. Die Struktur mit drei Elementen und zwei entscheidenden Fragen entspricht genau dem in Rn. 184–188 beschriebenen Ansatz; die drei möglichen Ergebnisse folgen Rn. 202. Ergänzend ist der Verfahrensstatus des Guidance-Entwurfs berücksichtigt: Sein Inhalt wurde am 27.07.2026 gebilligt; die förmliche Annahme steht bis zum Vorliegen aller Sprachfassungen noch aus. Erst danach soll die Guidance als offizielle, weiterhin unverbindliche Auslegungshilfe der Kommission verwendet werden.

Versionshinweis (v17, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 06.04.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Versionshinweis (v16, 12.08.2026): Der Guidance-Status wurde im Vorspann, im Abschnitt „Was kommt als Nächstes“, in der Methodik und in Quelle [3] präzisiert. Die Bezeichnung als finale Guidance und die unbelegte Erwartung ausbleibender Änderungen wurden korrigiert. Die historischen Versionshinweise bleiben unverändert.

Stand: 06.08.2026 (v15 — Grenzfall 5 „White-Label und OEM“ um den Unterabschnitt „Warum die Pflicht beim Auftraggeber landet: das Sachherrschaftsäquivalent“ ergänzt: dogmatische Herleitung der Hersteller-Zurechnung nach NK-CRA/Mehnert, Art. 3 Rn. 123 — Grenzen der Sachherrschafts-Anknüpfung bei unkörperlicher Software und bei Auftragsfertigung, Untauglichkeit einer Anknüpfung an das Eigentum, Zusammenhang von Herstellereigenschaft und Inverkehrbringen nach Art. 13 Abs. 1 CRA, Lösung über die alleinige Entscheidungshoheit des Auftraggebers als Sachherrschaftsäquivalent —, mit Querverweis auf die gleichbedeutende Verwendung des Begriffs in Teil 1 der Serie und mit dem Hinweis auf die im Kommentar ausgewiesene Abweichung vom Blue Guide, Ziffer 2.2; Quellenverzeichnis um Eintrag [8] (Schröder/Hartl, Nomos 2026) erweitert; Methodik-Hinweis entsprechend ergänzt). Vorherige Fassung (v14, Stand 06.08.2026): Datum der BSI TR-03183-H Version 1.1.0 von „03.07.2026“ auf den im PDF-Deckblatt und in der Dokumentenhistorie genannten Stand 30.05.2026 korrigiert, im Fliesstext und in Fussnote [4]; die Angabe zur Vorfassung „Community Draft v1.0.0, Februar 2026“ als Information der BSI-Konsultationsseite gekennzeichnet, da die Dokumentenhistorie der Version 1.1.0 nur einen einzigen Eintrag enthält und keine Vorfassung ausweist; neuer Abschnitt „Sonderanfertigung ist nicht dasselbe wie Anpassbarkeit“ ergänzt — Rechtsgrundlage Anhang I Teil I Nr. 2 lit. b, Anhang I Teil II Nr. 8 und Erwägungsgrund 64 CRA, Abgrenzung nach FAQ Nr. 4.2.5 (CRM-Plattform mit geringfügigen Anpassungen und Plugin-/Schnittstellen-Anpassbarkeit sind keine Sonderanfertigung), ausdrückliche Abgrenzung vom RDPS-Kriterium „massgeschneidert“ aus Rn. 195; Abschnitt „Was kommt als Nächstes“ um die Arbeitsdefinition der Datenfernverarbeitungslösung aus BSI TR-03183-H Kap. 2 ergänzt; Quellenverzeichnis um Eintrag [7] (FAQs der Kommissionsdienststellen) erweitert; Stichtagsangabe im Fliesstext auf 06.08.2026 aktualisiert. Vorherige Fassung (v13, Stand 05.08.2026): Anpassung an die finale EU-Kommissions-Guidance C(2026) 5252 final, Annex, deren Inhalt am 27.07.2026 von der Kommission gebilligt wurde und den bisherigen Entwurf Ares(2026)2319816 vom 03.03.2026 ersetzt: sämtliche Randnummern-Verweise im Artikel auf die Nummerierung der finalen Fassung umgestellt (u. a. Rn. 168–172 → 184–188, Rn. 169 → 185, Rn. 173–177 → 189–193, Rn. 179–186 → 195–202, Rn. 176 → 192, Rn. 178 → 194); dabei ist zu beachten, dass die Kommission in der finalen Fassung die Buchstaben-Zuordnung der drei Ergebnisse gegenüber dem Entwurf vertauscht hat — Rn. 202 lit. b bezeichnet jetzt die reine Risikobewertung (vormals „Ergebnis C“), Rn. 202 lit. c die Komponentenbehandlung (vormals „Ergebnis B“); alle fünf Grenzfälle wurden entsprechend korrigiert; Element-3-Beschreibung um die Definition „unter der Verantwortung des Herstellers“ aus Rn. 195 final ergänzt; Abschnitt „Was kommt als Nächstes“ und Methodik-Hinweis auf den Verfahrensstand aktualisiert; Quellenverzeichnis Eintrag [3] durch die finale Primärquelle ersetzt.

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. 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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026. Der Annex ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten (Stand 12.08.2026). 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, Andreas (Hrsg.): Cyber Resilience Act — Verordnung (EU) 2024/2847. Nomos-Kommentar, 1. Auflage 2025. Hier insbesondere § 4 Rn. 26 (alternativ-exklusive Hersteller-Stellung), Rn. 27 (Kennzeichnungspraxis „hergestellt für“ / „vertrieben durch“), Rn. 28 (Konkretisierung „herstellen“ / „vermarkten“ für Software) und Rn. 29 (wesentliche Änderung nach Art. 22 CRA bei IT-Dienstleistern und Integratoren).

[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.3 vom 01.07.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, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 21 kommentiert von Mehnert. Hier insbesondere Art. 3 Rn. 123 (Sachherrschaftsäquivalent als Anknüpfungspunkt des Inverkehrbringens bei unkörperlicher Software und in Auftragsfertigungs-/White-Label-Konstellationen; die Fussnote zu Rn. 123 verweist auf Ziffer 2.2 des „Blue Guide“ der EU-Kommission 2022 als abweichende Auffassung).

Stand: 13.08.2026 (v18 — freigegebene Schlusskorrektur: Art. 13 Abs. 5 einheitlich zitiert und die Entkopplungspassage an den weiten Funktionsbegriff des RDPS-Tests sowie das Ergebnis der Risikobewertung nach Art. 13 Abs. 2 angepasst. Vorherige Fassung: v17; zeitabhängige Formulierungen unverändert.)