CRA-Meldepflicht: 24 Stunden, seit September scharf
Seit dem 11. September 2026 – vor knapp drei Wochen – gilt die erste verbindliche Meldepflicht des Cyber Resilience Act (CRA): Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden an ENISA und das zuständige nationale CSIRT melden. Anders als die noch ferne vollständige CRA-Konformitätspflicht ab Dezember 2027 ist das kein Dokument, das irgendwann fertig sein muss, sondern ein operativer Prozess, der im Ernstfall ab sofort tatsächlich innerhalb von 24 Stunden funktionieren muss. Für Software-Teams, die bislang keinen strukturierten Schwachstellen-Meldeprozess hatten, ist das eine völlig neue Art von Zeitdruck.
Status Was seit dem 11. September konkret gilt
Der CRA selbst ist bereits seit Dezember 2024 in Kraft, seine Anwendbarkeit ist aber gestaffelt. Am 11. September 2026 wurde konkret Artikel 14 scharf geschaltet: die Pflicht, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden, die die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen. Wichtig zur Einordnung: Nicht jede theoretisch denkbare Schwachstelle löst diese Pflicht aus – entscheidend ist, dass sie nachweislich aktiv ausgenutzt wird. Eine rein hypothetische oder nur intern entdeckte, nicht ausgenutzte Schwachstelle fällt nicht unter diese konkrete Meldepflicht. Bereits am 11. Juni 2026, drei Monate zuvor, waren zudem die Bestimmungen zur Notifizierung von Konformitätsbewertungsstellen in Kraft getreten – ein vorbereitender Schritt, der in der öffentlichen Wahrnehmung deutlich weniger Aufmerksamkeit erhielt als die eigentliche Meldepflicht.
Fristen Die drei gestaffelten Meldungen im Detail
Praxis Warum das ein technischer Prozess ist, kein Compliance-Dokument
Eine 24-Stunden-Frist lässt sich nicht mit einer nachträglich erstellten Richtlinie einhalten – sie erfordert einen bereits eingespielten operativen Ablauf. Dazu gehört ein klar definierter, öffentlich auffindbarer Kontaktpunkt für Sicherheitsforschende, eine interne Eskalationskette, die auch außerhalb der Kernarbeitszeit funktioniert, und eine Entscheidungsbefugnis, die eine Meldung auslösen kann, ohne erst mehrere Freigabeschleifen durchlaufen zu müssen. Unternehmen, die noch keinen etablierten PSIRT-Prozess (Product Security Incident Response Team) haben, sollten diesen jetzt aufbauen, statt im Ernstfall zu improvisieren. Ein realistischer Test dafür: Könnte das eigene Team heute Nacht um drei Uhr innerhalb von 24 Stunden eine vollständige Frühwarnung erstellen, wenn eine aktiv ausgenutzte Schwachstelle gemeldet würde?
SBOM als praktische Voraussetzung: Eine Software Bill of Materials ist für die reine Meldepflicht nach Art. 14 formal nicht zwingend vorgeschrieben, in der Praxis aber kaum verzichtbar: Ohne eine aktuelle Übersicht der eigenen Softwarekomponenten lässt sich eine öffentlich bekannt gewordene Schwachstelle (CVE) nicht zuverlässig den eigenen Produkten zuordnen – und genau diese Zuordnung ist die Voraussetzung dafür, überhaupt zu wissen, ob eine Meldepflicht ausgelöst wurde. Gerade bei Produkten mit vielen Abhängigkeiten von Drittanbieter-Bibliotheken summiert sich dieser Prüfaufwand schnell, wenn keine aktuelle SBOM vorliegt.
Einordnung Abgrenzung zu NIS2
CRA und NIS2 ergänzen sich, decken aber unterschiedliche Ebenen ab: NIS2 richtet sich an den Betrieb von Unternehmen in bestimmten kritischen Sektoren und verlangt organisatorisches Risikomanagement. Der CRA setzt dagegen am Produkt und am Hersteller an – unabhängig davon, in welcher Branche das Produkt eingesetzt wird. Ein Unternehmen kann durchaus gleichzeitig NIS2-pflichtig als Betreiber und CRA-pflichtig als Hersteller eigener Software sein, etwa wenn es eine selbst entwickelte Anwendung im eigenen Betrieb und gleichzeitig am Markt vertreibt. In diesem Fall lohnt sich eine koordinierte Betrachtung beider Meldewege, da sich Zuständigkeiten und Fristen im Detail unterscheiden können.
Was ein Mindest-PSIRT-Setup jetzt braucht
- 01Öffentlicher Security-Kontaktpunkt – eine auffindbare Adresse oder ein Formular, über das Sicherheitsforschende Schwachstellen melden können.
- 02Interne Eskalationskette definieren – wer entscheidet, ob eine Meldung ausgelöst wird, und das auch außerhalb der Regelarbeitszeit.
- 03SBOM aktuell halten – Grundlage, um eine gemeldete CVE überhaupt den eigenen Produkten zuordnen zu können.
- 04Meldeweg zur Single Reporting Platform kennen – nicht erst im Ernstfall herausfinden müssen, wie und wo gemeldet wird.
- 05CRA- und NIS2-Pflichten getrennt, aber koordiniert prüfen – beide Meldewege können parallel relevant sein.
Ein Thema, das auch uns selbst betrifft
Als Anbieter einer Software mit digitalen Elementen beobachten wir die CRA-Anforderungen auch für Fakturia selbst und halten unsere eigenen Prozesse für Schwachstellenmeldungen entsprechend bereit. Für Unternehmen, die eigene Software entwickeln oder vertreiben, lohnt sich jetzt der ehrliche Check, ob der eigene PSIRT-Prozess eine 24-Stunden-Frist tatsächlich einhalten könnte – nicht erst, wenn der Ernstfall eintritt und die Uhr bereits läuft.
Beratungsgespräch vereinbarenFazit
Die CRA-Meldepflicht ist seit dem 11. September 2026 kein Zukunftsthema mehr, sondern ein Prozess, der im Ernstfall funktionieren muss – mit einer Frist, die im deutschen Produktrecht bislang keine Entsprechung hatte. Wer noch keinen etablierten PSIRT-Prozess und keine aktuelle SBOM hat, sollte beides jetzt aufbauen, statt darauf zu hoffen, dass der Ernstfall erst nach der vollständigen CRA-Konformität ab Dezember 2027 eintritt. Die verbleibende Zeit bis dahin lässt sich sinnvoll nutzen, um genau die Prozesse zu etablieren, die dann ohnehin verpflichtend nachgewiesen werden müssen.
Häufige Fragen zur CRA-Meldepflicht
Muss jede Sicherheitslücke gemeldet werden?
Nein. Die seit 11. September 2026 geltende Meldepflicht betrifft aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Eine intern entdeckte, nicht aktiv ausgenutzte Schwachstelle löst diese konkrete Meldepflicht nicht aus.
Wie lange habe ich Zeit, eine ausgenutzte Schwachstelle zu melden?
Eine Frühwarnung muss innerhalb von 24 Stunden erfolgen, eine detaillierte Vollmeldung innerhalb von 72 Stunden, und ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme.
Ist eine SBOM für die Meldepflicht vorgeschrieben?
Formal ist eine Software Bill of Materials für die reine Meldepflicht nach Art. 14 nicht zwingend vorgeschrieben, in der Praxis aber kaum verzichtbar, um gemeldete Schwachstellen überhaupt den eigenen Produkten zuordnen zu können.
Was ist der Unterschied zwischen CRA und NIS2?
NIS2 richtet sich an den Betrieb von Unternehmen in bestimmten kritischen Sektoren, der CRA an das Produkt und den Hersteller selbst. Ein Unternehmen kann gleichzeitig in beide Pflichtenkreise fallen.