Cyber Resilience Act für Softwarehersteller und SaaS-Anbieter: Pflichten, Fristen, Sanktionen

Mit dem Cyber Resilience Act hat die EU erstmals horizontale Cybersicherheitsanforderungen für „Produkte mit digitalen Elementen“ geschaffen. Für viele Softwarehäuser ist das ein Paradigmenwechsel: Sicherheit ist nicht mehr nur eine Frage der Qualität und der Vertragsgestaltung, sondern eine gesetzliche Voraussetzung dafür, ein Produkt in der EU überhaupt anbieten zu dürfen. Dieser Beitrag gibt einen Überblick über die Pflichten, die ab Dezember 2027 gelten, und zeigt, wo SaaS-Anbieter genauer hinsehen sollten. Zu den bereits geltenden Meldepflichten lesen Sie unseren Beitrag Cyber Resilience Act: Meldepflicht seit dem 11. September 2026.

Was regelt der Cyber Resilience Act?

Der CRA regelt die Bereitstellung von Produkten mit digitalen Elementen auf dem Unionsmarkt, die grundlegenden Cybersicherheitsanforderungen an ihre Konzeption, Entwicklung und Herstellung, den Umgang mit Schwachstellen sowie Marktüberwachung und Durchsetzung. Er folgt dem Muster des europäischen Produktsicherheitsrechts: Wer ein Produkt in Verkehr bringt, muss die Anforderungen nachweisen, eine Konformitätserklärung ausstellen und das Produkt mit dem CE-Zeichen versehen.

Erfasst sind nicht nur vernetzte Geräte, sondern auch Software, sofern ihr Zweck oder ihre vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz einschließt. Dazu gehören etwa Betriebssysteme, Anwendungssoftware, Apps, Browser, Passwort-Manager, Router, Firewalls oder Systeme zur Angriffserkennung. Für einige Bereiche gelten vorrangige Sonderregelungen, etwa für bestimmte Medizinprodukte, Kraftfahrzeuge und Produkte für militärische Zwecke.

Die Fristen

• 10. Dezember 2024: Inkrafttreten der Verordnung (zwanzig Tage nach Veröffentlichung im Amtsblatt am 20. November 2024).
• 11. Juni 2026: Anwendung der Vorschriften über die Notifizierung von Konformitätsbewertungsstellen (Kapitel IV).
• 11. September 2026: Anwendung der Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle (Art. 14 CRA), auch für bereits auf dem Markt befindliche Produkte.
• 11. Dezember 2027: Anwendung aller übrigen Pflichten (Art. 71 Abs. 2 CRA).

Die Übergangsfrist bis Ende 2027 ist keine Schonfrist. Schwachstellenmanagement, Produktklassifizierung, SBOM und technische Dokumentation lassen sich nicht in wenigen Wochen aufbauen, und Produkte, die nach dem Stichtag in Verkehr gebracht werden, müssen die Anforderungen von Anfang an erfüllen.

Pflichten für Softwarehersteller

Hersteller im Sinne des CRA ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet. Für Softwarehäuser sind die Pflichten aus Art. 13 CRA und Anhang I deshalb der Kern. Stand-alone-Software ohne jede Verbindungsmöglichkeit dürfte zwar außerhalb des Anwendungsbereichs liegen; angesichts üblicher Update-, Lizenz- und Supportmechanismen ist das in der Praxis aber die Ausnahme.

1. Security by Design und Risikobewertung

Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass sie ein den Risiken angemessenes Cybersicherheitsniveau aufweisen. Anhang I Teil I nennt unter anderem eine sichere Standardkonfiguration, Schutz vor unbefugtem Zugriff, Vertraulichkeit und Integrität von Daten, Datenminimierung, eine möglichst kleine Angriffsfläche und die Möglichkeit, Daten und Einstellungen sicher zu löschen. Produkte dürfen nicht mit bekannten ausnutzbaren Schwachstellen auf den Markt gebracht werden.

Grundlage ist eine dokumentierte Cybersicherheitsrisikobewertung, die die Zweckbestimmung, die vernünftigerweise vorhersehbare Verwendung, die Betriebsumgebung und die erwartete Nutzungsdauer berücksichtigt. Sie ist während des Unterstützungszeitraums fortzuschreiben und Teil der technischen Dokumentation.

2. Software-Stückliste und Komponenten Dritter

