CRA-Meldepflicht: Wann die 24-Stunden-Frist für Hersteller beginnt
Hersteller müssen nun aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden melden. Doch die Pflicht gilt auch für Maschinen, die längst beim Kunden stehen.
Bei CRA-Meldungen zählt nicht erst das Absenden: Hersteller müssen intern klären, wann aus einem Hinweis ein meldepflichtiger Sicherheitsvorfall wird.
Foto: Smarterpix/DCStudio
Der Hersteller Sonicwall bestätigte vor einigen Wochen zwei aktiv ausgenutzte Zero-Day-Lücken in seiner Remote-Access-Appliance SMA 1000. Eine der Schwachstellen, CVE-2026-15409, erhielt den CVSS-Höchstwert 10,0, die zweite wurde mit 7,2 bewertet. Sonicwall bestätigte für beide eine aktive Ausnutzung. Ein vergleichbarer Fall würde für einen vom Cyber Resilience Act (CRA) erfassten Hersteller die Meldepflicht auslösen, sobald er davon Kenntnis erlangt.
Maßgeblich ist Artikel 14 des Cyber Resilience Act, der Verordnung (EU) 2024/2847. Betroffen sind Hersteller von Produkten mit digitalen Elementen einschließlich zugehöriger Datenfernverarbeitungslösungen. Für Maschinen- und Anlagenbauer besonders wichtig ist Artikel 69 Absatz 3: Die Meldepflicht gilt auch für Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, sofern sie in den Anwendungsbereich des CRA fallen. Die übrigen Produktanforderungen gelten für solche Bestandsprodukte grundsätzlich erst dann, wenn sie nach diesem Stichtag wesentlich verändert werden.
Inhaltsverzeichnis
Wie groß die Lücke zwischen Rechtslage und betrieblicher Vorbereitung ist, zeigte kurz vor dem Start eine Bitkom-Umfrage unter 1003 deutschen Unternehmen ab zehn Beschäftigten und mindestens 1 Mio. € Jahresumsatz. Nur 29 % wussten nach eigener Angabe, was der CRA für ihr Unternehmen bedeutet. 38 % hatten davon gehört, konnten die Bedeutung aber nicht einschätzen, 28 % kannten ihn gar nicht. Die Befragung fand zwischen Kalenderwoche 16 und 23 des Jahres 2026 statt.
Was binnen 24 und 72 Stunden gemeldet werden muss
Eine aktiv ausgenutzte Schwachstelle ist eine Schwachstelle im Produkt, für die verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat. Theoretische Ausnutzbarkeit allein genügt nicht.
Darüber hinaus ist ein schwerwiegender Sicherheitsvorfall meldepflichtig. Artikel 14 Absatz 5 nennt dafür zwei Fallgruppen: Der Vorfall beeinträchtigt die Fähigkeit eines Produkts, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder kann dies tun. Oder er hat dazu geführt, dass Schadcode in ein Produkt oder in das Netz eines Nutzers eingeschleust oder dort ausgeführt wurde bzw. kann dazu führen. Damit kann etwa auch die Kompromittierung von Schlüsseln für signierte Firmware-Updates relevant werden.
Die Meldung erfolgt in drei Stufen. Binnen 24 Stunden nach Kenntniserlangung ist eine Frühwarnung abzugeben. Bei einer aktiv ausgenutzten Schwachstelle sind dabei die Mitgliedstaaten anzugeben, in denen das Produkt nach Kenntnis des Herstellers bereitgestellt wurde. Innerhalb von 72 Stunden folgen Angaben zum Produkt, zur Art der Schwachstelle und ihrer Ausnutzung sowie zu bereits ergriffenen oder für Nutzer möglichen Gegenmaßnahmen. Spätestens 14 Tage nach Bereitstellung einer Korrektur- oder Risikominderungsmaßnahme folgt der Abschlussbericht.
Für einen schwerwiegenden Sicherheitsvorfall gelten ebenfalls die 24- und 72-Stunden-Stufen. In der Frühwarnung ist mindestens anzugeben, ob ein Verdacht auf rechtswidrige oder böswillige Handlungen besteht; gegebenenfalls sind auch die Mitgliedstaaten zu nennen, in denen das Produkt bereitgestellt wurde. Der Abschlussbericht ist grundsätzlich spätestens einen Monat nach der 72-Stunden-Meldung fällig.
Zusätzlich muss der Hersteller die betroffenen Nutzer über die Schwachstelle oder den Vorfall informieren und, soweit erforderlich, auf Maßnahmen hinweisen, mit denen sie die Auswirkungen mindern können.
Enisa-Plattform ist seit September in Betrieb
Die Meldung läuft über die Single Reporting Platform der EU-Agentur für Cybersicherheit Enisa. Sie ist seit dem 11. September 2026 operativ. Eine Meldung über die Plattform geht an das zuständige, als Koordinator benannte CSIRT (Computer Security Incident Response Team) und an Enisa; Hersteller müssen also nicht parallel mehrere nationale Meldungen abgeben.
Für Deutschland nennt Enisa den beim BSI angesiedelten Cert-Bund (Computer Emergency Response Team) als koordinierendes CSIRT. Für den Zugang zur Plattform benötigen die für ein Unternehmen handelnden Personen ein EU-Log-in-Konto mit Mehrfaktor-Authentifizierung.
Das deutsche Durchführungsgesetz hatte Anfang Oktober das parlamentarische Verfahren noch nicht abgeschlossen. Der Bundestag hatte den Regierungsentwurf am 11. Juni 2026 in erster Lesung an die Ausschüsse überwiesen. Für die seit 11. September geltenden Meldepflichten bedeutet das keinen Aufschub: Der CRA ist eine EU-Verordnung und gilt insoweit unmittelbar.
Wann beginnt die 24-Stunden-Frist?
Allerdings läuft die Zeit unter Umständen bereits vor der eigentlichen Meldung: Wann hat ein Hersteller im Sinne des CRA „Kenntnis erlangt“? Das ist nicht zwangsläufig der Moment, in dem der erste Hinweis eingeht.
Mit der Mitteilung C(2026) 5252 samt Anhang hat die EU-Kommission am 27. Juli 2026 Leitlinien zur Anwendung des CRA veröffentlicht. Danach soll ein Hersteller einen verdächtigen Vorgang zunächst unverzüglich bewerten. Nach Auffassung der Kommission liegt Kenntnis vor, wenn diese erste Bewertung mit hinreichender Gewissheit ergibt, dass eine Schwachstelle tatsächlich aktiv ausgenutzt wird oder ein schwerwiegender Sicherheitsvorfall eingetreten ist. Ein ungeprüfter Hinweis allein setzt die 24-Stunden-Frist damit nicht automatisch in Gang.
Die Leitlinien sind nicht rechtsverbindlich, bilden aber eine wichtige Auslegungshilfe. Der Engpass liegt damit vor der eigentlichen Meldung: in der schnellen und belastbaren Erstbewertung. Gerade bei Meldungen aus dem Feld kann das schwierig werden. Ein Servicetechniker meldet ungewöhnliches Verhalten einer Maschine, ein Kunde schickt Logdateien oder ein Komponentenlieferant warnt vor einer Schwachstelle. Noch ist damit nicht zwangsläufig eine CRA-Meldung fällig. Der Vorgang muss aber so schnell bei einer Stelle landen, die beurteilen kann, ob aus dem Hinweis eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall geworden ist.
Der Hersteller sollte deshalb auch dokumentieren können, was zwischen dem ersten Hinweis und der Entscheidung über die Meldepflicht geschehen ist. Wer dafür keinen Prozess hat, verliert Zeit, noch bevor die eigentliche Frist läuft.
CRA-Meldepflicht: Was Hersteller jetzt organisiert haben sollten
Besonders wichtig ist es, dass die Zuständigkeit klar benannt wird. Eine Person oder Funktion muss Hinweise entgegennehmen, die Erstbewertung koordinieren und gegebenenfalls die CRA-Meldung auslösen können. In größeren Unternehmen übernimmt das häufig ein Product Security Incident Response Team (PSIRT). In kleineren Betrieben kann eine definierte Rolle mit Vertretungsregelung genügen.
Dazu braucht es einen festgelegten Eingang für externe Hinweise, etwa eine veröffentlichte Sicherheitsadresse und ein Verfahren zur koordinierten Offenlegung. Orientierung bieten unter anderem ISO/IEC 29147 für die Offenlegung von Schwachstellen und ISO/IEC 30111 für deren interne Bearbeitung.
Seit die Plattform live ist, gehört auch der operative Zugang zur Vorbereitung: Verantwortliche sollten ein EU-Log-in-Konto, also das zentrale Benutzerkonto für Onlinedienste der EU-Kommission, einschließlich Mehrfaktor-Authentifizierung eingerichtet, die zuständigen Vertreter festgelegt und den Meldeweg praktisch durchgespielt haben. Enisa weist darauf hin, dass Meldungen zunächst über die Benutzeroberfläche eingegeben werden müssen; eine Programmierschnittstelle steht zum Start noch nicht bereit. Enisa stellt zudem ein Feld-für-Feld-Glossar zur Meldeplattform bereit. Es zeigt, welche Angaben in der Frühwarnung nach 72 Stunden und im Abschlussbericht erforderlich sind.
Zeit sparen außerdem vorbereitete Meldevorlagen für alle drei Stufen. Produktbezeichnung, betroffene Versionen, Mitgliedstaaten, Beschreibung der Ausnutzung, Gegenmaßnahmen und Ansprechpartner lassen sich teilweise vorbereiten. Ein Probelauf mit Entwicklung, Service, IT-Sicherheit und Recht zeigt meist schneller als jedes Organigramm, an welcher Stelle Informationen oder Entscheidungsbefugnisse fehlen.
Geldbußen bis zu 15 Mio. € – aber nicht sofort
Verstöße gegen Artikel 14 fallen grundsätzlich in die höchste Sanktionsstufe des CRA: Vorgesehen sind Geldbußen von bis zu 15 Mio. € oder bei Unternehmen bis zu 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres – je nachdem, welcher Betrag höher ist.
Dieser Bußgeldrahmen gilt allerdings noch nicht. Während Artikel 14 seit dem 11. September 2026 anzuwenden ist, werden die übrigen Vorschriften des CRA – und damit auch Artikel 64 über die Sanktionen – grundsätzlich erst zum 11. Dezember 2027 anwendbar. Eine heute versäumte Meldung ist damit zwar ein Verstoß gegen eine bereits geltende CRA-Pflicht. Die in Artikel 64 vorgesehenen CRA-Geldbußen greifen derzeit aber noch nicht. Welche anderen rechtlichen oder vertraglichen Folgen ein konkreter Vorfall haben kann, hängt vom Einzelfall ab.
Für Kleinst- und Kleinunternehmen enthält Artikel 64 Absatz 10 zudem eine besondere Ausnahme: Für diese gelten die Geldbußen nicht, wenn sie lediglich die 24-Stunden-Frist nach Artikel 14 Absatz 2 Buchstabe a bzw. Absatz 4 Buchstabe a versäumen. Maßgeblich für die Unternehmensgröße ist die Empfehlung 2003/361/EG. Ein kleines Unternehmen hat weniger als 50 Beschäftigte und höchstens 10 Mio. € Jahresumsatz oder Jahresbilanzsumme. Für einen Maschinenbauer mit 200 Beschäftigten gilt diese Ausnahme nicht.
Der CRA verlangt seit September noch nicht die vollständige Cybersecurity-Organisation, die ab Dezember 2027 für neue Produkte erforderlich ist. Bei Schwachstellen und Sicherheitsvorfällen gilt die Verordnung aber bereits heute. Sie verlangt, dass ein Betrieb weiß, wer entscheidet, ob die Uhr läuft. Wer das nicht klärt, klärt es unter Zeitdruck, parallel zu dem Vorfall, der die Frage ausgelöst hat.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 3 Nr. 19 und 42, Artikel 14, Artikel 64, Artikel 69, Artikel 71.
- Berichtigung 2025/90555 vom 2. Juli 2025 zu Artikel 64 Absatz 10 (ELI: data.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj).
- Europäische Kommission, Mitteilung C(2026) 5252 samt Anhang, veröffentlicht am 27. Juli 2026, Leitlinien nach Artikel 26 CRA. Zur Kenntniserlangung Abschnitt 9.1.
- Empfehlung 2003/361/EG der Kommission (KMU-Definition).
- SonicWall PSIRT, Advisory SNWLID-2026-0008 vom 14. Juli 2026, zu CVE-2026-15409 (CVSS 10,0) und CVE-2026-15410. CISA, Known Exploited Vulnerabilities Catalog, Aufnahme am 14. Juli 2026. Volexity, Analyse vom 17. Juli 2026, frühestes Kompromittierungszeichen 22. Juni 2026.
- Enisa, Single Reporting Platform, FAQ, Stand 31. Juli 2026, zu EU-Login und koordinierenden CSIRTs. BSI, Informationsseite zur CRA-Meldepflicht und Single Reporting Platform, Stand 10. September 2026, zur Erreichbarkeit der Plattform.
- Bitkom, Digitalverband, CRA-Umfrage unter 1.003 Unternehmen ab 10 Beschäftigten und einem Jahresumsatz ab 1 Mio. Euro, Feldzeit Kalenderwoche 16 bis 23 des Jahres 2026, veröffentlicht am 10. September 2026.
- Deutscher Bundestag, Drucksache 21/6134 (CRA-Durchführungsgesetz), erste Lesung 11. Juni 2026, federführend Innenausschuss.
- FIRST, PSIRT Services Framework. ISO/IEC 29147 (Vulnerability Disclosure) und ISO/IEC 30111 (Vulnerability Handling).
Ein Beitrag von:
