CRA-Meldepflicht 2026:
Der 24/72-Stunden-Plan

Die CRA-Meldepflicht 2026 wird am 11. September praktisch relevant: Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei Produkten mit digitalen Elementen fristgebunden melden. Die erste Warnung ist ohne unangemessene Verzögerung, spätestens innerhalb von 24 Stunden nach Kenntnis, fällig; die Hauptmeldung folgt spätestens nach 72 Stunden. Wer erst im Incident klärt, welches Produkt betroffen ist, wer entscheiden darf und welche Daten vorliegen, verliert die knappe Frist mit Organisationsarbeit.

Dieser Leitfaden übersetzt die offiziellen Vorgaben in einen umsetzbaren Ablauf für Softwareanbieter, IoT-Hersteller und technische Mittelständler. Er ist eine technische und organisatorische Orientierung, keine Rechtsberatung. Ob ein konkretes Unternehmen oder Produkt erfasst ist, muss anhand der Verordnung und bei Bedarf mit qualifizierter Rechtsberatung geprüft werden.

Was sich am 11. September 2026 tatsächlich ändert

Ab diesem Datum gelten die Berichtspflichten aus Artikel 14 des Cyber Resilience Act (CRA). Die Europäische Kommission nennt zwei meldepflichtige Kategorien: aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen. Die Meldung läuft einmalig über die von ENISA betriebene Single Reporting Platform (SRP) an den zuständigen koordinierenden Computer Security Incident Response Team (CSIRT) und grundsätzlich zugleich an ENISA.

Das ist nicht dasselbe wie „jede gefundene Schwachstelle innerhalb von 24 Stunden melden“. Aktiv ausgenutzt bedeutet laut ENISA-FAQ, aktualisiert am 3. August 2026, dass verlässliche Hinweise auf eine unbefugte Ausnutzung durch einen böswilligen Akteur vorliegen. Ein schwerwiegender Vorfall beeinträchtigt oder gefährdet die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen des Produkts.

Welche Frist welche Information verlangt

Der Meldeprozess ist gestuft. Die frühe Meldung soll Geschwindigkeit sichern; spätere Stufen ergänzen die technische Bewertung. Die Kommission und ENISA beschreiben folgenden Rahmen:

Der Auslöser ist der Zeitpunkt, an dem der Hersteller Kenntnis von der aktiven Ausnutzung oder dem schwerwiegenden Vorfall erlangt. Deshalb gehört ein dokumentierter „Awareness“-Zeitpunkt in jedes Ticket. Ohne ihn lässt sich später weder die Friststeuerung noch die Entscheidung nachvollziehen.

Für wen die CRA-Meldepflicht relevant sein kann

Der CRA richtet die Hauptpflichten an Hersteller, die ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke auf dem EU-Markt bereitstellen. Dazu können eigenständige Software, verbundene Geräte und separat vermarktete Komponenten gehören. Entscheidend sind Rolle, Produkt und Marktbereitstellung – nicht allein Branche oder Unternehmensgröße. Die Zusammenfassung der Kommission beschreibt Produkte im Anwendungsbereich als solche, deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung umfasst.

Auch Bestandsprodukte gehören in die Analyse. Nach der Kommissionszusammenfassung gelten die Berichtspflichten für alle entsprechenden Produkte, die auf dem EU-Markt bereitgestellt wurden, einschließlich Produkten vor dem 11. Dezember 2027. Laut ENISA muss eine aktive Ausnutzung, die dem Hersteller bereits vor Beginn der Berichtspflicht bekannt war, jedoch nicht rückwirkend gemeldet werden. Das ist eine wichtige zeitliche Grenze, ersetzt aber keine produktspezifische Rechtsprüfung.

Für Importeure, Händler, Open-Source-Stewards und Anbieter freier Software gelten andere Rollen und teilweise andere Pflichten. Ein SaaS-Angebot, eine interne Anwendung oder ein Remote-Service lässt sich nicht seriös anhand eines Etiketts einordnen. Die im Juli veröffentlichte Kommissionsleitlinie enthält dafür Beispiele und Abgrenzungen; bei Zweifeln sollte das Ergebnis dokumentiert und fachkundig geprüft werden.

Der 7-Schritte-Plan für einen belastbaren Meldeprozess

