Cyber Resilience Act: Was Software- und SaaS-Anbieter jetzt umsetzen müssen

IT-Recht · Serie Digitalrecht, Teil 2 | Teil 1: Produkthaftung für Software | Teil 3: NIS-2 ·Stand: Oktober 2026

Freitag, 22 Uhr: Ein Sicherheitsforscher meldet Ihnen, dass Angreifer eine Lücke im Update-Agenten Ihrer Software aktiv ausnutzen. Denn seit dem 11. September 2026 beginnt mit dieser Nachricht eine Frist. Nach dem Cyber Resilience Act (CRA) muss bis Samstagabend eine Frühwarnung bei der europäischen Meldeplattform eingegangen sein. Wer den Prozess also erst jetzt sucht, verliert genau die Stunden, die er nicht hat.

Der CRA macht Cybersicherheit zur Produkteigenschaft, so verbindlich wie die elektrische Sicherheit eines Toasters. Zudem legt er fest, welche Sicherheit Ihr Produkt mitbringen muss. In diesem Beitrag erfahren Sie, welche Software erfasst ist und wann SaaS darunter fällt. Außerdem zeigen wir, welche Pflichten schon heute gelten und mit welchen sieben Schritten Sie bis Dezember 2027 compliant werden.

Das Wichtigste in Kürze

• Software ist erfasst, sobald sie beim Nutzer läuft: Desktop-Programme, Apps, Plug-ins, SDKs, Firmware und Betriebssysteme gehören dazu. Eigene Hardware ist dafür also nicht nötig.
• Die Meldepflicht läuft bereits: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden. Das gilt zudem auch für Produkte, die schon vor dem Stichtag auf dem Markt waren.
• SaaS ist ein Grenzfall: Das gehostete Backend bleibt meist außen vor. Cloud-Funktionen, ohne die ein Gerät nicht funktioniert, zählen dagegen zum Produkt.
• Mindestens fünf Jahre Sicherheitsupdates sind die Regel, bei längerer erwarteter Nutzung entsprechend mehr.
• Bußgelder bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes drohen bei Verstößen gegen die Kernpflichten. Zivilrechtlich wirkt der CRA über die neue Produkthaftung.

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act ist eine EU-Verordnung. Er gilt in allen Mitgliedstaaten unmittelbar, ein deutsches Umsetzungsgesetz braucht es daher nicht. Sein Ansatz ist neu für die IT-Branche, aber aus dem Produktrecht vertraut. Bevor ein Produkt auf den Markt kommt, bewertet der Hersteller die Risiken und setzt die Anforderungen um. Anschließend dokumentiert er alles und bestätigt die Konformität mit der CE-Kennzeichnung.

Der entscheidende Unterschied zu klassischen Produkten: Die Pflichten enden nicht mit dem Verkauf. Stattdessen begleitet der CRA Ihr Produkt über den gesamten Lebenszyklus, vom Design über Updates bis zum Ende des Unterstützungszeitraums.

Der Zeitplan des Cyber Resilience Act im Überblick

Der Leitfaden der Kommission ist rechtlich nicht bindend. Verbindlich auslegen kann den CRA nämlich nur der EuGH. Marktüberwachungsbehörden und Prüfstellen werden sich aber daran orientieren. Wer davon abweicht, muss seine Lösung deshalb gut begründen können.

CRA, NIS-2 und Produkthaftung: Wer regelt was?

Viele Unternehmen werfen die neuen Regelwerke in einen Topf. Sie greifen aber an unterschiedlichen Stellen an und können nebeneinander gelten:

Im ersten Teil unserer Serie haben wir gezeigt, warum Software künftig haftet wie eine Maschine. Der CRA liefert dazu den Maßstab. Die Verbindung zur Produkthaftung ist deshalb besonders eng: Cybersicherheitsanforderungen fließen in die Frage ein, ob ein Produkt fehlerhaft ist. Erfüllt Ihr Produkt verbindliche Sicherheitsanforderungen nicht, kann ein Gericht den Produktfehler sogar vermuten. Ihre CRA-Dokumentation ist damit zugleich Ihr wichtigstes Beweismittel im Haftungsfall.

Welche Produkte fallen unter den Cyber Resilience Act?

Der CRA spricht von Produkten mit digitalen Elementen (Art. 3 Nr. 1 CRA). Gemeint ist damit Software oder Hardware mit einer direkten oder indirekten Datenverbindung zu einem Gerät oder Netz. Maßgeblich ist außerdem die bestimmungsgemäße oder vorhersehbare Verwendung. Dabei genügt schon eine logische Verbindung, etwa die eines lokalen Programms zum Betriebssystem. Auf die Branche kommt es nicht an, sondern allein auf das Produkt. Typischerweise erfasst sind:

• Vernetzte Hardware wie Router, Kameras, Smart-Home-Geräte, Wallboxen oder Industriesteuerungen
• Lokal ausgeführte Software wie Desktop-Anwendungen, mobile Apps, Browser-Erweiterungen und Betriebssysteme
• Komponenten, die eigenständig vermarktet werden, etwa Firmware, Bibliotheken oder Softwaremodule
• Datenfernverarbeitung, also Cloud-Funktionen, die ein Hersteller für sein Produkt entwickelt und ohne die es eine Funktion nicht erfüllen kann

Nicht erfasst sind dagegen Produkte ohne jede Verbindungsmöglichkeit, etwa die Firmware einer Spülmaschine ohne Netzanbindung.

Ausnahmen: Spezialrecht geht vor

Wo es bereits gleichwertige EU-Regeln gibt, tritt der CRA zurück. Das betrifft vor allem Medizinprodukte und In-vitro-Diagnostika (MDR und IVDR) sowie typgenehmigte Kraftfahrzeuge. Ebenso ausgenommen sind zertifizierte Luftfahrtprodukte, Schiffsausrüstung sowie Produkte für die nationale Sicherheit und Verteidigung. Auch identische Ersatzteile fallen nicht darunter (Art. 2 Abs. 6 CRA). Prüfen Sie jede Ausnahme produktbezogen, denn eine pauschale Branchenausnahme gibt es nicht.

Open Source: privilegiert, aber nicht pauschal frei

Freie und quelloffene Software, die Sie ohne kommerzielle Tätigkeit bereitstellen, fällt nicht unter die Herstellerpflichten. Kommerziell wird es, sobald Sie für die Software einen Preis verlangen. Dasselbe gilt, wenn Sie sie über Werbung oder Abonnements monetarisieren. Ein Spendenlink allein reicht dafür nach dem Leitfaden jedoch nicht. Manche Stiftungen und andere juristische Personen tragen Open-Source-Projekte dauerhaft. Für sie schafft der CRA die Rolle des Verwalters quelloffener Software mit deutlich leichteren Pflichten (Art. 24 CRA).

Für die meisten Unternehmen ist allerdings die andere Richtung wichtiger. Wer Open-Source-Bibliotheken in sein Produkt einbaut, bleibt Hersteller des Gesamtprodukts. Sie müssen die Komponenten mit Sorgfalt auswählen (Art. 13 Abs. 5 CRA). Außerdem melden Sie gefundene Schwachstellen an das Projekt (Art. 13 Abs. 6 CRA). Das entspricht der Logik, die wir in Teil 1 für die Produkthaftung beschrieben haben.

Fällt SaaS unter den Cyber Resilience Act?

Das ist die Frage, die Software-Unternehmen am häufigsten stellen. Die Antwort hängt nicht am Geschäftsmodell. Entscheidend ist, wo die Software läuft und welche Funktion sie für ein anderes Produkt übernimmt. Manche Software läuft ausschließlich auf Ihrer Infrastruktur und Ihre Kunden nutzen sie nur im Browser. Für sich genommen ist sie deshalb kein Produkt im Sinne des CRA. Für vergleichbare Dienste ist eher NIS-2 zuständig. Alles, was Sie an Kunden ausliefern, ist dagegen erfasst.

Damit kann ein und dasselbe Angebot teils drin und teils draußen sein. Die folgende Übersicht hilft bei der ersten Einordnung:

Datenfernverarbeitung: die drei Prüffragen

Den schwierigsten Fall übersehen allerdings viele: Cloud-Dienste, die eine Funktion eines vernetzten Produkts tragen. Eine Datenfernverarbeitung liegt vor, wenn alle drei Voraussetzungen erfüllt sind:

• Ferne: Die Verarbeitung der Daten findet außerhalb des Produkts statt, etwa in der Cloud.
• Notwendigkeit: Ohne die Verarbeitung könnte das Produkt mindestens eine seiner Funktionen nicht erfüllen.
• Verantwortung: Die Software stammt vom Hersteller selbst oder entstand unter seiner Verantwortung.

Nach dem Leitfaden zählen nur die Module, mit denen das Produkt unmittelbar interagiert, samt ihrer Schnittstellen. Nachgelagerte Back-Office-Systeme gehören folglich nicht dazu.

Praxisbeispiel: Ein Hersteller von Wallboxen lässt das Lastmanagement in seiner eigenen Cloud berechnen. Ohne diese Berechnung lädt die Wallbox jedoch nur mit Mindestleistung. Die Cloud ist also Datenfernverarbeitung, und der Hersteller bewertet sie zusammen mit der Wallbox. Den externen Dienst, über den derselbe Hersteller Rechnungen verschickt, erfasst der CRA dagegen nicht.

Was SaaS-Anbieter trotzdem vorbereiten sollten

Auch wenn Ihr Dienst selbst nicht unter den CRA fällt, kann er Teil der Lieferkette eines regulierten Produkts sein. Ihre Kunden müssen ihre Zulieferer sorgfältig prüfen und verlangen deshalb Nachweise. Halten Sie deshalb bereit:

• eine aktuelle Liste eingesetzter Drittkomponenten und Unterauftragnehmer
• einen dokumentierten Prozess für Schwachstellen, von der Meldung bis zur Kundeninformation
• verbindliche Angaben zu Sicherheitsupdates und deren Rhythmus
• Notfall- und Wiederanlaufpläne für funktionskritische Dienste
• eine Verantwortungsmatrix, die festlegt, wer Schwachstellen koordiniert, Updates freigibt und Kunden informiert

Welche Pflichten haben Hersteller nach dem Cyber Resilience Act?

Die Hauptlast trägt der Hersteller. Das ist, wer ein Produkt entwickelt oder entwickeln lässt und es unter eigenem Namen vermarktet. Auch Händler und Einführer werden zum Hersteller, wenn sie ein Produkt unter eigener Marke vertreiben oder wesentlich verändern. Das betrifft insbesondere White-Label-Modelle. Ab dem 11.12.2027 gelten insbesondere diese Pflichten:

• Risikobewertung (Art. 13 Abs. 2 CRA): Sie ist zunächst das Fundament. Aus ihr folgt nämlich, welche Anforderungen für Ihr Produkt relevant sind. Der CRA ist risikobasiert und verlangt keine absolute Fehlerfreiheit.
• Security by Design und by Default (Anhang I Teil I): sichere Standardeinstellungen, Schutz vor unbefugtem Zugriff, Datenminimierung sowie Schutz von Integrität und Vertraulichkeit.
• Schwachstellenmanagement (Anhang I Teil II): eine Software-Stückliste (SBOM), Behebung ohne Verzögerung und kostenlose Sicherheitsupdates, möglichst getrennt von Funktionsupdates. Dazu kommen eine Richtlinie zur koordinierten Offenlegung und eine Kontaktstelle für Meldungen.
• Unterstützungszeitraum (Art. 13 Abs. 8 CRA): Er richtet sich nach der erwarteten Nutzungsdauer und beträgt in der Regel mindestens fünf Jahre. Käufer müssen ihn beim Kauf erkennen können. Bei Software mit vielen Releases braucht jede Version einen eigenen Zeitraum.
• Dokumentation und Konformität: technische Dokumentation, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung.

Wichtige und kritische Produkte: Wann eine Prüfstelle nötig wird

Wie Sie die Konformität nachweisen, hängt von der Kernfunktionalität Ihres Produkts ab. Die Anhänge III und IV des CRA führen die Kategorien auf. Technisch beschreibt sie die Durchführungsverordnung (EU) 2025/2392:

• Standardprodukte: Sie bewerten die Konformität selbst. Das betrifft die große Mehrheit der Software.
• Wichtige Produkte der Klasse I, etwa Passwortmanager, VPN-Software oder Betriebssysteme: Selbstbewertung nur, wenn Sie eine harmonisierte Norm oder ein vergleichbares Regelwerk vollständig anwenden.
• Wichtige Produkte der Klasse II, etwa Firewalls oder Hypervisoren, sowie kritische Produkte: Sie müssen eine externe Stelle einbinden.

Eine zusätzliche Funktion ändert die Einstufung nicht, solange sie die Kernfunktion nur ergänzt. Vorsicht allerdings bei modularen Plattformen: Module, die Kunden separat kaufen oder abonnieren, sind eigene Produkte mit eigener Einstufung. Planen Sie für Klasse II früh, denn die Kapazitäten der Prüfstellen sind knapp.

Updates: Wann wird aus Ihrer Software ein neues Produkt?

Eine wesentliche Änderung (Art. 3 Nr. 30 CRA) macht Ihr Produkt rechtlich zu einem neuen Produkt mit neuer Bewertung. Maßstab ist dabei das Risiko, nicht der Umfang der Änderung. Ein Sicherheitsupdate ist in aller Regel keine wesentliche Änderung, auch wenn es tief in den Code eingreift. Eine kleine neue Funktion kann es dagegen sein, wenn sie neue Angriffsflächen öffnet. Das gilt zum Beispiel für einen Fernzugriff für den Support.

Prüfen Sie bei jedem größeren Release vier Fragen: Entstehen neue Angriffswege? Werden neue Angriffsszenarien möglich? Steigt die Wahrscheinlichkeit bekannter Szenarien? Ändern sich deren Auswirkungen? Lautet die Antwort viermal Nein, liegt meist keine wesentliche Änderung vor.

Praxistipp: Nehmen Sie geplante Roadmap-Funktionen schon heute in die Risikobewertung auf. Denn bereits bewertete Funktionen dürfen Sie später freischalten, ohne eine wesentliche Änderung auszulösen.

Meldepflichten seit 11.09.2026: So läuft eine Meldung ab

Die Meldepflichten nach Art. 14 CRA sind der erste Teil des CRA, der bereits gilt. Sie betreffen zwei Ereignisse: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die die Sicherheit Ihres Produkts beeinträchtigen. Sie melden einmal über die Single Reporting Platform der ENISA. Von dort geht die Meldung an das zuständige nationale CSIRT am Ort Ihrer Hauptniederlassung und an die ENISA. In Deutschland ist das CSIRT beim BSI angesiedelt.

In der Praxis übersehen Unternehmen jedoch oft drei Punkte:

• Auch Altprodukte sind erfasst. Die Meldepflicht gilt unabhängig davon, wann das Produkt auf den Markt kam. Nach dem Leitfaden gilt sie sogar nach Ablauf des Unterstützungszeitraums.
• Drittkomponenten zählen, wenn Angreifer sie in Ihrem Produkt ausnutzen. Eine Lücke in einer eingebauten Bibliothek wird meldepflichtig, sobald Angreifer sie in Ihrem Produkt aktiv ausnutzen.
• Sie müssen die Nutzer informieren, und zwar risikobasiert und verhältnismäßig. Technische Details, die Angreifern helfen würden, müssen Sie allerdings nicht veröffentlichen.

Praxisbeispiel: Ein Anbieter von Buchhaltungssoftware erfährt am Freitag um 18 Uhr, dass Angreifer seinen Desktop-Client aktiv attackieren. Die Frühwarnung muss folglich bis Samstag 18 Uhr eingegangen sein. Fließen dabei personenbezogene Daten ab, läuft parallel die 72-Stunden-Frist der DSGVO. Diese verlangt eine eigene Meldung an die Datenschutzaufsicht. Steuern Sie beide Prozesse deshalb aus einem gemeinsamen Ablaufplan heraus.

Was droht bei Verstößen gegen den Cyber Resilience Act?

Der Sanktionsrahmen folgt dem Muster der jüngeren EU-Digitalgesetze (Art. 64 CRA):

• bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Sicherheitsanforderungen und die zentralen Herstellerpflichten einschließlich der Meldepflichten
• bis 10 Mio. Euro oder 2 % bei Verstößen gegen sonstige Pflichten
• bis 5 Mio. Euro oder 1 % bei falschen oder unvollständigen Angaben gegenüber Behörden

Zusätzlich drohen Maßnahmen der Marktüberwachung bis hin zu Vertriebsverbot und Rückruf. Der wirtschaftlich größte Hebel dürfte aber die Produkthaftung sein. Wer die CRA-Anforderungen nicht erfüllt, liefert Geschädigten das Argument für einen Produktfehler gleich mit.

Handlungsempfehlungen: 7 Schritte zur CRA-Compliance

1. Produkte und Rollen erfassen: Listen Sie zunächst alle Produkte mit digitalen Elementen auf. Bestimmen Sie dann je Produkt, ob Sie Hersteller, Einführer oder Händler sind. Achten Sie dabei besonders auf White-Label- und Eigenmarkenprodukte.
2. Komponenten abgrenzen: Trennen Sie bei SaaS-Angeboten zunächst das Backend von allem, was Sie ausliefern. Prüfen Sie anschließend für Cloud-Funktionen die drei Kriterien der Datenfernverarbeitung.
3. Meldeprozess sofort aufsetzen: EU-Login-Konto anlegen, auf der ENISA-Plattform registrieren, zuständiges CSIRT bestimmen, Rufbereitschaft und Vorlagen festlegen. Denn diese Pflicht gilt bereits.
4. SBOM und Lieferkette aufbauen: Erfassen Sie alle Drittanbieter- und Open-Source-Komponenten mit Versionen. Überwachen Sie diese anschließend laufend auf Schwachstellen.
5. Unterstützungszeitraum festlegen: Bestimmen Sie den Zeitraum je Version und kalkulieren Sie die Kosten. Nehmen Sie ihn außerdem in Angebote und Verträge auf.
6. Klasse und Konformitätsweg klären: Ordnen Sie zunächst jedes Produkt einer Kategorie zu. Bei Klasse II oder kritischen Produkten sprechen Sie frühzeitig mit einer Prüfstelle.
7. Verträge und Haftung verzahnen: Regeln Sie mit Zulieferern vertraglich SBOM-Lieferung, Schwachstelleninformation, Update-Pflichten und Regress. Gleichen Sie die Maßnahmen schließlich mit Ihrer Vorbereitung auf das neue Produkthaftungsrecht ab.

Fazit: Der Cyber Resilience Act macht Sicherheit zur Produkteigenschaft

Der CRA beendet die Zeit, in der Cybersicherheit eine freiwillige Qualitätsfrage war. Drei Punkte sollten Sie mitnehmen:

• Software ist Produkt. Wer Software ausliefert, ist folglich Hersteller, auch ohne ein einziges Gerät im Portfolio.
• SaaS entbindet nicht automatisch. Entscheidend ist, was beim Kunden läuft und welche Funktion Ihr Dienst für ein anderes Produkt übernimmt.
• Die Uhr läuft schon. Die Meldepflichten gelten seit September 2026, die volle Geltung folgt im Dezember 2027.

Wer CRA und Produkthaftung zusammen denkt, erledigt viele Aufgaben nur einmal. Dieselbe Dokumentation, die die Konformität belegt, verteidigt Sie nämlich auch vor Gericht.

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung im Einzelfall. Stand: Oktober 2026. Maßgeblich ist der im Amtsblatt veröffentlichte Wortlaut der Verordnung (EU) 2024/2847. Der Leitfaden der Kommission ist nicht verbindlich.

Sie möchten wissen, welche Ihrer Produkte unter den CRA fallen? Vereinbaren Sie ein unverbindliches Erstgespräch. Wir ordnen Ihr Portfolio ein und prüfen Ihren Meldeprozess sowie Ihre Lieferverträge.

Jetzt Erstgespräch anfragen

FAQ: Häufig gestellte Fragen zum Cyber Resilience Act