Cyber Resilience Act - was der CRA für Softwarehersteller bedeutet

4 Min Lesezeit Serie: compliance #compliance#cra#eu

Scope, Meldepflichten, SBOM und Bussgelder des EU Cyber Resilience Act (Verordnung 2024/2847), mit Fristen bis 2027 und Einordnung für SaaS und Open Source.

Problem

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist die erste horizontale Produktsicherheitsverordnung für Software und vernetzte Hardware im EU-Binnenmarkt. Wer in Deutschland SaaS entwickelt oder On-Premise-Produkte vertreibt, muss jetzt entscheiden, ob er Hersteller im Sinne des CRA ist, welche Melde- und Dokumentationspflichten gelten und welche Frist zuerst zuschlaegt. Die Materie ist in Fachkreisen nicht unumstritten, weil die Abgrenzung zu reinem SaaS und die FOSS-Ausnahme erst durch Leitlinien und Durchführungsrechtsakte scharf werden.

Kurze Antwort

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfaelle gelten ab dem 11. September 2026, die vollständigen Hersteller-Pflichten inklusive CE-Kennzeichnung ab dem 11. Dezember 2027. Erfasst sind "Produkte mit digitalen Elementen", also Software und Hardware, die auf dem EU-Markt bereitgestellt werden. Reines, browserbasiertes SaaS ist grundsaetzlich ausgenommen, Cloud-Backends eines CRA-Produkts hingegen nicht. Bei Verstoessen gegen die wesentlichen Cybersicherheitsanforderungen drohen Bussgelder bis 15 Mio. EUR oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was hoeher ist.

Tiefgang

Anwendungsbereich

Nach Art. 3 CRA ist ein "Produkt mit digitalen Elementen" jedes Software- oder Hardware-Produkt sowie dessen Datenfernverarbeitungsloesungen, sofern deren Fehlen eine Funktion des Produkts verhindern wuerde. Eingebettete Software in Geraeten faellt damit fast immer unter den CRA. Reines Software-as-a-Service, auf das nur per Browser zugegriffen wird, ist kein CRA-Produkt und faellt stattdessen in den Geltungsbereich von NIS-2. Die Grenze verschiebt sich allerdings, sobald ein herunterladbares Produkt ein vom selben Hersteller betriebenes Backend zwingend benoetigt; dann wird dieses Backend Teil des Produkts und muss die CRA-Anforderungen erfuellen.

Klassifizierung und Konformitaetsbewertung

Der CRA kennt drei Stufen. Die Standard-Produkte (etwa 90 Prozent aller Produkte) können eine Selbstbewertung nach Modul A durchführen. Wichtige Produkte der Klasse I nach Anhang III (z.B. Passwort-Manager, Netzwerkmanagement-Werkzeuge, VPN) duerfen die Selbstbewertung nur nutzen, wenn harmonisierte Normen oder eine europaeische Cybersicherheitszertifizierung vollständig angewandt werden; sonst ist eine benannte Stelle einzubinden. Wichtige Produkte der Klasse II (z.B. Firewalls, Intrusion-Detection-Systeme für industrielle Umgebungen) verlangen zwingend eine Dritt-Pruefung. Kritische Produkte nach Anhang IV (etwa Smart-Meter-Gateways und Secure Elements) benoetigen eine europaeische Zertifizierung.

Wesentliche Anforderungen

Anhang I Teil I verlangt Security-by-Design: sichere Standardkonfiguration, Schutz vor unberechtigtem Zugriff, Vertraulichkeit und Integritaet gespeicherter sowie übertragener Daten, Minimierung der Angriffsflaeche und ein Haertungsstand, der dem Risiko entspricht. Anhang I Teil II verlangt ein geregeltes Vulnerability Handling über den gesamten Support-Zeitraum, einschließlich einer maschinenlesbaren Software Bill of Materials (SBOM) für mindestens die Top-Level-Abhaengigkeiten, koordinierter Offenlegung, zeitnaher Sicherheits-Updates und einer Kontaktadresse für Sicherheitsforschende. Das BSI hat mit der Technischen Richtlinie TR-03183 bereits konkrete SBOM- und Vulnerability-Handling-Vorgaben vorgelegt, die als Orientierung vor den harmonisierten CEN/CENELEC-Normen dienen.

