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

Problem

Ab dem 11. Dezember 2027 gilt im EU-Binnenmarkt eine harte Regel: Ein Produkt mit digitalen Elementen, das die CRA-Anforderungen nicht erfüllt, darf nicht mehr in Verkehr gebracht werden - keine Konformität, kein Verkauf. Damit wird Cybersicherheit von der Kür zur Marktzugangsvoraussetzung. Sie entwickeln Software oder vertreiben vernetzte Hardware und fragen sich also zu Recht, ob der CRA Sie betrifft und was zuerst zu tun ist. 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 klären: Bin ich CRA-Hersteller, welche Melde- und Dokumentationspflichten gelten, welche Frist greift zuerst? Umstritten sind vor allem die Abgrenzung zu reinem SaaS und die FOSS-Ausnahme (FOSS, Free and Open Source Software - frei verfügbare quelloffene Software); beide werden erst durch Leitlinien und Durchführungsrechtsakte scharf.

Für wen ist das? Für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen.

Kurze Antwort

Der CRA macht Cybersicherheit erstmals zur Voraussetzung dafür, dass ein digitales Produkt im EU-Markt verkauft werden darf - mit gestaffelten Fristen und spürbaren Bußgeldern.

• In Kraft seit 10. Dezember 2024; Meldepflichten ab 11. September 2026; übrige Hersteller-Pflichten samt CE-Kennzeichnung (sichtbares Konformitätszeichen) ab 11. Dezember 2027.
• Erfasst sind "Produkte mit digitalen Elementen", also auf dem EU-Markt bereitgestellte Software und Hardware.
• Reines Browser-SaaS ist grundsätzlich ausgenommen; das Cloud-Backend eines herunterladbaren CRA-Produkts nicht.
• Pflichten: Sicherheit von Anfang an, geordneter Schwachstellen-Umgang, Software-Stückliste (SBOM), Sicherheits-Updates über den Support-Zeitraum.
• Verstöße gegen die wesentlichen Anforderungen kosten bis 15 Mio. EUR oder 2,5 Prozent des weltweiten Jahresumsatzes.

Tiefgang

Anwendungsbereich

Nach Art. 3 CRA ist ein "Produkt mit digitalen Elementen" jedes Software- oder Hardware-Produkt samt zugehöriger Datenfernverarbeitung, sofern es ohne diese eine Funktion verlöre. Eingebettete Software fällt damit fast immer unter den CRA. Reines Browser-SaaS ist kein CRA-Produkt, sondern unterliegt NIS-2 (der EU-Richtlinie zur Cybersicherheit). Die Grenze verschiebt sich aber, sobald ein herunterladbares Produkt zwingend ein Backend des gleichen Herstellers braucht: Dann wird es CRA-pflichtiger Teil des Produkts.

Klassifizierung und Konformitätsbewertung

Der CRA kennt drei Stufen. Standard-Produkte (rund 90 Prozent) dürfen sich selbst bewerten (Modul A). Klasse I nach Anhang III (etwa Passwort-Manager, Netzwerkmanagement-Werkzeuge, VPN) nur bei vollständiger Anwendung harmonisierter Normen oder europäischer Cybersicherheitszertifizierung; sonst ist eine benannte Stelle (unabhängige Prüfstelle) nötig. Klasse II (etwa Firewalls, industrielle Angriffserkennung) verlangt sie zwingend. Kritische Produkte nach Anhang IV (etwa Smart-Meter-Gateways, Secure Elements) benötigen eine europäische Zertifizierung.

Wesentliche Anforderungen

Anhang I Teil I verlangt Sicherheit von Anfang an: sichere Standardkonfiguration, Schutz vor unberechtigtem Zugriff, Vertraulichkeit und Integrität gespeicherter wie übertragener Daten, kleine Angriffsfläche, risikogerechtes Schutzniveau. Teil II verlangt geregelten Schwachstellen-Umgang über den gesamten Support-Zeitraum: eine maschinenlesbare Stückliste der Software-Bausteine (SBOM, Software Bill of Materials) für mindestens die direkten Abhängigkeiten, ein geordnetes Offenlegungsverfahren, zeitnahe Sicherheits-Updates und eine Kontaktadresse für Sicherheitsforschende. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat mit der Technischen Richtlinie TR-03183 konkrete Vorgaben zu SBOM und Schwachstellen-Umgang vorgelegt; sie orientieren, bis die harmonisierten CEN/CENELEC-Normen (gemeinsame europäische Normen) kommen.

