SaaS ist keine generelle Ausnahme beim CRA: Remote-Datenverarbeitung, SBOMs und der CRA

Softwareunternehmen verlassen sich häufig auf eine vertraute Unterscheidung: Produkte sind reguliert, Services nicht. Cloud-Delivery-Modelle, abonnementbasierte Modelle und Remote-Verarbeitung wurden oft nicht nur als geschäftliche Innovationen betrachtet, sondern auch als Wege, regulatorische Risiken zu reduzieren. Der EU Cyber Resilience Act (CRA) stellt diese Annahme infrage. Entscheidend ist nach dem CRA nicht, ob etwas als „SaaS“ vermarktet wird, sondern ob es Teil eines „Produkts mit digitalen Elementen“ ist, das auf dem Markt bereitgestellt wird. Wenn „Remote“-Datenverarbeitung für die Kernfunktionalität eines Produkts wesentlich ist, fällt das Cloud-Backend möglicherweise nicht mehr außerhalb des regulatorischen Rahmens.

Der rechtliche Wandel: Remote-Datenverarbeitung als Teil des Produkts

Der CRA definiert „Remote-Datenverarbeitung“ als Datenverarbeitung aus der Ferne, für die die Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde, und deren Fehlen das Produkt daran hindern würde, eine seiner Funktionen auszuführen. Diese Formulierung ist bedeutsam: Wenn ein verbundenes Gerät oder ein lokal installiertes Softwareprodukt auf Backend-Infrastruktur angewiesen ist, um wie vorgesehen zu funktionieren, ist die Remote-Komponente nicht nur ein Nebenservice, sondern Teil des regulierten Ökosystems.

Dies verwischt die traditionelle Unterscheidung zwischen SaaS und Produkt. Ein lokal installierter Endpoint-Agent, der nur funktioniert, wenn er sich mit der Cloud des Anbieters verbindet, ein Smart Device, das seine Kernanalysen remote durchführt, oder ein Softwareprodukt, das seine Hauptfunktionen in der Cloud verarbeitet, können alle unter den CRA fallen. Die architektonische Entscheidung, Funktionalität in die Cloud zu verlagern, entfernt sie nicht automatisch aus der regulatorischen Prüfung. Vielmehr verschiebt sie die Analyse darauf, ob diese Funktionalität essenziell ist.

Schwachstellenmanagement folgt der Architektur

Wenn Remote-Verarbeitung als Teil der Produktfunktionalität betrachtet wird, treten die Lifecycle-Verpflichtungen des CRA in Kraft. Hersteller müssen Schwachstellen unverzüglich beheben, Sicherheitsupdates bereitstellen, wo erforderlich, und Meldepflichten bei aktiv ausgenutzten Schwachstellen oder schwerwiegenden Vorfällen erfüllen. Diese Pflichten beschränken sich nicht auf Firmware oder herunterladbare Binärdateien. Wenn der Backend-Service für den Betrieb des Produkts notwendig ist, können Schwachstellen in diesem Service regulatorische Konsequenzen haben.

Hier gibt es also keine Ausnahme mehr. Eine kritische Schwachstelle in einem cloudbasierten Authentifizierungsdienst, eine Backend-API-Schwachstelle oder eine ausgenutzte Open-Source-Komponente im serverseitigen Stack kann die Sicherheit des Produkts auf dem EU-Markt direkt beeinträchtigen. Selbst wenn ein Exploit außerhalb der EU auftritt, greifen die Melde- und Handhabungspflichten nach dem CRA, sobald das betroffene Produkt in der Union vermarktet wird.

Copyleft und die Cloud: Eine subtile, aber wichtige Konvergenz

Die Auswirkungen gehen über die Cybersicherheits-Compliance hinaus. Für Unternehmen, die stark auf Open-Source-Software in ihren Backend-Stacks setzen, fügt die Integration von Remote-Verarbeitung in die Kernfunktionalität des Produkts eine weitere Komplexitätsebene hinzu. Der CRA ändert das Urheberrecht nicht, aber er beeinflusst, wie Regulierungsbehörden die Verantwortungsgrenzen betrachten. Behandeln Hersteller Remote-Komponenten als Teil des Produkts, müssen sie auch für diese Komponenten Due-Diligence-, Dokumentations- und Schwachstellenmanagementpflichten erfüllen.