Hersteller müssen Schwachstellen und Komponenten ihrer Produkte ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1). Beim Einbau von Komponenten Dritter, auch von Open-Source-Bibliotheken, ist die gebotene Sorgfalt anzuwenden, damit sie die Sicherheit des Gesamtprodukts nicht beeinträchtigen (Art. 13 Abs. 5 CRA). Wer eine Schwachstelle in einer Komponente feststellt, muss sie dem Hersteller oder Maintainer der Komponente melden und im eigenen Produkt beheben (Art. 13 Abs. 6 CRA). Die Verantwortung für das Gesamtprodukt bleibt beim Hersteller.

3. Schwachstellenmanagement und Updates

Anhang I Teil II verlangt einen dauerhaft funktionierenden Prozess: regelmäßige Sicherheitstests, eine Strategie für die koordinierte Offenlegung von Schwachstellen, eine Kontaktadresse für Meldungen, unverzügliche Behebung durch Sicherheitsupdates, möglichst getrennt von Funktionsupdates, sichere Update-Mechanismen und die Veröffentlichung von Informationen über behobene Schwachstellen. Sicherheitsupdates sind unverzüglich und grundsätzlich kostenlos bereitzustellen; abweichende Vereinbarungen sind nur für maßgeschneiderte Produkte mit gewerblichen Nutzern vorgesehen.

4. Unterstützungszeitraum

Der Hersteller muss einen Unterstützungszeitraum festlegen, der die voraussichtliche Nutzungsdauer widerspiegelt. Er beträgt mindestens fünf Jahre; nur wenn das Produkt voraussichtlich kürzer genutzt wird, ist ein entsprechend kürzerer Zeitraum zulässig (Art. 13 Abs. 8 CRA). Bereitgestellte Sicherheitsupdates müssen mindestens zehn Jahre oder für den restlichen Unterstützungszeitraum verfügbar bleiben, je nachdem, was länger ist (Art. 13 Abs. 9 CRA). Das wirkt sich unmittelbar auf Produktplanung, Release-Strategie, Personal und Kalkulation aus und muss mit Supportzusagen, End-of-Life-Regelungen und Haftungsklauseln in den Verträgen abgestimmt werden.

5. Dokumentation, Konformitätsbewertung und CE-Kennzeichnung

Vor dem Inverkehrbringen sind die technische Dokumentation zu erstellen, die Konformitätsbewertung durchzuführen, die EU-Konformitätserklärung auszustellen und die CE-Kennzeichnung anzubringen. Welches Verfahren gilt, hängt von der Produktkategorie ab (Art. 32 CRA):

• Standardprodukte: Interne Kontrolle durch den Hersteller genügt.
• Wichtige Produkte der Klasse I (Anhang III, z. B. Browser, Passwort-Manager, Antivirensoftware, Router): Interne Kontrolle nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein Zertifizierungsschema vollständig angewendet werden; sonst ist eine Prüfung durch eine notifizierte Stelle erforderlich.
• Wichtige Produkte der Klasse II (z. B. Firewalls, Systeme zur Angriffserkennung und -abwehr): Stets Baumusterprüfung, umfassende Qualitätssicherung oder ein europäisches Zertifizierungsschema.
• Kritische Produkte (Anhang IV): Vorrangig ein europäisches Zertifizierungsschema.

Die richtige Einordnung des eigenen Produkts ist deshalb eine der ersten und folgenreichsten Weichenstellungen.

Was gilt für SaaS-Anbieter?

Bei SaaS-Angeboten ist sorgfältig zu unterscheiden. Ein reiner Cloud-Dienst ist für sich genommen grundsätzlich kein Produkt mit digitalen Elementen. Der CRA erfasst Cloud-Lösungen aber als „Datenfernverarbeitung“, wenn die entfernte Verarbeitung vom Hersteller selbst oder unter seiner Verantwortung entwickelt wurde und das Produkt ohne sie eine seiner Funktionen nicht erfüllen könnte (Art. 3 Nr. 2 CRA, Erwägungsgrund 12). Die Cloud-Steuerung eines Smart-Home-Geräts ist das typische Beispiel.

Für SaaS-Anbieter folgt daraus ein Abgrenzungsrisiko. Neben dem eigentlichen Dienst bieten viele Anbieter Komponenten an, die beim Kunden laufen: Desktop- oder Mobile-Clients, Agenten, SDKs, Browsererweiterungen, On-Premise-Connectoren oder Administrationssoftware. Solche Komponenten können eigenständige Produkte mit digitalen Elementen sein, auch wenn das Geschäftsmodell im Übrigen in der Cloud läuft. Wo genau die Grenze verläuft, ist in der Fachdiskussion teilweise noch offen und hängt stark von der Architektur im Einzelfall ab.

