CRA-Meldepflichten ab September 2026: Haben Sie es im Blick?

17. Juni 2026

Viele Hersteller von Produkten mit digitalen Elementen richten ihre Vorbereitung auf den Cyber Resilience Act (CRA) weiterhin stark auf das Jahr 2027 aus. Dann greifen die umfassenden Sicherheitsanforderungen vollständig. Ein operativ kritischer Meilenstein liegt jedoch deutlich früher: Ab dem 11. September 2026 gelten bereits die Meldepflichten.

Phillip Ansorge, Managing Security Consultant bei der usd AG, begleitet Kunden bei der strukturierten Einordnung der CRA-Anforderungen. Seine Einschätzung: Häufig wird unterschätzt, welche organisatorischen und prozessualen Voraussetzungen bis September 2026 geschaffen werden müssen, um die geforderten Meldepflichten zuverlässig zu erfüllen.

Denn viele beschränken diese Anforderungen auf das reine Reporting. Tatsächlich gehen die im CRA geforderten Meldepflichten weit darüber hinaus. Die eigentliche Herausforderung liegt bereits in der Vorbereitung: Etwa bei der Frage, ob relevante Sicherheitsereignisse strukturiert erkannt, eingeordnet und fristgerecht intern eskaliert werden können.

Im diesem Blogpost ordnet Phillip Ansorge die Anforderungen zur Meldepflicht ein und zeigt, worauf es in der praktischen Umsetzung ankommt.

Wenn Sie sich vorab einen Überblick über die Grundlagen und den Geltungsbereich des CRA verschaffen möchten, finden Sie diese in unserem Beitrag „7 Fragen zum Cyber Resilience Act“.

Welche CRA-Anforderungen ab September 2026 konkret greifen

Ab dem 11. September 2026 müssen Hersteller Schwachstellen sowie Sicherheitsvorfälle melden, sobald sie davon Kenntnis erlangen. Nicht jede Schwachstelle und jeder Sicherheitsvorfall sind dabei meldepflichtig:

Meldepflichtig ist eine Schwachstelle, die aktiv ausgenutzt wird – also eine Sicherheitslücke mit nachweislich realen Angriffen, nicht nur theoretischer Ausnutzbarkeit. Reine Proof of Concepts oder Forschungsergebnisse genügen nicht. Entscheidend ist, dass eine tatsächliche Exploitation im eigenen Produkt vorliegt.

Meldepflichtig ist ein schwerwiegender Sicherheitsvorfall, wenn als Ereignis die Sicherheit eines Produkts beeinträchtigt ist oder beeinträchtigt werden kann – insbesondere in Hinblick auf Vertraulichkeit, Integrität, Verfügbarkeit oder Authentizität. Dazu gehören auch Sicherheitsvorfälle in der Herstellerumgebung, sofern sie sich direkt auf die Produktsicherheit auswirken.

Die Meldefristen sind in Artikel 14 des Cyber Resilience Act klar definiert:

  • Frühwarnmeldung innerhalb von 24 Stunden
  • Vollständige Meldung innerhalb von 72 Stunden
  • Abschlussbericht bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme, bei schwerwiegenden Vorfällen innerhalb eines Monats.

Die Meldung erfolgt über die Single Reporting Platform der ENISA (European Union Agency for Cybersecurity): ENISA Single Reporting Platform.

Die Herausforderung in der Praxis liegt dabei weniger im Melden selbst als in der belastbaren Bewertung konkreter Ereignisse unter Zeitdruck. Besonders bei der Frühwarnmeldung müssen Entscheidungen getroffen werden, obwohl die Informationslage noch nicht vollständig ist. Diese Einordnung gelingt nur, wenn Zuständigkeiten, Entscheidungswege und Bewertungslogiken im Vorfeld eindeutig definiert und erprobt sind.

Dabei ist zu berücksichtigen: Die Meldefristen gelten unabhängig von Wochenenden oder Feiertagen. Entscheidungs- und Meldeprozesse müssen daher so aufgesetzt sein, dass sie jederzeit greifen können.

