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

Von Redaktion codAIx | 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 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

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): Findet die Datenverarbeitung ausserhalb der Betriebsumgebung des Nutzers statt? Dieses Element ist nach Rn. 169 „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. 173–177): 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. 173 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. 179–186): 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, 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. 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 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, Art. 13(5)-Pflichten 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. 173 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. 186 lit. a); für zugekaufte Drittanbieter-Features Komponente — Risikobewertung nach Art. 13 Abs. 2 und Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 186 lit. b). 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. 186 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. 186 lit. b). 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. 186 lit. c).

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. 186 lit. b) 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. 186 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. 186 lit. a). Drittanbieter-API → Komponente mit Risikobewertung nach Art. 13 Abs. 2 und Due Diligence nach Art. 13 Abs. 5 CRA (Rn. 186 lit. b).

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.

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

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 reine Marketing- oder Informationswebsite zu einem separaten Produkt ist keine RDPS (Rn. 178). 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.

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 öffentliche Konsultation zur Draft Communication der EU-Kommission ist am 31. März 2026 abgeschlossen[3]. Stand 8. Mai 2026 ist die finale EU-Kommissions-Guidance noch nicht veröffentlicht; ein Erscheinungsdatum hat die Kommission bislang nicht angekündigt. Die Final-Fassung wird voraussichtlich 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 Technische Richtlinie liegt inzwischen in Version 1.1.0 vor (Stand: 03.07.2026); die Vorfassung, der Community Draft v1.0.0 vom Februar 2026, war bis zum 31. März 2026 öffentlich kommentierbar.

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: 05.04.2026. Zuletzt geprüft am: 03.07.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 und die Draft Communication Ares(2026)2319816, Kapitel 8 (Rn. 162–192). Sekundärquellen — insbesondere der Nomos-Kommentar zum CRA von Wiebe (2025) — werden als solche gekennzeichnet und in den jeweiligen Abschnitten ausgewiesen. 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. Stand: 24.05.2026 (v9 — Element-1-Darstellung präzisiert: Die Distanz ist „relevant, aber nicht hinreichend" und zugleich eine notwendige Voraussetzung, fehlt sie, ist eine RDPS ausgeschlossen; die fünf Grenzfälle auf ein einheitliches Prüfschema umgestellt — Vorbedingung (lokale Anknüpfung, Distanz), dann Zwei-Fragen-Test (Funktionalität, Herstellerverantwortung), Fall 5 als Hersteller-Zurechnung gekennzeichnet; Telemetrie- und Website-Abschnitt präzisiert: Der Zwei-Fragen-Test wird angewendet und ergibt bei fehlender Funktionsnotwendigkeit Kategorie C; eine funktionstragende Website kann RDPS sein, ist aber kein eigenständiges Produkt; Kategorie-B-Ergebnis in den Grenzfällen auf Art. 13 Abs. 2 und 5 CRA ergänzt; Grenzfall 2 um die C-Variante und eine bedingte Distanz-Prüfung erweitert; Grenzfall 3 in zwei Perspektiven (Integrator und SDK-Hersteller) gegliedert, der unzutreffende Integrator-Risiko-Kasten entfernt und durch einen Querverweis auf Artikel 10 ersetzt; Grenzfall 4 nach Kategorie A und B differenziert; Begriffsverwendung vereinheitlicht — „Backend" zu Beginn der Grenzfälle als Kurzform für die serverseitige Datenfernverarbeitung eingeführt und in den abstrakten Passagen durch den Rechtsbegriff „serverseitige Software" bzw. „Datenfernverarbeitung" 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. 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, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", März 2026. Öffentliche Konsultation abgeschlossen am 31. März 2026. Erscheinungsdatum der finalen Fassung von der Kommission bisher nicht angekündigt (https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act).

[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 (Vorfassung: Community Draft v1.0.0, Februar 2026; öffentliche Kommentierung am 31. März 2026 abgelaufen). 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