Die CRA-Meldepflicht startet am 11. September 2026 und gilt auch für längst verkaufte Produkte

Was am 11. September 2026 wirklich passiert

Viele Hersteller haben den Cyber Resilience Act als Thema für 2027 abgelegt. Das ist verständlich und trotzdem falsch. Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten. Ihre Sicherheitsanforderungen gelten in voller Breite ab dem 11. Dezember 2027. Dazwischen liegen zwei vorgezogene Stichtage. Seit dem 11. Juni 2026 gilt Kapitel IV zur Benennung von Prüfstellen, also die Artikel 35 bis 51. Ab dem 11. September 2026 gilt Artikel 14, die Meldepflicht (Art. 71 Abs. 2).

Der Abstand zwischen den beiden Daten ist keine juristische Feinheit. Er ist eine Frage der Betriebsbereitschaft. Am 11. Dezember 2027 musst du nachweisen, dass ein Produkt sicher entwickelt wurde. Am 11. September 2026 musst du innerhalb von 24 Stunden eine Meldung absetzen können. Das setzt voraus, dass du weißt, was in deinen Produkten steckt, wer sie einsetzt und wer bei dir nachts ans Telefon geht. Das erste ist ein Entwicklungsprojekt mit 15 Monaten Vorlauf. Das zweite ist eine Fähigkeit, die deine Organisation hat oder nicht hat.

Genau diese Reihenfolge ist das Problem. Die Meldepflicht kommt zuerst, die Bauanforderungen später. Wer die Verordnung von hinten liest, plant für 2027 eine sichere Entwicklung und übersieht, dass er 2026 schon über unsichere Altprodukte berichten muss.

Wie eng die Frist ist, zeigt ein Blick auf reale Angriffe. Die 24 Stunden beginnen in dem Moment, in dem du von der Ausnutzung erfährst, nicht mit der Veröffentlichung einer Schwachstellennummer. Eine CVE ist die öffentliche Kennung einer Schwachstelle. VulnCheck zählte für 2025 884 Schwachstellen, für die erstmals Belege einer Ausnutzung vorlagen. Bei 28,96 Prozent davon lief die Ausnutzung schon am Tag der CVE-Veröffentlichung oder davor. Im Jahr zuvor waren es 23,6 Prozent. Die Uhr startet also regelmäßig, bevor es einen öffentlichen Eintrag gibt.

Warum die drei Fristen härter sind, als sie klingen

Artikel 14 kennt zwei Auslöser und je drei Berichte. Der erste Auslöser ist eine aktiv ausgenutzte Schwachstelle in einem deiner Produkte. Der zweite ist ein schwerwiegender Vorfall, der die Sicherheit des Produkts beeinträchtigt. Beide Auslöser haben eigene Fristenketten und die Bezugspunkte unterscheiden sich.

Auslöser	Frühwarnung und vollständige Meldung	Abschlussbericht
Aktiv ausgenutzte Schwachstelle	24 Stunden und 72 Stunden ab Kenntnis (Art. 14 Abs. 2)	Spätestens 14 Tage, nachdem eine Abhilfe oder Risikominderung verfügbar ist
Schwerwiegender Vorfall	24 Stunden und 72 Stunden ab Kenntnis (Art. 14 Abs. 4)	Ein Monat nach Einreichung der 72-Stunden-Meldung

Die beiden Abschlussberichte hängen an verschiedenen Ankern. Bei der Schwachstelle läuft die Uhr ab dem Moment, in dem eine Gegenmaßnahme verfügbar ist. Der Verordnungstext spricht von einer korrigierenden oder risikomindernden Maßnahme. Ein dokumentierter Workaround löst die 14 Tage also genauso aus wie ein fertiger Patch. Beim Vorfall zählt die Einreichung der 72-Stunden-Meldung, nicht die Kenntnis und nicht die Verfügbarkeit einer Lösung. Wer die Anker verwechselt, plant den falschen Kalender.

