Artikel 3(1) des Cyber Resilience Act, Verordnung (EU) 2024/2847, definiert ein Produkt mit digitalen Elementen als „ein Software- oder Hardwareprodukt und dessen Lösungen zur Datenfernverarbeitung“. Artikel 3(2) definiert Datenfernverarbeitung als „Datenverarbeitung aus der Ferne, für die die Software vom Hersteller oder unter der Verantwortung des Herstellers konzipiert und entwickelt wird und ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht ausführen könnte“. Ob Ihr Produkt überhaupt im Anwendungsbereich liegt, entscheidet sich an Artikel 2 und Erwägungsgrund 12. Liegt es darin, ist die nächste Frage für jedes Unternehmen mit App und Cloud, welche Teile der Cloud mit hineingekommen sind, denn diese Teile gehören in die Risikobewertung, die grundlegenden Anforderungen, die technische Dokumentation und die Meldepflicht.

Die Leitlinien der Kommission zur Anwendung der Verordnung, C(2026) 5252 vom 27. Juli 2026, Abschnitt 8, Randnummern 178 bis 208, beantworten diese Frage genauer, als die Verordnung es tut. Dieser Artikel ist dieser Abschnitt mit seinen fünf Anwendungsfällen, gelesen für einen Softwarehersteller.

Zwei kumulative Tests

Randnummer 184 zerlegt die Definition in drei Elemente: ob die Verarbeitung aus der Ferne erfolgt, ob ihr Fehlen das Produkt daran hindern würde, eine seiner Funktionen auszuführen, und ob die Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde. Randnummer 185 stellt das erste dann als „relevant, aber nicht ausreichend“ beiseite: Cloud, Edge und die eigenen Server des Herstellers vor Ort zählen alle als aus der Ferne (Randnummer 187), sodass das erste Element selten etwas entscheidet. Randnummer 188 stellt die Regel auf: Das zweite und das dritte sind „die zwei entscheidenden und kumulativen Fragen“, und „werden beide Fragen bejaht, gilt die Datenfernverarbeitung“ als Lösung zur Datenfernverarbeitung.

Randnummer 202 nennt die drei Ergebnisse. Beides ja: Es ist Teil Ihres Produkts, und Anhang I gilt dafür. Der Funktionstest nein: nicht Teil des Produkts, aber „die Hersteller sollten die Risiken, die sich aus dem Vorhandensein einer solchen Datenverarbeitung ergeben, im Rahmen ihrer Risikobewertung bewerten“. Der Funktionstest ja, der Verantwortungstest nein: „Die Hersteller sollten die Drittlösung wie eine Komponente behandeln“, die Risiken ihrer Integration bewerten und mindern und „Sorgfaltspflicht ausüben“.

Test eins: Würde ihr Fehlen eine Funktion stoppen

Das Wort ist „Funktionen“, nicht Kernfunktionalität. Randnummer 189: „Der Begriff ‚Funktionen‘ in dieser Definition ist nicht auf die ‚Kernfunktionalität‘ oder die ‚Zweckbestimmung‘ des Produkts mit digitalen Elementen beschränkt“ und umfasst „sowohl Funktionen, die die Zweckbestimmung des Produkts mit digitalen Elementen, wie die Nutzer sie erleben, unmittelbar erfüllen, als auch Funktionen, die die Gesamtleistung des Produkts unterstützen“. Randnummer 190 nennt sechs Beispiele für Fernverarbeitung, ohne die ein Produkt nicht auskommt: „(i) Senden von Befehlen an ein Gerät; (ii) Synchronisieren von Dateien; (iii) Onboarding des Nutzers; (iv) Konfiguration (Personalisierung des Produkts mit digitalen Elementen); (v) automatisierte Verteilung von Updates, einschließlich Funktionsupdates und Sicherheitspatches; (vi) Identitäts- und Zugriffsverwaltung“.

Zwei Präzisierungen sind für Software wichtig. Eine Funktion, die der Nutzer sowohl aus der Ferne als auch manuell ausführen kann, die Glühbirne per App oder per Hand geschaltet, zählt trotzdem: „Das Ausführen dieser Funktion aus der Ferne gilt ebenfalls als Teil der Funktionen, die das Produkt mit digitalen Elementen bietet“ (Randnummer 191). Und das Gegenbeispiel ist Telemetrie: „Die Fernanalyse von Telemetriedaten, die rein zu statistischen Zwecken oder für die künftige Produktentwicklung erhoben werden“, ist keine Funktion, die das Produkt braucht, also keine Datenfernverarbeitung (Randnummer 192), wobei Randnummer 193 ergänzt, dass die Risiken dieser Fernkomponenten dennoch in die Risikobewertung gehören.

Websites bekommen eine eigene Randnummer, 194. Eine Website, die nur Informationen über das Produkt trägt, gehört nicht dazu, „selbst wenn das Produkt auf diese Website weiterleitet“. Eine Website, die „eine Funktion ermöglicht oder unterstützt“, schon: „Ein Authentifizierungsportal, das Anmeldedaten oder Token ausgibt, die das Produkt mit digitalen Elementen zum Betrieb benötigt, wäre als RDPS anzusehen.“ Für die meisten Softwareunternehmen bringt dieser eine Satz den Login-Dienst ins Produkt.

Test zwei: von Ihnen oder unter Ihrer Verantwortung konzipiert und entwickelt

Randnummer 195: Selbst entwickelte Software erfüllt den Test, und Software, die ein externer Anbieter für Sie baut, ebenfalls, aber „unter der Verantwortung des Herstellers“ bedeutet „maßgeschneidert für den Hersteller“, Fälle, in denen „die Software ausschließlich vom Hersteller oder in seinem Auftrag auf Grundlage der von ihm vorgegebenen Entwürfe und Spezifikationen gebaut wird“. Einen bestehenden Dienst zu lizenzieren, „oder leicht abgewandelte Versionen davon“, ist das nicht.

Wer ihn betreibt, ist unerheblich. Randnummer 196: „Der Begriff ‚wer die Lösung betreibt‘ ist kein entscheidender Faktor, da die CRA-Definition nur auf Konzeption und Entwicklung abstellt.“ Ein Backend, das Sie geschrieben haben und ein Hosting-Unternehmen betreibt, ist Ihres.

Die Randnummern 197 bis 200 sortieren dann die drei Cloud-Modelle. Auf Dritt-IaaS bringen Sie eigene Betriebssysteme und Anwendungen aus; diese Software „wird vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt und kann daher“ als RDPS „gelten“ (Randnummer 198). Auf Dritt-PaaS bringen Sie Ihre eigene Anwendung auf der Laufzeitumgebung des Anbieters aus; „die Anwendung wird daher vom Hersteller konzipiert und entwickelt“ und kann gelten (Randnummer 199). Eine in Ihr Produkt integrierte SaaS-Anwendung eines Dritten „wird daher nicht vom Hersteller konzipiert und entwickelt“ (Randnummer 200) und ist keine Datenfernverarbeitung, welche Funktion sie auch unterstützt.

Was außerhalb der Definition liegt, liegt nicht außerhalb Ihrer Verantwortung. Randnummer 201: Der Hypervisor unter Ihrem IaaS, das Betriebssystem unter Ihrem PaaS, das Dritt-SaaS „sollten als Komponenten Dritter ähnlich betrachtet werden“, wo sie die Sicherheit des Produkts berühren, und der Hersteller „ist verpflichtet, die mit der Integration dieser Elemente verbundenen Risiken zu ermitteln und zu bewerten und ihnen durch Umsetzung der grundlegenden Anforderungen am Produkt mit digitalen Elementen selbst zu begegnen“, unter Ausübung „einer der Sorgfaltspflicht nach Artikel 13(5) ähnlichen Pflicht“.

Die Grenze: Module, mit denen Ihr Produkt spricht, nicht alles dahinter

Das ist der Teil, der entscheidet, wie groß die technische Dokumentation wird. Randnummer 205: Die Datenfernverarbeitung, die der Konformitätsbewertung des Produkts unterliegt, „sollte auf jene Softwaremodule beschränkt sein, die für die Funktionalität des Produkts mit digitalen Elementen verantwortlich sind, und auf die Schnittstellen, die diese Module zu externen Diensten nutzen. Weitere Backend-Systeme, die anschließende Verarbeitung durchführen und mit denen das Produkt mit digitalen Elementen nicht direkt interagiert, gelten nicht als RDPS.“ Randnummer 206 behält sie in der Risikobewertung als „externe Abhängigkeiten, die bewertet werden müssen“ und „durch Maßnahmen auf Produktebene“ zu mindern sind.

