Cyber Resilience Act und SaaS: Wann ist Ihre Cloud-Software wirklich betroffen?

Gilt der Cyber Resilience Act für SaaS-Anbieter?

Reine SaaS-Lösungen, die ausschließlich über den Browser bereitgestellt werden und keinen Bezug zu einem vernetzten Produkt haben, sind vom CRA grundsätzlich ausgenommen. Die Ausnahme greift jedoch nicht pauschal: Wer einen Desktop-Client, eine Mobile App oder eine Browser-Extension anbietet, ist mit diesen Komponenten direkt betroffen. Gleiches gilt für SaaS, die als Datenfernverarbeitungslösung integraler Bestandteil eines vernetzten Produkts ist. Die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gilt für betroffene Hersteller ab dem 11. September 2026 – unabhängig davon, ob das gesamte Produkt oder nur einzelne Komponenten im Scope liegen.

Gilt der CRA für uns eigentlich?“ – Die Frage, die viele SaaS-Anbieter noch nicht gestellt haben

Wer den Cyber Resilience Act zum ersten Mal liest, denkt meist an vernetzte Industrieanlagen, smarte Haushaltsgeräte oder On-Premise-Software. Die Schlussfolgerung liegt nah: „Wir sind eine Cloud-Lösung, kein Hardwarehersteller, das betrifft uns nicht.“ Diese Einschätzung ist verständlich, aber in vielen Fällen unvollständig.

Der CRA knüpft seine Anforderungen nicht daran, wie ein Produkt vermarktet wird, sondern daran, wie es technisch gebaut ist und in welchem Kontext es eingesetzt wird. Eine SaaS-Bezeichnung schützt nicht automatisch vor dem Anwendungsbereich der Verordnung. Entscheidend ist, ob das Produkt eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk ermöglicht und ob es als eigenständiges Produkt auf dem Markt bereitgestellt wird.

Das führt in der Praxis zu einer Situation, die viele SaaS-Anbieter überrascht: Nicht die gesamte Lösung muss unter den CRA fallen. Es reicht, wenn eine einzige Komponente, etwa eine Mobile App oder ein Desktop-Client, die Kriterien erfüllt. Und wer als Cloud-Backend für ein vernetztes Produkt fungiert, ist unter Umständen ebenfalls betroffen, auch wenn die eigene Oberfläche rein browserbasiert ist.

Dieser Artikel klärt, wann SaaS-Anbieter tatsächlich in den Scope des CRA fallen, wo die Grenzen des Anwendungsbereichs liegen und wie eine strukturierte Betroffenheitsprüfung aussieht. Ein Überblick über den CRA insgesamt, seine Ziele und die Zeitplanung bis 2027, findet sich in unserem Einführungsartikel zum Cyber Resilience Act.

Was der CRA unter „Produkt mit digitalen Elementen“ versteht

Produkt mit digitalen Elementen ist der zentrale Anknüpfungspunkt des CRA. Er ist bewusst weit gefasst: Gemeint ist jede Hardware oder Software, die direkt oder indirekt eine Datenverbindung zu einem Gerät oder Netzwerk haben kann. Ob diese Verbindung im Alltag tatsächlich genutzt wird, spielt keine Rolle. Es genügt, dass sie technisch vorgesehen oder bei vernünftiger Betrachtung vorhersehbar ist.

Für Software bedeutet das konkret: Eine Anwendung, die Daten an einen Server sendet, Updates über das Netz bezieht oder mit anderen Systemen kommuniziert, erfüllt dieses Kriterium in aller Regel. Das schließt klassische Desktop-Software ebenso ein wie Mobile Apps, Browser-Extensions oder eingebettete Firmware.

Eng damit verbunden ist ein Begriff, der für SaaS-Anbieter besondere Relevanz hat: die Datenfernverarbeitungslösung. Der CRA definiert in Artikel 3 Nr. 2 der Verordnung (EU) 2024/2847 darunter jede Datenverarbeitung, die aus der Ferne für ein Produkt mit digitalen Elementen erbracht wird und für dessen Kernfunktion notwendig ist. Wenn ein physisches oder vernetztes Produkt ohne den Cloud-Dienst eines Anbieters nicht funktioniert, kann dieser Cloud-Dienst selbst zum Teil des regulierten Produkts werden.

Was ist eine Datenfernverarbeitungslösung im Sinne des CRA?

Eine serverseitige oder cloudbasierte Verarbeitung, die für die Kernfunktion eines vernetzten Produkts zwingend erforderlich ist und vom Hersteller des Produkts selbst oder in dessen Auftrag bereitgestellt wird. Beispiel: Das Cloud-Backend einer Flottenmanagement-Software, ohne das die angebundenen Fahrzeugsensoren keine auswertbaren Daten liefern.

Fällt browserbasierte Software automatisch aus dem Scope heraus?

Nicht automatisch. Eine reine Browseranwendung ohne downloadbare Komponente und ohne Bezug zu einem vernetzten Produkt ist in der Regel nicht betroffen. Sobald jedoch eine der genannten Bedingungen zutrifft, ändert sich die Einordnung. Die Bereitstellung über den Browser allein ist kein Freifahrtschein.

Wann SaaS-Anbieter unter den CRA fallen

Die Frage, ob eine SaaS-Lösung unter den CRA fällt, lässt sich nicht pauschal beantworten. Sie hängt von der konkreten Produktarchitektur, dem Einsatzkontext und der eigenen Rolle in der Lieferkette ab. In der Praxis kristallisieren sich drei Fallkonstellationen heraus, die für SaaS-Anbieter besonders relevant sind.

Fall 1 – Die Datenfernverarbeitungslösung

Die erste und häufig übersehene Konstellation betrifft SaaS-Anbieter, deren Dienst als Cloud-Backend für ein vernetztes Produkt fungiert. Das klassische Beispiel ist eine Softwareplattform, die Sensordaten von IoT-Geräten empfängt, verarbeitet und auswertet. Ohne den Cloud-Dienst liefern die Geräte keine verwertbaren Ergebnisse. Die SaaS ist damit keine eigenständige Ergänzung, sondern integraler Bestandteil des Produkts.

In diesem Fall kann der CRA auch dann greifen, wenn die eigene Oberfläche ausschließlich browserbasiert ist und keine Software auf dem Endgerät des Nutzers installiert wird. Entscheidend ist nicht die Darstellungsform, sondern die funktionale Abhängigkeit.

Fall 2 – Hybride Produktarchitektur

Viele Anbieter betreiben neben ihrer browsergestützten Hauptanwendung zusätzliche Komponenten: einen Desktop-Client für Windows oder macOS, eine Mobile App für iOS oder Android oder eine Browser-Extension, die lokal auf dem Gerät des Nutzers läuft.

Jede dieser Komponenten ist aus CRA-Perspektive ein eigenständiges Produkt mit digitalen Elementen. Selbst wenn der Anteil am Gesamtprodukt gering ist, ändert das nichts an der Einordnung. Die Komponente wird auf dem Markt bereitgestellt, läuft auf dem Gerät des Nutzers und hat eine Netzwerkverbindung.

Fall 3 – OEM und White-Label

Die dritte Konstellation betrifft Anbieter, die ihre Technologie als Bestandteil eines anderen Produkts lizenzieren. In diesem Modell kann die CRA-Verantwortung vertraglich auf den Hersteller des Endprodukts übergehen. Eine stillschweigende Annahme reicht jedoch nicht. Die Abgrenzung muss aktiv gestaltet, vertraglich dokumentiert und technisch nachvollziehbar sein.

Reine Browseranwendungen ohne downloadbare Komponente, ohne funktionale Abhängigkeit von einem vernetzten Produkt und ohne OEM-Einbettung sind in den meisten Fällen nicht vom CRA erfasst. Sie sind aber die Ausnahme, nicht die Regel.

Wann SaaS-Anbieter klar außerhalb des CRA-Scope liegen

Nicht jeder SaaS-Anbieter muss sich durch eine aufwendige Betroffenheitsprüfung arbeiten. Wer eine Anwendung ausschließlich über den Browser bereitstellt, keine downloadbaren Komponenten anbietet, keinen Bezug zu einem vernetzten physischen Produkt hat und dessen Cloud-Infrastruktur nicht für die Kernfunktion eines solchen Produkts notwendig ist, fällt in der Regel nicht unter den CRA.

Typische Beispiele sind browserbasierte Projektmanagement-Tools, kollaborative Dokumentenplattformen oder CRM-Systeme, die unabhängig von vernetzten Geräten betrieben werden.

Für diese Anbieter ist jedoch nicht der CRA das relevante Regelwerk, sondern die NIS2-Richtlinie beziehungsweise in Deutschland das NIS2UmsuCG – das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz. Welche Anforderungen NIS2 konkret für SaaS- und Cloud-Anbieter bedeutet, haben wir in einem gesonderten Artikel zusammengefasst: NIS2 Umsetzung in Unternehmen: Vom Zertifikat zur nachweisbaren Wirksamkeit.

Die entscheidende Erkenntnis: Die Frage „Falle ich unter den CRA?“ lässt sich nicht mit einem Blick auf die eigene Marketingbezeichnung beantworten. Sie erfordert eine ehrliche Auseinandersetzung mit der eigenen Produktarchitektur.

Entscheidungsmatrix – Bin ich als SaaS-Anbieter vom CRA betroffen?

Die folgenden fünf Fragen helfen dabei, die eigene Betroffenheit einzuschätzen. Sie ersetzen keine rechtliche oder technische Einzelfallprüfung, geben aber eine erste strukturierte Orientierung.