PFLICHTEN, FRISTEN, FUNDSTELLEN

Was der Cyber Resilience Act von Ihnen verlangt

Seit dem 11.09.2026 gelten die Meldepflichten des CRA. Diese Seite stellt zusammen, welche Ereignisse eine Meldung auslösen, welche Fristen laufen, an wen gemeldet wird und welche Pflichten daneben bestehen — jeweils mit der Fundstelle in der Verordnung, damit Sie selbst beurteilen können, was davon Ihr Haus betrifft.

DIE FRAGE VOR ALLER TECHNIK

Wer bei Ihnen bemerkt es — und wer schreibt in 24 Stunden die Meldung?

Die Verordnung verlangt keine Abteilung und kein Werkzeug. Sie verlangt, dass jemand rechtzeitig hinschaut, richtig einordnet, fristgerecht meldet und es belegen kann. Wenn diese Rollen bei Ihnen nicht benannt sind, ist das der erste Punkt — vor jeder Software.

RECHTLICHER STAND DIESER SEITE

Die Angaben hier sind recherchiert (Stand Juli 2026, Sekundärquellen mit Zitat des Verordnungswortlauts) und rechtlich nicht validiert. Verbindlich ist allein der Originaltext der Verordnung (EU) 2024/2847 zusammen mit dem deutschen CRA-Durchführungsgesetz. Resilvance leistet Prozessunterstützung und keine Rechtsberatung; die Bewertung und jede Meldung bleiben beim Hersteller.

Wo eine Auslegung offen ist, steht das auf dieser Seite ausdrücklich dabei (siehe Abschnitt 3). Für eine rechtsverbindliche Beurteilung Ihres Falls ziehen Sie anwaltlichen Rat hinzu.

Ab wann gilt was

10.12.2024

In Kraft getreten

Die Verordnung gilt unmittelbar in allen Mitgliedstaaten; keine nationale Umsetzung nötig.

11.09.2026

Meldepflichten

Art. 14 CRA ist anwendbar. Die europäische geht in Betrieb, das nimmt Meldungen an.

11.12.2027

Alle übrigen Pflichten

Produktanforderungen nach Anhang I, und greifen vollständig.

Art. 64 CRA Bei Verstößen gegen die Anforderungen des Anhangs I sowie gegen Art. 13 und Art. 14 sind Geldbußen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vorgesehen, je nachdem, welcher Betrag höher ist. Die Bemessung berücksichtigt unter anderem Schwere und Dauer des Verstoßes sowie die Unternehmensgröße.

Zwei Ereignisse lösen eine Meldung aus — und nur diese zwei

Routinemäßige Fehler und regulär gepatchte Schwachstellen ohne Ausnutzungsnachweis fallen nicht unter die Meldepflicht. Sie laufen über das normale Schwachstellenmanagement, das Anhang I Teil II ohnehin verlangt.

Art. 3 + Art. 14 CRA

Aktiv ausgenutzte Schwachstelle

Art. 3 definiert die aktiv ausgenutzte Schwachstelle: Es liegt ein belastbarer Nachweis vor, dass ein böswilliger Akteur über sie Schadcode auf einem System ausgeführt hat, ohne Zustimmung des Inhabers. Art. 14 verlangt die Meldung, wenn diese Schwachstelle in Ihrem Produkt enthalten ist.

Eine bekannte, aber nicht ausgenutzte Schwachstelle löst die Meldepflicht nicht aus.

Art. 14 CRA · Art. 6 Nr. 6 NIS2

Schwerwiegender Sicherheitsvorfall

Der zweite Auslöser verweist auf die NIS2-Richtlinie (EU) 2022/2555: ein Vorfall, der die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Daten zu schützen beziehungsweise Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sicherzustellen.

Dieser Auslöser steht in keinem Datenfeed. Er kommt aus dem Feld: ein Kundenanruf, ein Support-Ticket, eine Auffälligkeit in der Fernwartung. Kein Monitoring der Welt fängt ihn ab — er braucht einen benannten Prozess im Unternehmen.

Vier Stufen zwischen Datenbanktreffer und Meldepflicht