1. Produkte und Rollen inventarisieren. Erfassen Sie Produktname, Versionen, verantwortliche Gesellschaft, EU-Märkte, Supportstatus und technische Eigentümer. Markieren Sie offene Scope-Fragen statt sie stillschweigend zu beantworten.
2. Eingangskanäle bündeln. Support, Security-Mails, Monitoring, Kundenmeldungen, Lieferantenhinweise und öffentliche Schwachstellenquellen müssen ein gemeinsames Triage-Team erreichen. Ein klarer Security-Kontakt reduziert verlorene Hinweise.
3. Entscheidungskriterien festlegen. Trennen Sie gewöhnliche Schwachstelle, verlässlichen Hinweis auf aktive Ausnutzung und möglichen schwerwiegenden Produktvorfall. Halten Sie Evidenz, Unsicherheit und Entscheidungsgrund fest.
4. Den Awareness-Zeitpunkt protokollieren. Ein Zeitstempel, die Quelle und die Person, die die Information bewertet hat, starten die interne Friststeuerung. Bei Unsicherheit darf das Ticket nicht ohne Eigentümer liegen bleiben.
5. 24h- und 72h-Vorlagen vorbereiten. Nutzen Sie die Feldliste im aktuellen ENISA-FAQ als Datenvertrag. Produkt, Mitgliedstaaten, Ereignisart, erste Bewertung, Maßnahmen und Nutzerhinweise sollten feste Felder sein, keine freie E-Mail-Erzählung.
6. Vertretung und Freigabe regeln. Benennen Sie primäre und sekundäre Meldeverantwortliche. Technik bewertet Evidenz; Management und gegebenenfalls Legal prüfen externe Aussagen. Die Stellvertretung muss auch nachts, am Wochenende und bei Urlaub funktionieren.
7. Einen Tischtest durchführen. Simulieren Sie eine aktiv ausgenutzte Bibliothek in einem ausgelieferten Produkt. Prüfen Sie nach zwei Stunden, ob Produktbestand, Kundenwirkung, Gegenmaßnahmen, Ansprechpartner und Entscheidungsweg sichtbar sind.

Diese sieben Schritte sind eine ATMAN-Umsetzungsempfehlung, keine wörtliche CRA-Vorgabe. Sie leiten sich aus den knappen Fristen und den von ENISA veröffentlichten Datenfeldern ab. Für technische Teams ist das Ziel ein nachvollziehbarer Incident-Workflow, der regulatorische Entscheidungen ermöglicht, ohne die eigentliche Eindämmung zu blockieren.

Wie Technik die 24-Stunden-Frist beherrschbar macht

Eine Software Bill of Materials (SBOM) ist für die September-Meldung nicht der Bericht selbst. Sie kann aber die wichtigste Suchhilfe sein: Welche Produktversion enthält die betroffene Komponente, welche Kunden oder Märkte können betroffen sein und wer besitzt den Build? Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt, SBOM-Werkzeuge schon in der Entwicklung zu integrieren und das Schwachstellenhandling über den Produktlebenszyklus mitzudenken.

Praktisch braucht die Inventarliste eine Verbindung zu Releases, Abhängigkeiten und Supportstatus. Ein Scanner ohne Produktzuordnung erzeugt Funde, aber keine belastbare Meldeentscheidung. Umgekehrt ersetzt eine SBOM weder Exploit-Evidenz noch Incident-Analyse. Die sinnvolle Kette lautet: Signal erfassen, Produktbezug herstellen, Evidenz bewerten, Auswirkung begrenzen, Meldeentscheidung dokumentieren und fristgerecht aktualisieren.

Für die SRP-Registrierung ist Zurückhaltung sinnvoll. ENISA erklärt, dass ein aktives EU-Login-Konto vorliegen muss, rät aber dazu, Registrierung und Validierung erst zu beginnen, wenn eine konkrete Meldung erforderlich ist. Die Validierung durch den koordinierenden CSIRT läuft parallel und hindert die Abgabe nicht. Teams sollten daher Zugang, Rollen und benötigte Firmendaten vorbereiten – aber der jeweils aktuellen ENISA-Registrierungsanleitung folgen, weil sich Plattformdetails noch ändern können.

Entscheidungscheck vor dem 11. September

• Ist dokumentiert, welche Gesellschaft für welches Produkt als Hersteller auftritt?
• Erreichen Security-, Support- und Lieferantenmeldungen eine rund um die Uhr handlungsfähige Stelle?
• Kann das Team aktive Ausnutzung und schweren Produktvorfall von einem normalen Finding unterscheiden?
• Wer setzt den Awareness-Zeitpunkt und startet die 24/72-Stunden-Uhr?
• Sind Produktversionen, betroffene EU-Märkte, technische Besitzer und erste Gegenmaßnahmen schnell auffindbar?
• Gibt es eine freigegebene Vorlage für Frühwarnung, Hauptmeldung und Abschlussbericht?
• Ist klar, wer technisch entscheidet, wer extern kommuniziert und wer vertritt?
• Wurde der Ablauf mit einem realistischen Szenario und fehlenden Informationen getestet?

Häufige Fragen zur CRA-Meldepflicht 2026

Welche Ereignisse müssen Hersteller ab 11. September 2026 melden?

Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken. Nicht jede gewöhnliche Schwachstelle löst automatisch eine CRA-Meldung aus.

Gilt die CRA-Meldepflicht auch für ältere Produkte?

Ja. Die Berichtspflichten erfassen auch Produkte mit digitalen Elementen, die bereits vor dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wurden. Eine vor dem 11. September 2026 bereits bekannte aktive Ausnutzung wird laut ENISA jedoch nicht rückwirkend meldepflichtig.

Sollten Hersteller schon jetzt ein Konto auf der CRA-Meldeplattform anlegen?

Ein aktives EU-Login-Konto kann vorbereitet werden. ENISA rät jedoch dazu, die Registrierung und Validierung auf der Single Reporting Platform erst zu starten, wenn eine konkrete Meldung erforderlich ist.

Gelten ab September 2026 schon alle CRA-Anforderungen?

Nein. Ab 11. September 2026 gelten die Berichtspflichten nach Artikel 14. Die wesentlichen Produkt- und Lebenszyklusanforderungen gelten grundsätzlich ab 11. Dezember 2027.