Fällt mein SaaS unter den CRA?

Reine SaaS-, PaaS- und IaaS-Angebote fallen nach Erwägungsgrund 12 der CRA-Verordnung grundsätzlich nicht unter den Cyber Resilience Act, sondern unter die NIS-2-Richtlinie. Eine Ausnahme besteht, wenn die Software als eigenständiges Produkt in Verkehr gebracht wird (z. B. installierbare App) oder wenn ein Cloud-Backend als sogenannte Remote-Datenverarbeitungslösung (RDPS) untrennbarer Bestandteil eines Produkts mit digitalen Elementen ist. 

Ob ein SaaS-Produkt unter den Cyber Resilience Act (CRA) fällt, ist für viele Anbieter im DACH-Raum noch unklar, gerade weil sich die Fristen konkretisieren: Ab dem 11. September 2026 greifen die ersten Meldepflichten nach Art. 14 CRA für Unternehmen, deren Produkte tatsächlich in den Anwendungsbereich fallen (mehr dazu im Artikel zur CRA-Meldepflicht). Für reine SaaS-Anbieter stellt sich davor eine grundlegendere Frage: Bin ich überhaupt betroffen, oder greift für mein Angebot stattdessen die NIS 2-Richtlinie? Die Antwort hängt nicht vom Label "Software" ab, sondern von einer präzisen Abgrenzung zwischen Produkt und Service, die dieser Artikel Schritt für Schritt auflöst. 

Grundregel: Recital 12 CRA vs. NIS-2 

Der Ausgangspunkt steht in Erwägungsgrund 12 der CRA-Verordnung (VO (EU) 2024/2847): Cloud-Dienste, die unabhängig von der Verantwortung eines Herstellers eines Produkts mit digitalen Elementen konzipiert und entwickelt werden, fallen grundsätzlich nicht in den Anwendungsbereich der CRA. Reine SaaS-, PaaS- und IaaS-Angebote werden stattdessen von der NIS-2-Richtlinie (RL (EU) 2022/2555) erfasst, die eigene Sicherheitsanforderungen für Cloud-Computing-Dienste vorsieht. 

Für die Praxis heißt das: Wer ausschließlich eine über den Browser nutzbare Software-as-a-Service-Lösung betreibt, ohne dass diese Bestandteil eines separaten Hardware- oder Software-Produkts ist, bewegt sich in der Regel im NIS-2-Rahmen, nicht im CRA-Rahmen. Der entscheidende Bruch verläuft also nicht zwischen "Cloud" und "On-Premise", sondern zwischen Service und Produkt. 

Wann wird SaaS doch zum "Produkt"? 

Die Abgrenzung ist nicht immer eindeutig. Software gilt als "Produkt mit digitalen Elementen" im Sinne der CRA und ist damit potenziell betroffen, wenn einer von zwei Fällen zutrifft. 

Fall A: Eigenständiges Software-Produkt. Die Software wird als herunterladbare oder installierbare Anwendung in Verkehr gebracht, etwa eine Desktop-Applikation, eine mobile App oder ein Client, den Nutzer selbst installieren. Hier greift die CRA unabhängig davon, ob im Hintergrund zusätzlich Cloud-Komponenten laufen. 

Fall B: Remote-Datenverarbeitungslösung (RDPS) nach Art. 3 CRA. Ein Cloud-Backend gilt als Teil eines Produkts mit digitalen Elementen, wenn es vom Hersteller (oder in dessen Verantwortung) entwickelt wurde und das Produkt ohne diese Datenverarbeitung eine seiner Kernfunktionen nicht erfüllen kann. Ein typisches Beispiel ist eine mobile App, die zwingend auf eine vom selben Hersteller betriebene API oder Datenbank zugreifen muss, um zu funktionieren. 

Reines SaaS ohne Anbindung an ein separates Produkt fällt dagegen unter keinen der beiden Fälle und bleibt im NIS-2-Rahmen. 

Die finale Kommissions-Leitlinie und der Dreifachtest 

Am 27. Juli 2026 hat die Europäische Kommission den Inhalt ihrer Leitlinie zur Anwendung der CRA genehmigt (Dokument C(2026) 5252, gestützt auf Art. 26 CRA). Inhaltlich ist die Leitlinie damit final, die formale Annahme in allen EU-Amtssprachen steht jedoch noch aus. Wichtig für die Einordnung bleibt unabhängig davon: Die Leitlinie ist eine Auslegungshilfe der Kommission, aber rechtlich nicht bindend. Eine verbindliche Auslegung der CRA kann letztlich nur der Europäische Gerichtshof liefern. 

Die Leitlinie beschreibt drei kumulative Kriterien, die alle gleichzeitig erfüllt sein müssen, damit ein Cloud-Backend als RDPS in den CRA-Anwendungsbereich fällt: 

1. Datenverarbeitung aus der Ferne. Die Verarbeitung findet außerhalb des Endgeräts der Nutzerin oder des Nutzers statt. 
2. Funktionale Notwendigkeit. Das Produkt kann ohne diese Datenverarbeitung eine seiner Funktionen nicht erfüllen. 
3. Gleiche Herstellerverantwortung. Die Software für die Datenverarbeitung wurde vom Hersteller des Produkts selbst entwickelt oder in dessen Auftrag und Verantwortung. 

Fehlt eines der drei Kriterien, bleibt das Cloud-Backend außerhalb des CRA-Anwendungsbereichs, auch wenn es technisch eng mit einem Produkt verbunden ist. 

Betroffenheits-Check 

Die folgende Übersicht hilft bei der ersten Einordnung. Sie ersetzt keine Rechtsberatung, gibt aber eine belastbare erste Orientierung. 

Für Implementierer (CTO, CISO, IT Security Manager): Die Abgrenzung hat direkte Auswirkungen auf Architekturentscheidungen. Wer eine Companion-App oder einen lokalen Client plant, sollte frühzeitig prüfen, ob damit auch das dahinterliegende Backend zur RDPS wird und somit CRA-Anforderungen wie Security-by-Design und Schwachstellenmanagement für die gesamte Kette gelten, nicht nur für die App selbst. Eine klare technische Dokumentation, welche Komponente welche Funktion erfüllt, erleichtert diese Einordnung erheblich. 

Für Entscheider (CEO, CFO): Unabhängig davon, ob am Ende die CRA oder NIS-2 greift, entstehen in beiden Fällen Pflichten und Haftungsrisiken für die Geschäftsführung. Die Frage ist also nicht "betrifft uns Regulierung überhaupt", sondern "welches Regelwerk, mit welchen Nachweis- und Meldepflichten". Eine frühzeitige, dokumentierte Einordnung schafft Rechtssicherheit gegenüber Aufsichtsbehörden und Geschäftspartnern. 

Vorhandene Nachweise nutzen: C5 und SOC 2 als Ausgangsbasis 

Unternehmen, die bereits nach BSI C5 oder SOC 2 geprüft sind, verfügen bereits über dokumentierte Nachweise zu Sicherheitsmaßnahmen, Change-Management und Incident Response. Diese Nachweise lassen sich bei der Einordnung nach NIS 2 oder CRA in der Regel als Ausgangsbasis nutzen, statt Dokumentation und Prozesse doppelt aufzubauen. Das ersetzt die individuelle CRA/NIS-2-Prüfung nicht, reduziert aber den Aufwand für bereits geprüfte Organisationen spürbar. 

Die folgenden Begriffe sind bewusst knapp gehalten und dienen der schnellen Orientierung, sie ersetzen keine vollständigen Rechtsdefinitionen.