Von Redaktion codAIx | 23. März 2026

Ist meine Software CRA-pflichtig oder nicht? Diese Frage hat Softwarehersteller seit Inkrafttreten des Cyber Resilience Act am 10. Dezember 2024 beschäftigt. Seit März 2026 gibt es dazu eine veröffentlichte Orientierungshilfe der EU-Kommission mit einem strukturierten Test, der die Abgrenzung zwischen CRA-pflichtiger Datenfernverarbeitung und reinen Cloud-Diensten operationalisiert. Am 27. Juli 2026 hat die Kommission den Inhalt des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs gebilligt; dieser Annex ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 3. März 2026 [1]. Wir erklären, wie der Test in der veröffentlichten Annex-Fassung funktioniert — und spielen ihn an konkreten Praxisbeispielen durch.

Warum ein Test nötig wurde

Im ersten Teil dieser Serie haben wir die grundlegende Abgrenzung dargestellt: Der CRA erfasst „Produkte mit digitalen Elementen“ einschliesslich ihrer Datenfernverarbeitungslösungen (Remote Data Processing Solutions, RDPS) [2]. Reine Cloud-Dienste ohne lokale Produktkomponente fallen nicht unter den CRA, sondern unter die NIS-2-Richtlinie [5], sofern der Anbieter die dort definierten Schwellenwerte erreicht.

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

Wichtig für die Abgrenzung zur NIS-2-Sphäre: Das hauseigene Netz- und Informationssystem des Herstellers — etwa interne IT, Buchhaltungssysteme oder allgemeine Unternehmens-IT — bleibt, soweit es nicht produktnotwendig ist, ausserhalb des CRA-Anwendungsbereichs. Die Guidance stellt das in Rn. 182 ausdrücklich klar: „internal systems relating to the manufacturer's own human resources, payrolls, customer relationship management, continuous integration/continuous delivery (CI/CD) pipelines, the distribution of security updates to edge locations, should not be considered as RDPS“ [1]. Ebenso ausserhalb des RDPS-Anwendungsbereichs liegen laut Rn. 182 Systeme für Audit- und Testaktivitäten wie Penetrationstests, Threat Hunting und Red Teaming. Der CRA adressiert das Produkt und seine produktnotwendigen Bestandteile, nicht die gesamte IT-Landschaft des Herstellers.

In der Praxis hat sich allerdings schnell gezeigt: Die Grenze zwischen CRA-pflichtiger RDPS und reiner Cloud-Software ist alles andere als trennscharf. Wann genau ist eine Server-Komponente „integraler Bestandteil“ eines lokalen Produkts? Reicht ein optionaler Cloud-Sync? Zählt ein Browser-Plugin als „lokale Komponente“?

Die EU-Kommission hat auf diese Unsicherheit reagiert. Am 3. März 2026 hatte sie zunächst unter dem Aktenzeichen Ares(2026)2319816 einen Entwurf mit dem Titel „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ zur Konsultation veröffentlicht. Am 27. Juli 2026 hat die Kommission den Inhalt des als Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs gebilligt [1]. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Das rund 70 Seiten starke Dokument umfasst weiterhin neun nummerierte Kapitel — von der Scope-Abgrenzung über Open-Source-Software, wesentliche Änderungen und Support-Perioden bis zur Datenfernverarbeitung und dem Zusammenspiel mit anderen EU-Rechtsakten. Die Kommission hatte bereits beim Entwurf vier inhaltliche Schwerpunkte hervorgehoben: Datenfernverarbeitung (RDPS), freie und Open-Source-Software, Support-Perioden sowie das Zusammenspiel des CRA mit anderen EU-Rechtsakten. Einzelne Kanzleipublikationen — etwa Linklaters in ihrem Client Briefing vom März 2026 — hatten den Entwurf in zehn Kernpunkten für die Praxis strukturiert [3]. Kapitel 8 widmet sich ausschliesslich der Frage, wann Remote-Datenverarbeitung als RDPS unter den CRA fällt; in der veröffentlichten Annex-Fassung umfasst es Rn. 178–208 (statt zuvor Rn. 162–192 im Entwurf). Zum Stand 12. August 2026 steht die förmliche Annahme noch aus. Die Guidance schafft auch nach ihrer Annahme 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.

Hinweis zur Quellenlage: Sämtliche Randnummern-Verweise in diesem Artikel beziehen sich auf den von der Kommission am 27. Juli 2026 inhaltlich gebilligten und als Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurf. Herangezogen werden insbesondere Kapitel 7.3 (Rn. 167–173) und Kapitel 8 (Rn. 178–208). Die frühere Entwurfsnummerierung vom 3. März 2026 wird nur noch bei der Darstellung der Quellenentwicklung genannt.

Die Vorfrage: Existiert überhaupt ein CRA-Produkt?

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

Drei Elemente, zwei entscheidende Fragen

Die Kommission zerlegt die RDPS-Prüfung in drei Elemente, die sich aus der Legaldefinition in Art. 3 Nr. 2 CRA ergeben (Rn. 184):

  1. Findet die Datenverarbeitung „auf Distanz“ (at a distance) statt?
  2. Würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausführt?
  3. Wurde die Software vom Hersteller des Produkts entworfen und entwickelt — oder unter dessen Verantwortung?

Hinweis zur Reihenfolge: Die Kommission ordnet die drei Tatbestandsmerkmale analytisch um. Der Wortlaut von Art. 3 Nr. 2 CRA selbst listet sie in der Reihenfolge Distanz → Hersteller → Funktion auf. Die Kommission zieht in Rn. 184 die Funktionsprüfung vor die Herstellerprüfung, weil das die sachlich klarere Prüfungsreihenfolge ergibt: zuerst wird die substantielle Hürde (Funktion) geprüft, dann die Verantwortungszurechnung (Hersteller). Die rechtsdogmatische Substanz bleibt identisch — der Verordnungstext und die Kommissions-Guidance prüfen dieselben drei Voraussetzungen. Wir folgen in diesem Artikel der Kommissionsreihenfolge, weil sie didaktisch klarer ist.

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

