Seit dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act (CRA) unmittelbar. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden. Damit entsteht vor dem allgemeinen Beginn der wesentlichen CRA-Pflichten am 11. Dezember 2027 ein operativer Herstellerprozess mit engen Fristen, produktbezogener Bewertung und verbindlicher Behördenkommunikation.
Im Mittelpunkt steht nicht eine allgemeine Incident-Meldung für Unternehmen, sondern die Sicherheit des vermarkteten Produkts. Für Organisationen, die zugleich als wesentliche oder wichtige Einrichtung in den Anwendungsbereich von NIS2 fallen, können bei demselben technischen Ereignis zusätzlich NIS2-Pflichten relevant sein. Die Fristen ähneln sich, die rechtlichen Auslöser und Prüfungen sind jedoch nicht identisch.
Warum der 11. September 2026 für Hersteller ein operativer Stichtag ist
Die Verordnung (EU) 2024/2847 verpflichtet Hersteller seit dem 11. September 2026 zur Meldung bestimmter Sicherheitsereignisse. Die Europäische Kommission weist darauf hin, dass die Meldepflichten nach Artikel 14 vorgezogen gelten; sie erfassen auch CRA-erfasste Produkte, die bereits vor dem 11. Dezember 2027 auf dem Markt bereitgestellt wurden. Entscheidend ist, wann der Hersteller Kenntnis von der aktiven Ausnutzung oder dem schweren Sicherheitsvorfall erlangt.
Die Pflicht betrifft nicht jeden Sicherheitsbefund. Sie setzt entweder eine aktiv ausgenutzte Schwachstelle oder einen schweren Sicherheitsvorfall voraus. Hersteller müssen daneben betroffene Nutzer und, soweit angemessen, alle Nutzer informieren sowie erforderliche Korrektur- und Minderungsmaßnahmen kommunizieren. Soweit angemessen, soll die Information strukturiert und maschinenlesbar erfolgen.
Die zwei CRA-Auslöser: Exploit-Evidenz oder schwerer Produktvorfall
Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Belege bestehen, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des Systeminhabers ausgenutzt hat. Das bloße Vorliegen einer CVE, eines Forschungshinweises oder einer theoretisch ausnutzbaren Schwachstelle genügt daher nicht. Maßgeblich ist die Kenntnis des Herstellers von aktiver Ausnutzung.
Ein schwerer Sicherheitsvorfall ist produktbezogen zu beurteilen. Er liegt vor, wenn die Fähigkeit des Produkts beeinträchtigt wird oder beeinträchtigt werden kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Gleiches gilt, wenn Schadcode in das Produkt oder in Netz- und Informationssysteme eines Produktnutzers eingebracht oder ausgeführt wurde oder werden kann. Die gesetzlichen Tatbestände und Meldeinhalte ergeben sich aus Artikel 14 CRA.
Diese Einordnung verlangt eine belastbare Erstbewertung. PSIRT, SOC, Support, Vulnerability-Disclosure-Kanäle, Threat Intelligence und Komponentenlieferanten müssen Signale deshalb in einer gemeinsamen produktbezogenen Triage zusammenführen. Besonders wichtig ist die Dokumentation der Exploit-Evidenz, der betroffenen Produktversionen und der tatsächlich verfügbaren Minderungsmaßnahmen.
24 Stunden, 72 Stunden, Abschlussbericht: der CRA-Meldefahrplan
Für beide Meldekategorien beginnt mit der Kenntniserlangung ein dreistufiger Ablauf. Zunächst ist unverzüglich, spätestens binnen 24 Stunden, eine Frühwarnung abzugeben. Es folgt unverzüglich, spätestens binnen 72 Stunden, eine Meldung. Der Abschlussbericht ist bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Minderungsmaßnahme fällig. Bei schweren Sicherheitsvorfällen beträgt die Frist einen Monat ab der 72-Stunden-Meldung.
Die Inhalte unterscheiden sich nach Fallgruppe. Bei aktiv ausgenutzten Schwachstellen soll die Frühwarnung gegebenenfalls die Mitgliedstaaten nennen, in denen das Produkt bereitgestellt wurde. Die Folgemeldung umfasst unter anderem Angaben zum Produkt, zur Art von Exploit und Schwachstelle sowie zu ergriffenen oder für Nutzer verfügbaren Abhilfe- und Minderungsmaßnahmen. Bei schweren Sicherheitsvorfällen muss die Frühwarnung mindestens erkennen lassen, ob ein rechtswidriger oder böswilliger Auslöser vermutet wird. Die 72-Stunden-Meldung enthält insbesondere Art des Vorfalls, erste Bewertung sowie Maßnahmen für Hersteller und Nutzer.
Ein 24-Stunden-Runbook sollte daher Zeitstempel der Kenntniserlangung, Produkt und Versionen, Qualität der Exploit-Evidenz, Verbreitungsstaaten, erste Eindämmung, Nutzermaßnahmen, Freigaben und Übermittlungsnachweise erfassen. Eine abschließende forensische Bewertung kann in dieser Zeit regelmäßig noch nicht vorliegen. Das entbindet nicht von der fristgerechten Frühwarnung.
Einmal über die SRP melden – Zuständigkeit vorher klären
Die Meldung erfolgt einmalig über die von ENISA betriebene CRA Single Reporting Platform (SRP). Sie wird an den koordinierenden CSIRT des Mitgliedstaats der EU-Hauptniederlassung übermittelt und ist gleichzeitig für ENISA zugänglich. Der empfangende CSIRT verteilt die Information grundsätzlich unverzüglich an relevante CSIRTs der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde. Die Plattform ist seit dem 11. September 2026 betriebsbereit; nähere Hinweise veröffentlicht ENISA zum Start der SRP.
Als Hauptniederlassung gilt grundsätzlich der Mitgliedstaat, in dem Entscheidungen über die Cybersicherheit der Produkte überwiegend getroffen werden. Ist dies nicht bestimmbar, kommt die EU-Niederlassung mit den meisten Beschäftigten in Betracht. Für Hersteller ohne EU-Hauptniederlassung enthält der CRA weitere Zuordnungsregeln. Diese Festlegung gehört in die Vorsorgeplanung, nicht in die erste Stunde eines Vorfalls.
Praktisch relevant sind auch die Zugriffsbedingungen: Assigned Representatives benötigen ein persönliches EU-Login-Konto mit Mehrfaktor-Authentisierung. Ein Hersteller kann einen Primary sowie bis zu 20 Secondary Assigned Representatives benennen. Die SRP stellt in ihrer ersten Ausbaustufe keine API bereit; die Einreichung erfolgt über die Plattformoberfläche. Unternehmen benötigen daher getestete Vertretungsregeln und ein manuelles Browser-Runbook. Die ENISA-FAQ zur SRP erläutert diese Rahmenbedingungen.
CRA und NIS2: ähnliche Uhr, unterschiedliche Meldeentscheidung
NIS2 betrifft wesentliche und wichtige Einrichtungen und knüpft an erhebliche Vorfälle mit signifikanter Auswirkung auf die Erbringung ihrer Dienste an. Ein solcher Vorfall kann etwa schwere Betriebsstörungen, finanzielle Verluste oder erhebliche materielle oder immaterielle Schäden verursachen. Artikel 23 der NIS2-Richtlinie sieht ebenfalls grundsätzlich Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats vor.
Gleiche technische Fakten können folglich zwei regulatorische Bewertungen auslösen. Der CRA fragt: Ist die Sicherheit eines Produkts mit digitalen Elementen durch eine aktiv ausgenutzte Schwachstelle oder einen schweren Vorfall betroffen? NIS2 fragt: Ist eine regulierte Einrichtung von einem erheblichen Vorfall in ihrer Dienstleistungserbringung betroffen? Daraus folgt: Ein gemeinsames Lagebild ist sinnvoll, aber CRA- und NIS2-Triage müssen getrennt dokumentiert werden. Bei erfüllten Tatbeständen können parallele Meldevorgänge erforderlich sein. Empfänger und Detailprozesse unter NIS2 richten sich zudem nach der jeweiligen nationalen Umsetzung.
Gemeinsames Lagebild: klare Rollen und belastbare Nachweise
Ein gemeinsames Incident-Fact-Pack verhindert widersprüchliche Bewertungen, ohne die getrennten Rechtsprüfungen zu vermischen. Es sollte technische Evidenz, betroffene Produkte und Komponenten, Versionen und Konfigurationen, Kundenbereitstellungen, Indikatoren einer aktiven Ausnutzung, Patch- und Workaround-Status sowie den Kommunikationsstand enthalten.
- PSIRT verantwortet Produktbetroffenheit, Schwachstellenbewertung, Komponentenabgleich, Advisory und technische Meldeinhalte.
- SOC und Incident Response liefern Telemetrie, Exploit-Hinweise, Forensik, Eindämmung und Wiederherstellung.
- Produktmanagement priorisiert Releases, Supportmaßnahmen und Kundenkommunikation.
- Legal und Compliance steuern die regulatorische Prüfung, Freigaben und konsistente Behördenkommunikation.
- Geschäftsleitung sollte Eskalationsschwellen und Entscheidungsrechte für fristkritische Meldungen vorab festlegen.
Ein vollständiger Audit Trail umfasst insbesondere Kenntniszeitpunkt, Quellen und Qualität der Evidenz, Entscheidungsprotokolle, Fassungen der SRP-Meldung, Nutzerhinweise, Kommunikation mit CSIRT und ENISA sowie Abschluss- und Lessons-Learned-Unterlagen.
Drittkomponenten: vom Lieferantenhinweis zur Produktbewertung
Bei Drittkomponenten reicht ein SBOM- oder Komponentenverzeichnis allein nicht aus. Erforderlich ist der Abgleich mit den tatsächlich ausgelieferten Produktversionen, Konfigurationen, Supportständen, Kundenbereitstellungen, Exploit-Informationen und verfügbaren Maßnahmen. Nur so lässt sich beurteilen, ob eine aktiv ausgenutzte Komponentenschwachstelle im eigenen Produkt enthalten, ausnutzbar und für die CRA-Meldung relevant ist.
Lieferanteninformationen sollten deshalb außerhalb der Geschäftszeiten erreichbar sein und Hinweise zu betroffenen Versionen, Exploit-Evidenz, Patches und Minderungsmaßnahmen abdecken. Vertragliche und operative Eskalationswege sind eine praktische Vorsorgemaßnahme; sie sollten nicht pauschal als bereits unmittelbar geltende CRA-Vertragspflicht verstanden werden.
Fazit: Meldefähigkeit ist ein Produktprozess
Hersteller sollten Artikel 14 CRA als dauerhaft auslösbaren Produkt-Sicherheitsprozess behandeln. Priorität haben ein 24-Stunden-Runbook, SRP-Zugänge und Vertretungen, eine geklärte CSIRT-Zuordnung, ein gemeinsames Faktenmodell sowie eine getrennte CRA- und NIS2-Entscheidung. Die am 27. Juli 2026 veröffentlichten Leitlinien der Europäischen Kommission können die operative Auslegung unterstützen, sind jedoch nicht rechtsverbindlich und ersetzen weder die Verordnung noch die Prüfung des konkreten Falls.