Meldepflichten

Art. 14 CRA verlangt eine dreistufige Meldung an die zuständige nationale CSIRT (Computer Security Incident Response Team - staatliches Computer-Notfallteam) und die ENISA Single Reporting Platform (zentrale Meldeplattform der EU-Cybersicherheitsagentur ENISA). Nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls folgen binnen 24 Stunden eine Erstmeldung, binnen 72 Stunden eine Zwischenmeldung mit Details und eine Abschlussmeldung binnen 14 Tagen (Schwachstelle, nach Update) bzw. einem Monat (Vorfall). Die Pflicht greift ab 11. September 2026, 15 Monate vor den übrigen Hersteller-Pflichten.

FOSS-Ausnahme und kommerzielle Aktivität

Rein nicht-kommerzielle Open-Source-Entwicklung bleibt ausgenommen. Die Kommission fasst "kommerzielle Aktivität" aber weit: bezahlter Support, Premium-Versionen, kommerziell ausgerichtete Unternehmensbeteiligung oder Spenden über den Kosten können den Hersteller-Status auslösen. Dazwischen steht die neue Rolle des "Open-Source-Software-Stewards" (Art. 24, ein Verwalter quelloffener Software mit reduzierten Pflichten), etwa für tragende Stiftungen.

Sanktionen

Art. 64 CRA staffelt die Bußgelder, jeweils nach dem höheren Wert. Verstöße gegen Anhang I sowie gegen Art. 13/14 (Hersteller-Pflichten, Meldung) kosten bis 15 Mio. EUR oder 2,5 Prozent des weltweiten Jahresumsatzes. Verstöße gegen Importeur- und Händlerpflichten oder die Konformitätsbewertung liegen bei 10 Mio. EUR oder 2 Prozent, falsche Behördenangaben bei 5 Mio. EUR oder 1 Prozent.

Abgelehnte Alternativen

Abwarten ist keine Option: Die Meldepflicht gilt 15 Monate vor den Produktpflichten, und der CE-Zwang greift für alle Neuprodukte ab 11. Dezember 2027, unabhängig vom Normenstand. Marktrückzug ist für deutsche B2B-SaaS-Firmen keine Lösung. Die SaaS-Ausnahme trägt nur ohne Download-Komponente und wesentliche Hersteller-Backend-Logik; sobald ein Agent, On-Prem-Connector oder CLI ausgeliefert wird, greift der CRA.

Was Sie jetzt tun sollten

• Hersteller-Status klären: Prüfen Sie, ob Sie ein "Produkt mit digitalen Elementen" in den EU-Markt bringen - also etwa einen Download, Agenten, Connector oder CLI ausliefern. Reines Browser-SaaS fällt grundsätzlich nicht darunter.
• Produktklasse einordnen: Bestimmen Sie früh, ob Ihr Produkt selbst bewertbar ist (rund 90 Prozent) oder unter Anhang III/IV fällt und eine benannte Stelle oder Zertifizierung braucht - das bestimmt Aufwand und Vorlauf.
• Schwachstellen-Prozess aufsetzen: Richten Sie eine Kontaktadresse für Sicherheitsforschende, ein Offenlegungsverfahren und einen Update-Pfad über den gesamten Support-Zeitraum ein.
• SBOM erzeugen: Bauen Sie eine maschinenlesbare Software-Stückliste mindestens für die direkten Abhängigkeiten in Ihre Entwicklung ein; orientieren Sie sich an der BSI-Richtlinie TR-03183.
• Meldefähigkeit vorbereiten: Stellen Sie sicher, dass Sie ab 11. September 2026 die 24-/72-Stunden- und Abschluss-Meldungen an CSIRT und ENISA-Plattform fristgerecht absetzen können.

Wie Dernium hier hilft

Dernium entwickelt Bausteine, die einzelne Pflichten in die Praxis übersetzen, ersetzt aber keine CRA-Compliance-Beratung. Dernium Scan und Dernium Clean liefern nachvollziehbare, wiederholbar erzeugbare Datei-Prüfergebnisse als Nachweis für ein Schwachstellen-Verfahren. Dernium Mailcheck deckt den Eingangskanal für Sicherheitsmeldungen ab.

Offene Punkte