Dazu kommt eine oft übersehene Klausel. Nach Art. 14 Abs. 6 kann das zuständige CSIRT jederzeit einen Zwischenbericht anfordern. Ein CSIRT ist ein staatliches Notfallteam für IT-Sicherheit. Die drei Fristen sind eine Untergrenze, keine abschließende Berichtslast. Wer für 24, 72 und 14 plant, aber keine Kapazität für Rückfragen hat, hat die Ressourcen falsch bemessen.

Was als schwerwiegender Vorfall zählt

Art. 14 Abs. 5 liefert eine Definition und sie enthält bewusst keinen Schwellenwert nach CVSS, dem gängigen Punktesystem für die Schwere von Schwachstellen. Schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Echtheit, Unversehrtheit oder Vertraulichkeit wichtiger Daten oder Funktionen zu schützen. Ebenso, wenn er zur Einschleusung oder Ausführung von Schadcode geführt hat oder führen kann (Art. 14).

Das “kann” ist der teure Teil. Die Schwelle bemisst sich am Potenzial, nicht am eingetretenen Schaden. Eine interne Regel “wir melden ab CVSS 9,0” hat im Verordnungstext keine Entsprechung. Die Bewertung muss je Produkt erfolgen und innerhalb von Stunden, nicht in der nächsten Sicherheitsrunde.

Die vergessene vierte Pflicht

Art. 14 Abs. 8 verlangt zusätzlich, dass du die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall informierst, einschließlich der Gegenmaßnahmen. Das Format muss maschinenlesbar sein, also automatisiert verarbeitbar. Unterlässt du das, können die CSIRTs die Nutzer selbst informieren.

An diesem Punkt reißen viele Meldeprozesse. Die Behördenmeldung ist ein Formular. Die Nutzerinformation ist eine Verteilerliste, ein Kanal und ein maschinenlesbares Format für Sicherheitshinweise, das jemand vorher aufgesetzt haben muss. Beides gleichzeitig unter Zeitdruck zu improvisieren, funktioniert nicht.

Warum alte Produkte das größte Risiko sind

Hier liegt der eigentliche Haken. Art. 69 Abs. 2 stellt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, weitgehend frei. Die übrigen CRA-Anforderungen greifen bei ihnen erst, wenn sie ab diesem Datum wesentlich verändert werden. Absatz 3 macht davon eine Ausnahme: Die Pflichten aus Artikel 14 gelten für alle Produkte mit digitalen Elementen im Anwendungsbereich der Verordnung, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden (Art. 69).

In Betriebssprache: Für den kompletten Altbestand musst du melden, aber du musst ihn nicht sicher gebaut haben. Die Nachweispflicht ist ausgesetzt, die Meldepflicht nicht.

Das trifft genau die Produkte, über die niemand mehr gern spricht. Das Gerät von 2019 mit einem eingefrorenen Betriebssystem. Der Industrie-Gateway mit einer Verschlüsselungsbibliothek, für die es seit Jahren keine Updates gibt. Die App, deren Baustein-Anbieter den Support eingestellt hat. Für all das brauchst du ab dem 11. September 2026 keine Konformitätserklärung, aber eine belastbare Antwort auf eine Frage: Steckt diese Schwachstelle in einem unserer ausgelieferten Produkte und wird sie ausgenutzt.

Bei Bausteinen ohne Support ist diese Antwort strukturell schwierig. Es gibt keine Sicherheitshinweise vom Hersteller mehr, keine gepflegten Versionsbereiche, oft nicht einmal einen verlässlichen Paketnamen. Die Schwachstelle taucht in einem Bericht über Angriffe auf und niemand im Unternehmen kann in 24 Stunden sagen, in welchen Firmware-Ständen die betroffene Bibliothek steckt. Deshalb ist die Vorarbeit für die Meldepflicht keine Compliance-Aufgabe, sondern eine Frage der Sicherheitsarchitektur.

Warum ohne Stückliste keine 24-Stunden-Meldung möglich ist

Eine Frühwarnung nach 24 Stunden verlangt drei Angaben, die kein Ticketsystem aus dem Nichts erzeugt: welches Produkt betroffen ist, in welchen ausgelieferten Versionen und wer diese Versionen einsetzt. Wer das erst im Vorfall recherchiert, verliert die Frist beim ersten Anruf.

