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

Von Redaktion codAIx | März 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 i. V. m. Veröffentlichung im ABl. vom 20.11.2024]. Das Kapitel IV (Notifizierungsvorschriften, Art. 35–51 CRA) gilt ab dem 11. Juni 2026 [1, Art. 71 Abs. 2 UAbs. 2]. Die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen greifen ab dem 11. September 2026 — das sind zum Stand 20. Mai 2026 noch knapp vier Monate [1, Art. 14 i. V. m. Art. 71 Abs. 2 UAbs. 2]. Die vollständigen Produktanforderungen gelten ab dem 11. Dezember 2027 — also etwa 19 Monate später [1, Art. 71 Abs. 2 UAbs. 1]. Wer dann nicht konform ist, riskiert Bussgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes [1, Art. 64 Abs. 2].

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, einschliesslich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden" [1, Art. 3 Nr. 1].

Zwei Dinge fallen auf. Zunächst: 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. Art. 3 Nr. 1 CRA stellt dies ausdrücklich klar [1, Art. 3 Nr. 1].

Darüber hinaus — 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 die zugrunde liegende „Datenfernverarbeitung" als jede Datenverarbeitung in der Distanz, für die die Software vom Hersteller oder unter dessen Verantwortung konzipiert und entwickelt wird und deren Fehlen verhindern würde, dass das Produkt mit digitalen Elementen eine seiner Funktionen ausführen kann [1, Art. 3 Nr. 2]. Der Verordnungstext nennt damit drei Tatbestandsmerkmale, die wir nachfolgend in der Reihenfolge des Gesetzeswortlauts erläutern:

Erstens muss die Datenverarbeitung räumlich entfernt stattfinden — also nicht lokal auf dem Gerät des Nutzers. Art. 3 Nr. 2 CRA knüpft dabei ausschliesslich an die Software an: erfasst ist eine „entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird" [1, Art. 3 Nr. 2]. Wem die Server-Infrastruktur selbst gehört, regelt der Wortlaut nicht. Auch Erwägungsgrund 11 stellt nur auf die Funktionserforderlichkeit ab: „die Fernverarbeitung oder -speicherung [fällt] nur insoweit in den Anwendungsbereich dieser Verordnung, als sie notwendig ist, damit ein Produkt mit digitalen Elementen seine Funktionen erfüllen kann" [1, ErwGr (11)]. Damit kommen eigene Rechenzentren des Herstellers, Hyperscaler-Dienste (AWS, Azure, GCP) und On-Premises-Installationen beim Kunden gleichermassen in Betracht, solange die dort laufende Software vom Hersteller stammt.

Zweitens muss die Software vom Hersteller selbst entwickelt worden sein oder unter dessen Verantwortung stehen. Art. 3 Nr. 13 CRA definiert „Hersteller" weit: erfasst ist eine Person, die „Produkte mit digitalen Elementen entwickelt oder herstellt oder die Produkte mit digitalen Elementen konzipieren, entwickeln oder herstellen lässt und sie unter ihrem Namen oder ihrer Marke vermarktet, sei es gegen Bezahlung, zur Monetarisierung oder unentgeltlich" [1, Art. 3 Nr. 13]. Auftragsentwicklung, OEM- und White-Label-Konstruktionen sowie individuell für das Produkt entwickelte SaaS-Komponenten fallen damit in die Verantwortungssphäre des Herstellers, auch wenn er sie nicht selbst codiert. Erwägungsgrund 12 grenzt umgekehrt aus: „Cloud-Dienste, die ausserhalb der Verantwortung eines Herstellers eines Produkts mit digitalen Elementen entworfen und entwickelt wurden, [fallen] nicht in den Anwendungsbereich dieser Verordnung" [1, ErwGr (12)]. Generische Cloud-Bausteine, die der Hersteller lediglich als Infrastruktur einkauft — etwa Speicherdienste oder ein Standard-Authentifizierungsanbieter —, bleiben damit aussen vor.

Drittens — und das ist der praktisch entscheidende Punkt — würde das Fehlen der entfernten Verarbeitung verhindern, dass das Produkt eine seiner Funktionen ausführen kann. Art. 3 Nr. 2 CRA verlangt ausdrücklich eine Verarbeitung, „ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte" [1, Art. 3 Nr. 2]. Erwägungsgrund 12 macht das negativ greifbar: „Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen, [fallen] nicht in den Anwendungsbereich dieser Verordnung" [1, ErwGr (12)]. Für die Praxis folgt daraus: Optionale, hilfreiche, aber für die Kernfunktion entbehrliche Cloud-Komponenten — etwa ein parallel laufendes Telemetrie-Dashboard oder ein reines Service-Portal — lösen für sich genommen keine Pflicht nach dem CRA aus. Ist die entfernte Verarbeitung dagegen funktional unverzichtbar, wird das gesamte Produkt — lokale Komponente plus Cloud-Backend — als Einheit nach dem CRA bewertet.

