CRA-Meldepflicht ab September 2026: Was Hersteller jetzt vorbereiten müssen

Der Cyber Resilience Act (CRA) ist seit Dezember 2024 in Kraft, seine volle Anwendung folgt aber erst am 11. Dezember 2027. Dazwischen liegt ein Datum, das in vielen Produktteams noch unterschätzt wird: Am 11. September 2026 greift die Meldepflicht nach Artikel 14. Ab diesem Tag müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb enger Fristen an die Behörden melden. Die eigentliche Hürde ist dabei nicht der Meldetag selbst, sondern die Frage, ob ein Hersteller eine laufende Ausnutzung seines Produkts überhaupt rechtzeitig bemerkt.

Dieser Beitrag konzentriert sich bewusst auf die Meldepflicht und ihre praktische Umsetzung. Die breiteren CRA-Anforderungen wie Secure by Design, Konformitätsbewertung und CE-Kennzeichnung haben wir an anderer Stelle behandelt.

Was sich am 11. September 2026 ändert

Der CRA staffelt seine Pflichten zeitlich. Der Großteil der Anforderungen, von den grundlegenden Sicherheitsanforderungen bis zur Konformitätsbewertung, wird erst mit der vollen Anwendung ab 11. Dezember 2027 verbindlich. Für Hersteller ist allein die Meldepflicht vorgezogen: Sie gilt bereits ab dem 11. September 2026.

Damit hat der Gesetzgeber genau den Teil des CRA priorisiert, der auf laufende Bedrohungen reagiert. Die Logik dahinter ist nachvollziehbar. Behörden und andere Hersteller sollen möglichst früh erfahren, wenn eine Schwachstelle real angegriffen wird, damit Gegenmaßnahmen koordiniert werden können. Für Hersteller bedeutet das aber, dass sie über ein Jahr vor der vollen Anwendung bereits einen funktionierenden Meldeprozess brauchen.

Wer betroffen ist: Hersteller, nicht Betreiber

Die Meldepflicht des CRA richtet sich an Hersteller von Produkten mit digitalen Elementen. Darunter fällt sowohl Software als auch vernetzte Hardware, vom industriellen Gateway über die IoT-Komponente bis zur Anwendungssoftware, die in der EU auf den Markt gebracht wird. Es ist eine Produkt- und Herstellerperspektive: Wer betroffen ist, entscheidet sich daran, ob man ein Produkt in Verkehr bringt, nicht daran, wie kritisch der eigene Betrieb ist.

Genau hier entsteht die häufigste Verwechslung, nämlich die mit NIS-2. Die NIS-2-Richtlinie adressiert Betreiber und Einrichtungen und damit die Organisationsperspektive. Sie fragt, wie kritisch ein Unternehmen für Wirtschaft und Gesellschaft ist, und knüpft daran Meldepflichten für Vorfälle im eigenen Betrieb. Der CRA fragt dagegen nach dem Produkt und verpflichtet dessen Hersteller, Schwachstellen und Vorfälle mit Produktbezug zu melden.

Ein Unternehmen kann durchaus von beiden Regelwerken erfasst sein. Ein Hersteller von Netzwerktechnik, der zugleich als wesentliche Einrichtung unter NIS-2 fällt, betreibt dann zwei getrennte Meldewege mit unterschiedlichen Auslösern und Adressaten. Diese Trennung sauber zu dokumentieren gehört zu den ersten Aufgaben bei der Vorbereitung.

Was gemeldet werden muss

Meldepflichtig sind zwei Kategorien von Ereignissen. Erstens aktiv ausgenutzte Schwachstellen im Produkt. Zweitens schwerwiegende Sicherheitsvorfälle, die Auswirkungen auf die Sicherheit des Produkts mit digitalen Elementen haben.

Der entscheidende und oft missverstandene Begriff ist "aktiv ausgenutzt". Gemeint ist nicht die theoretische Ausnutzbarkeit einer Schwachstelle, wie sie ein CVSS-Score beschreibt, sondern der Nachweis, dass Angreifer die Lücke real ausnutzen. Es braucht Belege für tatsächliche Angriffe, etwa aus Telemetrie, aus einer Incident-Analyse oder aus verlässlicher Threat Intelligence. Eine kritische, aber bislang nur potenziell ausnutzbare Schwachstelle fällt für sich genommen nicht unter diese Meldepflicht. Erst wenn Hinweise auf reale Ausnutzung vorliegen, startet die Uhr.

Diese Unterscheidung ist für Produktverantwortliche zentral, weil sie den Auslöser der Meldung definiert. Der Übergang von "es könnte ausgenutzt werden" zu "es wird ausgenutzt" ist genau der Moment, den ein Hersteller zuverlässig erkennen können muss.

Die Fristen: 24 Stunden, 72 Stunden, 14 Tage

Die Meldung erfolgt mehrstufig, und die Fristen sind knapp bemessen.

1. Frühwarnung innerhalb von 24 Stunden: Sobald ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Vorfall erlangt, muss binnen 24 Stunden eine erste Frühwarnung abgesetzt werden.
2. Detaillierte Meldung innerhalb von 72 Stunden: Danach folgt eine ausführlichere Meldung mit den bis dahin bekannten Details zur Schwachstelle oder zum Vorfall und zu ersten Gegenmaßnahmen.
3. Abschlussbericht: Bei Schwachstellen ist ein Abschlussbericht spätestens 14 Tage nach dem Zeitpunkt fällig, zu dem eine Korrekturmaßnahme, also in der Regel ein Patch, verfügbar ist. Bei schwerwiegenden Vorfällen ist der Abschlussbericht innerhalb eines Monats nach der detaillierten Meldung vorzulegen.

