CRA Meldepflicht 2026: Was müssen Hersteller digitaler Produkte seit September 2026 melden, wie funktionieren die 24- und 72-Stunden-Fristen und wie lässt sich ein praktikabler Ablauf ohne hektische Ad-hoc-Reaktion einrichten? Dieser Leitfaden zeigt die technischen und organisatorischen Schritte für den Mittelstand.
Stand: 21. Oktober 2026 · Fachbeitrag GORTNET · Hinweis: keine Rechtsberatung.
Was sich seit September 2026 geändert hat
Die CRA Meldepflicht 2026 ist kein Zukunftsprojekt mehr. Seit dem 11. September 2026 müssen betroffene Hersteller von Produkten mit digitalen Elementen bestimmte aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle über die zentrale europäische Meldeplattform anzeigen. Die vollständigen Anforderungen des Cyber Resilience Act werden überwiegend erst ab dem 11. Dezember 2027 anwendbar; die Meldepflicht ist jedoch vorgezogen. Gerade Softwareanbieter, Gerätehersteller und Unternehmen mit eigenen vernetzten Produkten benötigen daher schon heute einen belastbaren Prozess.
Ein gewöhnlicher Anwender einer gekauften Software wird dadurch nicht automatisch zum meldepflichtigen Hersteller. Die konkrete Rolle ergibt sich aus dem Produkt, dem Inverkehrbringen sowie den Regelungen des CRA. Eine juristische Einordnung ersetzt dieser technische Leitfaden nicht.
Welche Ereignisse tatsächlich meldepflichtig sind
Nicht jede theoretische Sicherheitslücke ist automatisch ein meldepflichtiges Ereignis. Relevant ist insbesondere eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen, wenn der Hersteller davon Kenntnis erhält. Daneben erfasst die Verordnung schwerwiegende Vorfälle, die die Sicherheit des Produkts beeinträchtigen. Eine belastbare Triage muss Fakten, Zeitpunkt der Kenntniserlangung und mögliche Auswirkungen dokumentieren.
Richten Sie zwei parallele Entscheidungspfade ein: Product Security Incident Response Team (PSIRT) für die Produktbewertung und Security Operations für laufende technische Eindämmung. Der PSIRT-Eintrag sollte Produktversion, Schwachstellenklasse, mögliche Angriffswege, verfügbare Indikatoren, betroffene Komponenten und Quelle des ersten Hinweises enthalten.
24-Stunden-Frist: belastbare Frühwarnung statt perfekter Bericht
Die erste Warnung ist grundsätzlich innerhalb von 24 Stunden nach Kenntniserlangung zu übermitteln. Dafür müssen nicht alle technischen Details endgültig feststehen. Entscheidend ist, dass der Hersteller nach interner Bewertung fristgerecht reagiert, nachvollziehbare Informationen übermittelt und offene Fragen als vorläufig kennzeichnet. Ein Meldeprozess, der auf eine vollständige forensische Analyse wartet, gefährdet die Frist.
Legen Sie eine durchgehend erreichbare Meldeadresse und eine Stellvertretung fest. Ein Alarm aus Support, Bug-Bounty-Programm, SOC oder Kundenmeldung muss unmittelbar einem Incident-Owner zugeordnet werden. Dokumentieren Sie Zeitstempel mit Zeitzone, Quelle, erste Einschätzung und den Status der Entscheidung. Prüfen Sie die Details im Einzelfall anhand der EU-Vorgaben.
72-Stunden-Frist und Abschlussbericht sauber unterscheiden
Auf die Frühwarnung folgt grundsätzlich die eigentliche Meldung innerhalb von 72 Stunden nach Kenntniserlangung. Für aktiv ausgenutzte Schwachstellen ist ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme vorgesehen. Für schwerwiegende Sicherheitsvorfälle gilt grundsätzlich eine andere Abschlussfrist: spätestens einen Monat nach der 72-Stunden-Meldung. Deshalb sollte Ihr Ticket-System Ereignisklasse und Fristberechnung getrennt abbilden.
Stellen Sie für jede Eskalationsstufe einen Freigabeweg sicher: technische Fakten werden vom PSIRT geprüft, regulatorische Kriterien von der zuständigen Funktion bewertet und die Kommunikation nach außen durch benannte Verantwortliche freigegeben. Eine Erinnerung kurz vor Fristende ist nur ein Backup; die operative Bearbeitung darf nicht davon abhängen.
Technischer Melde-Workflow für mittelständische Hersteller
Ein praxistauglicher Prozess besteht aus fünf Phasen. Erkennen: Sicherheitsmeldungen aus Monitoring, CERT-Informationen, Kundentickets, Code-Scans und Forschermeldungen erfassen. Bewerten: Betroffenheit und tatsächliche Ausnutzung verifizieren. Eskalieren: Herstellerrolle, Meldekategorie und Fristen entscheiden. Melden: den Vorgang über die CRA Single Reporting Platform abwickeln. Nachbereiten: Ursache, Maßnahme, Nachweis und Lessons Learned dokumentieren.
Jede Phase braucht ein überprüfbares Ergebnis. Ein einziges unstrukturiertes E-Mail-Postfach reicht meist nicht. Sinnvoll sind eine zentrale Incident-ID, eindeutige Eigentümerschaft, Versionierung der Aussagen und eine Liste der tatsächlich betroffenen Produktfamilien. Wo möglich, automatisieren Sie Erinnerungen, aber niemals die endgültige Meldeentscheidung ohne verantwortliche Person.
SBOM, Asset-Inventar und Produktsicherheit verknüpfen
Viele Teams wissen, dass eine Bibliothek gefährdet ist, können aber nicht schnell sagen, in welchen ausgelieferten Produkten und Versionen sie steckt. Eine Software Bill of Materials (SBOM) hilft, Abhängigkeiten sichtbar zu machen. Ergänzen Sie diese durch Build-Herkunft, Release-Kanäle, Wartungszeiträume, Signaturen und eine Kontaktstelle für koordinierte Schwachstellenmeldungen.
Eine SBOM allein erkennt keine aktive Ausnutzung. Verbinden Sie deshalb externe Hinweise, Schwachstellendaten, interne Telemetrie und Produktinventare. Priorisieren Sie nach realer Exposition, Angriffsmöglichkeit und Folgen für Kunden. So entsteht aus einer Dateiliste ein handlungsfähiger Product-Security-Prozess.
Schnittstelle zu NIS2, DSGVO und Kundenkommunikation
CRA, NIS2 und DSGVO haben unterschiedliche Adressaten, Kriterien und Meldewege. Ein technischer Vorfall kann mehrere Prüfungen auslösen, aber eine CRA-Meldung ersetzt nicht automatisch eine andere gesetzliche Meldung. Legen Sie dafür eine Melde-Matrix an: Was ist passiert? Wer ist betroffen? Welche Verpflichtung greift? Welche Frist startet wann? Wer entscheidet?
Auch ohne direkte Meldepflicht kann Kundeninformation notwendig sein, etwa damit Anwender einen Patch einsetzen oder eine exponierte Schnittstelle absichern. Gute Kommunikation benennt betroffene Versionen, technische Voraussetzungen, empfohlene Gegenmaßnahmen und den geplanten Update-Pfad. Vermeiden Sie unbelegte Zusicherungen wie „vollständig sicher“.
30-Tage-Plan für die Umsetzung der CRA Meldepflicht 2026
Woche 1: Betroffene Produkte, juristische Rollen, Ansprechpartner und bestehende Incident-Prozesse aufnehmen. Woche 2: Melde-Matrix, Einstufungskriterien, Vorlagen sowie 24-/72-Stunden-Timer definieren. Woche 3: SBOM- und Release-Daten anbinden, Berechtigungen zur Meldeplattform klären und Eskalationsketten testen. Woche 4: einen simulierten Vorfall durchspielen und messen, ob alle Freigaben auch abends und am Wochenende funktionieren.
Dokumentieren Sie beim Test nicht nur die Bearbeitungszeit, sondern auch Medienbrüche, fehlende Kontaktinformationen, unklare Produktzuordnungen und verzögerte Entscheidungen. Eine kurze nachprüfbare Übung ist wertvoller als ein umfangreiches Dokument ohne gelebten Prozess.
Häufige Fragen zur CRA Meldepflicht 2026
Gilt die Pflicht schon jetzt? Ja, die im CRA vorgesehenen Meldepflichten gelten seit dem 11. September 2026; die weitreichenden Produktanforderungen folgen überwiegend im Dezember 2027. Wo wird gemeldet? Über die von ENISA bereitgestellte Single Reporting Platform. Ist jede CVE meldepflichtig? Nein, die gesetzlichen Tatbestände müssen konkret geprüft werden. Reicht eine automatisierte Meldung? Automatisierung kann Fristen sichern; Verantwortlichkeit und fachliche Prüfung bleiben wesentlich.
Fazit: Wer Produktinventar, Security Monitoring, Incident Response und klar benannte Verantwortliche verbindet, kann regulatorische Fristen beherrschbar machen. Für Hersteller ist die CRA Meldepflicht 2026 vor allem eine Frage von vorbereitetem Handeln und belastbarer Dokumentation.
Offizielle Quellen und weiterführende Hinweise: Europäische Kommission: CRA-Meldepflichten · ENISA: Single Reporting Platform · CRA-Zeitplan.
Weitere Praxisbeiträge: Active Directory Security Assessment und IT-Notfallplan testen. Für die technische Umsetzung eines Incident-Response-Prozesses unterstützt GORTNET Cybersecurity Unternehmen mit Bestandsaufnahme und priorisiertem Maßnahmenplan.