Unabhängig vom CRA können Cloud-Dienste der NIS-2-Regulierung unterliegen, in Deutschland umgesetzt im BSI-Gesetz. Sie knüpft nicht an das Produkt, sondern an die Einrichtung an und verlangt Risikomanagementmaßnahmen wie Vorfallbehandlung, Lieferkettensicherheit, Schwachstellenmanagement, Zugriffskontrolle und Multi-Faktor-Authentifizierung. Ob ein Unternehmen erfasst ist, hängt unter anderem von Sektor und Größe ab.

Verträge anpassen

Der CRA verlagert Pflichten auf den Hersteller, die vertraglich nicht abbedungen werden können. Verträge mit Kunden, Lieferanten und Dienstleistern sollten sie aber abbilden, insbesondere:

• Supportdauer, Update- und End-of-Life-Regelungen im Einklang mit dem Unterstützungszeitraum,
• Reaktionszeiten, Mitwirkung bei Sicherheitsvorfällen und Informationspflichten,
• Zusicherungen, SBOM-Daten und Schwachstellenmeldungen von Zulieferern und Entwicklungsdienstleistern,
• Audit- und Nachweisrechte sowie Regelungen zu Datenlöschung und Außerbetriebnahme,
• Haftungsbeschränkungen in AGB, die mit den zwingenden Pflichten vereinbar bleiben müssen.

Sanktionen und Marktüberwachung

Die Marktüberwachungsbehörden können Korrekturmaßnahmen verlangen, den Vertrieb beschränken und die Rücknahme oder den Rückruf eines Produkts anordnen. Die Mitgliedstaaten legen die Sanktionen fest; der CRA gibt die Höchstgrenzen vor (Art. 64 CRA):

• bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Anforderungen nach Anhang I und die Pflichten aus Art. 13 und 14,
• bis zu 10 Mio. Euro oder 2 % bei Verstößen gegen weitere Pflichten, etwa von Importeuren und Händlern oder zur Konformitätserklärung und CE-Kennzeichnung,
• bis zu 5 Mio. Euro oder 1 % bei falschen, unvollständigen oder irreführenden Angaben gegenüber Behörden und notifizierten Stellen.

Maßgeblich ist jeweils der höhere Betrag. Für Kleinst- und Kleinunternehmen gibt es eine Ausnahme bei verspäteten Frühwarnungen nach Art. 14, für Verwalter quelloffener Software sind Geldbußen ausgeschlossen. Außerdem sind Verbandsklagen von Verbraucherverbänden ausdrücklich vorgesehen (Art. 65 CRA).

Was jetzt zu tun ist

1. Anwendungsbereich und Rollen klären: Für jedes Produkt und jede Komponente dokumentieren, ob ein Produkt mit digitalen Elementen vorliegt, wer Hersteller ist und welche Kategorie einschlägig ist.
2. Prozesse aufbauen: Verantwortlichkeit für Produktsicherheit, Schwachstellenmanagement, koordinierte Offenlegung, Meldeprozess und Patch-Management festlegen.
3. SBOM und Lieferkette: Komponenten erfassen und die Sorgfalt bei Open-Source- und Drittkomponenten nachvollziehbar machen.
4. Dokumentation: Risikobewertung, technische Dokumentation und Konformitätsbewertung vorbereiten.
5. Verträge und AGB prüfen: Support, Updates, Haftung und Zuliefererpflichten an den CRA anpassen.

Der CRA ist kein einmaliges Zertifizierungsprojekt, sondern verlangt ein dauerhaft betriebenes System aus Entwicklung, Lieferkettenkontrolle, Schwachstellenbehandlung und Dokumentation. Welche Pflichten im Einzelnen gelten, hängt vom Produkt, seiner Architektur und seiner Vermarktung ab.

Rechtliche Begleitung beim Cyber Resilience Act

Wir unterstützen Softwarehersteller und SaaS-Anbieter bei der Einordnung ihrer Produkte, bei der Anpassung von AGB, Lizenz-, Support- und Lieferantenverträgen und bei der Abwehr von Abmahnungen und behördlichen Maßnahmen. Mehr dazu auf den Seiten Fachanwalt für IT-Recht und AGB und Rechtstexte erstellen lassen. Lesen Sie auch unsere Beiträge zur CRA-Meldepflicht, zu KI-Klauseln in AGB und zu DORA.

Wenn Sie wissen möchten, ob und wie Ihr Produkt betroffen ist, nehmen Sie Kontakt mit uns auf.

Quellen: Verordnung (EU) 2024/2847 (Cyber Resilience Act), ABl. L vom 20.11.2024, insbesondere Art. 3, 13, 14, 32, 64, 65, 71 und Anhänge I, III, IV. Dieser Beitrag dient der allgemeinen Information und ersetzt keine rechtliche Prüfung im Einzelfall.