Wo die eigentliche Prüfungsarbeit liegt, ist in Element 2 und Element 3. Die Kommission formuliert es in Rn. 188 unmissverständlich: Nur wenn beide Fragen bejaht werden, liegt eine RDPS vor. Es handelt sich also um einen kumulativen Zwei-Fragen-Test auf der Grundlage der notwendigen Vorbedingung Distanz — nicht um eine streng sequenzielle Dreier-Kaskade.

Auch die Kommentarliteratur liest die Definitionsmerkmale des Art. 3 Nr. 2 CRA kumulativ (Wiebe/Jossen, § 4 Rn. 3, 5) [4].

Element 1: Datenverarbeitung „auf Distanz“

Die Kommission nutzt den Begriff „auf Distanz“ bewusst weit (Rn. 186). Erwägungsgrund 11 des CRA unterscheidet zwischen Daten, die „lokal auf dem Gerät des Nutzers“ verarbeitet werden, und solchen, die „vom Hersteller fernverarbeitet“ werden. Remote-Datenverarbeitung findet typischerweise ausserhalb der Betriebsumgebung des Nutzers statt — sei es in der Cloud, im Rechenzentrum des Herstellers oder bei einem Dienstleister.

Wichtig dabei: Eine RDPS muss nicht auf der Cloud-Infrastruktur eines Drittanbieters laufen. Die Kommission stellt in Rn. 187 ausdrücklich klar, dass auch eine Verarbeitung auf den eigenen lokalen Servern des Herstellers eine RDPS sein kann. Eine Lösung, die der Hersteller in seinem eigenen Rechenzentrum und auf einer Private Cloud betreibt, qualifiziert ebenso als RDPS wie eine Lösung auf einer Public Cloud bei einem externen Anbieter — der Betriebsort entscheidet nicht.

Worauf es für die „Distanz“ ankommt, ist deshalb nicht, wem die Server gehören, sondern ein einziger Bezugspunkt: die Betriebsumgebung des Nutzers. Remote-Datenverarbeitung liegt vor, wenn die Verarbeitung ausserhalb dieser Umgebung stattfindet (Rn. 186) — gleichviel, ob die Server dem Hersteller, einem Cloud-Anbieter oder einem sonstigen Dienstleister gehören. Verarbeitung auf den Servern des Herstellers und Verarbeitung bei einem Drittanbieter sind also beide „auf Distanz“; die Eigentümer- und Entwicklerfrage gehört nicht zu Element 1, sondern zu Element 3. Die Kehrseite folgt aus der Definition selbst: Art. 3 Nr. 2 CRA macht die entfernt stattfindende Verarbeitung zum konstitutiven Tatbestandsmerkmal, und Rn. 186 misst „entfernt“ an der Umgebung des Nutzers — beim professionellen Nutzer einschliesslich seiner eigenen betrieblichen Umgebung. Läuft die Software innerhalb dieser Umgebung — etwa eine Lösung, die der Kunde auf seinen eigenen Servern in seiner eigenen Betriebsumgebung installiert und betreibt —, fehlt die Distanz, und eine RDPS scheidet schon an Element 1 aus.

„Keine RDPS“ bedeutet dabei aber nicht „kein CRA“. Erwägungsgrund 11 CRA stellt ausdrücklich klar, dass ein Produkt „in seiner Gesamtheit“ gesichert sein muss — „unabhängig davon, ob die Daten lokal auf dem Gerät des Nutzers oder aus der Ferne durch den Hersteller verarbeitet oder gespeichert werden“. Software, die der Hersteller zur Installation beim Kunden in Verkehr bringt, ist selbst ein Produkt mit digitalen Elementen (Art. 3 Nr. 1 CRA) und unterliegt dem CRA unmittelbar als Produkt. Die RDPS-Konstruktion des Art. 3 Nr. 2 CRA ist nur der Brückenkopf für die ferne Verarbeitung; die lokale Verarbeitung braucht diese Brücke nicht, weil sie bereits das Produkt selbst ist.

Ebenso wenig schliesst Edge Computing eine RDPS-Qualifikation aus: Auch Verarbeitung „nahe am Gerät“ kann „auf Distanz“ stattfinden (Rn. 186).

Element 2: Verhindert das Fehlen eine Funktion des Produkts?

Hier liegt der substantielle Kern der Prüfung. Die Kommission definiert „Funktionen“ dabei bewusst weit — und das ist eine der wichtigsten Klarstellungen der gesamten Guidance.

Der Gesetzeswortlaut spricht davon, dass das Fehlen der Datenverarbeitung das Produkt daran hindern würde, „eine seiner Funktionen auszuführen.“ Die Kommission betont (Rn. 189): Dieser Begriff ist nicht auf die Kernfunktionalität oder den bestimmungsgemässen Zweck des Produkts beschränkt. Der CRA kennt eine solche Einschränkung nicht. Erfasst sind sowohl Funktionen, die den Hauptzweck des Produkts unmittelbar erfüllen, als auch solche, die die Gesamtleistung des Produkts unterstützen.

Die Kommission listet in Rn. 190 konkrete Beispiele für Funktionen auf, deren Fehlen eine RDPS-Qualifikation begründen kann:

  • Senden von Steuerbefehlen an ein Gerät
  • Synchronisierung von Dateien
  • Onboarding des Nutzers
  • Konfiguration und Personalisierung des Produkts
  • Automatisierte Verteilung von Updates, einschliesslich Feature-Updates und Sicherheitspatches
  • Identitäts- und Zugriffsverwaltung

Die Erwähnung von Updates ist bemerkenswert: Ein Produkt, das seinen Update-Mechanismus über einen Server des Herstellers abwickelt, kann allein dadurch eine RDPS-Komponente haben — wenn das Fehlen dieses Mechanismus verhindert, dass das Produkt Sicherheits- oder Funktionsupdates erhält.

