CRA Meldepflicht seit 11. September 2026: Was Hersteller jetzt operativ sicherstellen müssen

Der 11. September 2026 war die erste harte Frist des Cyber Resilience Act (CRA), die Hersteller digitaler Produkte unmittelbar trifft. Seitdem sind die Melde- und Berichtspflichten nach Art. 14 der Verordnung (EU) 2024/2847 verbindlich, während die vollen Produktanforderungen erst ab dem 11. Dezember 2027 gelten. Die Meldepflicht erfasst nach Art. 69 Abs. 3 auch Produkte, die schon vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Wer heute keine funktionierenden Meldeprozesse hat, kann die Fristen im Ernstfall kaum einhalten, auch wenn das Produkt selbst noch nicht CE-konform sein muss.

Dieser Artikel erklärt, welche Fristen gelten, was gemeldet werden muss, wie der Meldeweg über die ENISA Single Reporting Platform funktioniert und welche organisatorischen Vorbereitungen Hersteller konkret anstoßen sollten.

Was seit 11. September 2026 gemeldet werden muss

Die Meldepflicht erfasst zwei Kategorien von Ereignissen, die strikt zu unterscheiden sind:

• Aktiv ausgenutzte Schwachstellen: Sobald ein Hersteller Kenntnis davon erlangt, dass eine Schwachstelle in seinem Produkt mit digitalen Elementen aktiv von Angreifern ausgenutzt wird, greift die Meldepflicht - unabhängig davon, ob bereits ein Patch verfügbar ist.
• Schwerwiegende Sicherheitsvorfälle: Vorfälle, die sich auf die Sicherheit des Produkts auswirken und nach Art. 14 Abs. 5 als schwerwiegend einzustufen sind, lösen ebenfalls die Meldekette aus.

Die Fristen laufen ab der Kenntnisnahme durch den Hersteller. Wann der Angriff stattfand oder wann Dritte ihn entdeckt haben, ist für den Fristbeginn ohne Bedeutung. Diese Abgrenzung hat praktische Konsequenzen für interne Monitoring- und Triage-Prozesse.

Die drei Meldestufen im Detail

Das CRA-Melderegime folgt einem gestuften Berichtsmodell, das operativ präzise umgesetzt werden muss:

Ein vermeidbarer Fehler in Compliance-Dokumenten: Der Abschlussbericht wird pauschal mit "14 Tagen" beschrieben. Korrekt ist die Differenzierung: Für Schwachstellen gilt die 14-Tage-Frist ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, für schwerwiegende Vorfälle gilt ein Monat ab der 72-Stunden-Meldung. Diese Unterscheidung sollte sich in internen Prozessdokumenten und Runbooks widerspiegeln.

Der Meldeweg: ENISA Single Reporting Platform

Alle Meldungen laufen über die einheitliche Meldeplattform (Single Reporting Platform, SRP), die die EU-Agentur für Cybersicherheit ENISA nach Art. 16 einrichtet und betreibt. Die Meldung geht über den Endpunkt des als Koordinator benannten CSIRT des Mitgliedstaats Ihrer Hauptniederlassung und ist gleichzeitig für die ENISA zugänglich (Art. 14 Abs. 7).

Das CSIRT leitet die Meldung an die CSIRTs der Mitgliedstaaten weiter, in denen das Produkt bereitgestellt wurde; nur in eng begrenzten Fällen kann es die Weiterleitung aufschieben (Art. 16 Abs. 2). Für die CRA-Meldung genügt dieser eine Weg; Meldepflichten aus anderen Regelwerken wie NIS2 bleiben unberührt.

Hinweis zur Meldeplattform: Hersteller sollten den offiziellen ENISA-Kommunikationskanälen folgen, den Zugang zur Plattform vorab einrichten und intern testen. Ein Onboarding erst im Meldefall ist bei einem 24-Stunden-Eskalationspfad kein realistisches Szenario.

Was operativ vorbereitet werden muss: PSIRT-Aufbau

Eine Meldung in 24 Stunden abzusetzen ist kein administrativer Akt, der sich spontan organisieren lässt. Dahinter steht ein funktionierender Product Security Incident Response-Prozess (PSIRT) - oder zumindest eine schlanke, für das Unternehmen passende Entsprechung davon. Für Hersteller, die noch keine strukturierten Vulnerability-Management-Prozesse betreiben, ist der PSIRT-Aufbau ein zentraler Baustein der CRA-Vorbereitung.

Detektionsfähigkeit: Wann gilt die Uhr als gestartet?

Die 24-Stunden-Frist beginnt mit Kenntnisnahme durch den Hersteller. Damit stellt sich unmittelbar die Frage: Über welche Kanäle erhält der Hersteller Kenntnis? Typische Quellen sind interne Sicherheitsüberwachung, Hinweise von Sicherheitsforschern (Responsible Disclosure), Kundenberichte und Threat-Intelligence-Feeds. Ohne definierte Eingangskanäle und eine verantwortliche Rolle, die Meldungen entgegennimmt und bewertet, ist die Frist faktisch nicht einzuhalten.

