Cyber Resilience Act: Ist Ihre SaaS betroffen?

Der Cyber Resilience Act (CRA) gilt in der Softwarebranche oft als reines Hardware-Thema, das vernetzte Geräte betrifft, aber nicht die eigene Anwendung. Diese Einschätzung ist riskant. Ab dem 11. September 2026 greift die erste verbindliche Pflichtenstufe, und ihr Anwendungsbereich reicht weiter in die Software- und SaaS-Welt, als viele Anbieter erwarten.

Für Geschäftsführung, Produktverantwortliche und Entwicklungsteams steht vor Ablauf der Frist eine Frage im Vordergrund: Fällt das eigene Produkt unter den CRA, und welche Pflichten sind bis wann umzusetzen?

Worum es beim CRA geht

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Sie ist am 10. Dezember 2024 in Kraft getreten und gilt unmittelbar in allen Mitgliedstaaten. Ein deutsches Umsetzungsgesetz ist für die Wirksamkeit der Pflichten nicht erforderlich; ein nationales Durchführungsgesetz regelt vor allem Zuständigkeiten und Sanktionsvollzug.

Das Regelungsziel lässt sich knapp fassen: Produkte mit digitalen Elementen sollen über ihren gesamten Lebenszyklus sicher sein. Sicher konzipiert, sicher ausgeliefert, mit Updates versorgt und mit einem belastbaren Prozess für Schwachstellen. Damit wird ein Großteil dessen, was bislang als freiwillige Security-by-Design-Praxis galt, zu verbindlichem Produktrecht mit CE-Kennzeichnung und Marktaufsicht.

Anwendungsbereich: welche Produkte der CRA erfasst

Über den Anwendungsbereich entscheiden sich die meisten Fehleinschätzungen. Der CRA erfasst Produkte mit digitalen Elementen, also Software oder Hardware, deren bestimmungsgemäße Nutzung eine Datenverbindung zu einem Gerät oder Netz umfasst. Ausdrücklich erfasst ist auch eigenständige Software, nicht nur eingebettete Firmware.

Für die Digitalwirtschaft ist die Abgrenzung bei SaaS entscheidend:

Konstellation	CRA-relevant?
On-Premise- oder Desktop-Software, die ausgeliefert wird	Ja — Produkt mit digitalen Elementen
Mobile App im App-Store-Vertrieb	In der Regel ja
Reines SaaS als eigenständige Dienstleistung	Grundsätzlich nein — eher NIS-2 / BSIG
SaaS als Fernverarbeitungslösung für ein CRA-Produkt	Ja — die Backend-Komponente wird miterfasst

Reines Software-as-a-Service, bei dem die Anwendung vollständig in der Anbieter-Cloud läuft und der Kunde keinen Code erhält, fällt im Grundsatz nicht unter den CRA, sondern in die Logik der NIS-2-Regulierung. Übernimmt das Cloud-Backend dagegen die Fernverarbeitung für ein Produkt, das ohne diese Verarbeitung eine seiner Funktionen nicht erfüllen kann, etwa die Companion-Cloud einer App oder eines vernetzten Geräts, wird diese Komponente vom CRA erfasst.

Was heißt „Fernverarbeitungslösung“ konkret? +

Der CRA erfasst remote data processing solutions, also Datenverarbeitung aus der Ferne, die für ein Produkt mit digitalen Elementen so notwendig ist, dass das Produkt ohne sie eine seiner Funktionen nicht ausführen kann. Beispiel: Zu einer Smart-Home-App gehört ein Gerät; die App kommuniziert mit einem Cloud-Backend, ohne das die Steuerung nicht funktioniert. Dann gehören App und Backend zum regulierten Produkt, obwohl das Backend nur ein Server beim Anbieter ist. Ein davon unabhängiges CRM, das rein als Web-SaaS angeboten wird, ist nicht gemeint.

Produktklassen und Konformitätsbewertung

Der CRA staffelt die Anforderungen nach Risiko. Für die meisten Produkte gilt die Standardkategorie mit Selbstbewertung der Konformität. Für sicherheitskritischere Produkte gelten strengere Verfahren; hier wird die Einstufung in die Kategorien „wichtig” (mit zwei Klassen) und „kritisch” relevant, die über die Anhänge der Verordnung definiert werden.

Pflichten des Herstellers

Hersteller im Sinne des CRA ist, wer ein Produkt unter eigenem Namen oder eigener Marke entwickelt und in Verkehr bringt. Die Kernpflichten:

• Security by Design und Default: Das Produkt muss die grundlegenden Cybersicherheitsanforderungen erfüllen (Anhang I der Verordnung), von sicheren Standardeinstellungen über die Minimierung der Angriffsfläche bis zur Absicherung von Daten.
• Schwachstellenmanagement über den Support-Zeitraum: Schwachstellen sind zu identifizieren, zu dokumentieren und ohne unangemessene Verzögerung durch Sicherheitsupdates zu beheben. Der Support-Zeitraum muss der erwarteten Nutzungsdauer entsprechen, mindestens jedoch fünf Jahre, sofern das Produkt nicht nachweislich kürzer genutzt wird.
• Software Bill of Materials (SBOM): Die Komponenten des Produkts sind zu kennen und zu dokumentieren. Ohne Inventar der Abhängigkeiten ist Schwachstellenmanagement nicht leistbar.
• Technische Dokumentation, Konformitätsbewertung, CE-Kennzeichnung: Der CRA gehört zum „New Legislative Framework”; am Ende steht die CE-Kennzeichnung als sichtbares Konformitätssignal.
• Meldepflichten bei aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen (dazu sogleich).

Meldepflichten ab 11. September 2026

Der CRA gilt gestuft. Die Meldepflichten nach Artikel 14 greifen bereits ab dem 11. September 2026 und damit vor der vollständigen Geltung der übrigen Vorgaben.

Ab diesem Datum sind aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle an die zuständige Stelle zu melden, koordiniert über die EU-Agentur ENISA. Die Taktung ist eng:

Stufe	Frist	Inhalt
Frühwarnung	24 Stunden	erste Kenntnisnahme, Basisinformationen
Meldung	72 Stunden	Details zur Schwachstelle / zum Vorfall
Abschlussbericht	14 Tage	Ursachenanalyse, ergriffene Maßnahmen

Bußgeldrahmen

Der CRA sieht einen gestaffelten Bußgeldrahmen vor (Artikel 64). Die Höchstbeträge liegen, wie bei DSGVO und DSA, bewusst hoch:

Stufe	Bußgeldrahmen	Wofür
Schwerste Verstöße	bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes	grundlegende Sicherheitsanforderungen (Anhang I), Herstellerpflichten (Art. 13), Meldepflichten (Art. 14)
Weitere Pflichtverstöße	bis 10 Mio. € oder 2 % des Umsatzes	u. a. Importeur- und Händlerpflichten, Konformitätsbewertung, CE-Kennzeichnung
Falschangaben	bis 5 Mio. € oder 1 % des Umsatzes	falsche, unvollständige oder irreführende Angaben gegenüber Behörden oder benannten Stellen

Maßgeblich ist jeweils der höhere der beiden Werte. Bei nennenswertem Umsatz ist die prozentuale Grenze die eigentliche Sanktionsdrohung, nicht der absolute Betrag.

Die schwersten Verstöße betreffen die grundlegenden Sicherheitsanforderungen und die Meldepflichten; sie sind mit dem höchsten Bußgeldrahmen bewehrt.

Open Source im CRA

In Entwicklungsteams sorgt eine Frage für Unsicherheit: Führt Open-Source-Engagement zur Herstellereigenschaft nach dem CRA? Die Verordnung differenziert. Freie und quelloffene Software, die außerhalb einer geschäftlichen Tätigkeit entwickelt und bereitgestellt wird, ist vom vollen Pflichtenkatalog ausgenommen. Für Open-Source-Software-Steward, also Organisationen, die die Entwicklung kommerziell genutzter Open-Source-Komponenten dauerhaft und strukturiert unterstützen, gilt ein eigenes, milderes Regime.

Die Schwierigkeit liegt in der Abgrenzung zwischen geschäftlicher und nicht geschäftlicher Tätigkeit. Wer Open Source als Kern eines kommerziellen Angebots bereitstellt oder Support vergütet bekommt, sollte diese Einordnung nicht offenlassen.

Verbreitete Fehleinschätzungen

