CRA Meldepflicht ab 11. September 2026: Was Hersteller jetzt operativ vorbereiten müssen

Der 11. September 2026 ist die erste harte Frist des Cyber Resilience Act (CRA), die Hersteller digitaler Produkte unmittelbar trifft — und sie rückt schneller näher, als viele Compliance-Roadmaps einplanen. Während die vollen Produktanforderungen erst ab dem 11. Dezember 2027 gelten, sind die Melde- und Berichtspflichten nach Art. 14 der Verordnung (EU) 2024/2847 bereits über ein Jahr früher verbindlich. Wer an diesem Datum keine funktionierenden Prozesse vorweisen kann, riskiert regulatorische Konsequenzen — ohne dass das Produkt selbst schon 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 ab 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.
• Schwere Sicherheitsvorfälle ("severe incidents"): Vorfälle, die Auswirkungen auf die Sicherheit des Produkts haben und als schwerwiegend einzustufen sind, lösen ebenfalls die Meldekette aus.

Entscheidend ist der Zeitpunkt der Kenntnisnahme durch den Hersteller — nicht der Zeitpunkt des tatsächlichen Angriffs oder der Entdeckung durch Dritte. Diese Abgrenzung hat praktische Konsequenzen für interne Monitoring- und Triage-Prozesse.

Die drei Meldefristen im Detail

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

Ein häufiger Fehler in frühen 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 der Korrekturmaßnahme, für schwere 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 CRA Single Reporting Platform (SRP), die von der EU-Agentur für Cybersicherheit ENISA betrieben wird. Das Prinzip: Hersteller melden einmal — die Plattform leitet die Information automatisch weiter an:

• das CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat,
• und — außer in begründeten Ausnahmefällen — parallel an ENISA.

Das empfangende CSIRT teilt relevante Meldeinformationen anschließend mit weiteren betroffenen CSIRTs innerhalb der EU. Hersteller müssen also keine Mehrfachmeldungen an verschiedene Behörden einreichen — die Einmalmeldung über die SRP genügt.

Wichtiger aktueller Hinweis (Stand Juli 2026): Die ENISA Single Reporting Platform war zum Redaktionszeitpunkt dieses Artikels noch nicht vollständig operativ. ENISA hat angekündigt, die Plattform rechtzeitig vor dem 11. September 2026 bereitzustellen. Hersteller sollten den offiziellen ENISA-Kommunikationskanälen folgen und ihre internen Testläufe frühzeitig einplanen — ein Onboarding in die Plattform wenige Tage vor der Frist ist kein realistisches Szenario bei einem 24-Stunden-Eskalationspfad.

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 typischerweise das aufwändigste operative Element 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 die Einrichtung einer dedizierten security@-Adresse oder eines vergleichbaren Vulnerability-Disclosure-Kanals — der CRA sieht dies implizit voraus, und gut aufgestellte Hersteller haben diesen Kanal öffentlich zugänglich.

Triage und Klassifikation in unter 24 Stunden

Nicht jede gemeldete Schwachstelle oder jeder Sicherheitshinweis löst eine CRA-Meldepflicht aus. Entscheidend ist, ob eine Schwachstelle aktiv ausgenutzt wird oder ob ein Vorfall als schwer 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

Für die 72-Stunden-Meldung sind inhaltlich u. a. Angaben zu den ergriffenen Korrektur- und Minderungsmaßnahmen erforderlich. Das bedeutet: innerhalb von drei Tagen muss nicht nur gemeldet, sondern auch bereits gehandelt worden sein — oder zumindest eine nachvollziehbare Sofortmaßnahme. Vorbereitete Meldeschablonen (Templates) für die häufigsten Szenarien reduzieren die Reaktionszeit erheblich.

SBOM als Grundlage für schnelle Reaktion

Eine vollständige Software Bill of Materials (SBOM) ist nicht nur eine eigenständige CRA-Pflicht — sie ist auch 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 zum 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.

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 den Vorbereitungshorizont bis September 2026:

• Sofort: Prüfen, ob und für welche Produkte eine Meldepflicht besteht (Betroffenheitsanalyse). Bin ich überhaupt betroffen?
• Bis Q3 2026: Vulnerability-Disclosure-Kanal einrichten, interne Triage-Prozesse definieren, Verantwortlichkeiten festlegen, Melde-Templates erstellen, SRP-Onboarding testen sobald verfügbar.
• 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 Frist ein Jahr früher kommt und weil ein funktionierender PSIRT-Prozess operativen Vorlauf von mindestens sechs Monaten braucht, um zuverlässig zu sein. 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. Christian Gebhardt, Geschäftsführer und Mitautor des ACS/BSI-Leitfadens zum Pentesting von LLMs sowie Mitglied der ACS-KI-Facharbeitsgruppe, bringt dabei praktische Umsetzungserfahrung aus PKI-, DORA-, NIS2- und SBOM/Schwachstellenmanagement-Projekten ein.