Eine Software-Stückliste, englisch Software Bill of Materials oder SBOM, ist deshalb keine Dokumentationspflicht. Sie ist die Datenstruktur, an der die Frist hängt. Entscheidend ist nicht, dass eine SBOM existiert, sondern dass sie pro ausgeliefertem Release existiert, unveränderlich abgelegt ist und maschinell abfragbar bleibt. Eine SBOM, die nur im Build-Ordner des letzten Durchlaufs liegt, hilft bei einer Schwachstelle in einer drei Jahre alten Version nicht.

Drei Bausteine gehören zusammen. Erstens die Erzeugung: Die SBOM entsteht im Release-Prozess, wird signiert und mit Produkt, Version und Auslieferungsdatum in einem Register abgelegt, das nachträglich nicht verändert werden kann. Zweitens die Abfrage: Für eine gegebene Schwachstelle liefert das Register in Minuten alle ausgelieferten Versionen, die den betroffenen Baustein enthalten, samt der Information, ob der Baustein noch gepflegt wird und ob ein Patch existiert. Drittens die Verbindung zum Kundenregister: Zu jeder betroffenen Version steht fest, wer sie einsetzt.

Die Merkmale “Baustein ohne Support” und “kein Patch vorhanden” sind die wichtigsten. Ein Treffer mit beiden Merkmalen bedeutet, dass die 14-Tage-Uhr des Abschlussberichts erst mit einer dokumentierten Risikominderung zu laufen beginnt. Diese Maßnahme muss beschrieben, freigegeben und an die Nutzer kommuniziert werden. Das ist Arbeit, die du vor dem Vorfall erledigst oder gar nicht.

Praktisch heißt das drei Verbindungen: das SBOM-Register an den Release-Prozess, das Kundenregister an die Versionsstände und beides an eine dauerhafte Beobachtung der Meldungen über neue Schwachstellen und laufende Angriffe. Ohne die dritte Verbindung erfährst du von der Ausnutzung durch einen Kunden und dann ist ein Teil der 24 Stunden schon weg.

Wer meldet an wen und über welches Werkzeug

Die Meldung erfolgt einmal. Die Kommission formuliert es unmissverständlich: Hersteller melden nur einmal über die CRA Single Reporting Platform (Kommission, CRA reporting). Die Plattform leitet die Meldung gleichzeitig an das als Koordinator benannte CSIRT und an die EU-Agentur für Cybersicherheit ENISA weiter (Art. 14 Abs. 1 und Abs. 3). Errichtet und betrieben wird sie nach Art. 16 Abs. 1 von ENISA.

Zuständig ist das CSIRT des Mitgliedstaats deiner Hauptniederlassung. Der CRA definiert diese nicht über den Handelsregistereintrag, sondern über den Ort, an dem die Entscheidungen zur Sicherheit der Produkte überwiegend getroffen werden (Art. 14 Abs. 7). Für Hersteller aus Drittstaaten greift eine Kaskade: zuerst der Bevollmächtigte, dann der Importeur, dann der Händler, andernfalls der Mitgliedstaat mit den meisten Nutzern. Wer Entwicklung, Produktsicherheit und Geschäftsleitung über mehrere Länder verteilt hat, sollte diese Zuordnung schriftlich festhalten, bevor sie im Ernstfall bestritten wird.

Zwei Einschränkungen gehören dazu. Erstens ist die Weitergabe an ENISA kein Automatismus. Nach Art. 16 kann ein CSIRT die Weiterverbreitung einer Meldung aus begründeten Sicherheitsgründen zurückhalten, insbesondere während einer laufenden koordinierten Offenlegung. Es muss ENISA dann unverzüglich über die Entscheidung, die Begründung und den geplanten Zeitpunkt informieren (Art. 16). Zweitens veröffentlicht ENISA die Liste der benannten Koordinator-CSIRTs auf ihren Seiten zur Plattform. Prüfe dort, welches CSIRT für dein Land eingetragen ist. Für Deutschland entwickelt das BSI die Technische Richtlinie TR-03183, die die CRA-Anforderungen für Hersteller und Produkte konkretisiert.