• „Der CRA ist Hardware-Recht.” Eigenständige Software und Apps sind ausdrücklich erfasst.
• „Bis Ende 2027 ist Zeit.” Das gilt nur für die Hauptpflichten. Die Meldepflichten greifen bereits ab dem 11. September 2026.
• „Wir sind zu klein.” Der CRA sieht Erleichterungen für Kleinstunternehmen bei einzelnen Dokumentationspflichten vor, aber keine generelle Ausnahme von den Sicherheitsanforderungen. Wer ein Produkt in Verkehr bringt, ist im Anwendungsbereich.
• „SBOM kommt später.” Ohne Komponenten-Inventar funktionieren weder Meldepflicht noch Schwachstellenmanagement.
• „Die Haftung ist vertraglich ausgeschlossen.” Der CRA ist öffentlich-rechtliches Produktrecht mit Bußgeldern und Marktaufsicht. Ein AGB-Haftungsausschluss gegenüber Kunden berührt die behördlichen Pflichten nicht.

Handlungsplan bis September 2026

Vorrang haben die Punkte 1 und 2, weil die Meldepflicht zuerst greift und die Betroffenheitsanalyse alle weiteren Schritte steuert. Für die vertragliche Umsetzung, besonders in Zulieferketten und SaaS-Verträgen, lohnt der frühe Blick in die IT- und Softwarerecht-Praxis, bevor Formulierungen im Standardvertrag festgeschrieben werden.

// FAQ

Häufige Fragen zum Cyber Resilience Act

Fällt reines SaaS unter den Cyber Resilience Act? +

Reines Software-as-a-Service als eigenständige Dienstleistung fällt im Grundsatz nicht unter den CRA, sondern eher in die NIS-2-Logik. Erfasst wird SaaS dann, wenn es als Fernverarbeitungslösung für ein CRA-Produkt dient, also wenn das Backend für die Funktion eines ausgelieferten Produkts (App, Gerät) notwendig ist. In gemischten Architekturen ist eine pauschale Entwarnung riskant.

Ab wann gilt der Cyber Resilience Act? +

Der CRA (Verordnung (EU) 2024/2847) ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten nach Art. 14 gelten ab dem 11. September 2026, die Hauptpflichten (Sicherheitsanforderungen, Konformitätsbewertung, CE-Kennzeichnung) ab dem 11. Dezember 2027.

Wie hoch sind die Bußgelder beim CRA? +

Der CRA staffelt die Bußgelder: bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes für die schwersten Verstöße, bis 10 Mio. € oder 2 % für weitere Pflichtverstöße und bis 5 Mio. € oder 1 % für Falschangaben gegenüber Behörden. Maßgeblich ist jeweils der höhere Wert.

Was ist eine SBOM und ist sie für den CRA erforderlich? +

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Software-Komponenten und Abhängigkeiten eines Produkts. Sie bildet die Grundlage für Schwachstellenmanagement und Meldepflicht; ohne SBOM lassen sich diese CRA-Kernpflichten nicht sauber erfüllen.

Führt die Nutzung von Open Source zur Herstellereigenschaft? +

Nicht automatisch. Freie und quelloffene Software, die außerhalb geschäftlicher Tätigkeit entwickelt wird, ist vom vollen Pflichtenkatalog ausgenommen; für Open-Source-Software-Steward gilt ein milderes Regime. Für das kommerzielle Gesamtprodukt bleibt die Verantwortung jedoch bestehen, einschließlich der eingesetzten Open-Source-Komponenten.

Fazit

Der Cyber Resilience Act ist kein reines 2027-Thema. Die erste verbindliche Frist, die Meldepflichten, läuft ab dem 11. September 2026, und der Anwendungsbereich reicht tiefer in die Software- und SaaS-Welt, als häufig angenommen. Wer die Betroffenheit früh klärt und einen Meldeprozess einrichtet, hat den kritischen Teil der Vorbereitung erledigt, bevor die Marktaufsicht aktiv wird.

Konkret gehören Betroffenheitsanalyse und 24-Stunden-Meldeprozess auf die Agenda der laufenden Produktplanung, nicht auf die für 2027.

---

Stand: 28. Juli 2026 · Dieser Beitrag ist eine allgemeine Information und ersetzt keine Rechtsberatung im Einzelfall. Für eine auf das jeweilige Unternehmen zugeschnittene Einschätzung steht die JUN Legal GmbH zur Verfügung.