Hinweis zur Reihenfolge: Die EU-Kommission greift dieselben drei Tatbestandsmerkmale in ihrer Draft Communication Ares(2026)2319816 (Rn. 168) auf, ordnet sie aber analytisch um: Sie zieht die Funktionsprüfung vor die Herstellerprüfung, weil das die sachlich klarere Prüfungsreihenfolge ergibt. Wir folgen im nächsten Teil dieser Serie der Reihenfolge der Kommission. Die rechtsdogmatische Substanz bleibt identisch — nur die Prüfungsabfolge unterscheidet sich [5].

In der deutschsprachigen Kommentarliteratur ist umstritten, ob eine Datenfernverarbeitungslösung ein zwingendes Tatbestandsmerkmal des Produktbegriffs ist. Die überwiegende Auffassung verneint dies (so Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3, 5) [8]; eine Mindermeinung (Schöttle, MMR 2024, 741, 742) fasst sie als kumulatives Erfordernis auf. Im Zweifel sollten auch Hersteller reiner Offline-Software die CRA-Anwendbarkeit prüfen.

Warum SaaS systematisch besonders behandelt wird

Bevor wir auf die praktische Falle für SaaS-Anbieter eingehen, lohnt ein Blick auf die rechtliche Systematik. Eine SaaS ist technisch zweifellos „Software" im Sinne von Art. 3 Nr. 4 CRA — „Teil eines elektronischen Informationssystems, der aus Computercode besteht" [1, Art. 3 Nr. 4]. Trotzdem fällt eine reine Browser-SaaS nicht unter den CRA. Wo genau sie aus dem Anwendungsbereich herausfällt, ist juristisch nicht zweifelsfrei. In der Kommentarliteratur stehen sich zwei Lesarten gegenüber, die im Ergebnis zur selben Schlussfolgerung führen.

Lesart A (herrschende Lesart) — Scheitern am Produkterfordernis. Nach dieser Auffassung ist eine reine SaaS bereits kein „Produkt" iSd Art. 3 Nr. 1 CRA. „Produkt" ist im EU-Produktrecht eine abgrenzbare, in eine einzelne Marktbereitstellung überführbare Einheit — so auch der „Blue Guide on the implementation of EU product rules" 2022 der EU-Kommission in Abschnitt 2 [9]. Eine SaaS ist ihrem Wesen nach das Gegenteil: kein abgegrenztes Software-Artefakt, sondern ein kontinuierlich erbrachter Dienst. Der CRA-Kommentar von Wiebe formuliert das präzise und mit einer wichtigen Bedingung: Cloud-Dienstmodelle wie SaaS, PaaS und IaaS, „welche die Produktfunktionalität — etwa als Backend — nicht unterstützen bzw. für diese nicht erforderlich sind, stellen folglich keine CRA-relevante Software dar" [8, § 4 Rn. 5]. SaaS ist also technisch Software, aber — solange sie kein Produkt funktional trägt — keine CRA-relevante Software. Erwägungsgrund 12 CRA bekräftigt das, indem er Cloud-Dienstmodelle der NIS-2-Richtlinie zuweist [1, ErwGr (12); 4]; die EU-Kommissions-Guidance bestätigt es in Ares Rn. 167 [5, Rn. 167].

Lesart B (theoretisch denkbare Alternativauslegung) — Scheitern am Bereitstellungserfordernis. Denkbar wäre auch, SaaS-Code als „Softwareprodukt" iSd Art. 3 Nr. 1 CRA einzuordnen und das Ausscheiden erst an der fehlenden „Abgabe" iSd Art. 3 Nr. 22 CRA festzumachen. Diese Auslegung bleibt enger am isolierten Wortlaut, wird in der Kommentarliteratur aber nicht als eigenständige Gegenposition vertreten und kommt ohnehin zum gleichen Ergebnis.