Randnummer 182 zählt auf, was die Definition nach Erwägungsgrund 11 nie erreichen sollte: „Interne Systeme für die eigene Personalverwaltung, Gehaltsabrechnung, das Kundenbeziehungsmanagement, CI/CD-Pipelines (Continuous Integration/Continuous Delivery), die Verteilung von Sicherheitsupdates an Edge-Standorte sollten nicht als RDPS betrachtet werden“, und ebenso wenig „Systeme im Zusammenhang mit Audit- und Testtätigkeiten wie Penetrationstests, Threat Hunting und Red Teaming“. Der CRA erfasst das Produkt, nicht „die gesamte IT-Infrastruktur einer Organisation“. Das ist das Gebiet von NIS2, und Erwägungsgrund 12 sagt es.

Der Mobile-Banking-Fall, der der Fall der meisten Softwareunternehmen ist

Abschnitt 8.3.1 geht die App einer Bank mit selbst gehostetem Backend und einem Support-Chat eines Dritten durch. Die App spricht mit einer „Banking-Schnittstelle“, die die Bank gebaut hat und die ihrerseits ein Kontoverwaltungssystem und ein Hauptbuch abfragt. Die Schnittstelle authentifiziert den Kunden, übermittelt Überweisungsaufträge und gibt deren Status zurück; sie „ist notwendig, damit die App ihre Funktionen ausführen kann“, und „wird unter der Verantwortung des Herstellers konzipiert und entwickelt“, also ist sie Datenfernverarbeitung und „muss daher in die Cybersicherheitsrisikobewertung und in die Umsetzung der grundlegenden Anforderungen einbezogen werden“. Das Kontoverwaltungssystem und das Hauptbuch sind es nicht: „Die App interagiert nicht direkt mit ihnen“, und „obwohl ihre Verfügbarkeit für den Abschluss einer Funktion notwendig sein mag, erfasst der CRA nur jene Teile des Systems, die direkt mit dem Produkt interagieren“. Sie bleiben externe Abhängigkeiten, deren Kompromittierung „es einem Angreifer erlauben könnte, Transaktionsergebnisse zu beeinflussen“, zu mindern auf Produktebene, „etwa durch starke Authentifizierung der Backend-Schnittstellen, Integritätsschutz der Transaktionsdaten, sichere Kommunikationskanäle und Prüfung der von der App empfangenen Antworten“.

Der Support-Chat, „von einem Drittanbieter entwickelt und betrieben“, ist für eine Funktion notwendig, besteht aber den Verantwortungstest nicht, ist also „kein RDPS“ und „sollte wie eine Komponente eines Dritten behandelt werden“, isoliert von den Kernfunktionen, mit Sorgfaltspflicht gegenüber dem Anbieter.

Übertragen auf ein typisches B2B-SaaS mit Desktop- oder Mobilclient: Das API-Gateway und der Authentifizierungsdienst, die der Client aufruft, sind im Produkt; das Data Warehouse drei Stationen dahinter ist eine externe Abhängigkeit; die eingebetteten Analyse-, Chat- oder Zahlungs-Widgets Dritter sind Komponenten. Die anderen vier Fälle bestätigen das Muster: Die Cloud-Funktionen eines Thermostats auf Dritt-IaaS sind drin (8.3.2), der Dritt-SaaS-Speicher eines E-Readers ist eine Komponente (8.3.3), der Bilderkennungsdienst eines Roboters auf IaaS ist drin (8.3.4), und das 5G-Netz eines Telefons ist keines von beidem, „nur ein Kommunikationskanal“, ohne Sorgfaltspflicht gegenüber dem Betreiber (8.3.5).

Was in die Dokumentation gehört, und was Sie wiederverwenden können

