Cyber Resilience Act: Neue Meldepflichten für Hersteller ab September 2026
Am 10. Dezember 2024 trat die Verordnung (EU) 2024/2847 – der Cyber Resilience Act (CRA) – in Kraft. Der Großteil der Pflichten gilt ab dem 11. Dezember 2027. Eine zentrale Regel jedoch beginnt bereits am 11. September 2026: die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Betroffen sind alle Hersteller von Hardware- und Softwareprodukten mit digitalen Elementen, die auf dem EU-Markt verkauft werden – einschließlich Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden.
Für Compliance-Verantwortliche und Security-Manager bedeutet das: Vulnerability-Handling wird nicht erst in zwei Jahren relevant, sondern in wenigen Monaten. Dieser Artikel ist Teil unserer Serie zu unserer Regulatory Transformation Capability (RTC), zeigt den Anwendungsbereich, die konkreten Meldefristen und wie Hersteller ihre Prozesse aufbauen, ohne dass die regulatorische Vorbereitung selbst zum Projekt wird.
Anwendungsbereich: Wer ist vom Cyber Resilience Act der EU betroffen?
Der CRA (link) gilt für alle Produkte mit digitalen Elementen, die auf dem EU-Markt in Verkehr gebracht werden. Dazu gehören sowohl Hardware als auch Software – von Smart-Home-Geräten über industrielle Steuerungen bis hin zu Apps und Computerprogrammen. Maßgeblich ist, dass das Produkt eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder einem Netzwerk ermöglichen kann.
Hersteller im Sinne der Verordnung sind die natürlichen oder juristischen Personen, die ein Produkt mit digitalen Elementen unter ihrem Namen oder ihrer Marke in Verkehr bringen. Auch Open-Source-Software-Stewardinnen und -Stewards tragen Berichtspflichten, sofern sie mit Produkten im Anwendungsbereich tätig werden.
Ausgenommen sind Produkte, die ausschließlich für Sicherheits- oder Verteidigungszwecke entwickelt wurden, sowie spezifisch für den Umgang mit klassifizierten Informationen konzipierte Systeme. Medizinprodukte unterliegen weiterhin der Medizinprodukateverordnung, Kraftfahrzeuge der Typgenehmigungsrichtlinie. Die Abgrenzung erfordert im Einzelfall eine sorgfältige Prüfung.
Ein entscheidender Punkt: Die Meldepflichten nach Artikel 14 gelten nicht nur für Produkte, die nach dem 11. Dezember 2027 in Verkehr gebracht werden. Artikel 69 Absatz 3 nimmt die Berichtspflicht ausdrücklich von der allgemeinen Übergangsregelung aus. Das bedeutet: Hersteller müssen auch für Produkte melden, die sie bereits vor Inkrafttreten der Vollanwendung auf den Markt gebracht haben. Diese rückwirkende Reichweite ist eine der am wenigsten diskutierten, aber praktisch bedeutsamsten Aspekte des CRA.
Was muss gemeldet werden?
Artikel 14 des CRA schafft zwei meldepflichtige Ereignisse. Beide Begriffe sind enger gefasst, als der allgemeine Begriff Sicherheitslücke.
Aktiv ausgenutzte Schwachstellen
ine Schwachstelle gilt als aktiv ausgenutzt, wenn zuverlässige Belege vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis der Systemsitzinhabenden in einem System ausgenutzt hat. Wer eine Schwachstelle entdeckt und patcht, bevor sie ausgenutzt wird, behandelt dies über den normalen Vulnerability-Handling-Prozess – nicht über den Meldekanal. Die Meldepflicht setzt den Moment der Erkenntnis voraus, nicht den der Entdeckung.
Schwerwiegende Sicherheitsvorfälle
Ein Vorfall gilt dann als schwerwiegend, wenn er die Fähigkeit des Produkts, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen zu schützen, negativ beeinträchtigt hat oder beeinträchtigen kann. Die Kriterien stehen in Artikel 14 Absatz 5. Sie beziehen sich auf die Anzahl der betroffenen Nutzerinnen und Nutzer, die Art und den Umfang der betroffenen Daten, die Fähigkeit, den Vorfall selbstständig zu beheben, und die zeitliche Dauer der Beeinträchtigung.
Aber: Nicht jede Sicherheitslücke ist meldepflichtig. Routine-Bugs, die nicht aktiv ausgenutzt werden, oder Vorfälle ohne signifikante Auswirkung fallen nicht unter Artikel 14. Der Gesetzgeber hat bewusst eine Schwelle gezogen.
Die drei Fristen des EU Cyber Resilience Act
Ab dem 11. September 2026 gilt ein gestaffeltes Meldesystem, gemessen ab dem Zeitpunkt, zu dem der Hersteller vom Ereignis Kenntnis erlangt. Drei Stufen sind vorgeschrieben.
Erstmeldung (Early Warning) – innerhalb von 24 Stunden.
Die erste Nachricht muss unverzüglich erfolgen und eine erste Einschätzung des Vorfalls oder der Schwachstelle enthalten. Bei Sicherheitsvorfällen ist außerdem anzugeben, ob der Vorfall mutmaßlich auf rechtswidrige oder böswillige Handlungen zurückzuführen ist. Diese Frist ist die kritischste: Sie beginnt im Moment der Wissensentstehung, auch wenn noch keine vollständige Analyse vorliegt.
Vollständige Meldung – innerhalb von 72 Stunden.
Die zweite Mitteilung enthält eine detailliertere Beschreibung der Art der Schwachstelle oder des Vorfalls, eine erste Einschätzung der Schwere, sowie die ergriffenen oder von den Nutzerinnen und Nutzern zu ergreifenden Korrektur- oder Minderungsmaßnahmen.
Abschlussbericht. Bei aktiv ausgenutzten Schwachstellen ist er spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme einzureichen. Bei schwerwiegenden Sicherheitsvorfällen ist er innerhalb eines Monats nach der 72-Stunden-Meldung fällig und umfasst die vollständige Beschreibung, Schweregrad, Auswirkung und angewendete Behebung.
Ab wann zählen die Fristen?
Die Fristen beginnen mit dem Zeitpunkt der Kenntnisnahme durch den Hersteller, nicht mit dem Zeitpunkt der technischen Identifikation oder der Freigabe eines Patches.
Wo werden Meldungen eingereicht?
Die Meldungen erfolgen über die CRA Single Reporting Platform (SRP), die von ENISA, der Europäischen Agentur für Cybersicherheit, eingerichtet und betrieben wird. Die Plattform ist seit dem 11. September 2026 betriebsbereit.
Link zur Plattform (klick!)
Hersteller reichen ihre Meldung einmalig über die SRP ein. Die Information geht an das CSIRT (Computer Security Incident Response Team) des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat, und an ENISA. Das empfangene CSIRT teilt die Meldung daraufhin ohne Verzögerung mit allen anderen CSIRTs mit, in deren Hoheitsgebiet das Produkt in Verkehr gebracht wurde. In außergewöhnlichen Fällen und auf begründeten Cybersicherheitsgründen kann das CSIRT die Weitergabe verzögern; die Kommission hat dazu eine Delegierte Verordnung 2026/881 im Dezember 2025 erlassen. (Link)
Vulnerability-Handling: Vom Prozess zur Routine in der Governance
Die Meldepflichten sind nur ein Teil dessen, was der CRA von Herstellern erwartet. Ein tragfähiges Vulnerability-Handling ist die Grundvoraussetzung, um den Meldefristen überhaupt gerecht werden zu können. Artikel 8 und Teil II von Annex I der Verordnung verlangen einen durchgängigen Lebenszyklus-Ansatz.
Security by Design
Hersteller müssen bei der Planung, den Entwurf, die Entwicklung, Produktion, Lieferung und Wartung ihrer Produkte eine Cybersecurity-Risikobewertung durchführen und deren Ergebnis in allen Phasen berücksichtigen. Das Produkt muss so konzipiert werden, dass beim Inverkehrbringen keine Schwachstellen mit bekannter Ausnutzbarkeit vorhanden sind.
Support Period
Hersteller müssen einen Unterstützungszeitraum festlegen, während dessen sie Sicherheitsupdates bereitstellen. Dieser Zeitraum muss der erwarteten Nutzungsdauer des Produkts entsprechen und mindestens fünf Jahre ab dem Inverkehrbringen betragen, sofern die erwartete Nutzung kürzer ist. Während der gesamten Support Period müssen Hersteller die Sicherheit des Produkts überwachen und Schwachstellen wirksam bearbeiten.
Software Bill of Materials (SBOM)
Hersteller müssen eine strukturierte Inventarisierung aller Softwarekomponenten und Abhängigkeiten ihres Produkts führen. Die SBOM ist nicht nur eine technische Dokumentationspflicht, sondern eine Voraussetzung dafür, dass Hersteller bei einem Sicherheitsvorfall schnell einschätzen können, welche Komponenten betroffen sind und welche Korrekturmaßnahmen erforderlich sind.
Coordinated Vulnerability Disclosure (CVD)
Hersteller müssen eine Richtlinie für den koordinierten Umgang mit gemeldeten Schwachstellen etablieren und einen klar sichtbaren Meldekanal bereitstellen, über den externe Forschende, Kundinnen und Kunden Sicherheitslücken melden können.
Sicherheitsupdates
Sobald eine Korrektur verfügbar ist, müssen Hersteller diese unverzüglich und standardmäßig kostenlos verbreiten. Jeder Update muss für mindestens zehn Jahre nach seiner Bereitstellung oder für den Rest der Support Period – je nachdem, welcher Zeitraum länger ist – verfügbar bleiben. Hersteller müssen zudem Informationen über behobene Schwachstellen veröffentlichen, sobald ein Update verfügbar ist, mit eingeschränkter Verzögerung nur dann, wenn dies aus Sicherheitsgründen gerechtfertigt ist.
Wie Hersteller ihre Compliance aufsetzen können
Die Meldepflichten seit September 2026 treffen manche Hersteller in eine Situation, in der sie Vulnerability-Management bislang eher ad hoc betrieben haben. Das erfordert keine komplette Neustrukturierung, sondern präzise Erweiterungen bestehender Prozesse.
Eindeutige und bekannte Meldewege
Eine interne Ablaufrichtlinie, die definiert, wer ein potenziell meldepflichtiges Ereignis erkennt, wer die Meldefristen überwacht und wer die SRP-Meldung verfasst und einreicht, ist der dringendste Schritt. Diese Richtlinie muss die 24-Stunden-Frist als absolute Obergrenze behandeln, auch wenn noch keine vollständige Analyse vorliegt.
SRP-Zugang sicherstellen
Hersteller müssen sich auf der CRA Single Reporting Platform registrieren, bevor die erste Meldung ansteht. ENISA bietet Anleitungen und Schulungsmaterialien an. Der Registrierungsprozess sollte nicht verschoben werden.
Vorhandenes Inventar der Produktlandschaft
Für die Meldepflicht sind alle Produkte mit digitalen Elementen relevant, die auf dem EU-Markt verkauft werden – nicht nur die Neuentwicklungen. Eine kurze Inventarisierung, welche Produkte in welche Kategorien fallen und welche Support Period gelten, schafft die Grundlage für eine priorisierte Vorbereitung.
Aktuelle Software Bill of Material (SBOM) vorhalten
Ohne eine aktuelle Bestandsliste aller Softwarekomponenten ist weder eine fundierte Risikobewertung noch eine zuverlässige Meldepflicht möglich. Die SBOM-Pflicht ist also kein reines Dokumentationsprojekt, sondern eine Voraussetzung für das gesamte nachgelagerte Reporting.
Wichtig: Der CRA verlangt keine komplette Neuschreibung der Security-Prozesse. Bestehende Prozesse müssen die spezifischen Meldefristen und Dokumentationspflichten abbilden. Klare Zuständigkeit, definierte Fristen und ein funktionierender Meldekanal reichen aus, um die regulatorische Vorbereitung in den regulären Produktlebenszyklus zu integrieren. Die neuen Verpflichtungen können z.B. in Ihr bestehendes Governance Framework oder Informationssicherheitssystem (ISMS) integriert werden, sprechen Sie uns hierzu gerne an.