Umgekehrt gibt es eine klare Ausschlussregel (Rn. 192): Datenverarbeitung, die nicht dazu dient, eine Produktfunktion zu erfüllen, ist keine RDPS. Das betrifft insbesondere die rein statistische Analyse von Telemetriedaten oder die Verarbeitung von Nutzungsdaten für zukünftige Produktentwicklung.

Auch hier lässt die Kommission den Hersteller nicht vollständig aus der Verantwortung: Selbst wenn eine Datenverarbeitung keine Produktfunktion trägt, muss der Hersteller prüfen, ob die betreffenden Remote-Komponenten Risiken einführen, und diese im Rahmen seiner Cybersicherheits-Risikobewertung berücksichtigen und gegebenenfalls durch produktseitige Massnahmen mindern (Rn. 193).

Auch das Thema Websites wird adressiert (Rn. 194): Eine reine Informationswebsite zum Produkt ist keine RDPS — auch dann nicht, wenn das Produkt auf diese Website verweist. Aber eine Website, die eine Produktfunktion ermöglicht oder unterstützt — zum Beispiel ein Authentifizierungsportal, das Zugangsdaten oder Tokens für den Betrieb des Produkts bereitstellt — kann RDPS sein (sofern auch die übrigen Kriterien der Definition erfüllt sind).

Ein weiterer praxisrelevanter Hinweis (Rn. 191): Auch wenn eine Funktion sowohl lokal als auch ferngesteuert ausgeführt werden kann (z. B. eine smarte Glühbirne, die per App und per Schalter bedienbar ist), schliesst die Möglichkeit der lokalen Nutzung die RDPS-Qualifikation nicht aus. Die Remote-Funktionalität bleibt eine Funktion, die das Produkt anbietet.

Element 3: Vom Hersteller entworfen und entwickelt?

Die dritte Frage zielt auf die Verantwortlichkeit. Die Guidance präzisiert in Rn. 195 den Begriff „unter der Verantwortung“: Erfasst sind Remote-Datenverarbeitungslösungen, die massgeschneidert für den Hersteller sind. Es reicht nicht aus, lediglich ein bestehendes Produkt eines Drittanbieters zu lizenzieren, das der Anbieter auch anderen Kunden zur Verfügung stellt, oder eine geringfügig angepasste Version davon zu nutzen. Rn. 195 legt dafür in der veröffentlichten Annex-Fassung folgende Kriterien an:

  • Die Software ist massgeschneidert („tailor-made“) für den Hersteller.
  • Sie wird ausschliesslich im Auftrag des Herstellers oder unter dessen Verantwortung entwickelt.
  • Sie basiert auf den vom Hersteller vorgegebenen Spezifikationen und Designs.

Hinweis zur Quellenentwicklung: Der Entwurf vom 3. März 2026 hatte an dieser Stelle (dort Rn. 179) noch ein viertes Kriterium genannt — die eigentumsrechtliche Erwerbung der Technologie durch den Hersteller im Gegensatz zu blosser Lizenzierung. Die veröffentlichte Annex-Fassung (Rn. 195) enthält dieses Eigentums-/Lizenzkriterium nicht mehr; sie beschränkt sich auf die drei oben genannten, kumulativ zu lesenden Kriterien. Für die Praxis ändert das wenig an der entscheidenden Trennlinie: massgeschneiderte Auftragsentwicklung nach Vorgaben des Herstellers einerseits, Lizenzierung eines am Markt angebotenen Standardprodukts andererseits — nur eben ohne die (in der Praxis ohnehin schwer nachweisbare) Eigentumsfrage als eigenständiges Prüfkriterium.

Auf dieser Grundlage differenziert die Kommission zwischen verschiedenen Cloud-Servicemodellen (Rn. 197–200):

Infrastructure as a Service (IaaS): Der Hersteller betreibt eigene Software auf der Infrastruktur eines Cloud-Anbieters (z. B. AWS, Azure). Die Software ist vom Hersteller entworfen und entwickelt — sie kann als RDPS qualifizieren, wenn die übrigen Elemente erfüllt sind (Rn. 198). Dass die Infrastruktur von einem Dritten stammt, ist unerheblich.

Platform as a Service (PaaS): Der Hersteller entwickelt eine eigene Anwendung auf der Plattform eines Drittanbieters. Da der Hersteller die Kontrolle über die Anwendung hat, gilt sie als unter seiner Verantwortung entworfen und entwickelt — sie kann als RDPS qualifizieren (Rn. 199).

Software as a Service (SaaS) von Drittanbietern: Hier bietet ein SaaS-Anbieter eine fertige Anwendung an, die der Hersteller in sein Produkt integriert. Der Hersteller hat nur begrenzten Einfluss auf die Konfiguration. Die Anwendung ist nicht vom Hersteller entworfen und entwickelt — sie ist daher keine RDPS (Rn. 200). Eine Drittanbieter-SaaS könnte nur dann unter die Herstellerverantwortung fallen, wenn sie nach den drei oben genannten Kriterien tatsächlich massgeschneidert für den Hersteller entwickelt wurde — also faktisch eine Auftragsentwicklung in fremder Betriebsumgebung. Klassische Multi-Tenant-SaaS wie Stripe, Auth0, Okta, Salesforce oder Dropbox API fallen nie darunter, weil sie als Standardprodukte für viele Kunden vermarktet werden.

Entscheidend ist dabei (Rn. 196): Wer die Lösung betreibt (operates), ist für die RDPS-Qualifikation nicht massgeblich. Massgeblich ist allein, wer sie entworfen und entwickelt hat. Ein Hersteller, der seine Server-Software bei AWS hosten lässt, bleibt der Entwickler — auch wenn AWS den Betrieb übernimmt.

Wo endet die RDPS im Systemverbund?

