Cyber Resilience Act: Die Meldepflicht beginnt am 11. September 2026 — auch für längst verkaufte Produkte
Der Cyber Resilience Act — Verordnung (EU) 2024/2847 — wird fast überall mit dem 11. Dezember 2027 verbunden. Für die Meldepflichten stimmt das nicht: Sie gelten ab dem 11. September 2026, mit einer Frühwarnung binnen 24 Stunden und einer Meldung binnen 72 Stunden über die Single Reporting Platform der ENISA. Und sie gelten ausdrücklich auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Wer heute Software oder ein vernetztes Gerät im Markt hat, ist damit ab September betroffen — auch ohne ein einziges neues Produkt.
Der Cyber Resilience Act (CRA) ist die Verordnung (EU) 2024/2847. Voll anwendbar ist sie ab dem 11. Dezember 2027 — die Meldepflichten ihres Artikels 14 gelten jedoch bereits ab dem 11. September 2026: eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden, beides über die Single Reporting Platform der ENISA. Diese Meldepflicht gilt ausdrücklich auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Wer heute Software oder ein vernetztes Gerät im Markt hat, ist damit ab September 2026 betroffen — auch dann, wenn er bis dahin kein einziges neues Produkt ausliefert.
11.09.2026
Meldepflichten nach Art. 14 CRA: 24-Stunden-Frühwarnung, 72-Stunden-Meldung
auch Bestand
Gilt ausdrücklich auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden
11.12.2027
Volle Anwendbarkeit — u. a. SBOM und Konformitätsbewertung
15 Mio. € / 2,5 %
Sanktionsobergrenze nach Art. 64 Abs. 2 — nicht 35 Mio. €/7 %
Keine Rechtsberatung – Angaben ohne Gewähr. Beträge, Fristen und Schwellen können sich ändern; im Zweifel Fachperson hinzuziehen.
Häufige Fragen
Gilt der Cyber Resilience Act erst ab dem 11. Dezember 2027?
Nein — für die Meldepflichten nicht. Voll anwendbar ist die Verordnung (EU) 2024/2847 ab dem 11. Dezember 2027; dann greifen unter anderem SBOM und Konformitätsbewertung. Die Meldepflichten des Artikels 14 gelten aber schon ab dem 11. September 2026: eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden über die Single Reporting Platform der ENISA. Sie gelten ausdrücklich auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.
Wie viel Zeit habe ich, wenn eine Schwachstelle in meinem Produkt aktiv ausgenutzt wird?
Nach Artikel 14 des Cyber Resilience Act (Verordnung (EU) 2024/2847) gelten ab dem 11. September 2026 zwei Fristen: eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden, beides über die Single Reporting Platform der ENISA. Welche weiteren Auslöser Artikel 14 kennt und ob ein Abschlussbericht verlangt wird, haben wir nicht an der Primärquelle geprüft und sagen es deshalb hier nicht.
Betrifft mich der CRA, wenn ich nur alte Produkte im Markt habe und nichts Neues entwickle?
Sehr wahrscheinlich ja. Die Meldepflicht ab dem 11. September 2026 gilt ausdrücklich auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Ein Entwicklungsstopp verschiebt den Stichtag für die volle Anwendbarkeit, nicht den für die Meldepflicht. Dass Sie keine Updates mehr liefern, ändert an dem Umstand, an den die Pflicht anknüpft, ebenfalls nichts — ob die Verordnung einen Unterstützungszeitraum kennt, nach dessen Ablauf Pflichten enden, haben wir nicht geprüft.
Wo wird eine CRA-Meldung abgegeben?
Über die Single Reporting Platform der ENISA. Ob daneben eine nationale Meldung erforderlich ist und welche deutsche Behörde zuständig ist, gehört zu den Punkten, die wir bewusst offenlassen — dazu liegt uns keine an der Primärquelle geprüfte Angabe vor.
Wie hoch sind die Sanktionen nach dem Cyber Resilience Act?
Artikel 64 Absatz 2 der Verordnung (EU) 2024/2847 nennt eine Obergrenze von bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Die häufig dem CRA zugeschriebenen 35 Mio. € beziehungsweise 7 % stammen aus einem anderen Rechtsakt: Es sind die Werte der KI-Verordnung für die verbotenen Praktiken nach ihrem Artikel 5. Welche konkreten Verstöße unter welche Sanktionsstufe fallen, sagen wir nicht — Artikel 64 hat mehrere Absätze, und geprüft ist bei uns die Stufe mit 15 Mio. € / 2,5 %.
Ersetzt eine CRA-Meldung die Meldung nach NIS2 oder nach der DSGVO?
Nein. Das sind drei verschiedene Rechtsakte mit verschiedenen Adressaten und Auslösern: Der CRA nimmt Sie als Hersteller eines Produkts in die Pflicht und führt zur Single Reporting Platform der ENISA, NIS2 betrifft Sie als reguliertes Unternehmen gegenüber dem BSI, und Artikel 33 DSGVO verlangt bei einer Verletzung des Schutzes personenbezogener Daten binnen 72 Stunden eine Meldung an die Datenschutz-Aufsichtsbehörde. Ein einzelner Vorfall kann alle drei gleichzeitig auslösen.
Warum nennt dieser Leitfaden keine Produktklassen und keine Ausnahmen?
Weil wir sie nicht an der Primärquelle geprüft haben. Zum CRA sind für uns derzeit fünf Angaben geprüft: die Rechtsakt-Nummer (Verordnung (EU) 2024/2847), die Meldepflichten nach Artikel 14 ab dem 11.09.2026 mit 24 und 72 Stunden über die ENISA-Plattform, deren ausdrückliche Geltung auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden, die volle Anwendbarkeit ab dem 11.12.2027 samt SBOM und Konformitätsbewertung sowie die Sanktionsstufe nach Artikel 64 Absatz 2. Alles Weitere — Produktdefinition, Klassen, Ausnahmen für Open Source oder Cloud-Dienste, Unterstützungszeiträume — listen wir im Abschnitt „Was wir bewusst nicht sagen" als offene Punkte auf, statt Angaben aus zweiter Hand zu übernehmen.
Warum dieser Leitfaden kürzer ist, als Sie es von anderen kennen. Wir nennen zum CRA bewusst nur die fünf Angaben oben — sie sind an der Primärquelle geprüft. Produktklassen, Ausnahmen, Unterstützungszeiträume und weitere Sanktionsstufen, die anderswo zum CRA kursieren, stehen hier nicht, weil wir sie noch nicht geprüft haben. Der Abschnitt „Was wir bewusst nicht sagen" listet das offen auf. Eine Angabe, die man nicht nachschlagen kann, ist in einer Compliance-Planung wertlos — und in einer Kundenkommunikation gefährlich.
Der 11. September 2026: zwei Uhren beginnen zu laufen
Ab dem 11. September 2026 gelten die Meldepflichten des Artikels 14. Sie bestehen aus zwei aufeinanderfolgenden Schritten mit sehr kurzen Fristen:
Schritt
Frist
Weg
Frühwarnung
24 Stunden
Single Reporting Platform der ENISA
Meldung
72 Stunden
Single Reporting Platform der ENISA
Schritt
Frühwarnung
Frist
24 Stunden
Weg
Single Reporting Platform der ENISA
Schritt
Meldung
Frist
72 Stunden
Weg
Single Reporting Platform der ENISA
Der geprüfte Auslöser ist eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen. „Aktiv ausgenutzt" heißt: Es geht nicht um jede gefundene Lücke, sondern um den Fall, dass sie tatsächlich angegriffen wird.
24 Stunden sind keine Frist, die man mit gutem Willen einhält — sie sind eine Frist, die man vorbereitet. Ein Angriff hält sich nicht an Bürozeiten. Wenn eine Kundenmeldung am Freitagabend eingeht, entscheidet nicht die Rechtslage, ob Sie am Samstag melden, sondern ob im Betrieb jemand benannt ist, ihn jemand erreicht und er weiß, wo er die Meldung absetzt. Diese drei Punkte sind organisatorisch, nicht juristisch — und genau deshalb kann man sie heute schon erledigen.
Wichtig für die Erwartung: Wie viele Auslöser Artikel 14 insgesamt kennt, sagen wir hier nicht. Geprüft ist die aktiv ausgenutzte Schwachstelle. Ob daneben weitere Ereignisse eine Meldung auslösen und mit welchen Fristen, gehört zu den offenen Punkten am Ende dieser Seite — gehen Sie also nicht davon aus, dass die Liste vollständig ist.
Der Punkt, den fast niemand nennt: Bestandsprodukte
Die meisten Beiträge zum CRA beginnen und enden mit dem 11. Dezember 2027. Das ist nicht falsch — es ist unvollständig, und die Lücke ist ausgerechnet die teure.
Die Meldepflicht ab dem 11. September 2026 gilt ausdrücklich auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Anders gesagt: Sie erfasst genau die Produkte, die heute schon draußen sind. Kein Hersteller kann sich darauf zurückziehen, seine Software sei „von vor dem CRA".
Für die betriebliche Planung dreht dieser Satz die Reihenfolge um:
Sie brauchen die Meldefähigkeit vor der Konformität. Erst kommt die Frage „Können wir am 11. September 2026 binnen 24 Stunden melden?", dann die Frage „Sind unsere Produkte am 11. Dezember 2027 konform?". Die meisten Projektpläne, die derzeit herumgereicht werden, machen es umgekehrt.
Ein Produkt-Stopp hilft nicht. „Wir bringen bis 2027 nichts Neues heraus" verschiebt den 11. Dezember 2027, aber nicht den 11. September 2026 — der hängt am Bestand, nicht am Neugeschäft.
Auch ein eingestelltes Produkt ist in Verkehr gebracht worden. Dass Sie keine Updates mehr liefern, ändert nichts an der Tatsache, an die die Meldepflicht anknüpft. Ob die Verordnung einen Unterstützungszeitraum kennt, nach dessen Ablauf Pflichten entfallen, haben wir nicht geprüft — verlassen Sie sich also nicht darauf, sondern lassen Sie es prüfen.
Wer wissen will, ob und wie hart ihn das trifft, sortiert die Lage in unter einer Minute mit dem CRA-Betroffenheits-Check. Er ersetzt keine Rechtsberatung, macht aber genau diese Bestandsfalle sichtbar.
Zwei Daten, zwei völlig verschiedene Projekte
Der CRA hat für die Praxis zwei Stichtage, und sie verlangen Unterschiedliches:
Datum
Was greift
Was das im Betrieb heißt
11.09.2026
Meldepflichten nach Art. 14 (24 h / 72 h, ENISA-Plattform) — auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden
Ein Prozess: Wer bemerkt es, wer entscheidet, wer meldet, wie am Wochenende?
11.12.2027
Volle Anwendbarkeit — unter anderem SBOM und Konformitätsbewertung
Ein Produkt- und Datenprojekt: Stückliste der Software-Komponenten, Nachweise, Verfahren.
Datum
11.09.2026
Was greift
Meldepflichten nach Art. 14 (24 h / 72 h, ENISA-Plattform) — auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden
Was das im Betrieb heißt
Ein Prozess: Wer bemerkt es, wer entscheidet, wer meldet, wie am Wochenende?
Datum
11.12.2027
Was greift
Volle Anwendbarkeit — unter anderem SBOM und Konformitätsbewertung
Was das im Betrieb heißt
Ein Produkt- und Datenprojekt: Stückliste der Software-Komponenten, Nachweise, Verfahren.
Das erste Projekt kostet Organisation, das zweite kostet Entwicklungszeit. Wer beides in einen Topf wirft, plant in aller Regel das teure zuerst — und steht im September 2026 ohne Meldeweg da, während die SBOM-Werkzeugkette schon läuft.
Umgekehrt gilt: Die SBOM ist nichts, was man im Herbst 2027 anfängt. Eine belastbare Stückliste der eigenen Software-Komponenten wächst über Releases hinweg; sie ist außerdem genau die Grundlage, mit der man im Ernstfall in Stunden statt in Tagen beantworten kann, ob eine gemeldete Lücke überhaupt im eigenen Produkt steckt. Beide Stichtage arbeiten hier für einmal in dieselbe Richtung.
Die Zahl, die zum CRA fast überall falsch steht
Wenn Sie zum Cyber Resilience Act recherchieren, werden Sie regelmäßig auf 35 Mio. € oder 7 % des weltweiten Jahresumsatzes stoßen. Diese Zahlen gibt es — nur in einem anderen Rechtsakt.
Rechtsakt
Fundstelle
Obergrenze
Was im CRA steht
Verordnung (EU) 2024/2847 (CRA)
Art. 64 Abs. 2
bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes
Was oft dem CRA zugeschrieben wird
KI-Verordnung
Sanktionen für die verbotenen Praktiken nach Art. 5
35 Mio. € oder 7 %
Was im CRA steht
Rechtsakt
Verordnung (EU) 2024/2847 (CRA)
Fundstelle
Art. 64 Abs. 2
Obergrenze
bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes
Was oft dem CRA zugeschrieben wird
Rechtsakt
KI-Verordnung
Fundstelle
Sanktionen für die verbotenen Praktiken nach Art. 5
Obergrenze
35 Mio. € oder 7 %
Die Verwechslung ist nachvollziehbar: Beide Rechtsakte stammen aus derselben Digitalgesetzgebungs-Welle, beide sind EU-Verordnungen, und die 35/7-Zahl ist die medial bekannteste. Trotzdem ist sie zum CRA schlicht die falsche Fundstelle.
Warum uns dieser Punkt wichtig genug für einen eigenen Abschnitt ist: Eine Zahl, die in einer Vorstands- oder Geschäftsführungsvorlage steht und sich als aus dem falschen Gesetz abgeschrieben herausstellt, beschädigt die gesamte Vorlage — auch die richtigen Teile. Wer den CRA intern vertritt, sollte mit Artikel 64 Absatz 2 zitieren können und nicht mit einer Zahl aus dem Umlauf.
Und die Grenze auch hier: Welche konkreten Verstöße unter welche Sanktionsstufe fallen, sagen wir nicht. Artikel 64 hat mehrere Absätze; geprüft ist bei uns die Stufe mit 15 Mio. € / 2,5 %.
Wer betroffen ist — und wo wir die Grenze der geprüften Aussage ziehen
Der CRA richtet sich an Hersteller von Produkten mit digitalen Elementen — also an Hardware und an Software. Einschließlich der Produkte, die bereits verkauft sind.
Zwei Dinge, die dabei regelmäßig unterschätzt werden:
„Wir sind doch kein Software-Haus" ist keine Entwarnung. Wer ein Gerät baut, das sich verbindet oder Firmware enthält, verkauft ein Produkt mit digitalen Elementen — auch wenn der eigene Betrieb sich als Maschinenbauer, Anlagenbauer oder Elektrotechniker versteht.
Der Auslöser sitzt oft nicht bei Ihnen. Die Schwachstelle kann in einer zugekauften Bibliothek oder einem Fremdmodul stecken. Für die Meldeuhr ist entscheidend, dass sie in Ihrem Produkt steckt.
Hier endet unsere geprüfte Aussage — bewusst. Die Verordnung definiert artikelgenau, was ein Produkt mit digitalen Elementen ist, welche Rollen (Hersteller, Bevollmächtigter, Einführer, Händler) welche Pflichten tragen und welche Ausnahmen gelten. Zu keinem dieser Punkte treffen wir hier eine Aussage, weil wir die betreffenden Artikel noch nicht an der Primärquelle geprüft haben. Das betrifft insbesondere die Fragen, die uns am häufigsten gestellt werden: Wie ist Open Source erfasst? Wie ein reiner Cloud-Dienst ohne ausgeliefertes Produkt? Was gilt, wenn ein Produkt schon einem anderen Rechtsakt unterliegt? Eine Antwort darauf aus zweiter Hand abzuschreiben, wäre genau der Fehler, den wir bei anderen kritisieren.
Für eine erste Selbsteinordnung entlang der geprüften Punkte gibt es den CRA-Betroffenheits-Check. Auch er ersetzt keine Rechtsberatung.
Drei Uhren, drei Rechtsakte: CRA, NIS2 und die DSGVO
Der häufigste Denkfehler im Ernstfall ist nicht, die Frist zu verpassen — sondern zu glauben, man habe mit einer Meldung alles erledigt. In deutschen Betrieben können bei ein und demselben Vorfall drei völlig verschiedene Meldepflichten nebeneinanderstehen:
Worum es geht
Wohin
CRA
Aktiv ausgenutzte Schwachstelle in einem Produkt, das Sie in Verkehr gebracht haben (Art. 14, ab 11.09.2026)
Single Reporting Platform der ENISA
NIS2 / BSIG
Sicherheitsvorfall bei Ihnen als reguliertem Unternehmen — eine Betreiber-, keine Herstellerpflicht
Eine Meldung ersetzt die andere nicht. Die drei Pflichten haben verschiedene Adressaten, verschiedene Auslöser und verschiedene Rollen: Der CRA nimmt Sie als Hersteller in die Pflicht, NIS2 als Betreiber, die DSGVO als Verantwortlichen für personenbezogene Daten. Ein und derselbe Vorfall kann alle drei Rollen gleichzeitig berühren.
Praktische Konsequenz für den Notfallzettel: Nicht „wir melden binnen 72 Stunden" notieren, sondern je Pflicht getrennt festhalten, wer meldet, an wen und in welcher Frist. Ob zur CRA-Meldung über die ENISA-Plattform zusätzlich eine nationale Meldung tritt, gehört zu den offenen Punkten unten — auch das ist eine Frage für die rechtliche Prüfung, nicht für eine Annahme.
Was Sie bis September 2026 tun können — ohne Rechtsgutachten
Die folgenden Schritte sind organisatorisch, nicht juristisch. Sie kosten wenig, und sie sind unabhängig davon sinnvoll, wie die offenen Rechtsfragen ausgehen:
Ihre Produkte im Markt auflisten. Was haben Sie ausgeliefert, das Software ist oder Software enthält — auch das, was Sie nicht mehr aktiv pflegen? Eine Liste, kein Gutachten. Ohne sie kann niemand beurteilen, worauf sich eine Meldung überhaupt bezöge.
Einen Eingangskanal für Schwachstellenhinweise benennen. Eine erreichbare Adresse, die auch von außen zu finden ist, und ein Mensch, der dahinter sitzt. Der häufigste reale Fehler ist nicht die verpasste Frist, sondern die Meldung, die drei Wochen in einem unbeobachteten Postfach lag.
Die 24-Stunden-Uhr auf einen Wochenendtest stellen. Wer wird um 21 Uhr am Samstag erreicht, wer entscheidet, wer setzt die Meldung ab? Das einmal durchzuspielen, dauert eine Stunde und ist der einzige Weg, es vor dem Ernstfall zu wissen.
Den Meldeweg vorab klären. Die Meldung läuft über die Single Reporting Platform der ENISA. Wer dort im Ernstfall zum ersten Mal nachschaut, verliert genau die Stunden, die die Frist ausmachen.
Mit der Software-Stückliste anfangen. Nicht für September 2026, sondern für den 11. Dezember 2027 — und weil sie im Ernstfall die Frage beantwortet, ob eine bekannt gewordene Lücke überhaupt Ihr Produkt betrifft.
Die drei Meldepflichten trennen (CRA, NIS2, DSGVO) und je Pflicht Zuständigkeit und Adressat notieren.
Die offenen Punkte anwaltlich klären lassen — insbesondere, ob und wie Ihre Produkte erfasst sind, welche Rolle Sie einnehmen und ob Ausnahmen greifen.
Was wir bewusst nicht sagen — und warum das die nützlichere Auskunft ist
Zum CRA kursieren Angaben, die wir hier nicht wiederholen, weil wir sie nicht an der Primärquelle geprüft haben. Wir listen sie auf, damit Sie wissen, wonach Sie bei Ihrer Beratung fragen sollten:
Die Definition „Produkt mit digitalen Elementen" — artikelgenau, mit ihren Abgrenzungen.
Ausnahmen vom Anwendungsbereich — insbesondere Open Source, reine Cloud-/SaaS-Dienste ohne ausgeliefertes Produkt und Produkte, die bereits anderen Rechtsakten unterliegen.
Produktklassen und Konformitätsbewertungsverfahren — welche Produkte in welche Kategorie fallen und welches Verfahren daraus folgt.
Der Unterstützungszeitraum — ob die Verordnung einen Zeitraum kennt, nach dessen Ablauf Pflichten für ein Produkt enden.
Weitere Meldeauslöser nach Art. 14 neben der aktiv ausgenutzten Schwachstelle — und ihre Fristen.
Ein Abschlussbericht — ob, wann und in welcher Form die Verordnung einen verlangt.
Die zuständige Behörde in Deutschland und die Frage, ob neben der Meldung über die ENISA-Plattform national zu melden ist.
Die weiteren Sanktionsstufen nach Art. 64 und die Zuordnung, welcher Verstoß unter welche Stufe fällt.
Die artikelgenaue Rollenzuordnung (Hersteller, Bevollmächtigter, Einführer, Händler).
Übergangsregelungen für Produkte und Bestände rund um den 11. Dezember 2027.
Jeder dieser Punkte kann für Ihren Betrieb erheblich sein. Genau deshalb steht hier keine Angabe aus zweiter Hand: Eine falsche Ausnahme in einer Betroffenheitsprüfung ist teurer als eine fehlende. Sobald ein Punkt an der Primärquelle geprüft ist, ergänzen wir ihn hier — mit Artikel, Absatz und Datum.
Achtung — keine Rechtsberatung. Dieser Leitfaden ordnet den öffentlich zugänglichen Rechtsstand ein und benennt ausdrücklich, was er nicht abdeckt. Er ersetzt keine Rechtsberatung im Einzelfall — insbesondere nicht für die Frage, ob und wie Ihre Produkte vom Cyber Resilience Act erfasst sind.
Transparenz: Was CERTISCAN zum CRA (nicht) leistet
CERTISCAN hat kein Modul zum Cyber Resilience Act — nichts, was Schwachstellen verwaltet, Meldefristen überwacht, eine SBOM erzeugt oder eine Meldung an die ENISA-Plattform absetzt. Dieser Leitfaden ist reine Rechtseinordnung, und der zugehörige Check ist eine Orientierungshilfe, kein Produktangebot.
Was wir tatsächlich bereitstellen: eine laufend gepflegte Übersicht der Compliance-Fristen auf /compliance-radar, kostenlose Kurz-Checks zu anderen Pflichten auf /checks und — für die Frage, welche Fristen für Ihren Betrieb überhaupt gelten — den Fristen-Wächter. Für Ihre erste CRA-Selbsteinordnung: der CRA-Betroffenheits-Check. Und wenn gerade eine Schwachstelle auf dem Tisch liegt: der passende Fall.