Was gilt für SaaS, On-Premises und Apps?
Beim Cyber Resilience Act (CRA) denken viele zunächst an vernetzte Geräte, IoT-Hardware oder industrielle Steuerungen. Für Software-Hersteller ist die eigentliche Schlüsselfrage aber oft eine andere: Gilt der CRA auch für unsere Software – und wenn ja, für welche Form? Genau hier wird es in der Praxis spannend, denn zwischen On-Premises-Software, mobilen Apps und SaaS-Modellen gibt es wichtige Unterschiede. Der CRA ist seit dem 10. Dezember 2024 in Kraft. Die wesentlichen Pflichten gelten ab 11. Dezember 2027, die Reporting-Pflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle bereits ab 11. September 2026.
Der Ausgangspunkt: Der CRA ist ein Produktgesetz
Der CRA regelt Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Dazu zählen laut EU-Kommission sowohl Endprodukte als auch Komponenten, die separat in den Verkehr gebracht werden. Ein Produkt fällt in den CRA-Anwendungsbereich, wenn es auf dem Markt bereitgestellt wird und seine beabsichtigte oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.
Für Software-Hersteller ist das wichtig, weil der CRA eben nicht nur Embedded Software im Blick hat. Die Kommission beschreibt den CRA ausdrücklich als Regelwerk für Hardware und Software; in den CRA-Materialien werden sogar mobile Anwendungen ausdrücklich als Beispiel genannt.
Was für Apps gilt
Bei mobilen Apps ist die Einordnung vergleichsweise klar. Die Europäische Kommission nennt mobile applications ausdrücklich als CRA-relevante Produktkategorie im Kontext der Konformitätsbewertung. Das ist ein starkes Signal für die Praxis: Wer Apps als Produkt auf dem EU-Markt bereitstellt, sollte grundsätzlich davon ausgehen, dass CRA-Pflichten relevant werden können.
Das bedeutet nicht automatisch, dass jede App denselben Aufwand auslöst. Aber es bedeutet: App-Anbieter sollten das Thema nicht auf später verschieben. Sobald die App als Produkt mit digitalen Elementen eingeordnet wird, greifen Herstellerpflichten wie Risikobewertung, technische Dokumentation, Konformitätsbewertung, CE-Kennzeichnung und ein geregelter Umgang mit Schwachstellen über den Support-Zeitraum hinweg.
Was für On-Premises-Software gilt
Für klassische On-Premises-Software ist die Lage in der Regel ebenfalls relativ klar. Wenn Software als Produkt bereitgestellt wird und mit Geräten oder Netzwerken verbunden ist oder dafür bestimmt ist, spricht viel dafür, dass sie unter den CRA fällt. Der CRA ist gerade dafür geschaffen worden, auch Softwareprodukte auf dem EU-Markt mit einheitlichen Cybersecurity-Anforderungen zu erfassen.
Für viele Software-Häuser ist On-Prem deshalb der einfachste CRA-Fall: Die Software wird als Produkt ausgeliefert, ist klar einem Hersteller zugeordnet und wird im Rahmen einer wirtschaftlichen Tätigkeit auf dem Unionsmarkt bereitgestellt. Genau für solche Fälle sieht der CRA seine Herstellerpflichten vor.
Und was ist mit SaaS?
Hier beginnt die eigentliche Abgrenzungsarbeit. Der CRA definiert ein „Produkt mit digitalen Elementen“ als Software- oder Hardwareprodukt und seine Remote-Data-Processing-Lösungen. Eine solche Remote Data Processing Solution ist nach der EU-Definition eine Datenverarbeitung auf Distanz, die vom Hersteller oder unter seiner Verantwortung entwickelt wurde und deren Fehlen dazu führen würde, dass das Produkt mit digitalen Elementen eine seiner Funktionen nicht mehr ausführen kann.Das ist für SaaS-Anbieter der entscheidende Punkt:
Wenn eine Cloud- oder Backend-Komponente integraler Bestandteil eines Produkts ist und ohne sie eine Funktion des Produkts nicht mehr funktioniert, dann ist diese Remote-Lösung nach der CRA-Logik Teil des Produkts. Genau deshalb hat die Kommission 2026 zusätzliche Leitlinien veröffentlicht bzw. als Entwurf zur Konsultation gestellt, die sich ausdrücklich auf remote data processing solutions konzentrieren.
Die praktische Faustregel für SaaS
Für die Praxis lässt sich daraus eine sinnvolle erste Einordnung ableiten:
1. SaaS als integrierter Produktbestandteil
Wenn Ihre Cloud-Plattform oder Ihr Backend so eng mit einem digitalen Produkt verbunden ist, dass dieses Produkt ohne die Remote-Funktion wesentliche Features nicht mehr ausführen kann, ist CRA-Relevanz sehr wahrscheinlich. Das betrifft zum Beispiel Produkte, deren Sicherheits-, Steuerungs-, Analyse- oder Nutzungsfunktionen von einer herstellerseitig verantworteten Remote-Komponente abhängen. Diese Einschätzung folgt direkt aus der offiziellen Definition der „remote data processing solution“.
2. Standalone-SaaS ohne Produktbezug
Wenn Sie hingegen eine reine cloudbasierte Dienstleistung anbieten, die nicht als integrierter Bestandteil eines Produkts mit digitalen Elementen ausgestaltet ist, wird die Einordnung schwieriger. Der CRA ist seinem Aufbau nach ein Produktrechtsrahmen für Produkte mit digitalen Elementen. Gerade weil die Kommission zu diesem Punkt gesonderte Leitlinien vorbereitet hat, sollte reine Standalone-SaaS nicht vorschnell pauschal eingeordnet werden, sondern anhand des konkreten Leistungsmodells, der Produktarchitektur und der Marktbereitstellung geprüft werden. Diese Unsicherheit ist einer der Gründe, warum das Thema aktuell in der Umsetzung besonders relevant ist.
Drei typische Fallbeispiele
Fall 1: Mobile Business-App
Ein Anbieter vertreibt eine mobile App für Wartungsdokumentation oder Projektsteuerung. Mobile Apps werden von der Kommission ausdrücklich als CRA-relevantes Beispiel genannt. Hier sollte der Anbieter grundsätzlich mit CRA-Relevanz rechnen.
Fall 2: On-Premises-Software für Unternehmen
Ein Software-Haus liefert eine lokal installierte Lösung für Dokumentenmanagement, Produktionssteuerung oder Monitoring. Da der CRA Softwareprodukte auf dem Markt erfasst, ist dieser Fall typischerweise im CRA-Rahmen zu prüfen.
Fall 3: Cloud-Backend als notwendige Produktfunktion
Ein Hersteller bietet eine Software oder ein Gerät an, dessen zentrale Funktionen nur über ein herstellerseitiges Cloud-Backend laufen. Wenn das Produkt ohne diese Remote-Lösung eine Funktion nicht mehr erfüllen kann, spricht die CRA-Definition dafür, dass diese Remote-Komponente mit dem Produkt mitzudenken ist.
Warum diese Einordnung für Software-Hersteller so wichtig ist
Sobald ein Softwareprodukt in den CRA fällt, geht es nicht nur um ein Etikett, sondern um echte Pflichten: Hersteller müssen eine Cybersecurity-Risikobewertung durchführen, die wesentlichen Sicherheitsanforderungen umsetzen, die technische Dokumentation vorhalten, vor dem Inverkehrbringen eine Konformitätsbewertung durchführen, die EU-Konformitätserklärung erstellen und die CE-Kennzeichnung anbringen. Außerdem müssen sie einen Support-Zeitraum festlegen und wirksames Vulnerability Handling sicherstellen.
Für Software-Unternehmen heißt das konkret: Die CRA-Frage gehört nicht erst in die Rechtsabteilung, sondern auch in Produktmanagement, Entwicklung, DevSecOps, Support und Geschäftsführung. Wer die Einordnung zu spät macht, verliert Zeit bei Architektur, Verantwortlichkeiten, Dokumentation und Prozesseinführung. Diese Schlussfolgerung ergibt sich unmittelbar aus den Herstellerpflichten und den gestaffelten Anwendungszeitpunkten des CRA.
Fazit
Für Apps ist der CRA-Bezug heute am klarsten. On-Premises-Software ist in vielen Fällen ebenfalls naheliegend CRA-relevant, weil der CRA ausdrücklich Softwareprodukte auf dem Markt erfasst. SaaS ist der Bereich, in dem die Abgrenzung am stärksten vom konkreten Produkt- und Bereitstellungsmodell abhängt – insbesondere von der Frage, ob eine Remote-Komponente integraler Bestandteil eines Produkts mit digitalen Elementen ist. Genau deshalb ist für Software-Hersteller eine frühe CRA-Einordnung des Portfolios so wichtig.
Sie möchten belastbar klären, wie Ihre Software unter dem CRA einzuordnen ist – ob SaaS, On-Premises oder App? Wir unterstützen Sie mit einem pragmatischen CRA-Check für Software-Hersteller: Produktabgrenzung, Architekturprüfung, erste Risikoeinordnung und klare nächste Schritte für Compliance und Umsetzung.