Die Guidance ergänzt in Rn. 205–206 einen eigenständigen Abgrenzungsgrundsatz, der über den Zwei-Fragen-Test hinausgeht und für die Praxisbeispiele im nächsten Abschnitt wichtig ist: Die RDPS, die Teil des Produkts sind und damit dessen Konformitätsbewertung unterliegen, beschränken sich auf diejenigen Softwaremodule, die für die Funktion des Produkts verantwortlich sind, sowie auf die Schnittstellen, über die diese Module mit externen Diensten kommunizieren (Rn. 205). Weitere, nachgelagerte Backend-Systeme, die die Verarbeitung fortsetzen und mit denen das Produkt nicht direkt interagiert, gelten nicht als RDPS.

Das bedeutet aber nicht, dass diese nachgelagerten Systeme aus der Verantwortung des Herstellers herausfallen: Sie bleiben externe Abhängigkeiten, die im Rahmen der Cybersicherheits-Risikobewertung zu berücksichtigen und durch produktseitige Massnahmen abzusichern sind (Rn. 206). Dieser Grundsatz erklärt, warum im Banking-Beispiel weiter unten das Kontoverwaltungs- und Ledger-System der Bank keine RDPS sind, obwohl sie Teil derselben Systemlandschaft sind wie die Banking-Schnittstelle, mit der die App direkt kommuniziert.

Die drei Ergebnisse des Tests

Die Kommission definiert in Rn. 202 drei mögliche Ergebnisse — und das ist eine weitere wichtige Klarstellung, die über ein schlichtes „ja/nein“ hinausgeht:

Allen drei Ergebnissen ist dabei eines gemeinsam: Element 1 ist erfüllt — die Verarbeitung findet auf Distanz statt. Die drei Ergebnisse klassifizieren ausschliesslich Datenverarbeitung, die diese Vorbedingung bereits erfüllt; unterschieden wird auf dieser Stufe nur noch danach, wie Element 2 und Element 3 ausfallen. Fehlt schon die Distanz, wird keines dieser Ergebnisse erreicht — dann liegt bereits keine Datenfernverarbeitung im Sinne des Tests vor.

Ergebnis A — Element 2 und 3 bejaht: Die Datenverarbeitung qualifiziert als RDPS. Sie muss in die Cybersicherheits-Risikobewertung einbezogen werden, die SBOM muss sie abdecken, und die grundlegenden Cybersicherheitsanforderungen des Anhangs I gelten für das Gesamtprodukt.

Ergebnis B — Element 2 bejaht, Element 3 verneint: Die Drittanbieter-Lösung ist funktional notwendig, wurde aber nicht vom Hersteller entwickelt. In diesem Fall ist sie keine RDPS — aber der Hersteller unterliegt trotzdem konkreten CRA-Pflichten. Er muss die Drittanbieter-Lösung wie eine integrierte Komponente behandeln (Rn. 201 i. V. m. Rn. 202 lit. c). Das bedeutet konkret:

  • Risikobewertung nach Art. 13 Abs. 2 CRA: Die von der Drittanbieter-Lösung ausgehenden Risiken müssen in die produktbezogene Cybersicherheits-Risikobewertung einfliessen — insbesondere die Frage, was passiert, wenn der Dienst ausfällt, kompromittiert wird oder seine Sicherheitseigenschaften ändert.
  • Due Diligence nach Art. 13 Abs. 5 CRA: Der Hersteller muss aktiv prüfen, ob die Drittanbieter-Lösung den Sicherheitsanforderungen genügt. Rn. 170–171 der veröffentlichten Annex-Fassung unterscheiden diese Pflicht von der allgemeinen Risikobewertung und nennen als mögliche Nachweise insbesondere technische Spezifikationen, Sicherheitsdokumentation sowie einschlägige Konformitäts- oder Assurance-Dokumentation des Komponentenherstellers. Soweit angemessen, kann der Hersteller zusätzlich eigene Tests durchführen.
  • Produktseitige Massnahmen: Risiken aus externen Diensten oder Infrastrukturen, die nicht Teil des Produkts sind, muss der Hersteller nach Rn. 168–169 durch Massnahmen am eigenen Produkt behandeln. Genannt werden beispielsweise kryptografische Authentifizierung entfernter Befehle, Integritätsprüfungen, sicherheitsrelevante Protokolle oder Warnungen sowie ein sicherer Zustand des Produkts bei Ausfall des externen Dienstes.
  • SBOM: Die Drittanbieter-Komponente erscheint in der SBOM des Produkts als Top-Level-Abhängigkeit (Anhang I Teil II Nr. 1 i. V. m. Art. 13 Abs. 24 CRA; BSI TR-03183-2). Die SaaS selbst durchläuft aber keine eigene CRA-Konformitätsbewertung — sie wird nur als Komponente beschrieben.

Wichtig: Diese Pflichten kommen ausschliesslich aus dem CRA — nicht aus der NIS-2-Richtlinie oder einem anderen Gesetz. Der CRA ist herstellerzentriert: Wer ein Produkt auf den EU-Markt bringt, ist für dessen Sicherheit verantwortlich, einschliesslich aller Abhängigkeiten, die er nicht selbst entwickelt hat.

Ergebnis C — Element 2 verneint: Die Datenverarbeitung dient keiner Produktfunktion (z. B. reine Telemetrie für Nutzungsstatistiken). Sie ist weder RDPS noch Komponente. Aber auch hier entlässt der CRA den Hersteller nicht vollständig aus der Verantwortung: Er muss die von dieser Datenverbindung ausgehenden Risiken in seiner allgemeinen Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2 CRA berücksichtigen (Rn. 193). Der Grund: Auch eine nicht-funktionale Datenverbindung kann Angriffsfläche schaffen — etwa wenn ein Telemetrie-Endpunkt kompromittiert wird und als Einfallstor in das Produkt dient.