Die 24-Stunden-Uhr beginnt mit der Kenntniserlangung. Dieser Anknüpfungspunkt ist wichtig, denn er verlagert das Problem von der Meldung auf die Erkennung. Wer eine Ausnutzung erst Wochen später bemerkt, hat die Frist formal nicht verletzt, praktisch aber die Chance zur koordinierten Reaktion vertan.

Der Meldeweg: Single Reporting Platform, BSI und ENISA

Für die Meldung wurde ein zentraler Kanal geschaffen. Über die CRA Single Reporting Platform (SRP) melden Hersteller einmalig, statt wie bisher mehrere nationale Stellen einzeln informieren zu müssen. Die Meldung wird an das CSIRT des Mitgliedstaats gerichtet, in dem der Hersteller seinen Hauptsitz hat, und gleichzeitig an die ENISA weitergeleitet. Für Hersteller mit Hauptsitz in Deutschland ist damit das BSI mit CERT-Bund die zuständige Stelle.

Die Plattform soll bis zum 11. September 2026 betriebsbereit sein, also passend zum Beginn der Meldepflicht. Details zum Ablauf und zu den Meldeformaten fasst die EU-Kommission auf ihrer Seite zu den CRA-Meldepflichten zusammen. Wer den technischen Meldeweg vorab kennt und einmal durchspielt, verliert im Ernstfall keine Zeit mit Zugangsdaten, Zuständigkeiten oder Formatfragen.

Die eigentliche Herausforderung: Erkennung und Prozess

In der Praxis scheitert die 24-Stunden-Frist selten am Ausfüllen eines Formulars. Sie scheitert daran, dass ein Hersteller die aktive Ausnutzung seines Produkts gar nicht mitbekommt. Ein Software- oder Geräteanbieter sieht die Angriffe auf ausgelieferte Produkte in fremden Netzen nicht direkt. Die Information kommt von außen: über Sicherheitsforscher, über Kunden, über Threat-Intelligence-Feeds oder über die Analyse eines gemeldeten Vorfalls.

Damit verschiebt sich die Aufgabe. Die Meldepflicht ist im Kern eine Erkennungs- und Prozessanforderung. Ein Hersteller muss erstens in der Lage sein, Signale für reale Ausnutzung aufzunehmen und richtig einzuordnen, und zweitens intern schnell genug entscheiden können, ob ein Ereignis meldepflichtig ist und wer die Meldung verantwortet. Beides braucht definierte Strukturen, keine Ad-hoc-Reaktion.

Erschwerend kommt hinzu, dass die 24 Stunden ab Kenntniserlangung laufen, nicht ab einem Werktagsbeginn. Ein Hinweis, der am Freitagabend eingeht, lässt sich nicht bis Montag liegen. Ohne klare Rufbereitschaft und Eskalationswege ist die Frist strukturell nicht einzuhalten.

Was Hersteller jetzt konkret tun sollten

Die verbleibende Zeit bis September 2026 sollte für den Aufbau der Prozesse genutzt werden, nicht für das Warten auf die Plattform. Konkret empfiehlt sich:

• Einen internen Meldeprozess und ein PSIRT etablieren. Ein Product Security Incident Response Team bündelt Meldungen, bewertet sie und verantwortet die fristgerechte Abgabe. Zuständigkeiten, Vertretung und Rufbereitschaft müssen benannt sein, damit die 24-Stunden-Uhr auch am Wochenende bedient wird.
• Monitoring und Threat Intelligence aufbauen. Quellen für Hinweise auf aktive Ausnutzung müssen systematisch beobachtet werden, von Telemetrie eigener Produkte über CVE- und Exploit-Feeds bis zu Meldungen von Kunden und Forschern.
• Coordinated Vulnerability Disclosure einrichten. Ein erreichbarer, dokumentierter Meldekanal für externe Hinweisgeber sorgt dafür, dass kritische Informationen den Hersteller erreichen, statt in Postfächern zu versanden. Eine security.txt und eine klare Kontaktadresse sind das Minimum.
• Die Meldepflicht von NIS-2 abgrenzen. Wer unter beide Regelwerke fällt, dokumentiert getrennte Auslöser, Fristen und Adressaten, damit im Ernstfall nicht der falsche oder gar kein Meldeweg gewählt wird.
• Den Ernstfall üben. Eine Tabletop-Übung deckt auf, ob die Kette von der Kenntniserlangung bis zur Frühwarnung tatsächlich innerhalb von 24 Stunden trägt. Genau hier zeigen sich die Lücken, die im echten Vorfall teuer werden.

Der genaue Wortlaut der Pflichten steht in Artikel 14 der Verordnung (EU) 2024/2847 und sollte bei der Ausgestaltung des Prozesses als verbindliche Referenz herangezogen werden. Die SBOM-Pflicht ist übrigens nicht Teil der September-Meldepflicht, sondern der vollen Anwendung ab Dezember 2027; in Deutschland konkretisiert die BSI TR-03183-2 das erwartete Format.

Fazit

Die CRA-Meldepflicht ab dem 11. September 2026 ist kein Formularproblem, sondern eine Prozess- und Erkennungsanforderung. Entscheidend ist nicht, ob ein Hersteller ein Meldeformular ausfüllen kann, sondern ob er eine reale Ausnutzung seines Produkts rechtzeitig bemerkt und intern schnell genug handelt. Wer jetzt ein PSIRT, ein belastbares Monitoring und einen geübten Meldeprozess aufsetzt, erfüllt die Pflicht nicht nur formal, sondern wird auch tatsächlich handlungsfähig. Die verbleibenden Monate sind knapp genug, um damit nicht zu warten.