Die CRA-Grauzone: Hybrid-SaaS, Plugins und die RDPS-Falle — fünf Praxisfälle, die der Test nicht eindeutig löst

Von codAIx GmbH | 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 ohne finale 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 einschließlich 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ößenschwellen erreicht. Und der Orientierungsrahmen mit drei Elementen und zwei entscheidenden Fragen der EU-Kommission[3] bietet einen strukturierten Entscheidungsbaum für die Abgrenzung.

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

Die Draft Communication der Kommission beschreibt in den Rn. 168–172 einen strukturierten Entscheidungsprozess mit drei Elementen und zwei entscheidenden Fragen:

Element 1 — Distanz (Rn. 169): Wird die Datenverarbeitung von einem Server des Herstellers durchgeführt, der räumlich vom lokalen Produkt entfernt ist? Dieses Element ist „relevant aber nicht ausreichend" für sich allein und dient als Kontextprüfung.

Element 2 — Funktionalität (Rn. 170–175): 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": Sie umfasst alle Funktionen des Produkts — nicht nur Basisfunktionalität, sondern auch optionale oder Premium-Features (Rn. 173).

Element 3 — Herstellerverantwortlichkeit (Rn. 179–184): Wurde die serverseitige Software vom Hersteller des Produkts entworfen und entwickelt — oder unter seiner Verantwortung? Das ist die zweite entscheidende kumulative Frage. Sie spiegelt direkt die Legaldefinition in Art. 3 Nr. 2 CRA wider, wonach nur Datenverarbeitung erfasst ist, „for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer". Auch Erwägungsgrund 12 CRA bestätigt: Cloud-Dienste, die „outside the responsibility of a manufacturer" entwickelt wurden, fallen nicht unter den CRA.

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

