Cyber Resilience Act für Software- & SaaS-Hersteller

Der EU Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen auf horizontale Cybersicherheitsanforderungen. Für Software- und SaaS-Anbieter ist die zentrale Frage: Bin ich mit meinem Produkt im Anwendungsbereich - und wenn ja, mit welchem Teil? Diese Seite ordnet die Rechtslage technisch-organisatorisch ein. Sie liefert Orientierung, keine verbindliche Einzelfallberatung; eine rechtliche Bewertung im Einzelfall bleibt der Rechtsberatung vorbehalten.

Warum eigenständige Software betroffen ist

Ein Produkt mit digitalen Elementen (Art. 3 Nr. 1) ist ein Software- oder Hardwareprodukt samt seiner Datenfernverarbeitungslösungen, einschließlich separat in Verkehr gebrachter Komponenten. Voraussetzung (Art. 2 Abs. 1) ist, dass der bestimmungsgemäße Zweck oder die vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Eigenständige Software, also Anwendungen, die auf dem Markt bereitgestellt oder in Verkehr gebracht werden, gilt damit grundsätzlich als Produkt mit digitalen Elementen und fällt in den Anwendungsbereich des CRA.

Kernpflichten für Software-Hersteller

Als Hersteller (Art. 13) trifft Sie die Hauptlast der Pflichten. Die wesentlichen Handlungsfelder:

Selbstbewertung oder notifizierte Stelle?

Eine notifizierte Stelle (Notified Body) ist nicht für jedes Produkt nötig. Der CRA kennt vier Stufen (Art. 32, Anhang VIII): die unklassifizierte Standardkategorie, wichtige Produkte der Klasse I und Klasse II sowie kritische Produkte. Produkte der Standardkategorie bewerten sich selbst (Modul A). Wichtige Produkte der Klasse I dürfen dies ebenfalls, sofern harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) vollständig angewendet werden; andernfalls braucht es eine Drittprüfung (Modul B+C oder H). In jedem Fall vorgesehen ist eine Bewertung durch Dritte für Klasse II und kritische Produkte, bei Klasse I immer dann, wenn Normen, gemeinsame Spezifikationen oder ein Schema nicht vollständig angewandt werden. Zu den in Anhang III genannten Beispielen zählen etwa Passwort-Manager, Identitäts- und Zugriffsmanagement, Browser, VPNs, SIEM-Software oder Betriebssysteme (Klasse I) sowie etwa Firewalls, IDS/IPS und Hypervisoren (Klasse II). „Wichtig“ ist nicht dasselbe wie „kritisch“.

SBOM - ja, aber ohne festgelegtes Format

Anhang I Teil II Nr. 1 verlangt eine Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene abdeckt. Wichtig: Die Verordnung schreibt kein bestimmtes Format vor - es ist also nicht korrekt, dass der CRA CycloneDX oder SPDX vorschreibt. Beispiele für maschinenlesbare Formate sind CycloneDX und SPDX (ISO/IEC 5962); für die Anforderung zählt der Inhalt, also mindestens die obersten Abhängigkeiten. Die Kommission kann per Durchführungsrechtsakt später Format und Elemente festlegen (Art. 13 Abs. 24); ein solcher Durchführungsrechtsakt lag nach unserer Prüfung am 9. Oktober 2026 nicht vor. Die SBOM ist zudem ein Compliance-Artefakt, das den Behörden auf begründetes Verlangen offengelegt wird - keine Pflicht zur öffentlichen Veröffentlichung. Details in unserem Wissensbeitrag zu den SBOM-Anforderungen des CRA.

Zeitplan & Fahrplan

Der CRA ist am 10. Dezember 2024 in Kraft getreten - daraus folgen jedoch noch keine unmittelbar durchsetzbaren Pflichten. Die Anwendung ist gestaffelt (Art. 71 Abs. 2):

Die Meldefristen nach Art. 14 sind gestaffelt: Frühwarnung unverzüglich, spätestens 24 Stunden nach Kenntnis, Meldung spätestens nach 72 Stunden; der Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, bei schwerwiegenden Sicherheitsvorfällen innerhalb eines Monats nach der Meldung. Gemeldet werden aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Sicherheit des Produkts.

Empfohlener Fahrplan bis 2027: (1) Betroffenheit und mögliche Klassifizierung je Produkt klären; (2) Risikobewertung und Security-by-Design-Maßnahmen etablieren; (3) Schwachstellen-Prozess, CVD-Policy und SBOM-Generierung in die CI/CD-Pipeline integrieren; (4) Meldeprozesse für Art. 14 sofort aufsetzen, soweit noch nicht geschehen, denn sie sind seit September 2026 Pflicht; (5) technische Dokumentation (Anhang VII), EU-DoC und Konformitätsbewertung vor Dezember 2027 fertigstellen. Ein tieferer Überblick findet sich auf unserer CRA-Übersichtsseite.

Für Software-Teams ist es sinnvoll, früh zu beginnen: Ein Großteil der Anforderungen - SBOM-Erzeugung, Trennung von Sicherheits- und Funktionsupdates, dokumentierte CVD-Policy, sichere Update-Verteilung - lässt sich als Teil der bestehenden Entwicklungs- und Release-Prozesse umsetzen und muss nicht kurz vor der Frist als Sonderprojekt nachgeholt werden. Die Meldepflichten nach Art. 14 gelten bereits seit September 2026 und betreffen auch Produkte, die zu diesem Zeitpunkt schon auf dem Markt waren; ein funktionierender Melde- und Reaktionsprozess sollte daher priorisiert werden. Wer heute Architekturentscheidungen trifft, sollte den mindestens fünfjährigen Supportzeitraum von Anfang an einplanen.