SaaS und der Cyber Resilience Act: Warum 'Wir sind doch nur Cloud' nicht mehr reicht

Von codAIx GmbH | April 2026

Ab dem 11. Dezember 2027 gelten die Cybersicherheitsanforderungen des EU Cyber Resilience Act (CRA) für alle „Produkte mit digitalen Elementen" auf dem europäischen Markt. Viele SaaS-Anbieter wiegen sich in Sicherheit: Ihre Software läuft in der Cloud, nicht auf dem Gerät des Kunden — also keine CRA-Pflicht, richtig? Die Antwort ist komplizierter, als die meisten erwarten.

Eine Verordnung, die alles ändert

Der Cyber Resilience Act — offiziell Verordnung (EU) 2024/2847 [1] — ist die erste EU-weite horizontale Regulierung, die verbindliche Cybersicherheitsanforderungen für Software und Hardware festschreibt. Nicht als freiwilliger Standard, nicht als branchenspezifische Richtlinie, sondern als unmittelbar geltendes Recht in allen 27 Mitgliedstaaten.

Die zentrale Idee: Wer ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, muss nachweisen, dass es grundlegende Cybersicherheitsanforderungen erfüllt — von der Entwicklung über den gesamten Lebenszyklus bis zum End-of-Support. Dazu gehören Vulnerability Management, Software Bill of Materials (SBOM), Security by Design und eine dokumentierte Konformitätsbewertung.

Der Zeitplan steht fest: Die Verordnung ist seit 10. Dezember 2024 in Kraft [1, Art. 71 Abs. 1]. Die Meldepflichten für aktiv ausgenutzte Schwachstellen greifen ab dem 11. September 2026 [1, Art. 71 Abs. 2]. Die vollständigen Produktanforderungen gelten ab dem 11. Dezember 2027 [1, Art. 71 Abs. 3]. Wer dann nicht konform ist, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes [1, Art. 64 Abs. 1].

Was genau ist ein „Produkt mit digitalen Elementen"?

Art. 3 Nr. 1 CRA definiert den Schlüsselbegriff: Ein Produkt mit digitalen Elementen ist jedes Software- oder Hardwareprodukt „und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in Verkehr gebracht werden" [1, Art. 3 Nr. 1].

Zwei Dinge fallen auf. Erstens: Software allein — ohne jede Hardwarekomponente — kann ein Produkt mit digitalen Elementen sein. Eine Desktop-Anwendung, eine Mobile App, ein Firmware-Update: All das fällt unter den CRA, sobald es auf dem EU-Markt bereitgestellt wird. Die Erwägungsgründe (12) bis (14) des CRA stellen dies ausdrücklich klar [1, ErwGr (12)–(14)].

Zweitens — und hier wird es für SaaS-Anbieter relevant — der Begriff der „Datenfernverarbeitungslösung" (im Englischen: Remote Data Processing Solution, kurz RDPS). Art. 3 Nr. 2 CRA definiert sie als Datenverarbeitung auf Entfernung, die von der lokalen Softwarekomponente nicht durchgeführt werden kann [1, Art. 3 Nr. 2]. Entscheidend sind drei Kriterien: Erstens muss die Datenverarbeitung räumlich entfernt stattfinden (auf einem Server des Herstellers). Zweitens muss die Software vom Hersteller selbst entwickelt worden sein oder unter dessen Verantwortung stehen. Drittens — und das ist der kritische Punkt — darf die lokale Produktkomponente ohne diese entfernte Verarbeitung nicht in der Lage sein, eine ihrer Funktionen auszuführen. Die Abwesenheit der Cloud-Verarbeitung muss also eine wesentliche Funktion des Produkts beeinträchtigen.

Die Falle: Wann SaaS doch CRA-pflichtig wird

Hier liegt das Missverständnis, das in der DACH-Softwarebranche immer noch weit verbreitet ist. Viele Unternehmen kategorisieren ihr Produkt pauschal als „SaaS" und schlussfolgern: Cloud-basiert, also kein lokales Produkt, also kein CRA.

Diese Schlussfolgerung ist in vielen Fällen falsch.

Der Grund: Viele moderne SaaS-Produkte sind nicht mehr „rein" browserbasiert. Denken Sie an eine Projektmanagement-Software, die auch eine Desktop-App und eine Mobile App anbietet. Oder an ein Monitoring-Tool, das einen Agent auf dem Server des Kunden installiert. Oder an eine Collaboration-Plattform mit einem Browser-Plugin für die E-Mail-Integration.