Element 3 spielt für Ergebnis C keine Rolle. Anders als bei A und B kommt es hier allein auf Element 2 an: Sobald die Funktionsnotwendigkeit verneint ist, steht das Ergebnis fest — die Prüfung erreicht Element 3 (wurde die Software vom Hersteller entwickelt?) gar nicht mehr. Die Kommission bringt das in Rn. 202 ausdrücklich zum Ausdruck: Ergebnis A verlangt die Bejahung beider entscheidenden Fragen, Ergebnis B die Bejahung der Funktionsfrage bei verneinter Herstellerfrage — Ergebnis C dagegen knüpft allein an die verneinte Funktionsfrage an; die Herstellerfrage wird in der Beschreibung von Ergebnis C (Rn. 202 lit. b) nicht mehr genannt. Die praktische Folge: Kategorie C umfasst beide Konstellationen — herstellereigene nicht-funktionale Datenverbindungen (etwa eigene Nutzungstelemetrie) ebenso wie solche von Drittanbietern (etwa Google Analytics oder ein Crash-Reporting-Dienst).

Die drei Stufen im Überblick

Der CRA kennt also kein binäres „CRA-pflichtig oder nicht“. Stattdessen gibt es drei abgestufte Pflichtniveaus, die alle aus dem CRA selbst stammen:

| Ergebnis | Einstufung | CRA-Pflichten | |----------|-----------|---------------| | A (Element 2 + 3 bejaht) | RDPS | Volle CRA-Compliance: Anhang I, SBOM mit RDPS-Abdeckung, Schwachstellenmanagement, Konformitätsbewertung für das Gesamtprodukt inkl. Server-Komponente | | B (Element 2 bejaht, Element 3 verneint) | Komponente | Eingeschränkte CRA-Pflichten: Risikobewertung (Art. 13 Abs. 2), Due Diligence (Art. 13 Abs. 5), produktseitige Sicherheitsmassnahmen, SBOM-Eintrag als Top-Level-Abhängigkeit | | C (Element 2 verneint) | Weder RDPS noch Komponente | Minimale CRA-Pflicht: Berücksichtigung in der allgemeinen Risikobewertung (Art. 13 Abs. 2) |

Alle drei Stufen setzen dabei Element 1 (Distanz) als erfüllt voraus; sie unterscheiden sich allein darin, wie Element 2 und Element 3 ausfallen.

Entscheidend ist: Auch Ergebnis B und C sind CRA-Pflichten — keine freiwilligen Empfehlungen. Wer glaubt, durch Outsourcing an SaaS-Anbieter oder durch Verlagerung in die Cloud der CRA-Regulierung vollständig zu entkommen, verkennt die Systematik der Verordnung.

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

Damit die Abgrenzung greifbar wird, hier je drei Beispiele pro Ergebnis aus der Lebenswelt einer Juristin oder eines Compliance-Beauftragten:

Ergebnis A — RDPS (volle CRA-Pflicht):

  • Eine Smart-Türschloss-App (z. B. August, Nuki) mit Hersteller-App auf dem Smartphone und Hersteller-Cloud, die die Zugriffsrechte prüft. Ohne die Cloud lässt sich die Tür nicht per App öffnen, und die Cloud-Software stammt vom Hersteller.
  • Eine Banking-App einer konkreten Bank mit deren eigener Banking-Schnittstelle, die die Authentifizierung und die Anbahnung der Transaktionen abwickelt (Primärbeispiel der Kommission, Abschnitt 8.3.1). Das Kontoverwaltungs- und Ledger-System der Bank, das nicht direkt mit der App kommuniziert, ist nach Abschnitt 8.3.1 selbst keine RDPS — bleibt aber eine externe Abhängigkeit für die Risikobewertung.
  • Eine DocuSign-ähnliche Plattform, deren Desktop-Plugin nur mit dem hauseigenen Signaturserver funktioniert.

Ergebnis B — Drittanbieter-Komponente (Komponentenpflichten):

  • Eine Branchensoftware, die für die Login-Anmeldung Auth0 oder Okta nutzt — die Authentifizierung ist produktnotwendig (ohne sie kann der Nutzer das Produkt nicht öffnen), aber Auth0 und Okta sind Standard-Drittprodukte.
  • Ein e-Reader, der bei einem Drittanbieter-Cloudspeicher (z. B. Dropbox-API) Bücher synchronisiert (Primärbeispiel der Kommission, Abschnitt 8.3.3).
  • Eine Fuhrpark- oder Logistik-App mit lokalem Smartphone-Client, die für ihre Kernfunktion — die Routenführung — auf einen Karten- und Navigationsdienst eines Drittanbieters (z. B. Google Maps Platform, Mapbox) zugreift. Ohne den Kartendienst kann die App ihre zentrale Funktion nicht ausführen — er ist also funktional notwendig, aber als Standardprodukt des Drittanbieters nicht vom Hersteller entwickelt.

Ergebnis C — nur Risikobewertung:

  • Software, die Absturzberichte an Sentry oder Bugsnag schickt, damit der Hersteller Fehler analysieren kann — nicht produktfunktional.
  • Software mit Matomo- oder Google-Analytics-Integration zur reinen Nutzungsstatistik.
  • Hersteller-Telemetrie, mit der Nutzungsdaten zur Produktverbesserung gesammelt werden.

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

Fünf Praxisbeispiele aus der Guidance

Die Kommission selbst illustriert den Test in Abschnitt 8.3 an fünf Szenarien. Wir stellen sie im Folgenden alle fünf vor:

Beispiel 1: Banking-App mit zwei Datenströmen (Abschnitt 8.3.1). Das Kommissionsszenario zeigt eine Banking-App mit zwei verschiedenen Datenströmen — und damit zugleich, dass ein einziges Produkt mehrere Ergebnisse nebeneinander tragen kann.

Datenstrom 1 — selbst entwickelte Banking-Schnittstelle für Transaktionen. Die Banking-Schnittstelle wurde vom Finanzinstitut selbst entwickelt und self-hosted; sie authentifiziert den Kunden und wickelt die Transaktionen ab.

  • Element 1 (Distanz): erfüllt — die Verarbeitung läuft auf den Servern des Instituts, ausserhalb des Geräts.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die Banking-Schnittstelle kann die App ihre Kernfunktion, die Abwicklung von Transaktionen, nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Schnittstelle wurde vom Finanzinstitut selbst entworfen und entwickelt.