Diese vier Dinge werden regelmäßig durcheinandergebracht — mit teuren Folgen in beide Richtungen: entweder wird vorsorglich gemeldet, was nie meldepflichtig war, oder ein echter Fall wird als „nur ein CVE“ abgetan.

Technischer Treffer
Eine Schwachstellenquelle nennt Paketname und Version aus Ihrer Stückliste. Das ist ein Datenbankabgleich und sagt nichts darüber, ob jemand die Schwachstelle angreift.
→ belegt keine Ausnutzung
Hinweis auf aktive Ausnutzung
Ein Katalog wie oder die EUVD der führt die Schwachstelle als tatsächlich ausgenutzt. Das ist der praktische Prüf- und Eskalationsauslöser.
→ belegt keine Betroffenheit Ihres Produkts
Enthaltensein im Produkt
Erst die Prüfung von Version, Zielplattform, Architektur, Distribution und Patch-Stand, Build-Konfiguration und Auslieferungsumfang zeigt, ob die Schwachstelle in Ihrem ausgelieferten Produkt steckt. Ein Paket-Treffer allein belegt das nicht.
→ ist noch keine Meldepflicht
Bestätigte Meldepflicht
Die Entscheidung, dass ein meldepflichtiges Ereignis vorliegt, trifft der Hersteller — mit Begründung und Beleg. Keine Software entscheidet das für Sie.
→ Ihre Entscheidung, Ihre Freigabe

OFFENE AUSLEGUNGSFRAGE — HIER IST DAS BILD NICHT KLAR

Art. 3 beschreibt die aktive Ausnutzung ohne Bezug auf ein bestimmtes Produkt; nach dieser Lesart wäre ein belastbarer Ausnutzungsnachweis irgendwo auf der Welt zusammen mit dem Enthaltensein in Ihrem Produkt ausreichend. Erwägungsgrund 68 der Verordnung ist dagegen produktbezogen formuliert und zieht in die andere Richtung.

Welche Lesart gilt, ist nicht abschließend geklärt. Praktische Folge: Ein Ausnutzungshinweis zu einer Komponente, die in Ihrem Produkt steckt, ist mindestens ein Prüfauslöser mit dokumentierter Entscheidung — nichts, was man wegwinkt, und nichts, was automatisch eine Meldung wird.

Was Art. 14 nicht verlangt: den Nachweis, dass der verwundbare Code zur Laufzeit überhaupt erreicht wird. Die Frage ist, ob die Schwachstelle im Produkt enthalten ist — beantwortbar aus Build- und Auslieferungsfakten von dem, der den Build fährt. Eine Erreichbarkeitsanalyse ist eine freiwillige Verfeinerung, keine Pflicht.

Die Meldekette hat drei Stufen, nicht eine

Art. 14 CRA Alle Fristen laufen ab Kenntnisnahme durch den Hersteller.

Frühwarnung

unverzüglich, spätestens 24 Stunden

BEI EINER SCHWACHSTELLE: Betroffene Mitgliedstaaten, in denen das Produkt bereitgestellt wurde.
BEI EINEM VORFALL: Verdacht auf eine rechtswidrige oder böswillige Handlung, betroffene Mitgliedstaaten.

Meldung

72 Stunden

BEI EINER SCHWACHSTELLE: Allgemeine Produktinformation, Art der Schwachstelle und der Ausnutzung, ergriffene Korrektur- und Risikominderungsmaßnahmen, Maßnahmen für Nutzer.
BEI EINEM VORFALL: Art des Vorfalls, erste Bewertung, ergriffene Maßnahmen, Hinweise für Nutzer.

Abschlussbericht

14 Tage nach Verfügbarkeit einer Korrekturmaßnahme — bei Vorfällen spätestens einen Monat nach der 72-Stunden-Meldung

BEI EINER SCHWACHSTELLE: Beschreibung inklusive Schweregrad und Auswirkungen, Angaben zu den Akteuren, Details zu den .
BEI EINEM VORFALL: Detaillierte Analyse, Ursachen, Schwere, Auswirkungen, Abhilfemaßnahmen.