Was die CRA-Meldepflicht organisatorisch bedeutet

In der Praxis zeigt sich, dass die Meldepflichten weniger durch einzelne Anforderungen geprägt sind, sondern durch das Zusammenspiel mehrerer Faktoren. Dies erfordert einen Perspektivwechsel: Security wird nicht mehr nur im IT-Betrieb verortet, sondern als Bestandteil des gesamten Produktlebenszyklus verstanden.

Vor diesem Hintergrund ergeben sich entscheidende Faktoren, die Hersteller frühzeitig adressieren sollten:

  • Produktsicherheit über den gesamten Lebenszyklus hinweg verankern: Sicherheit betrifft nicht nur den Betrieb, sondern auch Entwicklung, Wartung und Weiterentwicklung von Produkten.
  • Transparenz über Produkte und Abhängigkeiten schaffen: Für eine schnelle Einordnung ist ausschlaggebend, welches Produkt in welcher Version betroffen ist und welche Abhängigkeiten bestehen, etwa zu Drittanbietern oder Cloud Services.
  • Vulnerability Management konsequent auf Produkte ausrichten: Vorhandene Prozesse bilden häufig eine gute Grundlage. Dabei kommt es darauf an, dass sie im Produktkontext durchgängig greifen, ohne für jedes Produkt separate Meldeprozesse aufzubauen.
  • Meldeentscheidungen unter Zeitdruck treffen: Bewertungen erfolgen in der Praxis oft parallel zur Analyse. Klare Kriterien und abgestimmte Entscheidungswege schaffen hier Orientierung.
  • Kurze Fristen organisatorisch abbilden: Die vorgegebenen Zeitrahmen erfordern abgestimmte Abläufe zwischen mehreren Funktionen, die im Ereignisfall ineinandergreifen.

Ihr Fahrplan zur Vorbereitung der CRA-Meldeprozesse

Ein Blick auf die Timeline zeigt: Ihnen bleiben nur noch wenige Wochen, bis die Anforderungen in Kraft treten. Je nach Ausgangslage unterscheidet sich der Umfang der erforderlichen Maßnahmen deutlich.

Um eine belastbare Grundlage zu schaffen, sollten Sie bis September 2026 insbesondere folgende Fragestellungen intern klären:

  • Wer trifft im Ernstfall die Entscheidung über eine Meldung?
  • Nach welchen Kriterien wird bewertet, ob ein Vorfall meldepflichtig ist?
  • Welche Informationen müssen dafür vorliegen und wie wird bei unvollständiger Datenlage entschieden?
  • Ab wann gilt ein Ereignis als bekannt und wann beginnt die 24‑Stunden‑Frist?
  • Welche Produkte, Versionen und Abhängigkeiten sind im Scope?
  • Wer trägt jeweils die Verantwortung?

Ergänzend sollten Sie prüfen:

  • Sind die Wege zur Meldung, Entscheidungsprozesse und die Kommunikation unter Zeitdruck abgestimmt?
  • Wurden diese Abläufe bereits anhand realistischer Szenarien getestet?

Im Hinblick auf die Vorbereitung betont Phillip Ansorge:

„Viele dieser Punkte lassen sich nicht kurzfristig umsetzen. Umso wichtiger ist es, frühzeitig zu klären, wie mit konkreten Fällen umgegangen werden soll. In unseren Projekten zeigt sich: Wenn diese erste Einordnung gelingt, lassen sich auch enge Fristen im nächsten Schritt handhabbar umsetzen.“

Ausblick: CRA-Anforderungen bis Dezember 2027

Die CRA-Meldepflichten ab September 2026 markieren einen ersten Meilenstein. Bis Dezember 2027 kommen weitere Anforderungen hinzu, die sich vereinfacht in drei Bereiche einordnen lassen:

  • Sicherheit über den gesamten Produktlebenszyklus hinweg („Secure by Design“),
  • technische Dokumentation und Nachweisführung im Rahmen der Konformitätsbewertung
  • sowie der strukturierte Umgang mit Schwachstellen einschließlich koordinierter Meldungen.