Aber hier wird es spannend: Rn. 186 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 Art. 13(5)-Sorgfaltspflichten (aber nicht RDPS): Wenn Frage 8.1.2 = Ja, aber Frage 8.1.3 = Nein (z. B. weil das Backend 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 Sicherheitsmaßnahmen (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 das eigene Backend, Art. 13(5)-Pflichten für integrierte Drittanbieter-APIs.

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

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.

Hier wird der Zwei-Fragen-Test präzise: Bei Frage 8.1.2 — „Würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausübt?" — ist die Antwort klar: Ja. Cloud-Speicher, Kollaboration und KI-Features sind tatsächliche Funktionen des Produkts (nicht nur optionale Extras).

Warum ist das so eindeutig? Rn. 173 der Draft Communication macht es unmissverständlich: „The notion of 'functions' is not limited to the product's 'core functionality' or 'intended purpose'." Alle verfügbaren Funktionen zählen — ob optional, gekauft oder freischaltbar. Wenn die Cloud-Features integraler Bestandteil des Produktversprechens sind (und das sind sie, wenn der Hersteller sie bewusst in die Architektur integriert hat), dann gehört ihre Datenverarbeitung zur Funktionalitätsprüfung.

Bei Frage 8.1.3 — Herstellerverantwortlichkeit — wurde die serverseitige Software (Cloud-Speicher, KI-Backend, Kollaborationsserver) vom Hersteller des Designtools selbst entworfen und entwickelt oder unter seiner Verantwortung? In den meisten Fällen: Ja — der Hersteller betreibt sein eigenes Cloud-Backend als integralen Bestandteil seines Produkts. Antwort: Ja.

Ergebnis: RDPS (Rn. 186(a)). Aber Achtung: Nutzt der Hersteller für einzelne Cloud-Features Drittanbieter-APIs (z. B. ein externes KI-Modell), die nicht unter seiner Verantwortung entwickelt wurden, könnte für diese spezifischen Features Frage 8.1.3 = Nein gelten — mit dem Ergebnis: Komponente mit Art. 13(5)-Sorgfaltspflichten statt RDPS. Die konservative Empfehlung bleibt: 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.

Für den CRA stellt sich die Frage: Ist eine Electron-App eine „lokale Softwarekomponente" im Sinne von Art. 3 Nr. 1[1]? Formal ja — der Nutzer installiert Software auf seinem Gerät, die Dateien werden lokal geschrieben, Prozesse werden lokal ausgeführt. Dass die Technologie unter der Haube ein Browser ist, ändert an der CRA-Einstufung nichts. Entscheidend ist die Perspektive des Nutzers und die Bereitstellungsform: Installation auf dem Endgerät gleich lokale Komponente.

Das bedeutet: Jeder Hersteller einer Electron-App, die mit einem Server kommuniziert, durchläuft die beiden Entscheidungsfragen. Die erste Frage (Element 1 — Distanz) ist erfüllt: Ja, es gibt räumlich entfernte Datenverarbeitung. Dann kommt es auf die zwei entscheidenden Fragen an: Würde die fehlende Serververbindung das Produkt funktional einschränken (Frage 8.1.2)? Und wurde die serverseitige Software vom Hersteller der Electron-App entworfen/entwickelt oder unter seiner Verantwortung (Frage 8.1.3)? Wenn beide mit Ja beantwortet werden: RDPS. Wenn 8.1.2 = Ja, aber 8.1.3 = Nein (z. B. weil die Electron-App ausschließlich Drittanbieter-APIs nutzt, die nicht unter Verantwortung des Herstellers entwickelt wurden): Komponente mit Art. 13(5)-Verpflichtungen.

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.

Hier greifen gleich zwei CRA-Dimensionen. Erstens die Komponentenfrage: Das SDK ist ein Produkt mit digitalen Elementen, das als Komponente in Verkehr gebracht wird[1]. Der SDK-Hersteller unterliegt den CRA-Pflichten als Hersteller der Komponente — einschließlich SBOM, Vulnerability Management und Konformitätsbewertung für das SDK selbst.

Zweitens die RDPS-Frage: Wenn das SDK funktional vom Backend des SDK-Herstellers abhängt (Frage 8.1.2 = Ja) und dieses Backend vom SDK-Hersteller selbst entworfen und entwickelt wurde oder unter seiner Verantwortung (Frage 8.1.3 = Ja), liegt eine Datenfernverarbeitungslösung auf Komponentenebene vor[1] (Rn. 186(a)). Der SDK-Hersteller ist für die Sicherheit des Gesamtsystems — SDK plus Backend — verantwortlich.

Für den Integrator — also das Unternehmen, das das SDK in sein Produkt einbaut — bedeutet das: Er muss die CRA-Compliance des SDK-Herstellers in seine eigene SBOM und sein Vulnerability Management einbeziehen. Die Supply-Chain-Anforderungen des CRA greifen hier direkt.

Wenn das SDK jedoch auf ein Backend zugreift, das nicht unter der Verantwortung des SDK-Herstellers entwickelt wurde (Frage 8.1.3 = Nein), aber Frage 8.1.2 = Ja: Dann ist das SDK eine Komponente mit Art. 13(5)-Sorgfaltspflichten (Rn. 186(b)), nicht eine RDPS.

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.

Die CRA-Einordnung: Eine Browser-Extension ist installierte Software auf dem Gerät des Nutzers[1]. Sie hat Zugriff auf lokale Daten (Browsing-Verlauf, Cookies, Seiteninhalt). Element 1 (Distanz): Ja, das Cloud-Backend ist räumlich entfernt. Frage 8.1.2: Ja — ohne Cloud-Backend keine Tiefenanalyse, und die Fähigkeit der Extension, Phishing zu erkennen, ist stark eingeschränkt. Frage 8.1.3: Wurde das Cloud-Backend vom Hersteller der Extension entworfen und entwickelt oder unter seiner Verantwortung? Wenn das Security-Unternehmen sein eigenes Analyse-Backend betreibt: Ja. Ergebnis (Rn. 186(a)): CRA-pflichtig als RDPS. Nutzt die Extension hingegen ausschließlich eine Drittanbieter-Threat-Intelligence-API, die nicht unter Verantwortung des Extension-Herstellers entwickelt wurde, könnte Frage 8.1.3 = Nein gelten — mit dem Ergebnis: Komponente mit Art. 13(5)-Pflichten (Rn. 186(b)).

Das hat Konsequenzen, die viele Extension-Entwickler noch nicht auf dem Schirm haben. Die SBOM muss die Extension und das Backend erfassen. Sicherheitsupdates müssen über den gesamten Lebenszyklus bereitgestellt werden. Und die Konformitätsbewertung muss das Zusammenspiel aus lokaler Extension und Cloud-Analyse abdecken.

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

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 unter ihrem Namen oder ihrer Handelsmarke vermarktet. Beim White-Label-Modell gibt es also potenziell zwei Hersteller: den Entwickler und den Markeninhaber. Beide können CRA-Pflichten treffen — der Entwickler als faktischer Hersteller, der Markeninhaber als derjenige, der das Produkt „unter seinem eigenen Namen oder seiner eigenen Handelsmarke" bereitstellt.

In der Praxis wird sich die Pflichtverteilung vertraglich regeln lassen müssen. Aber eines steht fest: Mindestens einer der beiden muss die CRA-Anforderungen vollständig erfüllen.

Weitere Grenzfälle aus der Guidance

Telemetrie-Ausschluss

Daten, die rein zu statistischen Zwecken erhoben werden, sind nicht RDPS, selbst wenn sie vom Hersteller-Server verarbeitet werden (Rn. 176). Entscheidend ist: Würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausübt? Wenn nein — weil die Daten nur der Nutzungsanalyse oder Fehlerberichterstattung dienen — greift der RDPS-Test nicht. Nutzungsmetriken oder Crash-Reports, die nicht zur Produktfunktionalität beitragen, fallen daher nicht unter den Zwei-Fragen-Test.

Website-Differenzierung

Websites sind nicht pauschal RDPS. Rn. 178 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 Website, die nur dazu dient, ein separates Produkt zu vermarkten, ist nicht selbst ein Produkt mit digitalen Elementen (Rn. 178). Aber eine Website, über die ein Nutzer sein Online-Konto verwaltet, ist es — und dann greifen die Fragen 8.1.2 und 8.1.3.

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 redesignen, dass die lokale und die Cloud-Komponente unabhängig funktionieren. Wenn die lokale App auch ohne Cloud ihren Kernzweck erfüllt, fällt bei Frage 8.1.2 die Antwort „Nein" — und die RDPS-Problematik entfällt (oder reduziert sich auf Outcome b: Komponente mit Art. 13(5)-Verpflichtungen). 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

Die finale Version der EU-Kommissions-Guidance wird voraussichtlich im Sommer 2026 erscheinen[3]. Sie wird weitere Konkretisierungen zu PWAs, Electron-Apps und Feature-gated Modellen liefern. 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 Grauzone wird kleiner, nicht größer. Jede neue Guidance, jede Interpretation durch die Kommission oder nationale Behörden wird den CRA-Anwendungsbereich eher ausdehnen als einschränken. Unternehmen, die sich heute in der Grauzone wähnen, sollten sich nicht darauf verlassen, dass sie dort bleiben.

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 Art. 95 AI Act für Ihre Compliance-Strategie bedeuten.

Unsicher, ob Ihr Produkt in der CRA-Grauzone liegt? Der crAIready Quick Check identifiziert auch die Grenzfälle systematisch — mit konkreten Handlungsempfehlungen und Verweisen auf die relevante EU-Guidance.

Hinweis zur Methodik

Alle Aussagen in diesem Artikel sind direkt gegen die Primärquellen verifiziert: die Verordnung (EU) 2024/2847 und die Draft Communication Ares(2026)2319816, Kapitel 8 (Rn. 162–192). Sekundärquellen werden als solche gekennzeichnet. Die Struktur mit drei Elementen und zwei entscheidenden Fragen entspricht genau dem in Rn. 168–172 beschriebenen Ansatz; die drei möglichen Ergebnisse folgen Rn. 186.

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. 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 Maßnahmen 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, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", März 2026. Konsultationsfrist: 13. April 2026.

[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)", Community Draft v1.0.0, Februar 2026. Kommentierungsfrist: 31. März 2026. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-H_v1_0_0.html?nn=1106058