Mit dieser Verordnung soll ein hohes Niveau an Cybersicherheit von Produkten mit digitalen Elementen und ihren integrierten Datenfernverarbeitungslösungen sichergestellt werden. Solche Datenfernverarbeitungslösungen sollten als entfernt stattfindende Datenverarbeitung definiert werden, für die eine Software vom Hersteller des Produkts mit digitalen Elementen selbst oder unter dessen Verantwortung konzipiert und entwickelt wird und ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte. Damit wird sichergestellt, dass solche Produkte in ihrer Gesamtheit von ihren Herstellern angemessen gesichert werden, unabhängig davon, ob die Daten lokal auf dem Gerät des Nutzers oder aus der Ferne durch den Hersteller verarbeitet oder gespeichert werden. Gleichzeitig fällt die Fernverarbeitung oder -speicherung nur insoweit in den Anwendungsbereich dieser Verordnung, als sie notwendig ist, damit ein Produkt mit digitalen Elementen seine Funktionen erfüllen kann. Eine solche Fernverarbeitung oder -speicherung liegt vor, wenn eine mobile Anwendung den Zugang zu einer Anwendungsprogrammierschnittstelle oder zu einer Datenbank erfordert, die über einen vom Hersteller entwickelten Dienst bereitgestellt wird. In diesem Fall fällt der Dienst als Datenfernverarbeitungslösung in den Anwendungsbereich dieser Verordnung. Die Anforderungen an Datenfernverarbeitungslösungen, die in den Anwendungsbereich dieser Verordnung fallen, beinhalten daher keine technischen, betrieblichen oder organisatorischen Maßnahmen zur Beherrschung der Risiken für die Sicherheit der Netz- und Informationssysteme des Herstellers insgesamt.
Erwägungsgrund 11
Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026
Auslegung der EU-Kommission
Guidance vom 27. Juli 2026Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.
Abschnitt 2.2Software als Produkt — Web-Apps und Websites
Software ist nur dann ein Produkt mit digitalen Elementen, wenn sie dem Nutzer bereitgestellt und auf dessen System ausgeführt wird. Web-Apps, die ausschließlich über den Browser genutzt werden, und reine Informations-Websites sind selbst keine Produkte — sie fallen nur als Remote Data Processing in den Scope, wenn sie eine Funktion eines Produkts unterstützen.
Kernaussagen
- Lokal installierte Anwendungen sind Produkte — auch Browser-Extensions und mit Web-Technologien gebaute Desktop-Apps, die lokal ausgeführt werden.
- Web-Apps und Progressive Web Apps, die nur im Browser laufen, sind keine Produkte mit digitalen Elementen (Erwägungsgründe 11 und 12).
- Ein lokal installierter Client plus die Datenverarbeitung „at a distance“, auf die er für seine Funktionen angewiesen ist, bilden zusammen das Produkt.
Für die Praxis
Sortieren Sie Ihr Portfolio in drei Körbe: (1) läuft lokal beim Nutzer (App, Desktop-Client, Browser-Extension) → Produkt im CRA-Sinn; (2) reine Browser-Anwendung oder Info-Website → kein Produkt; (3) Backend, das eine Produktfunktion trägt → als Remote Data Processing prüfen (Kapitel 8 der Leitlinien).
Abschnitt 8.1Was zählt als Remote Data Processing Solution (RDPS)?
Remote-Datenverarbeitung ist Teil des Produkts, wenn drei Kriterien kumulativ erfüllt sind: Verarbeitung „at a distance“, Funktionsnotwendigkeit (ohne sie könnte das Produkt eine Funktion nicht erfüllen) und Entwicklung durch den Hersteller oder unter seiner Verantwortung. Die Leitlinien übersetzen das in zwei Prüffragen mit Entscheidungsbaum.
Kernaussagen
- „Wer betreibt“ ist unerheblich: On-Premises- oder Private-Cloud-Lösungen können genauso RDPS sein wie Public-Cloud-Lösungen.
- „Funktionen“ meint mehr als Kernfunktionalität: auch Onboarding, Datei-Sync, Konfiguration, automatische Update-Verteilung und Identity/Access Management zählen.
- Telemetrie rein für Statistik oder Produktentwicklung ist kein RDPS — die Risiken solcher Remote-Komponenten gehören aber trotzdem in die Risikobewertung.
- IaaS/PaaS: Läuft die eigene (oder beauftragte) Software auf fremder Infrastruktur, kann sie RDPS sein; Standard-SaaS von Dritten ist kein RDPS, wird aber wie eine Dritt-Komponente behandelt (Risiken mitigieren + Due Diligence).
- „Unter Verantwortung des Herstellers“ = maßgeschneidert für den Hersteller nach dessen Designs/Spezifikationen — nicht das bloße Lizenzieren eines bestehenden Dienstes.
- Interne Systeme (HR, CRM, CI/CD-Pipelines, Update-Verteilung an Edge-Standorte, Pentest-/Red-Team-Infrastruktur) sind kein RDPS.
- Websites nur bei Funktionsbeitrag: ein Auth-Portal, das Tokens für das Produkt ausstellt, kann RDPS sein — eine Info-Website nicht, selbst wenn das Produkt auf sie verlinkt.
Für die Praxis
Beantworten Sie je Cloud-/Backend-Dienst zwei Fragen: (1) Fällt ohne ihn eine Produktfunktion aus (auch Onboarding, Sync, Updates, Login)? (2) Wurde die Software von uns oder nach unseren Vorgaben entwickelt? Zweimal Ja → Teil Ihres Produkts, gehört in Risikobewertung und Konformitätsbewertung. Nur Frage 1 Ja (z. B. Standard-SaaS) → wie Dritt-Komponente behandeln: Risiken mitigieren plus Due Diligence.
Abschnitt 8.2RDPS in Doku, Risikobewertung und Konformitätsbewertung
RDPS gehören in Risikobewertung, technische Dokumentation und Konformitätsbewertung des Produkts — beschränkt auf die Software-Module, die die Produktfunktion tragen, und deren Schnittstellen. Nachgelagerte Backend-Systeme ohne direkte Produkt-Interaktion sind kein RDPS, bleiben aber externe Abhängigkeiten, deren Risiken produktseitig zu mitigieren sind.
Kernaussagen
- Ein RDPS, das mehrere Produkte bedient, ist in jeder Produkt-Doku zu deklarieren — die RDPS-Dokumentation darf über Konformitätsbewertungen hinweg wiederverwendet werden.
- Wiederverwendbare Assurance-Nachweise für Dritt-Services: NIS-2-Nachweise (DVO (EU) 2024/2690), DORA-Nachweise, Zertifikate nach EU-Cybersicherheits-Schemata, ISO/IEC 27001/27017.
- Änderungen an Dritt-Services sind keine wesentliche Änderung des Produkts — Hersteller sollten sich aber vertraglich (SLAs) Informationen und Sicherheitsgarantien zusichern lassen und die Risikobewertung nachziehen.
Für die Praxis
Legen Sie ein zentrales RDPS-Dossier an — betroffene Software-Module, Schnittstellen, genutzte Provider samt Nachweisen (ISO 27001/27017, NIS-2-, DORA-Evidenz, EUCC-Zertifikate) — und referenzieren Sie es aus jeder Produkt-Doku. Verankern Sie in Provider-SLAs, dass Sie über wesentliche Änderungen informiert werden: Die lösen zwar keine neue Konformitätsbewertung aus, wohl aber ein Update Ihrer Risikobewertung.
Abschnitt 8.3Fünf RDPS-Use-Cases: Banking-App, Thermostat, e-Reader, Roboter, Mobilfunk
Fünf durchgespielte Fälle zeigen die Abgrenzung: Bei der Mobile-Banking-App ist das selbst entwickelte Banking-Interface RDPS, nachgelagerte Ledger-/Kontensysteme nicht, der Support-Chat (Dritt-SaaS) ist eine Dritt-Komponente. Smart Thermostat und Industrieroboter: eigene Cloud-Software auf Dritt-IaaS ist RDPS. e-Reader: Dritt-SaaS-Storage ist kein RDPS, aber als Komponente zu behandeln. Das Mobilfunknetz ist reiner Kommunikationskanal — kein RDPS, keine Due Diligence nötig.
Kernaussagen
- Der CRA erfasst nur die Systemteile, mit denen das Produkt direkt interagiert — Risiken dahinterliegender Systeme (z. B. kompromittiertes Ledger) sind produktseitig zu mitigieren (starke Backend-Authentisierung, Integritätsschutz, sichere Kanäle).
- Bei Dritt-IaaS: RDPS und IaaS-Nutzung in der technischen Doku dokumentieren; vom Provider z. B. NIS-2-Nachweise einholen.
- Netz-Infrastruktur (5G, Ethernet, WLAN, Router) ist Kommunikations-Enabler, nicht Datenverarbeitung, deren Fehlen eine Produktfunktion verhindert.
Für die Praxis
Ordnen Sie Ihr eigenes Setup dem nächstliegenden der fünf Kommissions-Use-Cases zu (Banking-App, Smart Thermostat, e-Reader, Industrieroboter, Mobilfunknetz) und übernehmen Sie dessen Logik: Was direkt mit dem Produkt interagiert und von Ihnen entwickelt wurde, ist RDPS; dahinterliegende Systeme sind externe Abhängigkeiten; reine Netzinfrastruktur ist gar nichts davon. Meist ersetzt das ein teures Einzelgutachten.
EU-Kommissions-Guidance (C(2026) 5252 final) — Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.
Verwandte Artikel
(1)Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex