Ist Software-as-a-Service (SaaS) nur Teil der Lieferkette, gilt sie nicht automatisch als Produkt mit digitalen Elementen im Sinne des Cyber Resilience Acts (CRA). Dennoch können SaaS-Anbieter sicherheitsrelevant werden – je nachdem, welche Funktion ihr Dienst im Verhältnis zum finalen Produkt mit digitalen Elementen übernimmt.
Wir erläutern, anhand welcher Kriterien die Einordnung von SaaS unter dem CRA erfolgt, welche Szenarien in der Praxis entstehen und welche Pflichten daraus konkret folgen.
Welche Rolle spielt SaaS im CRA-Kontext?
Der CRA (Verordnung (EU) 2024/2847) erfasst Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden. Ein klassischer SaaS-Dienst – also Software, die der Anbieter auf eigener Infrastruktur betreibt und dem Kunden über eine Schnittstelle oder Anwendung zugänglich macht – wird nicht zwangsläufig als eigenständiges Produkt mit digitalen Elementen bereitgestellt, sondern ist of nur Teil der Lieferkette.
Eine CRA-Betroffenheitsprüfung endet deshalb noch nicht, weil der SaaS-Dienst Teil der Lieferkette eines vom CRA regulierten Produkts sein kann. Entscheidend ist, welche Rolle die SaaS funktional einnimmt.
Der CRA unterscheidet in diesem Zusammenhang drei Konstellationen:
- SaaS als Datenfernverarbeitungslösung (Remote Data Processing Solution – RDPS),
- SaaS als integrierter Bestandteil einer Produktlösung sowie
- SaaS als rein externer Dienst.
Wann ist SaaS eine Datenfernverarbeitungslösung?
Ein Produkt mit digitalen Elementen kann eine Datenfernverarbeitungslösung beinhalten. Art. 3 Nr. 2 CRA definiert eine Datenfernverarbeitung als eine „entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller 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.“
Eine Datenfernverarbeitungslösung liegt nach Art. 3 Nr. 2 CRA somit vor, wenn drei Voraussetzungen kumulativ erfüllt sind:
- Die Datenverarbeitung findet auf Distanz statt – z.B. in einer Cloud-Infrastruktur außerhalb des Endgeräts.
- Ohne diese Verarbeitung könnte das Produkt eine seiner Funktionen nicht erfüllen.
- Die Software wurde vom Hersteller des Produkts selbst oder unter seiner Verantwortung entwickelt.
Das dritte Kriterium ist entscheidend für die Abgrenzung zwischen Datenfernverarbeitungslösung und externem Dienst: Nutzt der Hersteller einen fremdbetriebenen SaaS-Dienst, den er weder selbst entwickelt hat noch unter seiner Verantwortung entwickeln lässt, qualifiziert dieser Dienst nicht als Datenfernverarbeitungslösung.
Die EU-Kommission stellt in ihren Leitlinien klar, dass der CRA in diesem Fall nicht den SaaS-Betreiber, sondern ausschließlich den Produkthersteller in die Pflicht nimmt – dieser muss die Abhängigkeit jedoch in seiner Risikobeurteilung erfassen und produktseitig Risiken abmildern.
Welche vier Szenarien gibt es und was bedeuten sie für SaaS-Anbieter?
Die folgende Übersicht zeigt, welche Pflichten SaaS-Anbieter in den vier praxisrelevanten Szenarien unter dem CRA treffen können.
Szenario 1: SaaS als rein externer, nicht notwendiger Dienst
Der SaaS-Dienst ergänzt ein Endprodukt, ist für dessen Funktionen aber nicht zwingend erforderlich. In diesem Fall treffen den SaaS-Anbieter keine unmittelbaren CRA-Herstellerpflichten.
Als Teil der Lieferkette eines regulierten Produkts muss er jedoch mit vertraglichen Anforderungen des Produktherstellers rechnen: Nachweise zu Schwachstellenmanagement, Sicherheitsupdates, Authentisierung, Protokollierung, Verfügbarkeit und Vorfallkommunikation sind in diesem Kontext vorstellbar.
Szenario 2: SaaS als technisch notwendiger externer Dienst
Der SaaS-Dienst ist für eine Produktfunktion unverzichtbar, wird aber eigenständig von einem Drittanbieter entwickelt und betrieben. Der SaaS-Anbieter wird dadurch nicht selbst zum Hersteller des Endprodukts; die Herstellerpflichten verbleiben beim Produkthersteller. Dieser muss die Abhängigkeit bewerten und das Produkt mit geeigneten Maßnahmen absichern – etwa kryptografisch geschützte Schnittstellen, Integritätsprüfungen, Ausweichfunktionen oder einen sicheren Zustand bei Ausfall des Backends.
Der SaaS-Anbieter muss deshalb in der Praxis mit deutlich erweiterten Sicherheits- und Informationspflichten rechnen, auch wenn ihn die formalen CRA-Herstellerpflichten nicht direkt treffen.
Szenario 3: SaaS unter Verantwortung des Produktherstellers
Entwickelt der Produkthersteller die Cloud-Funktion selbst oder lässt er sie unter seiner Verantwortung entwickeln, und ist sie für eine Produktfunktion unentbehrlich, qualifiziert sie als Datenfernverarbeitungslösung und fällt in den vollen Anwendungsbereich des CRA. Der Hersteller muss die Lösung in Konformitätsbewertung, technische Dokumentation, Risikoanalyse und Schwachstellenprozesse einbeziehen.
Ein externer SaaS-Betreiber kann dabei als Entwicklungs-, Betriebs- oder Infrastrukturpartner eingebunden sein und wird praktisch deutlich strengeren vertraglichen Vorgaben unterliegen – darunter Mitwirkungspflichten bei Sicherheitstests, Schwachstellenkoordination und Nachweisführung.
Szenario 4: SaaS-Anbieter als Hersteller im Sinne des CRA
Bietet ein Unternehmen eine Softwarelösung selbst als Produkt mit digitalen Elementen auf dem Markt an – unter eigenem Namen oder eigener Marke –, kann es unabhängig vom Betriebsmodell als Hersteller gelten. Ob die Software als SaaS oder lokal installiert bereitgestellt wird, entscheidet diese Rolle nicht allein. Sobald eine SaaS-Lösung eine Client-Komponente mitliefert (z. B. eine Desktop-App oder ein Browser-Plugin), kann diese Komponente als eigenständiges Produkt mit digitalen Elementen einzustufen sein und dann gilt ein SaaS-Anbieter als Hersteller im Sinne des CRA.
In diesem Szenario treffen den Anbieter sämtliche Herstellerpflichten des CRA: sichere Entwicklung, Risikobeurteilung, technische Dokumentation einschließlich SBOM, Konformitätsbewertung, CE-Kennzeichnung, Schwachstellenprozesse sowie Meldepflichten.
Was sollten SaaS-Anbieter jetzt vorbereiten?
Unabhängig vom Szenario empfiehlt sich eine strukturierte Bestandsaufnahme: Für welche Kunden und Produkte wird der Dienst eingesetzt? Ist er ergänzend oder funktional notwendig? Entwickelt der Kunde die relevante Schnittstelle selbst oder unter seiner Verantwortung? Aus den Antworten ergibt sich, welches der vier Szenarien zutrifft – und welche Pflichten und Vertragsanforderungen konkret entstehen.
Darüber hinaus sollten SaaS-Anbieter unabhängig von ihrer CRA-Rolle folgende Grundlagen bereithalten, da Produkthersteller im Rahmen ihrer eigenen Due-Diligence-Pflicht nach Art. 13 Abs. 5 CRA entsprechende Nachweise verlangen werden:
- aktuelle Übersicht eingesetzter Drittsoftware und Unterauftragnehmer (Lieferkettentransparenz);
- dokumentierter Schwachstellenprozess: Meldung, Bewertung, Behebung, Kundenkommunikation;
- Informationen zu Sicherheitsupdates, deren Rhythmus und Unterstützungszeitraum;
- Notfall- und Wiederanlaufverfahren bei Ausfall – insbesondere für funktionskritische Dienste.
Eine dokumentierte Verantwortungsmatrix zwischen SaaS-Anbieter und Produkthersteller ist sinnvoll: Sie legt fest, wer Schwachstellen koordiniert, Updates freigibt, Kunden informiert und welche Nachweise für die Konformitätsbewertung bereitgestellt werden.
Fazit: Die CRA-Relevanz von SaaS hängt an der funktionalen Rolle
Die Annahme, SaaS sei generell vom CRA ausgenommen, ist ebenso unzutreffend wie die Gegenthese, jeder technisch notwendige Cloud-Dienst werde automatisch zum CRA-Produkt.
Für externe Dienste gilt: Der CRA reguliert, wie das Produkt mit den daraus entstehenden Risiken umgeht – nicht, wie die externe Infrastruktur organisiert oder betrieben wird. Die Herstellerrolle und alle damit verbundenen Pflichten treffen denjenigen, der das Endprodukt unter eigenem Namen auf dem Markt bereitstellt. Umgekehrt schützt die Bereitstellung als SaaS nicht vor Herstellerpflichten, wenn das Unternehmen selbst ein Produkt mit digitalen Elementen unter eigener Verantwortung auf dem Markt anbietet.
Ob und in welchem Umfang den SaaS-Anbieter Pflichten unter dem CRA treffen, hängt also nicht am Bereitstellungsmodell, sondern an der Frage, welche Funktion der Dienst im Verhältnis zu einem regulierten Produkt übernimmt.
Für die Praxis empfiehlt sich eine belastbare Einordnung je Dienst, ergänzt um dokumentierte Sicherheitsprozesse und klare Verträge mit den betroffenen Produktherstellern.