In jedem dieser Fälle existiert eine lokale Softwarekomponente — eine App, ein Agent, ein Plugin. Und sobald diese lokale Komponente ihre Funktion ohne die Server-Verarbeitung des Herstellers nicht erfüllen kann, liegt eine Datenfernverarbeitungslösung im Sinne des CRA vor. Das gesamte Produkt — lokale Komponente plus Cloud-Backend — wird dann nach dem CRA bewertet.

Entscheidend für diese Bewertung ist der neue Drei-Elemente-Test der EU-Kommission [5], den wir im nächsten Artikel dieser Serie im Detail vorstellen. Zunächst sei nur erwähnt: Die Bewertung ist nicht binär — das Ergebnis kann entweder eine CRA-pflichtige RDPS sein, oder eine Drittanbieter-Komponente mit abgestuften Compliance-Anforderungen, oder eine bloße Risikobewertung. Welches dieser drei Ergebnisse für Ihr Produkt relevant ist, hängt von Architektur und Design ab.

Die internationale Wirtschaftskanzlei DLA Piper hat diese Abgrenzung in einer Sekundärquelle vom Februar 2026 als „fine line" beschrieben [2]. Die Grenze zwischen CRA-pflichtiger RDPS und reiner Cloud-Software, die unter die NIS-2-Richtlinie fällt, verläuft oft mitten durch das Produktportfolio eines einzelnen Unternehmens. Auch Linklaters kommt in einer Sekundärquelle vom März 2026 zu einem ähnlichen Befund [3].

Reine SaaS: Was wirklich außen vor bleibt

Tatsächlich nicht CRA-pflichtig sind Lösungen, die ausschließlich über den Browser genutzt werden, keine lokale Installation erfordern und bei denen der Hersteller keine Software auf dem Gerät des Nutzers ausführt. Ein klassisches Beispiel: Eine reine Webmail-Oberfläche, die vollständig serverseitig läuft. Der Nutzer öffnet einen Browser, interagiert mit der Anwendung, aber auf seinem Gerät wird keine herstellereigene Software installiert oder ausgeführt.

Solche reinen SaaS-Lösungen fallen nicht unter den CRA, sondern unter das NIS-2-Regime (Richtlinie (EU) 2022/2555) [4], sofern der Anbieter als wesentlicher oder wichtiger Einrichtungstyp eingestuft wird. Erwägungsgrund (12) des CRA stellt klar, dass reine Cloud-Dienste ohne verbundenes lokales Produkt nicht in den Anwendungsbereich fallen [1, ErwGr (12)].

Die Abgrenzung klingt einfacher, als sie in der Praxis ist. Was ist mit einem SaaS-Produkt, das Progressive Web App (PWA)-Funktionalität bietet? Was, wenn der Browser-Tab offline-fähig ist und lokale Daten cached? Was, wenn ein optionales Desktop-Wrapper existiert, den nur 5 Prozent der Kunden nutzen? Diese Fragen sind Stand April 2026 nicht abschließend geklärt — aber die EU-Kommission hat mit einem neuen Orientierungsrahmen einen wichtigen Maßstab geschaffen [5], den wir im nächsten Artikel dieser Serie im Detail vorstellen.

Was das für die DACH-Softwarebranche bedeutet

Für Softwarehersteller in Deutschland, Österreich und der Schweiz hat die CRA-Abgrenzung weitreichende Konsequenzen. Die entscheidende Frage lautet nicht „Sind wir ein SaaS-Unternehmen?", sondern: „Hat unser Produkt eine lokale Komponente, die ohne Server-Verarbeitung nicht funktioniert?"

Viele Unternehmen, die sich als reine Cloud-Anbieter verstehen, bieten parallel Desktop-Apps, Mobile Apps, Browser-Extensions, CLI-Tools oder Agents an. Jede dieser lokalen Komponenten kann dazu führen, dass das Cloud-Backend als Datenfernverarbeitungslösung unter den CRA fällt. DLA Piper beschreibt diese Abgrenzung als „fine line", die oft mitten durch das Produktportfolio eines einzelnen Unternehmens verläuft [2].

Tatsächlich rein browserbasierte Lösungen — ohne jede lokale Installation — dürften in der DACH-Softwarebranche die Minderheit darstellen. Belastbare empirische Studien zum genauen Anteil existieren bisher nicht. Aber die Produktrealität spricht eine deutliche Sprache: Wer eine Desktop-App im Download-Bereich anbietet, wer ein SDK für Kundenintegrationen bereitstellt, wer Agents für Monitoring oder Deployment verteilt, ist mit hoher Wahrscheinlichkeit CRA-pflichtig — auch wenn das Kernprodukt „in der Cloud läuft".