Ergebnis: Die Banking-Schnittstelle ist RDPS und in die CRA-Pflichten des Gesamtprodukts einbezogen. Das Kontoverwaltungs- und das Ledger-System hingegen sind logisch getrennt und interagieren nicht direkt mit der App — sie sind keine RDPS (vgl. den Abgrenzungsgrundsatz aus Rn. 205–206 oben), bleiben aber externe Abhängigkeiten, deren Risiken (etwa eine Manipulation von Transaktionsergebnissen) in die Risikobewertung einfliessen und durch produktseitige Massnahmen abzusichern sind.

Datenstrom 2 — Drittanbieter-SaaS für den Support-Chat. Für die Kundenbetreuung integriert das Institut eine Chat-Lösung, die ein Drittanbieter entwickelt, gestaltet und betreibt (SaaS-Modell).

  • Element 1 (Distanz): erfüllt — der Chat läuft auf der Infrastruktur des Drittanbieters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — die Kommission ordnet den Support-Chat ausdrücklich einer Funktion des Produkts zu.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt — die Chat-Software stammt vollständig vom Drittanbieter.

Ergebnis: Keine RDPS, aber Behandlung wie eine Drittanbieter-Komponente — Due Diligence und produktseitige Massnahmen wie die Abschottung des Chats von den Kern-Bankfunktionen, die Kontrolle der Datenflüsse und die Validierung von Inhalten.

Damit vereint schon dieses eine Beispiel eine RDPS (Banking-Schnittstelle), eine Drittanbieter-Komponente (Support-Chat) und externe Abhängigkeiten ohne eigenen RDPS-Charakter (Kontoverwaltungs- und Ledger-System) — genau den Mix, den die Praxis prägt.

Beispiel 2: Smart-Thermostat mit Cloud (Abschnitt 8.3.2). Ein Smart-Thermostat-Hersteller lässt die Steuerungssoftware, über die Mobile App und Thermostat Daten austauschen und speichern, auf einer IaaS-Infrastruktur eines Drittanbieters laufen.

  • Element 1 (Distanz): erfüllt — die Verarbeitung findet in der Cloud statt, ausserhalb des Geräts.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die ferne Verarbeitung funktioniert der Thermostat nicht (keine Temperatursteuerung via App).
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Steuerungssoftware wurde vom Hersteller entworfen und entwickelt; dass sie auf fremder IaaS läuft, ist unerheblich.

Ergebnis: RDPS. Der Hersteller muss die RDPS und die Abhängigkeit von der Drittanbieter-IaaS in der technischen Dokumentation und der Risikobewertung erfassen.

Beispiel 3: e-Reader mit Drittanbieter-Speicher (Abschnitt 8.3.3). Ein e-Reader nutzt einen SaaS-Speicherdienst eines Drittanbieters, um die gekauften Bücher der Kunden zu speichern und zugänglich zu machen.

  • Element 1 (Distanz): erfüllt — die Speicherung erfolgt auf den Servern des SaaS-Anbieters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den Speicherdienst kann der e-Reader eine seiner Funktionen nicht ausführen.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt — der SaaS-Speicherdienst wurde nicht vom Hersteller entworfen und entwickelt; der Anbieter stellt ihn beliebigen Kunden für beliebige Zwecke bereit.

Ergebnis: Keine RDPS. Der Hersteller muss den SaaS-Dienst aber wie eine Drittanbieter-Komponente behandeln — mit Risikobewertung, Due Diligence und produktseitigen Sicherheitsmassnahmen wie sicherer Authentifizierung, Verschlüsselung und Integritätsschutz der Kommunikation.

Beispiel 4: Industrieroboter mit kamerabasierter Teileerkennung (Abschnitt 8.3.4). Ein Industrieroboter hat die Aufgabe, Teile aufzunehmen. Er sendet über Kameras erfasste Bilddaten an einen vom Hersteller entworfenen und entwickelten Remote-Dienst, der auf der IaaS-Infrastruktur eines Drittanbieters läuft. Der Cloud-Dienst berechnet anhand der Kamerabilder die Position eines Teils und sendet Befehle an den Roboter zurück, damit dieser das Teil aufnehmen kann.

  • Element 1 (Distanz): erfüllt — die Bildverarbeitung findet auf der Cloud-Infrastruktur statt, ausserhalb des Roboters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne diese Verarbeitung kann der Roboter keine Teile aufnehmen.
  • Element 3 (Hersteller-Verantwortung): erfüllt — die Software wurde vom Hersteller entwickelt; dass sie auf der IaaS eines Drittanbieters läuft, ist unerheblich (vgl. Element 3 und die IaaS-Fallgruppe oben).

Ergebnis: RDPS. Der Hersteller muss die RDPS sowie die Abhängigkeit von der Dritt-IaaS in der technischen Dokumentation erfassen und bei der Auswahl des IaaS-Anbieters Due Diligence ausüben — etwa durch Einholung eines Nachweises der NIS-2-Konformität des Anbieters. Für Hersteller aus dem Maschinen- und Anlagenbau ist dieses Beispiel besonders anschlussfähig, weil es die RDPS-Prüfung mit der parallel zu beachtenden Maschinenverordnung verknüpft.