Empfehlenswert ist eine eigene security@-Adresse oder ein vergleichbarer Meldekanal. Ab dem 11. Dezember 2027 verlangt der CRA ausdrücklich eine Kontaktadresse für Schwachstellenmeldungen und eine zentrale Anlaufstelle (Art. 13 Abs. 17, Anhang II Nr. 2).

Triage und Klassifikation in unter 24 Stunden

Nicht jede gemeldete Schwachstelle oder jeder Sicherheitshinweis löst eine CRA-Meldepflicht aus. Meldepflichtig wird es erst, wenn eine Schwachstelle aktiv ausgenutzt wird oder ein Vorfall als schwerwiegend einzustufen ist. Dieser Triage-Schritt muss unter Zeitdruck und mit klarer Rollenverantwortung funktionieren. Hilfreiche Struktur: ein einfaches Klassifikationsschema (Schwellenwerte, Checkliste) und eine Bereitschaftsregel, die außerhalb der Geschäftszeiten greift.

Meldeinhalte vorbereiten

Die 72-Stunden-Meldung enthält, soweit verfügbar, allgemeine Angaben, etwa zum Produkt, zur Art der Ausnutzung bzw. des Vorfalls (bei Vorfällen mit einer ersten Bewertung), zu ergriffenen Korrektur- oder Risikominderungsmaßnahmen und zu Maßnahmen, die Nutzer ergreifen können (Art. 14 Abs. 2 Buchst. b, Abs. 4 Buchst. b). Vorbereitete Meldevorlagen für typische Szenarien helfen, diese Angaben unter Zeitdruck zusammenzutragen.

SBOM als Grundlage für schnelle Reaktion

Eine vollständige Software Bill of Materials (SBOM) ist eine eigenständige CRA-Pflicht und zugleich die operative Voraussetzung dafür, im Ernstfall schnell zu wissen, welche Produktversionen von einer Schwachstelle betroffen sind und welche Kunden informiert werden müssen. Wer seit dem 11. September 2026 meldepflichtig ist, aber keine aktuelle SBOM führt, hat ein strukturelles Problem bei der Reaktionsgeschwindigkeit.

Wer ist meldepflichtig?

Meldepflichtig sind Hersteller von Produkten mit digitalen Elementen im Sinne der Verordnung - also natürliche oder juristische Personen, die ein solches Produkt entwickeln oder entwickeln lassen und es unter eigenem Namen oder eigener Marke auf dem EU-Markt bereitstellen. Das gilt auch für kostenlose Produkte und auch dann, wenn die Entwicklung an Dritte ausgelagert ist.

Einführer (Importeure) und Händler haben im CRA andere Rollen und primär andere Pflichten; die Meldepflicht nach Art. 14 adressiert direkt die Herstellerrolle. Ob Ihr Produkt unter den CRA fällt, lässt sich mit dem interaktiven Betroffenheits-Check klären. Einen strukturierten Überblick über alle Rollen und Ausnahmen bietet der Artikel Cyber Resilience Act - bin ich betroffen?

Fristen in der Zusammenschau: Was wann zu tun ist

Eine pragmatische Sicht auf die Reihenfolge ab heute, da die Meldepflicht seit September 2026 gilt:

• Sofort: Prüfen, ob und für welche Produkte eine Meldepflicht besteht (Betroffenheitsanalyse). Bin ich überhaupt betroffen?
• Ebenfalls sofort, falls noch offen: Vulnerability-Disclosure-Kanal einrichten, interne Triage-Prozesse definieren, Verantwortlichkeiten festlegen, Melde-Templates erstellen, Zugang zur Meldeplattform einrichten und testen.
• Parallel (bis 11.12.2027): SBOM aufbauen, technische Dokumentation, Security-by-Design in den Entwicklungszyklus integrieren, CE-Konformitätsbewertung vorbereiten. Details zum Gesamtüberblick der CRA-Anforderungen und Produktpflichten.

Für mittelständische Hersteller mit begrenzten Kapazitäten lautet die Priorisierungslogik klar: Meldeprozesse zuerst, weil diese Pflicht bereits gilt und weil ein PSIRT-Prozess Zeit im Betrieb braucht, bis er zuverlässig läuft. Den detaillierten Umsetzungsplan für KMU finden Sie unter Cyber Resilience Act Mittelstand: Priorisierter Umsetzungsplan.

Unterstützung beim PSIRT-Aufbau und der Meldeprozess-Vorbereitung

Blackfort Technology begleitet Hersteller von Produkten mit digitalen Elementen bei der operativen CRA-Vorbereitung: von der initialen Betroffenheitsanalyse über den Aufbau schlanker PSIRT-Prozesse bis zur Integration in bestehende ISMS-Strukturen. Blackfort Technology bringt dabei praktische Umsetzungserfahrung aus PKI-, DORA-, NIS2- und SBOM-/Schwachstellenmanagement-Projekten ein.