Die Durchführungsrechtsakte zu Anhang III und IV sowie die harmonisierten CEN/CENELEC-Normen (JTC 13 WG 9) sind in Arbeit, aber noch nicht final. Die ENISA Single Reporting Platform soll bis 11. September 2026 produktiv sein, mit vorgelagerter Testphase. Offen ist zudem, wie deutsche Behörden den Steward-Status feststellen und wie sich BSI-Marktüberwachung und Landesbehörden verhalten. Dernium verfolgt den Stand laufend und passt die Roadmap an neue Durchführungsrechtsakte an.

Häufige Fragen

Fällt mein reines Browser-SaaS unter den CRA?

Grundsätzlich nicht. Reines Browser-SaaS ohne herunterladbare Komponente ist kein "Produkt mit digitalen Elementen" und unterliegt eher NIS-2. Die Grenze verschiebt sich, sobald Sie etwas ausliefern, das beim Kunden läuft - einen Agenten, On-Prem-Connector, ein CLI oder ein herunterladbares Produkt, das zwingend Ihr Backend braucht. Dann greift der CRA für dieses Produkt.

Welche Frist trifft mich zuerst?

Die Meldepflicht nach Art. 14. Sie gilt ab 11. September 2026 - 15 Monate vor den übrigen Hersteller-Pflichten und der CE-Kennzeichnung, die erst ab 11. Dezember 2027 verpflichtend sind. Wer aktiv ausgenutzte Schwachstellen oder schwerwiegende Vorfälle nicht fristgerecht meldet, ist also als Erstes betroffen.

Muss ich für mein Produkt eine externe Prüfstelle einschalten?

Meist nicht. Rund 90 Prozent der Produkte dürfen sich selbst bewerten (Modul A). Eine benannte Stelle (unabhängige Prüfstelle) wird erst bei Anhang-III-Produkten ohne vollständige Normanwendung und bei Anhang-II-Produkten wie Firewalls zwingend nötig. Kritische Produkte nach Anhang IV brauchen eine europäische Zertifizierung. Die Einordnung Ihrer Produktklasse entscheidet das.

Was ist eine SBOM und reicht eine grobe Liste?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Software-Bausteine eines Produkts. Der CRA verlangt sie mindestens für die direkten Abhängigkeiten. Eine handgepflegte Tabelle reicht in der Praxis nicht, weil sie veraltet und nicht maschinenlesbar ist. Die BSI-Richtlinie TR-03183 gibt konkrete Format- und Inhaltsvorgaben.

Bin ich als reiner Open-Source-Entwickler betroffen?

Rein nicht-kommerzielle Open-Source-Entwicklung bleibt ausgenommen. Sobald aber kommerzielle Aktivität dazukommt - bezahlter Support, Premium-Versionen, kommerziell ausgerichtete Unternehmensbeteiligung oder Spenden über den Kosten - kann der Hersteller-Status entstehen. Für tragende Stiftungen gibt es die neue Zwischenrolle des Open-Source-Software-Stewards mit reduzierten Pflichten.

Mehr aus unserer CRA-Reihe

• SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte
• CRA-Meldepflicht: Schwachstellen und Vorfälle an CSIRT und ENISA (ab 2026)
• CRA-Konformitätsnachweise: Anhang V/VII und CE (ab 2027)
• DoC- und Tech-Doc-Generator im CRA-Nachweis
• Coordinated Vulnerability Disclosure: Policy, security.txt und CSAF
• Schwachstellen über den Support-Zeitraum behandeln: Fristen-Uhr und Behebungs-Lebenslauf
• Konformitätsbewertung nach CRA: welcher Pfad für welches Produkt (Art. 32)
• CRA Anhang II: Nutzerinformationen und Anleitungen als PDF
• Die CRA-Risikobewertung (Art. 13): welche Anforderungen für Ihr Produkt gelten
• Drittkomponenten nach CRA: Sorgfaltspflicht für Fremd- und Open-Source-Bausteine (Art. 13 Abs. 5)
• CRA-Readiness auf einen Blick: das Dashboard über alle Bausteine
• Wesentliche Veränderung nach CRA: wann eine neue Version neu bewertet werden muss (Art. 3 Nr. 30)
• Die notifizierte Stelle nach CRA: wann eine Dritt-Prüfung nötig ist und was sie braucht (Art. 32)
• Dernium CRA: ein Werkzeug für den gesamten Cyber Resilience Act