Beispiel 5: Smartphone mit Mobilfunknetz (Abschnitt 8.3.5). Ein Smartphone benötigt ein Mobilfunknetz (z. B. 5G) für Internet, Telefonie und Nachrichten. Die Kommission stellt klar: Das Netz ist kein RDPS. Entlang der drei Elemente wird deutlich, warum:

  • Element 1 (Distanz): wäre erfüllt — die Netzverarbeitung findet ausserhalb des Geräts statt. Damit ist aber nur die notwendige Vorbedingung erfüllt; ob eine RDPS vorliegt, entscheidet sich an Element 2 und 3.
  • Element 2 (Funktionsnotwendigkeit): nicht erfüllt. Das Netz ist ein blosser Kommunikationskanal, kein vom Produkt benötigter Verarbeitungsdienst. Sein Fehlen hindert das Smartphone nicht daran, die Funktion „sich korrekt mit einem Netz verbinden“ auszuführen — das Gerät arbeitet korrekt, es hat lediglich keine Verbindung.
  • Element 3 (Hersteller-Verantwortung): nicht erfüllt. Das Mobilfunknetz wird von den Telekommunikationsbetreibern entworfen, entwickelt und betrieben — nicht vom Smartphone-Hersteller. Art. 3 Nr. 2 CRA verlangt aber Software, die der Hersteller des Produkts selbst entwickelt oder verantwortet.

Ergebnis: Da der Test kumulativ Element 2 und 3 verlangt und hier beide fehlen, liegt keine RDPS vor. Das Netz ist auch keine Drittanbieter-Komponente — es ist keine Software in das Produkt integriert, das Produkt nutzt das Netz lediglich. Es besteht daher keine Due-Diligence-Pflicht gegenüber dem Netzbetreiber. Gleiches gilt für Ethernet-Kabel, Router und WLAN.

Was der Test nicht klärt

So hilfreich die Guidance als Orientierungshilfe ist — einige Konstellationen bleiben offen.

Progressive Web Apps (PWAs): Eine PWA wird über den Browser installiert, kann offline arbeiten und lokal Daten speichern. Ist sie ein „Produkt mit digitalen Elementen“ mit eigener RDPS? Die Guidance adressiert PWAs nicht explizit. Aus der Logik der Guidance (Rn. 194 zu Websites) lässt sich ableiten: Sobald eine PWA über eine reine Informationswebsite hinausgeht und aktive Produktfunktionen bereitstellt, dürfte sie als lokale Komponente gelten — mit der Konsequenz, dass verbundene Server-Verarbeitung die RDPS-Prüfung auslöst.

Optionale Komponenten: Wenn ein Produkt eine lokale Komponente anbietet, die nur ein Teil der Kunden nutzt — wird das gesamte Produkt CRA-pflichtig? Die Guidance geht auf diesen Fall nicht direkt ein. Die Definition in Art. 3 Nr. 1 CRA stellt allerdings auf das Produkt ab, das auf dem Markt bereitgestellt wird — nicht auf die individuelle Nutzung durch einzelne Kunden.

Telemetrie-Grauzone: Rn. 192 schliesst rein statistische Telemetrie von der RDPS-Qualifikation aus. Aber was ist mit Telemetrie, die indirekt eine Produktfunktion ermöglicht — etwa wenn Nutzungsdaten zur Personalisierung des Produkterlebnisses verwendet werden? Hier bleibt Interpretationsspielraum.

Diese offenen Punkte werden auch durch die veröffentlichte Annex-Fassung nicht abschliessend geklärt und dürften erst durch nachfolgende Leitlinien oder die Praxis der Marktüberwachungsbehörden konkretisiert werden. Bis dahin gilt: Im Zweifel konservativ einstufen und CRA-Pflicht annehmen.

Der strategische Blick

Für Softwareunternehmen in der DACH-Region hat der Test eine unmittelbare strategische Bedeutung, die über Compliance hinausgeht.

Zum einen schafft er Planungssicherheit. Wer den Test durchspielt und zu einem klaren Ergebnis kommt, kann seine Compliance-Strategie auf einer belastbaren Grundlage aufbauen — sei es die Vorbereitung auf die CRA-Anforderungen oder die Ausrichtung auf NIS-2.

Zum anderen macht der Test sichtbar, dass Produktarchitektur-Entscheidungen jetzt regulatorische Konsequenzen haben. Die Entscheidung, ob eine Funktion lokal oder serverseitig implementiert wird, ist nicht mehr nur eine technische — sie ist eine Compliance-Entscheidung. Besonders relevant: Auch die Wahl zwischen Eigenentwicklung und SaaS-Integration (Element 3) hat direkte regulatorische Auswirkungen.

Ein dritter Punkt verdient besondere Aufmerksamkeit: Die abgestuften Pflichten aus Ergebnis B und C (siehe oben) bedeuten, dass jede Form der Server-Kommunikation regulatorische Konsequenzen hat — selbst wenn das Ergebnis keine RDPS ist. Für Unternehmen, die viele Drittanbieter-Dienste integrieren, wird die Due-Diligence-Pflicht nach Art. 13 Abs. 5 CRA zum zentralen Compliance-Thema.

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

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Veröffentlicht am: 23.03.2026. Zuletzt geprüft am: 13.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Die abgestuften CRA-Pflichten nach Art. 13 — was Hersteller bei Risikobewertung, Due Diligence und produktseitigen Sicherheitsmassnahmen konkret leisten müssen, auch wenn keine RDPS vorliegt.

Quellen

[1] Europäische Kommission, 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).

[2] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyber Resilience Act), insbesondere Art. 3 Nr. 1 (Definition: Produkt mit digitalen Elementen) und Art. 3 Nr. 2 (Definition: Datenfernverarbeitungslösung) sowie Erwägungsgrund 11. ABl. L, 20.11.2024. Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[3] Linklaters, „EU Cyber Resilience Act: Commission issues first draft guidance – 10 key points you need to know“, Client Briefing März 2026. Verfügbar unter: https://techinsights.linklaters.com/post/102mmlo/eu-cyber-resilience-act-commission-issues-first-draft-guidance-10-key-points-y. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; bezieht sich auf den zwischenzeitlich durch den veröffentlichten Annex zu C(2026) 5252 als aktuelle Auswertungsgrundlage abgelösten Entwurf vom März 2026.

[4] Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3, 5. Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025.