Meldepflichten

Art. 14 CRA verlangt eine dreistufige Meldung an die zustaendige nationale CSIRT und an die ENISA Single Reporting Platform. Eine Erstmeldung ist innerhalb von 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls abzugeben, eine Zwischenmeldung mit weiteren Details innerhalb von 72 Stunden, und eine Abschlussmeldung innerhalb von 14 Tagen (Schwachstelle, nach Bereitstellung eines Updates) bzw. einem Monat (Vorfall). Diese Pflicht greift bereits ab dem 11. September 2026, also 15 Monate vor den restlichen Hersteller-Pflichten.

FOSS-Ausnahme und kommerzielle Aktivitaet

Rein nicht-kommerzielle Open-Source-Entwicklung bleibt ausgenommen. Die Kommission definiert kommerzielle Aktivitaet allerdings breit: bezahlter Support, Premium-Versionen, kommerziell ausgerichtete Unternehmensbeteiligung oder Spenden, die die Kosten übersteigen, können den Hersteller-Status ausloesen. Dazwischen steht die neue Rolle des "Open-Source-Software-Stewards" (Art. 24) mit reduzierten Pflichten, etwa für Foundations, die Projekte dauerhaft tragen.

Sanktionen

Art. 64 CRA staffelt die Bussgelder. Verstoesse gegen Anhang I und gegen Art. 13/14 (Hersteller-Pflichten, Meldung) sind mit bis zu 15 Mio. EUR oder 2,5 Prozent des weltweiten Jahresumsatzes sanktionierbar, je nachdem, was hoeher ist. Andere Verstoesse (Importeur- und Haendlerpflichten, Konformitaetsbewertung) liegen bei 10 Mio. EUR oder 2 Prozent, falsche Angaben gegenueber Behörden bei 5 Mio. EUR oder 1 Prozent.

Abgelehnte Alternativen

Abwarten, bis die harmonisierten Normen fertig sind, ist keine Option: Die Meldepflicht gilt 15 Monate vor den Produktpflichten, und der CE-Zwang greift für alle Neuprodukte ab dem 11. Dezember 2027 unabhängig vom Stand der Normen. Rueckzug aus dem EU-Markt ist bei einer deutschen B2B-SaaS-Firma kein Ausweg. Die Behauptung, man sei als SaaS-Anbieter vollständig ausgenommen, traegt nur, solange das Produkt keine Download-Komponente oder essentielle Hersteller-Backend-Logik enthält; sobald ein Agent, ein On-Prem-Connector oder ein CLI ausgeliefert wird, greift der CRA.

Wie Dernium hier hilft

Dernium entwickelt Bausteine, die einzelne Pflichten operationalisieren, ersetzt aber keine CRA-Compliance-Beratung. Dernium Scan und Dernium Clean liefern reproduzierbare Datei-Pruefergebnisse, die als Evidenz in ein Vulnerability-Handling-Verfahren einfliessen können. Dernium Mailcheck deckt den Eingangskanal für Security-Disclosures ab.

Offene Punkte

Die Durchführungsrechtsakte zu Anhang III und IV sowie die harmonisierten Normen von CEN/CENELEC (JTC 13 WG 9) sind in Arbeit, aber noch nicht final. Die ENISA Single Reporting Platform soll bis 11. September 2026 produktiv sein, die Testphase beginnt vorher. Offen ist außerdem, wie deutsche Behörden den Steward-Status konkret feststellen und wie die Marktueberwachung durch das BSI im Verhaeltnis zu Landesbehoerden ausgestaltet wird. Dernium verfolgt den Stand laufend und passt die Produkt-Roadmap an, sobald neue Durchführungsrechtsakte vorliegen.

Mehr aus unserer CRA-Reihe