Der Zugang zur Plattform läuft über ein EU-Login-Konto mit Zwei-Faktor-Anmeldung. Die Bevollmächtigung wird laut ENISA nach dem ersten Zugriff durch das Koordinator-CSIRT geprüft, parallel zum laufenden Meldeprozess. Das Konto sollte also lange vor dem ersten Vorfall existieren.

Ein Detail zum Einplanen: ENISA hat den Betrieb der Plattform für den 11. September 2026 angekündigt, also für denselben Tag, an dem die Pflicht beginnt. Ende Juni 2026 war sie laut dem Fachdienst cyberresilienceact.eu noch nicht erreichbar. Die Fristen aus Artikel 14 gelten unabhängig davon, ob das Werkzeug fertig ist. Fällt die Plattform aus, sieht ENISA vor, dass du wartest und danach nachmeldest. Für dringende Fälle solltest du den direkten Kontakt zu deinem CSIRT kennen.

Was organisatorisch stehen muss

Die technische Vorarbeit ist die eine Hälfte. Die andere ist eine Handvoll Festlegungen, die sich nicht kaufen lassen.

Baustein	Muss festgelegt sein	Typischer Fehler
Zuständiges CSIRT	Hauptniederlassung nach Art. 14 Abs. 7 dokumentiert, bei Drittstaaten die Kaskade	Handelsregistersitz statt Ort der Sicherheitsentscheidungen
Plattformzugang	EU-Login-Konto angelegt, mindestens zwei Personen bevollmächtigt	Ein Konto auf eine Person, die im Urlaub ist
Kenntnis	Festgelegt, welches Signal die 24-Stunden-Uhr startet und wer sie startet	Uhr beginnt erst in der Geschäftsleitungsrunde
Bewertung	Einstufung je Produkt nach Art. 14 Abs. 5 ohne CVSS-Schwelle	Interne Regel “ab CVSS 9,0 melden”
Nutzerinformation	Verteiler und maschinenlesbares Format nach Art. 14 Abs. 8	PDF-Anhang an eine Sammeladresse
Rückfragen	Kapazität für Zwischenberichte nach Art. 14 Abs. 6	Nur die drei Pflichtfristen eingeplant

Der Rest ist Ablauf. Wer die Meldung, die interne Eskalation und die Nutzerinformation als eine durchgängig automatisierte Kette baut, spart im Ernstfall nicht Minuten, sondern die Stunden, die zwischen Kenntnis und der ersten Entscheidung der Geschäftsleitung verloren gehen. Nebenbei entsteht der Nachweis, wann wer was wusste. Den brauchst du spätestens beim Abschlussbericht.

Was das Versäumnis kostet

Art. 64 setzt den Rahmen. Verstöße gegen die Anforderungen aus Anhang I sowie gegen die Pflichten aus Art. 13 und Art. 14 können mit Geldbußen bis zu 15 Millionen Euro oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes des Vorjahres belegt werden, je nachdem, welcher Betrag höher ist. Für andere Verstöße liegt die Obergrenze bei 10 Millionen Euro oder 2 Prozent, für falsche oder unvollständige Angaben gegenüber Marktüberwachungsbehörden bei 5 Millionen Euro oder 1 Prozent (Art. 64).

Zwei Ausnahmen sind wichtig und werden häufig überlesen. Kleinst- und Kleinunternehmen sind von Geldbußen ausgenommen, wenn sie die 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 lit. a oder Art. 14 Abs. 4 lit. a versäumen. Die übrigen Fristen und Pflichten aus Artikel 14 sind davon nicht erfasst. Open-Source-Software-Stewards sind von Geldbußen für Verstöße gegen die Verordnung ausgenommen. Beides entschärft die Sanktion, nicht die Pflicht. Wer die Meldung unterlässt, hat weiterhin gegen Artikel 14 verstoßen, mit allen Folgen für die Marktaufsicht, die daran hängen.

Wie die Pflicht durch die Lieferkette wandert