Randnummer 204: Hersteller „sollten (i) in der technischen Dokumentation angeben, dass ihr Produkt mit digitalen Elementen RDPS hat oder auf Fernlösungen Dritter angewiesen ist, und (ii) diese Lösungen beschreiben“, und wo ein Backend mehrere Produkte bedient, wird es in der Dokumentation jedes Produkts angegeben, und die Dokumentation „kann von einer Konformitätsbewertung zur nächsten wiederverwendet werden“.

Für die Dienste Dritter, auf die Sie angewiesen sind, nennt Randnummer 207 die Nachweise, die zur Unterstützung Ihrer Bewertung und Sorgfaltspflicht wiederverwendet werden können: Nachweise der Einhaltung der NIS2-Durchführungsverordnung durch den Anbieter, der DORA, ein Zertifikat nach einem europäischen Schema für die Cybersicherheitszertifizierung oder „Nachweise der Konformität mit ISO/IEC 27017:2015 oder ISO/IEC 27001:2022“. Randnummer 208 ergänzt die vertragliche Seite: Sicherheitsgarantien in Service-Level-Vereinbarungen, „einschließlich Zusicherungen, dass die Anbieter Schwachstellen angemessen handhaben“, und eine wesentliche Änderung beim Anbieter ist keine wesentliche Änderung Ihres Produkts, kann aber eine Überarbeitung Ihrer Risikobewertung verlangen.

Von der anderen Seite gelesen ist Randnummer 207(d) auch das, was Ihre eigenen Kunden von Ihnen verlangen können. Ist Ihr Produkt Datenfernverarbeitung für deren Produkt, ist Ihr ISO-27001-Zertifikat der Nachweis, den die Leitlinien für deren Dokumentation nennen.

Die Bestimmung, in sechs Zeilen

Halten Sie für jeden Ferndienst, den Ihr Produkt aufruft, fest:

  1. Den Dienst und die Funktion, die er unterstützt, im Sinne der Leitlinien.
  2. Test eins: Würde das Produkt diese Funktion ohne ihn verlieren. Telemetrie und Informationswebsites: nein.
  3. Test zwei: Von Ihnen oder nach Ihrer Spezifikation gebaut, oder eine lizenzierte Anwendung eines Dritten. IaaS und PaaS stellen Ihren Code auf die Innenseite; SaaS stellt die Anwendung auf die Komponentenseite.
  4. Das Ergebnis nach Randnummer 202: Teil des Produkts, eine Komponente, die mit Sorgfaltspflicht zu bewerten ist, oder eine externe Abhängigkeit, die zu bewerten ist.
  5. Die Grenze nach Randnummer 205: mit welchen Modulen das Produkt direkt interagiert und welche Systeme dahinter liegen.
  6. Den Nachweis, den Sie für jeden Dienst eines Dritten halten, aus der Liste in Randnummer 207, und das Datum, an dem Sie ihn erhalten haben.

Diese Tabelle ist der Abschnitt zur Fernverarbeitung in der technischen Dokumentation, der Input für die Risikobewertung, die Artikel 13 verlangt, und die Antwort auf die zweite Frage in unserer Anwendbarkeitsbestimmung. Sie ist auch die Liste der Systeme, deren Kompromittierung die Melde-Uhr startet, denn Randnummer 178 sagt, dass das Produkt, Fernverarbeitung eingeschlossen, das ist, worüber Artikel 14 berichtet.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3(1), (2) und (4), Artikel 13(2), (3) und (5), Erwägungsgründe 11 und 12.
  • Europäische Kommission, Leitlinien der Kommission zur Anwendung der Verordnung (EU) 2024/2847, C(2026) 5252 final vom 27. Juli 2026, Anhang, Abschnitt 8, Randnummern 178 bis 208 und Anwendungsfälle 8.3.1 bis 8.3.5.
  • Richtlinie (EU) 2022/2555 (NIS2) und Durchführungsverordnung (EU) 2024/2690 der Kommission, für die Cloud-Dienste, die die Leitlinien ihnen überlassen.

Dies ist keine Rechtsberatung. Abschnitt 8 umfasst elf Seiten, und die fünf Fälle sind der klarste Teil der gesamten Leitlinien; lesen Sie sie, bevor Sie Ihre eigene Grenze ziehen.