Was jetzt zu tun ist

Für Softwareunternehmen in der DACH-Region gibt es drei unmittelbare Handlungsschritte.

Der erste: Klären Sie, ob Ihr Produkt unter den CRA fällt. Nicht auf Basis einer pauschalen Einschätzung, sondern anhand der konkreten Produktarchitektur. Hat Ihre Lösung eine lokale Komponente — eine App, einen Agent, ein Plugin, ein SDK? Dann ist die Wahrscheinlichkeit hoch, dass Sie CRA-pflichtig sind. Das BSI empfiehlt in seiner Technischen Richtlinie TR-03183, diese Prüfung systematisch und dokumentiert durchzuführen [6].

Der zweite: Verstehen Sie den Zeitplan. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten bereits ab September 2026 [1, Art. 71 Abs. 2]. Das ist weniger als sechs Monate entfernt. Spätestens dann brauchen Sie einen funktionierenden Prozess für Vulnerability Disclosure und Incident Reporting — die ENISA wird dafür eine zentrale Meldeplattform betreiben [1, Art. 16].

Der dritte: Beginnen Sie jetzt mit der Gap-Analyse. Die vollständigen Produktanforderungen — SBOM, Security by Design, Konformitätsbewertung — treten im Dezember 2027 in Kraft. Das klingt weit weg, aber die Erfahrung mit vergleichbaren Regulierungen wie der DSGVO zeigt: Unternehmen, die erst ein Jahr vor der Deadline starten, geraten unter erheblichen Druck. Bitkom stellt in seinem aktuellen Positionspapier zum CRA fest, dass der Konformitätsbewertungsprozess so komplex sei, dass er „für die große Mehrheit der KMU, aber auch für größere Unternehmen, nicht zugleich rechtskonform und wirtschaftlich umsetzbar" sei [7].

Sie möchten wissen, ob Ihr Produkt unter den CRA fällt? Mit dem kostenlosen Quick Check auf craiready.com erhalten Sie in wenigen Minuten eine erste Einschätzung — einschließlich der relevanten Produktkategorie und der für Sie geltenden Fristen.

Im nächsten Artikel dieser Serie: Der Drei-Elemente-Test der EU-Kommission — das offizielle Instrument, mit dem Sie systematisch prüfen können, ob Ihre Software eine Datenfernverarbeitungslösung im Sinne des CRA darstellt.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyber Resilience Act). ABl. L, 20.11.2024. Verfügbar unter: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[2] DLA Piper, „Cyber Resilience Act: the fine line between SaaS and digital products", Februar 2026. Sekundärquelle zur Abgrenzung von SaaS und CRA-pflichtiger Datenfernverarbeitungslösung. Verfügbar unter: https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-the-fine-line-between-saas-and-digital-products. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; Primärquelle ist [1] und [5].

[3] Linklaters, „EU Cyber Resilience Act: Commission issues first draft guidance – 10 key points you need to know", März 2026. Sekundärquelle mit zentralen Punkten für Softwarehersteller. Verfügbar unter: https://techinsights.linklaters.com/post/102mmlo/eu-cyber-resilience-act-commission-issues-first-draft-guidance-10-key-points-y. Hinweis: Kanzlei-Publikation ohne garantierte dauerhafte Verfügbarkeit; Primärquelle ist [1] und [5].

[4] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). ABl. L 333, 27.12.2022. Verfügbar unter: https://eur-lex.europa.eu/eli/dir/2022/2555/oj.

[5] Europäische Kommission, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)" — Draft Communication Ares(2026)2319816 vom 3. März 2026. Enthält den Drei-Elemente-Test zur Bestimmung, ob eine Software als Datenfernverarbeitungslösung im Sinne des CRA einzustufen ist. Konsultationsfrist: 13. April 2026. Verfügbar unter: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959.

[6] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products. Teil 1: Cybersicherheitsanforderungen, Teil 2: SBOM, Teil 3: Schwachstellenmanagement. Sekundärquelle zur praktischen Umsetzung. Verfügbar unter: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/tr-03183.html.

[7] Bitkom e.V., „Cyber Resilience Act: An updated position paper on the transposition at the European Level", 2026. Sekundärquelle zu Umsetzungskomplexität, Fristen und KMU-Belastung. Bitkom stellt fest, der Konformitätsbewertungsprozess sei für die Mehrheit der KMU „not both legally compliant and economically feasible due to the effort involved". Verfügbar unter: https://www.bitkom.org/sites/main/files/2026-02/bitkom-position-paper-cyber-resilience-act-transposition-at-european-level.pdf.