[5] 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), insbesondere Art. 2 und 3 sowie Anhang I Nr. 8 und 9 zu Cloud-Computing- und Rechenzentrumsdiensten. ABl. L 333 vom 27.12.2022. Verfügbar unter: https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Hinweis zur Methodik

Dieser Artikel basiert auf der Analyse des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs (rund 70 Seiten), insbesondere auf Kapitel 7.3 (Rn. 167–173) und Kapitel 8 (Rn. 178–208), sowie auf dem Verordnungstext (EU) 2024/2847. Ergänzend wurde die deutsche Kommentarliteratur herangezogen, insbesondere Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Die Kommission hat den Inhalt des Guidance-Entwurfs am 27.07.2026 gebilligt. 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. Ob der Wortlaut bis zur förmlichen Annahme unverändert bleibt, lässt C(2026) 5252 offen. Die zuvor noch nach dem Entwurf zitierten Due-Diligence- und Produktmassnahmen sind nun anhand der veröffentlichten Annex-Fassung auf Rn. 168–171 aktualisiert.

Stand: 12.08.2026 (v17 — Erscheinungsdatum im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 23.03.2026 gesetzt; zeitabhängige Formulierungen unverändert. v16 — Verfahrensstatus der Guidance präzisiert; unzutreffende Aussage einer bereits abgeschlossenen Übersetzung in alle Amtssprachen und die unbelegte Erwartung ausbleibender Änderungen gestrichen; Bezeichnung als finale Guidance korrigiert; Entwurfsverweise zu Due Diligence und produktseitigen Massnahmen auf Rn. 168–171 der veröffentlichten Annex-Fassung aktualisiert. Die historischen Versionshinweise bleiben unverändert).

Stand: 13.08.2026 (v18 — freigegebene Schlusskorrektur: Schreibweisen und Komposita vereinheitlicht; fehlende Quelle [5] zur NIS-2-Richtlinie ergänzt. Vorherige Fassung: v17; zeitabhängige Formulierungen unverändert.)

Stand: 23.05.2026 (v9 — Vorfrage nach dem Produkterfordernis ergänzt; Querverweis auf Artikel 00 und 01 präzisiert und Art.-3-Nr.-1-Zitat korrigiert; Ergebnis-B-Beispiel ersetzt; alle vier Praxisbeispiele einheitlich entlang der drei Elemente strukturiert; Beispiel 1 um die Datenströme Support-Chat (SaaS) und Transaktionsbenachrichtigungen (PaaS) aus Abschnitt 8.3.1 erweitert. v10 — Klarstellung ergänzt, dass Ergebnis C allein an Element 2 anknüpft und Element 3 dort nicht mehr geprüft wird, Rn. 186 lit. c. v11 — Element 1 präzisiert: Bezugspunkt der „Distanz“ ist die Betriebsumgebung des Nutzers, nicht die Eigentümerschaft an der Infrastruktur (Art. 3 Nr. 2 CRA, Rn. 170/171); klargestellt, dass Software, die in der Umgebung des Nutzers läuft, mangels Distanz keine RDPS ist, als vom Hersteller in Verkehr gebrachtes Produkt mit digitalen Elementen nach Art. 3 Nr. 1 CRA und Erwägungsgrund 11 aber gleichwohl dem CRA unterliegt; den mehrdeutigen Begriff „On-Premises“ in der Element-1-Darstellung vermieden, da Rn. 171 ihn von den Räumlichkeiten des Herstellers aus denkt; klargestellt, dass die Distanz zwar „nicht hinreichend“, aber eine notwendige Voraussetzung ist und ihr Fehlen eine RDPS ausschliesst; in der Übersicht der drei Ergebnisse ergänzt, dass A, B und C die erfüllte Distanz (Element 1) voraussetzen; das Stufe-C-Label in der Übersichtstabelle von „Weder noch“ auf „Weder RDPS noch Komponente“ vereinheitlicht, konsistent mit Artikel 03). v15 (05.08.2026) — Anpassung an die von der Kommission am 27.07.2026 gebilligte finale Fassung der Guidance (Communication C(2026) 5252 final, Annex), die den Entwurf Ares(2026)2319816 vom 03.03.2026 ersetzt: sämtliche Randnummern-Verweise in Kapitel 8 von der Entwurfs- auf die finale Nummerierung (Rn. 178–208) umgestellt, einschliesslich der Korrektur der Ergebnis-B/C-Buchstaben in Rn. 202 (in der finalen Fassung ist lit. b die Risikobewertungs-Variante ohne Funktionsnotwendigkeit und lit. c die Komponenten-Variante — umgekehrt zur bisherigen Zählung); Quellenfussnote [1] auf die finale Fassung aktualisiert; Element-3-Kriterienliste auf die in Rn. 195 tatsächlich genannten drei Kriterien reduziert und das dort ersatzlos entfallene Entwurfskriterium der eigentumsrechtlichen Erwerbung der Technologie kenntlich gemacht; neuen Abschnitt „Wo endet die RDPS im Systemverbund?“ mit dem Abgrenzungsgrundsatz aus Rn. 205–206 (RDPS beschränkt auf funktionstragende Module und ihre Schnittstellen zu externen Diensten; nachgelagerte, nicht direkt kontaktierte Backend-Systeme sind keine RDPS, bleiben aber externe Abhängigkeiten mit Risikobewertungspflicht) ergänzt; im Banking-App-Beispiel (Abschnitt 8.3.1) den in der finalen Fassung nicht mehr enthaltenen dritten Datenstrom (PaaS-Transaktionsbenachrichtigungen) entfernt und Beispiel auf zwei Datenströme reduziert; fünftes Praxisbeispiel „Industrieroboter mit kamerabasierter Teileerkennung“ (Abschnitt 8.3.4) ergänzt und Beispiel-Nummerierung entsprechend angepasst; Abschnittstitel „Vier Praxisbeispiele aus der Draft Communication“ zu „Fünf Praxisbeispiele aus der Guidance“ geändert; Footer-Datierung („Zuletzt geprüft am“) und Methodik-Hinweis aktualisiert.)