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(1)) ist ein Software- oder Hardware-Produkt samt zugehöriger Datenfernverarbeitung, auch wenn Komponenten separat auf den Markt gebracht werden. Auslöser (Art. 2(1)) ist eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz. Eigenständige Software — also Anwendungen, die auf den Markt gebracht oder in Verkehr gebracht werden — gilt damit im Regelfall als Produkt mit digitalen Elementen und fällt in den Anwendungsbereich des CRA. Das ist der entscheidende Punkt für Software-Hersteller: Der CRA betrifft nicht nur „Geräte“, sondern auch reine Softwareprodukte.

Kernpflichten für Software-Hersteller

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

Selbstbewertung oder benannte Stelle?

Eine benannte Stelle (Notified Body) ist keineswegs für jedes Produkt nötig. Der CRA kennt vier Stufen (Art. 32, Annex VIII): den unklassifizierten Regelfall, wichtige Produkte der Klasse I und Klasse II sowie kritische Produkte. Die meisten Produkte mit digitalen Elementen bewerten sich selbst (Modul A). Wichtige Produkte der Klasse I dürfen dies ebenfalls, sofern harmonisierte Normen, gemeinsame Spezifikationen oder ein Zertifizierungsschema vollständig angewendet werden; andernfalls braucht es eine Drittprüfung. Eine benannte Stelle ist zwingend nur für Klasse II und kritische Produkte. Zu den in Annex 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

Annex I Teil II 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. Etablierte Formate wie CycloneDX, SPDX (ISO/IEC 5962) oder SWID erfüllen die Anforderung als anerkannte Formate (Orientierung, keine gesetzliche Vorgabe). Die Kommission kann per Durchführungsrechtsakt später ein Format festlegen; ein solcher liegt bislang 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(2)):

Die Meldefristen nach Art. 14 folgen einer Kaskade: Frühwarnung binnen 24 Stunden nach Kenntnisnahme, Meldung binnen 72 Stunden, Abschlussbericht bei Schwachstellen innerhalb von 14 Tagen nach Verfügbarkeit einer Fehlerbehebung, bei schweren Vorfällen dagegen innerhalb eines Monats nach der Meldung — die beiden Fristen sind also nicht identisch.

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 vor September 2026 aufsetzen; (5) technische Dokumentation (Annex 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 ab September 2026 und betreffen auch Produkte, die zu diesem Zeitpunkt schon auf dem Markt sind; ein funktionierender Melde- und Reaktionsprozess sollte daher priorisiert werden. Wer heute Architekturentscheidungen trifft, sollte den mindestens fünfjährigen Supportzeitraum von Anfang an einplanen.