In der Praxis bringt dies Remote-Infrastrukturen auf das Prüfungsniveau, das traditionell für lokalen Code gilt. Organisationen, die SaaS bisher als Möglichkeit zur Reduzierung von Copyleft-Risiken betrachteten, müssen möglicherweise ihre Annahmen neu bewerten. Architektonische Entscheidungen aus Lizenz- oder Vertriebsgründen können nun Compliance- und Risikomanagement-Auswirkungen im Rahmen des Produktsicherheitsrechts haben.

Die SBOM-Dimension: Transparenz im Backend

Die wohl praktischste Konsequenz betrifft Software Bills of Materials (SBOMs) und Software Composition Analysis (SCA). Wenn Remote-Datenverarbeitung für die Kernfunktionalität eines Produkts entscheidend ist, müssen Hersteller verstehen, was in der Backend-Umgebung enthalten ist. Open-Source-Bibliotheken, transitive Abhängigkeiten, KI-generierte Komponenten und Legacy-Code in Cloud-Diensten werden relevant für Risikoanalysen und Schwachstellenmanagement.

Eine SBOM, die nur Firmware oder Client-Anwendungen abdeckt, liefert möglicherweise kein vollständiges Compliance-Bild. Um den Due-Diligence-Erwartungen gemäß Artikel 13 zu entsprechen und die Pflichten zur Schwachstellenbehandlung gemäß Anhang I, Teil II, zu erfüllen, benötigen Organisationen möglicherweise SBOM-Transparenz für das Backend, kontinuierliches Monitoring der Abhängigkeiten und strukturierte Prozesse zur Nachverfolgung und Behebung von Schwachstellen über verteilte Architekturen hinweg.

Dies ist nicht nur ein Dokumentationsaufwand. Ohne genaue Bestandsdaten wird es schwierig, die Ausnutzbarkeit einer Schwachstelle zu bewerten, zu bestimmen, ob sie das Produkt betrifft, oder regulatorisch fristgerecht zu reagieren. Je wesentlicher die Cloud-Komponente, desto stärker spricht alles dafür, SBOM- und SCA-Praktiken auf die SaaS-Ebene auszudehnen.

Strategische Implikationen für Produktdesign

Der CRA verbietet SaaS-Modelle nicht und klassifiziert auch nicht automatisch jede Cloud-Funktion als reguliert. Optionale, klar trennbare und tatsächlich nebensächliche Services können außerhalb der Produktpflichten bleiben. Je enger die Remote-Funktionalität an den Zweck des Produkts gekoppelt ist, desto schwieriger können Hersteller argumentieren, dass das Backend außerhalb des regulatorischen Rahmens liegt.

Für Produkt- und Compliance-Teams bedeutet dies, dass architektonische Entscheidungen nicht nur auf Leistung und Skalierbarkeit basieren sollten, sondern auch auf regulatorischem Risiko. Die Grenze zwischen Service und Produkt ist nicht mehr rein kommerziell, sondern rechtlich und operativ relevant, was Supportzeiträume, Schwachstellenberichte, Konformitätsbewertungen und Dokumentationsstrategien betrifft.

Über den Anwendungsbereich hinaus: Vertrauen in einer Cloud-zentrierten Welt schaffen

Letztlich spiegelt der CRA eine breitere politische Ausrichtung wider: Cybersicherheit ist keine einmalige Zertifizierung, sondern eine kontinuierliche Verantwortung über den gesamten Produktlebenszyklus. Ob ein Chip, ein Container oder ein entferntes Rechenzentrum die Funktionalität ausführt, zählt die Rolle dieser Komponenten bei der Ermöglichung des Produktbetriebs.

Organisationen, die SaaS als Compliance-Fluchtweg betrachten, werden feststellen, dass die Linie zwischen Service und Produkt dünner ist als erwartet. Unternehmen, die frühzeitig in Transparenz der Lieferkette, Backend-SBOM-Management und strukturierte Schwachstellenprozesse investieren, sind besser aufgestellt, um in diesem sich entwickelnden Umfeld zu bestehen.

Wenn Sie Unterstützung benötigen, um zu verstehen, wie Remote-Architekturen, Open-Source-Komponenten und SBOM-gesteuerte Transparenz im Rahmen des CRA zusammenwirken, kontaktieren Sie uns.