CRA-Meldepflicht: Warum Hersteller nicht bis 2027 warten können

Eine Schwachstelle wird aktiv ausgenutzt. Euer Produkt könnte betroffen sein. Während die Entwicklung die Versionen prüft, sucht jemand den Meldeweg. Wer entscheidet jetzt, ob und was gemeldet werden muss?

Für betroffene Hersteller ist diese Frage bereits heute relevant: Die Meldepflichten nach Artikel 14 des Cyber Resilience Act (CRA) gelten seit dem 11. September 2026. Die späteren Hauptanforderungen ab Dezember 2027 sind kein Aufschub für diesen Teil. Das erklärt die Europäische Kommission auf ihrer Informationsseite zu den Meldepflichten.

Welche CRA-Meldepflicht gilt bereits?

Artikel 14 betrifft Hersteller von Produkten mit digitalen Elementen im Anwendungsbereich des CRA. Zu melden sind aktiv ausgenutzte Schwachstellen in diesen Produkten und schwere Sicherheitsvorfälle mit Auswirkungen auf deren Sicherheit. Nicht jede Schwachstelle und nicht jeder IT-Ausfall löst automatisch dieselbe Meldung aus.

Die ENISA-FAQ vom 15. Oktober unterscheidet außerdem die Adressaten: Die entsprechenden Pflichten für Open-Source-Software-Stewards nach Artikel 24 Absatz 3 gelten erst ab 11. Dezember 2027. Ein Hersteller ist nicht einfach mit einem Open-Source-Projekt oder dessen Mitwirkenden gleichzusetzen.

Prüfe deshalb zuerst Produkt, eigene Rolle und konkreten Sachverhalt. Die Frage ist nicht nur, ob dein Unternehmen allgemein unter NIS2 fällt.

Noch unsicher beim Anwendungsbereich? Unser interaktiver CRA-Betroffenheitscheck führt dich durch Produktbezug, Bereitstellung und eigene Rolle – mit einer eigenen Verzweigung für Cloud-Dienste.

24 Stunden, 72 Stunden – und danach?

Die Kommission nennt für die Frühwarnung 24 Stunden ab Kenntnis, für die anschließende Meldung 72 Stunden. Beim Abschlussbericht unterscheiden sich die beiden Fälle:

• Bei einer aktiv ausgenutzten Schwachstelle: spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme.
• Bei einem schweren Sicherheitsvorfall: innerhalb eines Monats nach der 72-Stunden-Meldung.

Diese Übersicht zeigt die zeitliche Struktur. Welche Informationen erforderlich sind und wann Kenntnis vorliegt, muss anhand des jeweiligen Sachverhalts bewertet werden. Die ENISA-FAQ verweist dafür auf die Kommissionsleitlinien und erklärt die unterschiedlichen Felder der Meldestufen. Ein zunächst unvollständiges Lagebild ist kein Grund, den internen Eingang eines Hinweises unsichtbar zu lassen.

Vor dem Portal braucht ihr einen Entscheidungsweg

Die Single Reporting Platform (SRP) ist seit dem 11. September 2026 in Betrieb. Sie bündelt die Übermittlung an die zuständigen Stellen. Sie nimmt eure Meldung entgegen – die interne Bewertung erledigt sie nicht.

Für den eigenen Ablauf hilft ein durchgespielter Fall. Beispiel: Ein Hinweis betrifft eine Bibliothek, die in mehreren ausgelieferten Produktversionen verwendet wird. Noch ist unklar, welche Version erreichbar ist und ob die gemeldete Ausnutzung auch euer Produkt betrifft.

Das ist unsere organisatorische Arbeitshilfe, keine amtliche Checkliste. Ihr könnt damit prüfen, ob die Übergaben funktionieren. Wer nur den Portal-Link verteilt, hat weder die Produktzuordnung noch eine belastbare Entscheidung organisiert.

Was bei der SRP praktisch wichtig ist

Die aktuelle ENISA-FAQ beschreibt Meldungen durch Assigned Representatives, also zugeordnete Vertreter des Herstellers. Sie können Meldungen im Rahmen ihrer Berechtigungen bearbeiten. Ein wichtiger Übergabepunkt: Entwürfe sind laut FAQ im individuellen Konto gespeichert und für andere Vertreter nicht sichtbar. Eine Vertretung sollte deshalb nicht erst im laufenden Vorfall feststellen, wo der Bearbeitungsstand liegt.

ENISA empfiehlt zugleich, die Zuordnung und Validierung für die SRP erst dann anzustoßen, wenn eine Meldung ansteht; ein aktives EU-Login-Konto erleichtert den Einstieg. Organisatorische Vorbereitung bedeutet daher nicht, entgegen dieser Empfehlung vorsorglich jede Herstellerzuordnung im Portal anzulegen. Klärt zunächst Zuständigkeit, EU Login und den internen Ablauf.

Eine direkte Meldeschnittstelle solltet ihr nicht voraussetzen: Für die erste SRP-Version nennt ENISA keine API. Interne Workflows lassen sich vorbereiten; die behördliche Übermittlung bleibt nach dem beschriebenen Stand ein Schritt über die Plattformoberfläche.

CRA, NIS2 und DSGVO getrennt beurteilen

Ein Ereignis kann mehrere Prüfungen auslösen: Produktsicherheit nach CRA, die Betroffenheit einer Einrichtung nach NIS2 und eine mögliche Verletzung des Schutzes personenbezogener Daten nach DSGVO. Eine gemeinsame interne Vorfallsakte kann die Fakten zusammenhalten. Sie macht aus diesen unterschiedlichen Pflichten aber keine einheitliche Meldung.

Für Rollen, Lagebild und Nachbereitung findest du den ausführlicheren Ablauf im Leitfaden zum Vorfallmanagement. Der CRA-Beitrag konzentriert sich auf den Produktbezug und die Übergabe in den Meldeprozess.

Der nächste sinnvolle Test

Nehmt einen fiktiven Produkthinweis und verfolgt ihn bis zur Entscheidung: Wer kennt die betroffenen Versionen? Wer hält die offenen Fragen zusammen? Wer übernimmt bei Abwesenheit? Wo wird die Begründung dokumentiert?

Der Test ist bestanden, wenn aus dem Hinweis ein nachvollziehbarer Vorgang mit Verantwortung und nächstem Schritt wird. Ein vorhandener Portalzugang allein beantwortet diese Fragen nicht.