Für Hersteller ist daher eine übergreifende Vorbereitung entscheidend. Wie bei den Meldepflichten gilt auch hier: Im Fokus steht die gezielte Weiterentwicklung vorhandener Strukturen. Während in einigen Fällen bereits belastbare Strukturen im Schwachstellen- und Incident Management bestehen, liegt der Fokus in anderen Konstellationen stärker auf Transparenz über Produktbestand, Abhängigkeiten und Entscheidungswege.

Dieses Bild bestätigt sich auch in der Praxis, wie Phillip Ansorge einordnet: „In unseren Projekten sehen wir, dass viele Hersteller bereits über tragfähige Strukturen und Prozesse verfügen, etwa aus IT-Sicherheitsstandards wie dem PCI Software Security Framework. Diese decken einige Teile der CRA-Anforderungen ab. Meist geht es daher nicht um einen kompletten Neuaufbau, sondern die fundierte Einordnung vorhandener Strukturen und das gezielte Schließen vorhandener Lücken. Genau hier schafft ein Scope-Workshop gefolgt von einer Gap-Analyse die notwendige Transparenz und bildet eine belastbare Grundlage für die weitere Umsetzung.“

Damit beantworten wir gemeinsam unter anderem die folgenden Fragen:

  • Welche Produkte sind betroffen?
  • Wo stehen wir heute im Hinblick auf die CRA-Anforderungen?
  • Welche Prozesse und Strukturen sind bereits vorhanden?
  • Wo besteht konkreter Handlungsbedarf?

Wir unterstützen Sie je nach Ausgangslage: von einer ersten Einordnung über die strukturierte Ableitung konkreter Maßnahmen oder der Weiterentwicklung bestehender Prozesse entlang des gesamten Produktlebenszyklus bis hin zum Konformitätsnachweis. Mehr dazu erfahren Sie hier.

Weitere Einblicke in die praktische Umsetzung gibt das Webinar von Phillip Ansorge „Cyber Resilience Act: Warum Risk Assessment jetzt den Takt vorgibt“ am 01.10.2026. Jetzt anmelden!


Zur Person: Phillip Ansorge

Phillip Ansorge ist Managing Security Consultant bei der usd AG. Er begleitet Hersteller bei der praxisnahen Umsetzung regulatorischer Anforderungen im Bereich Produkt- und Betriebssicherheit in komplexen Produktlandschaften und organisationsübergreifenden Strukturen. Sein Fokus liegt auf klaren Entscheidungswegen, belastbaren Meldeprozessen und nachvollziehbaren Sicherheitsentscheidungen.


Cyber Resilience Act: Das Wichtigste in Kürze

Für wen gilt der CRA?

Der CRA gilt für Produkte mit digitalen Elementen. Daraus ergeben sich Pflichten für Hersteller, die diese Produkte in der EU bereitstellen.

Ab wann gelten die CRA‑Meldepflichten?

Ab 11. September 2026.

Was muss gemeldet werden?

Aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle, sobald der Hersteller davon Kenntnis erlangt.

Welche Fristen gelten?

24 Stunden Frühwarnung, 72 Stunden vollständige Meldung, anschließender Abschlussbericht je nach Ereigniskategorie.

Über welche Plattform wird gemeldet?

Über die CRA Single Reporting Platform von ENISA.

Auch interessant:

Shadow AI: Wenn KI im Unternehmen zum blinden Fleck wird

Shadow AI: Wenn KI im Unternehmen zum blinden Fleck wird

Der Einsatz von Künstlicher Intelligenz (KI) ist längst zum festen Bestandteil des Arbeitsalltags geworden. Mitarbeiter*innen nutzen Tools wie ChatGPT, Claude oder Gemini, um schneller zu recherchieren, Dokumente zu erstellen, Code zu schreiben oder Daten auszuwerten....

mehr lesen

Kategorien

Kategorien