Die interessantere Durchsetzung läuft nicht über Bußgelder, sondern über Verträge. Honeywell betreibt eine öffentliche CRA-Lieferantenseite. Dort verlangt der Konzern von Lieferanten, bis zum 11. September 2026 funktionsfähige Meldeprozesse für Schwachstellen und Vorfälle einschließlich Registrierung auf der ENISA-Plattform vorzuhalten. Bis zum vierten Quartal 2026 sollen Lieferanten Konformitätsnachweise oder detaillierte Fahrpläne für alle Komponenten liefern, die in EU-Produkte einfließen, dazu maschinenlesbare Stücklisten und die Zusage, Honeywell binnen 24 Stunden über ausgenutzte Schwachstellen zu informieren. Bis zum 11. Dezember 2027 wird volle CRA-Konformität inklusive Konformitätsbewertung, CE-Kennzeichnung und EU-Konformitätserklärung erwartet (Honeywell).

Das ist der Mechanismus, der die Frist real macht. Ein Zulieferer, der unterhalb jeder Bußgeldschwelle liegt, verliert den Rahmenvertrag, wenn er die Nachweise nicht liefern kann.

Parallel formiert sich die Antwort im Open-Source-Bereich. Sieben Stiftungen, darunter Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation und Eclipse Foundation, kündigten am 2. April 2024 an, gemeinsame Spezifikationen für sichere Softwareentwicklung zur CRA-Umsetzung zu erarbeiten (Eclipse). Die daraus entstandene Open Regulatory Compliance Working Group der Eclipse Foundation zählt inzwischen über 50 Mitglieder, darunter Microsoft, Red Hat, GitHub, Google, Nokia und Mercedes-Benz. Am 14. August 2025 hat sie eine erste Sammlung von CRA-Ressourcen und einen Fahrplan für weitere Ergebnisse veröffentlicht (Eclipse Newsroom).

Was du jetzt prüfen kannst

Die Verordnung stellt bis zum 11. September 2026 keine Frage nach der Qualität deiner Software. Sie stellt eine Frage nach der Reaktionsfähigkeit deiner Organisation: Kannst du innerhalb eines Arbeitstags sagen, ob eine aktiv ausgenutzte Schwachstelle in einem deiner ausgelieferten Produkte steckt und kannst du die Betroffenen erreichen.

Diese Fähigkeit lässt sich auf drei Entscheidungen herunterbrechen. Erstens: eine Person mit Namen, die die Uhr startet, plus eine Vertretung. Zweitens: eine SBOM pro ausgeliefertem Release, unveränderlich abgelegt, für den Altbestand rückwirkend erzeugt. Drittens: ein maschinenlesbarer Kanal zu den Nutzern, der nicht erst im Ernstfall gebaut wird.

Ein ehrlicher Hinweis: Wie viel Arbeit das ist, hängt stark von deinem Ausgangszustand ab. Wer heute schon je Release eine Stückliste erzeugt, braucht vor allem das Register und das Kundenregister. Wer noch nie eine erzeugt hat, sollte mit dem Produkt anfangen, das am meisten im Feld ist. Alles andere hat bis 2027 Zeit. Diese drei Punkte nicht. Wenn du wissen willst, wie diese Kette in einer bestehenden Produktlandschaft aussieht, sprich mit uns.

Quellen

• Kommission: Cyber Resilience Act
• Kommission: CRA reporting obligations
• ENISA: Single Reporting Platform
• BSI: Cyber Resilience Act
• CRA Art. 14 (Meldepflichten)
• CRA Art. 14, Volltext mit Absatzgliederung
• CRA Art. 16 (Single Reporting Platform, Vertraulichkeit)
• CRA Art. 64 (Sanktionen)
• CRA Art. 69 (Übergangsbestimmungen)
• CRA Art. 71 (Inkrafttreten und Geltung)
• VulnCheck: State of Exploitation, Auswertung für 2025
• cyberresilienceact.eu: Single Reporting Platform noch nicht live, 29.06.2026
• Honeywell: EU Cyber Resilience Act, Lieferanteninformation
• Eclipse Foundation: Open Regulatory Compliance Working Group
• Eclipse Foundation: Sieben Stiftungen zu gemeinsamen CRA-Spezifikationen, 02.04.2024
• EUR-Lex: Verordnung (EU) 2024/2847