Wir folgen Lesart A, weil sie systematisch tragfähiger ist, der herrschenden Kommentarliteratur entspricht und nicht durch geschickte Vertragsgestaltung (etwa eine Subskriptions-„Abgabe") umgangen werden kann. Praktisch entscheidend: Beide Lesarten kommen zum selben Ergebnis — eine reine Browser-SaaS fällt nicht unter den CRA, sondern in die NIS-2-Sphäre.

Der Übergangsmoment, an dem das Produktrecht ansetzt, wird in Art. 3 Nr. 22 CRA definiert: „die entgeltliche oder unentgeltliche Abgabe eines Produkts mit digitalen Elementen zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit" [1, Art. 3 Nr. 22]. Eine Desktop-App wird mit dem Download in Verkehr gebracht; ein Firmware-Image, sobald es zum Flashen bereitgestellt wird; eine Mobile App, sobald sie im App Store erscheint. Eine reine Browser-SaaS hat diesen Übergangsmoment nicht — der Nutzer erhält keine Software-Kopie, sondern nutzt eine laufende Dienstleistung beim Anbieter.

Anschaulich machen lässt sich dieser Übergangsmoment am Werkstorprinzip — einem Konzept der Bereitstellungs-Ebene, das der CRA-Kommentar zur Bestimmung des Inverkehrbringens heranzieht: Ein Produkt ist in Verkehr gebracht, wenn es „das (digitale) Werkstor des Herstellers mit seinem Willen verlässt" [8, § 4 Rn. 18]. Eine heruntergeladene Desktop-App verlässt dieses Werkstor — die Kopie wandert auf das Gerät des Nutzers, der Hersteller verliert die unmittelbare Kontrolle über sie. Eine reine SaaS verlässt es nie: Ihr Code bleibt dauerhaft beim Anbieter, der Nutzer greift von aussen über eine Verbindung hinein. Das Werkstorprinzip setzt damit streng genommen am Bereitstellungserfordernis an und gehört dogmatisch zu Lesart B. Der tiefere Grund, warum eine SaaS das Werkstor nie verlässt, ist allerdings, dass es kein abgrenzbares Produkt-Exemplar gibt, das es überhaupt verlassen könnte — insofern macht das Werkstorprinzip zugleich den Befund von Lesart A anschaulich.

Die EU adressiert solche Dienstleistungen in einem parallelen Regulierungsrahmen:

| Sphäre | Anknüpfung | Beispiele | |---|---|---| | Produktrecht | Inverkehrbringen eines Produkts | CRA, Maschinenverordnung, RED, MDR | | Dienstleistungsrecht | Erbringung der Dienstleistung | NIS-2, eIDAS, DORA |

Reine Cloud-Dienste (IaaS, PaaS, SaaS ohne lokale Komponente) gehören in die zweite Sphäre.

Damit das Schutzkonzept des CRA nicht an der Cloud-Grenze endet, hat der Gesetzgeber in Art. 3 Nr. 2 CRA eine zweite Definition geschaffen: die Datenfernverarbeitungslösung (Remote Data Processing Solution, RDPS) — eine regulatorische Brücke zwischen Produktrecht und Dienstleistungsrecht. Wenn eine in Verkehr gebrachte lokale Komponente eines Produkts ohne eine bestimmte Server-Software auch nur eine ihrer Funktionen nicht mehr ausführen kann, und wenn der Hersteller diese Server-Software selbst entworfen und entwickelt hat, gilt die Server-Software als untrennbarer Bestandteil des CRA-Produkts (Art. 3 Nr. 1 CRA: „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen"). Sie wird damit in dieselben CRA-Pflichten einbezogen wie die lokale Komponente — Anhang I, SBOM, Schwachstellenmanagement, Konformitätsbewertung, Meldepflichten. Isoliert betrachtet wäre dieselbe Server-Software eine Cloud-Dienstleistung im NIS-2-Bereich.

Wichtig dabei ist die juristische Konstruktion: Die Server-Komponente wird nicht zu einem eigenen Produkt, das gesondert in Verkehr gebracht werden müsste. Die Bereitstellung iSd Art. 3 Nr. 22 CRA erfolgt einmal — durch die Auslieferung der lokalen Komponente — und trägt regulatorisch beide Teile (lokal und Server) gemeinsam.

Diese Systematik erklärt auch, warum sich Hersteller dem CRA nicht entziehen können, indem sie die sicherheitsrelevanten Funktionen in die Cloud auslagern: Sobald ein lokales Produkt existiert, das ohne die Cloud-Verarbeitung nicht funktioniert, zieht die RDPS-Konstruktion die Cloud automatisch mit hinein.

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 — die typischerweise über Datenverbindungen mit dem Cloud-Backend interagiert. Solche Datenverbindungen werden technisch über Netzwerksockets, Pipes, APIs oder Datenbankzugriffe realisiert (vgl. Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3) [8]. Reine Einweg-Schnittstellen wie RFID-Tags oder QR-Codes lösen die CRA-Anwendbarkeit als Datenverbindung dagegen nicht aus (vgl. Wiebe/Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 3) [8]. Sobald die 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.

Dahinter steht eine Prüfung in zwei Stufen, die man auseinanderhalten sollte. Die lokale Komponente ist der Anker: Sie allein entscheidet, ob überhaupt ein „Produkt mit digitalen Elementen" vorliegt und damit der CRA dem Grunde nach greift. Ohne lokale Komponente kein Produkt, kein CRA. Die Server-Abhängigkeit entscheidet dagegen über die Reichweite — also darüber, wie weit der CRA in die Cloud hineinreicht. Funktioniert die lokale Komponente auch ohne den Server, bleibt der Server ausserhalb der RDPS-Qualifikation; funktioniert sie ohne ihn nicht, wird die Server-Seite als RDPS in den Pflichtenkreis des Produkts gezogen. Kurz: Die lokale Komponente beantwortet die Frage „ob überhaupt CRA", die Server-Abhängigkeit die Frage „wie weit der CRA in die Cloud reicht".

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 blosse Risikobewertung. Welches dieser drei Ergebnisse für Ihr Produkt relevant ist, hängt von Architektur und Design ab.

Die internationale Wirtschaftskanzlei DLA Piper bezeichnete diese Abgrenzung in einer Mandanteninformation vom Februar 2026 als „fine line" [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 einem Briefing vom März 2026 zu einem ähnlichen Befund [3].

Reine SaaS: Was wirklich aussen vor bleibt

Tatsächlich nicht CRA-pflichtig sind Lösungen, die ausschliesslich ü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 20. Mai 2026 nicht abschliessend geklärt — aber die EU-Kommission hat mit einem neuen Orientierungsrahmen einen wichtigen Massstab 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" [2]. Sie verläuft oft mitten durch das Produktportfolio eines einzelnen Unternehmens.

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 Software Development Kit (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 Bundesamt für Sicherheit in der Informationstechnik – die deutsche Cybersicherheitsbehörde mit Sitz in Bonn (BSI) – bietet mit der Technischen Richtlinie TR-03183 eine Einstiegshilfe, die den CRA-Anwendungsbereich und die Anforderungen systematisch aufbereitet [6].

Der zweite: Verstehen Sie den Zeitplan. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten bereits ab dem 11. September 2026 — also in knapp vier Monaten (Stand 20. Mai 2026) [1, Art. 14 i. V. m. Art. 71 Abs. 2 UAbs. 2]. 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 — gelten ab dem 11. Dezember 2027, also etwa in 19 Monaten (Stand 20. Mai 2026). 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 grosse Mehrheit der KMU, aber auch für grössere Unternehmen, nicht zugleich rechtskonform und wirtschaftlich umsetzbar" sei [7].

Methodik und Quellenlage

Dieser Artikel stützt sich primär auf die Verordnung (EU) 2024/2847 [1] sowie den Draft-Communication-Entwurf der EU-Kommission Ares(2026)2319816 vom 3. März 2026 [5]. Bis zum 31. März 2026 hatte die EU-Kommission Feedback zu diesem Entwurf eingeholt; die Konsultation ist abgeschlossen, eine finale Version war zum Stand 20. Mai 2026 noch nicht veröffentlicht. Als ergänzende Quellen dienen Fachpublikationen von DLA Piper [2] und Linklaters [3], die Technische Richtlinie BSI TR-03183 [6], das Bitkom-Positionspapier [7] sowie der CRA-Kommentar von Wiebe (Nomos 2025) [8].

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

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Veröffentlicht am: 28.03.2026. Zuletzt geprüft am: 03.07.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

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", Mandanteninformation Februar 2026. 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", Client Briefing März 2026. 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 Massnahmen 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 abgelaufen am 31. März 2026; finale Version zum Stand 20. Mai 2026 noch nicht veröffentlicht. 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: General Requirements, Teil 2: Software Bill of Materials (SBOM), Teil 3: Vulnerability Reports and Notifications. 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", Positionspapier 2026. 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.

[8] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025. Juristischer Kommentar zu Auslegungsfragen des CRA, insbesondere zum Produktbegriff und zur Datenfernverarbeitungslösung (§ 4 Rn. 3–5).

[9] Europäische Kommission, „The 'Blue Guide' on the implementation of EU product rules 2022", Mitteilung der Kommission, ABl. C 247, 29.6.2022. Allgemeine Anleitung der EU-Kommission zur Auslegung des EU-Produktrechts (New Legislative Framework), insbesondere Abschnitt 2 zum Produktbegriff. Verfügbar unter: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:52022XC0629%2804%29