Schweregrad und Angaben zu den Angreifern gehören ausdrücklich erst in Stufe 3, nicht in die 72-Stunden-Meldung. Die verbindlichen Pflichtfelder je Stufe stehen noch nicht endgültig fest — sie kommen mit dem technischen Durchführungsrechtsakt beziehungsweise dem ENISA-Meldeformular.

Deshalb ist „vorsichtshalber melden“ keine Strategie: Eine Meldung ist nicht der Ausgang eines Vorgangs, sondern der Eingang in einen — mit Nachlieferpflicht bis zum Abschlussbericht. Wer im Zweifel meldet, verpflichtet sich zur Fortschreibung eines Falls, den er noch nicht bewertet hat.

An wen gemeldet wird — und auf welchem Weg

Art. 15 + Art. 16 CRA

Eine Meldung, ein Eingang

Gemeldet wird gleichzeitig an das koordinierende nationale CSIRT und an ENISA, über die zentrale elektronische Single Reporting Platform. Eine Einreichung genügt; die Weiterleitung an weitere betroffene Mitgliedstaaten und gegebenenfalls an Marktüberwachungsbehörden erfolgt von dort. Zuständig ist das CSIRT am Ort Ihrer Hauptniederlassung in der EU.

Deutschland — Gesetzgebung läuft

Das BSI in vier Rollen

Der Regierungsentwurf des CRA-Durchführungsgesetzes (BT-Drs. 21/6134, erste Lesung am 11.06.2026) benennt das BSI als Marktüberwachungsbehörde, notifizierende Behörde, CSIRT-Meldestelle und Verbraucherbeschwerdestelle; für Hochrisiko-KI ist voraussichtlich die Bundesnetzagentur zuständig. Die finale Verkündung war zum Recherchezeitpunkt nicht bestätigt — die BSI-Zuweisung gilt aber als politisch gesetzt.

Eine eigene nationale Meldeplattform gibt es nicht: Das BSI empfängt über die europäische Plattform.

Keine Schnittstelle zum Start: Die Meldung erfolgt über ein Web-Formular, nicht über eine API. Ein Werkzeug kann deshalb den Entwurf liefern und die Fristen führen — einreichen muss ein Mensch mit Freigabe. Als Referenzrahmen für Stückliste und Meldeverfahren dient die Technische Richtlinie des BSI TR-03183 (Teil 2 zur Stückliste, Teil 3 zum Meldeverfahren).

Die Pflichten neben der Meldung

Art. 14 Abs. 8 CRA

Betroffene Nutzer informieren

Nach der Meldung sind die betroffenen Nutzer unverzüglich zu informieren, inklusive der Maßnahmen zur Risikominderung und nach Möglichkeit maschinenlesbar. Bleibt der Hersteller untätig, können die CSIRTs selbst informieren.

Art. 13 CRA

Schwachstellen in Fremdkomponenten weitermelden

Wird eine Schwachstelle in einer integrierten Komponente festgestellt — auch in einer Open-Source-Komponente —, ist sie deren Hersteller oder Betreuer zu melden; entwickelte Korrekturen und Dokumentation sind zu teilen. Das ist eine Kooperationspflicht in der Lieferkette, keine Behördenmeldung.

Art. 13 CRA

Sicherheitsupdates im Supportzeitraum

Für die Dauer des festgelegten Supportzeitraums — im Regelfall mindestens fünf Jahre — sind Schwachstellen zu behandeln und Sicherheitsupdates bereitzustellen.

Wer sagt „bei uns ändert sich am Code nichts“, sagt in CRA-Sprache: „Wir haben ein ungedecktes Versprechen.“ Ein eingefrorenes Produkt hat keinen Update-Pfad — und neue Schwachstellen entstehen in seinen Bibliotheken trotzdem, oft Jahre nach der Auslieferung. Das ist ein Geschäftsführungsthema, kein Entwicklerthema.

Anhang I Teil II CRA

Schwachstellen behandeln und dokumentieren

Die Komponenten des Produkts sind zu kennen und in einer Software-Stückliste zu führen, Schwachstellen unverzüglich zu behandeln, das Produkt regelmäßig zu prüfen und die Ergebnisse zu dokumentieren. Genau hier wird jedes dokumentierte „nicht enthalten“ zum Nachweis — und nicht erst der Fund.

Art. 24 CRA Für Open-Source-Verwalter (Stewards) gilt eine eigene, leichtere Pflichtenkategorie mit Cybersicherheitsrichtlinie und Meldepflicht für aktiv ausgenutzte Schwachstellen.

Wie ein Ernstfall abläuft

Die entscheidende Beobachtung: Die Fragen sind bei jedem Treffer dieselben — und fast alle Antworten hängen am Produkt, nicht am Treffer. Wer sie erst nach Fristbeginn sammelt, verliert den ersten Tag mit internen Rückfragen.

Hinweis trifft ein
Aus einem Schwachstellenkatalog, von einem Kunden, aus dem Support oder aus der Fernwartung. Der zweite Weg ist der unangenehmere: Ein Vorfall steht in keinem Datenfeed.
Kenntnisnahme — hier startet die Uhr
Die 24 Stunden laufen ab , nicht ab dem Zeitpunkt, an dem der Kollege erreichbar ist, der die Build-Konfiguration kennt.
Enthaltensein prüfen
Richtige Version im Image? Passende Plattform und Architektur? Betroffene Funktion einkompiliert und ausgeliefert? Distributions-Patch zurückportiert? Das sind Tatsachenfragen über Build und Auslieferung — keine Quellcode-Analyse.
Ergebnis festhalten
Vier zulässige Endzustände: nicht enthalten · enthalten, nach heutigem Kenntnisstand nicht meldepflichtig · enthalten und meldepflichtig · Untersuchung läuft, nächste Bewertung am genannten Termin. Jeder Endzustand braucht Begründung und Beleg.
Fristen abarbeiten
binnen 24 Stunden, Meldung binnen 72 Stunden, Nutzerinformation unverzüglich, Abschlussbericht nach der Korrekturmaßnahme. Eine konservative Erstmeldung ist möglich, bevor alles verstanden ist.
Nachweis ablegen
Zeitpunkt, geprüftes Produkt, Stand der Stückliste, verwendete Datenquellen, Entscheidung und Begründung. Auch das Ergebnis „nicht enthalten“ ist ein Nachweis — und die Vorlage für spätere -Aussagen gegenüber Ihren B2B-Abnehmern.

Wer im Ernstfall was leistet

Die Arbeit zerfällt in drei Pakete. Die Grenze zwischen ihnen benennen wir vorab und nicht im Ernstfall:

Entscheiden

Enthalten? Betroffen? Meldepflichtig?

Vorbereitet und geführt von Resilvance — freigegeben von Ihnen.

Melden

Fristen, Entwürfe für alle drei Stufen, Nutzerinformation, Nachweis.

Resilvance bereitet vor, eingereicht wird von Ihnen: Die hat keine Schnittstelle, und die Freigabe bleibt beim Hersteller.

Beheben

Bibliothek aktualisieren, Release bauen, Update ausliefern.

Ihre Entwicklung. Die Bereitstellung von im ist Herstellerpflicht und nicht delegierbar.

Ein Hersteller mit eigener Entwicklung hat kein Behebungsproblem — eine Bibliothek zu aktualisieren und ein Release zu bauen tut sein Team ohnehin. Er hat ein Erkennungs-, Einordnungs- und Nachweisproblem. Genau dort setzt unser Angebot an, und es endet mit der eingereichten Meldung und dem Nachweis — nicht mit dem ausgelieferten Update.

Beantworten Sie diese Fragen einmal vorher, nicht unter Frist

Der Erstauftrag arbeitet den Prüfpfad einmal für eine Produktfamilie durch: Stückliste und Produktsteckbrief erheben, Ist-Bild gegen die Schwachstellenquellen, die produktabhängigen Fragen vorab beantwortet, der Meldeprozess mit benannten Personen und Fristen auf Papier — und ein Prüfbericht, den Sie vorzeigen können.

Der Erstauftrag im Überblick →Was wir im Dauerbetrieb liefern

Quellen

Zusammenstellung auf Basis einer Recherche vom Juli 2026. Fundstellen zur Verordnung (EU) 2024/2847 (CELEX 32024R2847); die Artikelbezüge sind Orientierung, nicht Zitat. Keine Rechtsberatung.