CRA: Meldepflicht nach Art. 14 CRA (Cyber Resilience Act) gelten ab dem 11. September 2026
A: Sinn
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist seit dem 10. Dezember 2024 geltendes EU-Recht. Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.
Die Idee: Sofern ein Unternehmen meldet „die Bibliothek XYZ“ ist Teil meiner Software und ist von Malware befallen, muss das Unternehmen dies an die ENISA melden (ENISA: European Union Agency for Cybersecurity — die EU-Agentur für Cybersicherheit mit Sitz in Athen. Diese ist zuständig für die Koordinierung der IT-Sicherheit auf EU-Ebene, betreibt die „EU-Schwachstellendatenbank“ und die „Single Reporting Platform“, über die die Meldungen nach Art. 14 CRA eingehen). Die ENISA und das BSI fungieren als „CSIRT“: (CSIRT: Computer Security Incident Response Team — in jedem EU-Mitgliedstaat gibt es ein nationales Pendant. In Deutschland ist das das BSI (Bundesamt für Sicherheit in der Informationstechnik). Das „CSIRT“ nimmt die Meldungen auf nationaler Ebene entgegen und koordiniert die Reaktion im jeweiligen Land.
Die ENISA kann auf Grundlage der Meldungen EU-weite Warnungen herausgeben und führt die EU-Schwachstellendatenbank (Art. 16 CRA), in der die gemeldeten kompromittierbaren Komponenten erfasst werden.
Art. 16 CRA verpflichtet die ENISA, eine EU-Schwachstellendatenbank (EU Vulnerability Database) zu führen. Da jeder Hersteller über seine SBOM wissen muss, welche Bibliotheken er einsetzt, kann er gegen diese Datenbank abgleichen.
Andere Pflichten des CRA – CE-Kennzeichnung, technische Dokumentation, Security by Design – kommen ab dem 11. Dezember 2027 hinzu.
B: Zielgruppe
Zielgruppe, wer ist betroffen:
Zusammenfassung: Es ist einfacher zu beschreiben, welche Produkte nicht unter den CRA fallen. Die reine App, die über den Browser zu betreiben ist, unterfällt nicht dem CRA. Jede Anwendung, bei denen der Hersteller eine lokale Softwarekomponente bereitstellt und die Funktionen des Serversoftware über die Bedienung des Clients ermöglicht, fällt unter den CRA.
Einzelheiten:
Der CRA soll Produkte absichern, die bestimmungsgemäß über Netze (Internet, lokale Netze oder physische Schnittstellen) Daten austauschen und bedient werden, also klassische Client Server Systeme.
Dazu gehören also vernetzte Systeme, Steuerungssysteme, Industrieautomation, reine Softwareprodukte. Die Unternehmensgröße spielt keine Rolle.
Nicht betroffen: Reiner Webserverzugriff über Browser (Ohne dass bestimmte Software im Browser gespeichert ist), Hersteller von Medizinprodukten (MDR), In-vitro-Diagnostika (IVDR), Fahrzeugen, Luftfahrtprodukten und Schiffsausrüstung — diese Sektoren haben eigene Cybersecurity-Regime.
Einige Beispiele:
1.) Kunde kauft Client und Serversystem und betreibt alles selbst: Server und Client werden auf dem EU-Markt „bereitgestellt“ im Sinne des Art. 2 CRA. Beides ist Produkt mit digitalen Elementen. CRA gilt.
2.)Hosted Cloud bei Kauf (Kunde kauft die Serversoftware und Clientsoftware, Serverersoftware wird durch den Anbieter im Rechenzentrum eines Dritten betrieben): Die Software wird dem Kunden überlassen — „auf dem Markt bereitgestellt.“ CRA gilt für Server und Client, genau wie bei On-Premises. Die Betreibereigenschaft ändert nichts, wenn zwei Dinge kumulativ erfüllt sind. Erstens, die Serversoftware wurde auch vom Hersteller entwickelt. Zweitens, ohne die Clientsoftware kann der Server eine seiner Funktionen nicht erfüllen und keine Daten verarbeiten.
3.)SaaS (Anbieter betreibt Serversorftware, Kunde hat Client-Software lokal installiert): Die Serversoftware bleibt beim Anbieter — sie wird nicht auf dem Markt bereitgestellt, sondern als Dienst erbracht. Aber: Wie Beispiel 2.
4.)Reine Browser-Anwendung (keinerlei lokale Installation): Kein Produkt wird bereitgestellt. Reiner Dienst. CRA gilt nicht. NIS2 gilt ggf. für den Anbieter als Betreiber.
C. Pflichten
Der CRA fordert die Erfüllung bestimmter Pflichten. Man muss bei der ENISA registriert sein, und man muss eine Dokumentation für die Erfüllung der Meldepflicht innerhalb der gesetzlich geforderten Pflichten aufweisen können.
- SLA Reaktion
Sanktionen: Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes (Art. 64 CRA).
- SBOM erstellen: Eine Software Bill of Materials für jedes betroffene Produkt ist die Voraussetzung dafür, überhaupt erkennen zu können, ob eine öffentlich bekannte Schwachstelle Ihr Produkt betrifft.
- PSIRT-Prozess steht für Product Security Incident Response Team — das klingt groß, kann aber auch der CTO mit einem dokumentierten Prozess sein: Wer beobachtet Schwachstellendatenbanken? Wer bewertet? Wer meldet? Wer informiert die Kunden? Dokumentieren Sie die Kette, benennen Sie Verantwortliche, testen Sie den Ablauf.
- Auf der ENISA SRP registrieren. Die Single Reporting Platform soll bis September 2026 betriebsbereit sein. Sobald die Registrierung möglich ist: Zugang einrichten, Meldewege testen.
- SLA etablieren
Der CRA etabliert eine Art „SLA Meldereaktion“
Stufe 1 – „Frühwarnung“: Innerhalb von 24 Stunden nach Kenntniserlangung einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls müssen Sie eine Frühwarnung an das BSI) und an die ENISA über die neue Single Reporting Platform (SRP) abgeben.
Stufe 2 – „Vollmeldung“: Innerhalb von 72 Stunden folgt die detaillierte Meldung mit Schwachstellenbeschreibung, betroffenen Produkten und ergriffenen Gegenmaßnahmen.
Stufe 3 — „Abschlussbericht“: Innerhalb von 14 Tagen nach Verfügbarkeit eines Patches (bei Schwachstellen), bzw. innerhalb eines Monats (bei Vorfällen) der Abschlussbericht mit Root-Cause-Analyse.
Zusätzlich müssen Sie nach Art. 14 Abs. 8 CRA auch die Nutzer Ihrer Produkte über die Schwachstelle und verfügbare Patches informieren (BTB).
- Nicht direkt im CRA genannt aber aus ihm abzuleiten ist eine Zeitenwende für die Pflicht zur Überwachung (Produktbeobachtungspflicht) und Verbesserung der Software ab dem September 2026. Dazu werde ich gesonderte Blogs veröffentlichen.
Haben Sie Fragen zur CRA-Meldepflicht oder zur Einordnung Ihrer Produkte? Sprechen Sie uns an.
