CRA: Die erste Frist beginnt am 11. September 2026

Die erste durchsetzbare Verpflichtung des Cyber Resilience Acts beginnt nicht im Dezember 2027, sondern bereits in wenigen Wochen. Sie betrifft auch Produkte, die sich seit Jahren auf dem Markt befinden. Für viele Hersteller wird dabei nicht die Meldung selbst die größte Herausforderung sein, sondern die Prozesse, die ihr vorausgehen.

Wenn im deutschsprachigen Raum über den Cyber Resilience Act gesprochen wird, wird meist ein Datum genannt: der 11. Dezember 2027. Ab diesem Zeitpunkt gilt die Verordnung in vollem Umfang – einschließlich CE-Kennzeichnung, technischer Dokumentation und Konformitätsbewertung.

Artikel 14 tritt jedoch bereits am 11. September 2026 in Kraft. Anders als die übrigen Bestimmungen des CRA betrifft er nicht nur neue Produkte. Nach Artikel 69 Absatz 3 erstrecken sich die Meldepflichten auch auf Produkte mit digitalen Elementen, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Wenn Sie Ihre Vorbereitungen auf den CRA erst für das kommende Jahr eingeplant haben, verändert Artikel 14 diesen Zeitplan. Wenn Sie zunächst klären möchten, ob Ihr Produkt überhaupt in den Anwendungsbereich des CRA fällt, sollten Sie mit unserem vollständigen Überblick über die Verordnung beginnen.

Was der Meldepflicht unterliegt

Artikel 14 führt zwei eigenständige Meldepflichten ein, die beide den Hersteller betreffen. Nicht den Kunden und nicht den Betreiber. Einführer und Händler, die von einem Problem erfahren, müssen den Hersteller informieren. Die Meldung selbst übermitteln sie jedoch nicht, und die 24-Stunden-Frist geht nicht auf sie über.

• Aktiv ausgenutzte Schwachstelle – eine Schwachstelle in Ihrem Produkt, für die zuverlässige Belege vorliegen, dass sie von einem Angreifer ohne Zustimmung des Systemeigentümers ausgenutzt wurde.
• Schwerwiegender Sicherheitsvorfall mit Auswirkungen auf die Produktsicherheit – beispielsweise die Kompromittierung einer Entwicklungs-, Produktions- oder Distributionsumgebung, durch die ein Angreifer Schadcode in den Distributionskanal oder die Signaturkette einschleusen kann. Es handelt sich dabei nicht um einen Vorfall beim Kunden, sondern um einen Vorfall beim Hersteller, der das Risiko für die Nutzer des Produkts erhöht.

In bestimmten Fällen gelten vergleichbare Verpflichtungen auch für Verwalter von Open-Source-Software gemäß Artikel 24, und zwar im Umfang ihrer Beteiligung an der Entwicklung der betroffenen Produkte.

Was die Meldepflicht nicht auslöst

Der Fund eines Sicherheitsforschers, ein Proof of Concept oder ein hoher CVSS-Wert lösen für sich genommen keine Meldepflicht nach Artikel 14 aus. Die Verordnung unterscheidet zwischen einer Schwachstelle, die lediglich existiert, und einer Schwachstelle, die aktiv ausgenutzt wird.

Entscheidend ist der Nachweis einer tatsächlichen Ausnutzung und nicht die Schwere der Schwachstelle.

Eine gewöhnliche Schwachstelle, die über Ihren CVD-Kanal gemeldet und im regulären Patch-Zyklus behoben wird, ist nicht meldepflichtig.

Das mag zunächst wie eine Erleichterung wirken. In der Praxis handelt es sich jedoch um den anspruchsvollsten Teil der gesamten Verpflichtung. Die Bewertung, ob eine Schwachstelle tatsächlich aktiv ausgenutzt wird, erfordert technisches Fachwissen sowie die Fähigkeit, verfügbare Informationen zu analysieren und korrekt zu bewerten.

Drei Fristen, zwei unterschiedliche Ausgangspunkte

Die 24 Stunden beginnen nicht erst, wenn Ihre Analyse abgeschlossen ist. Sie beginnen in dem Moment, in dem Sie von einer aktiven Ausnutzung oder einem schwerwiegenden Sicherheitsvorfall Kenntnis erlangen – nicht erst nach Abschluss interner Untersuchungen, der Bestätigung eines CVSS-Werts, der Ursachenanalyse oder der Bereitstellung eines Fixes.

Der Unterschied beim Abschlussbericht hat unmittelbare Auswirkungen auf die Planung. Bei einer Schwachstelle beginnt die 14-Tage-Frist erst, wenn eine Abhilfe- oder Risikominderungsmaßnahme verfügbar ist. Bei einem schwerwiegenden Sicherheitsvorfall läuft die Monatsfrist unabhängig davon, wie weit die Behebung bereits fortgeschritten ist.

Die Pflicht zur Information der Nutzer

Die Meldung an die zuständigen Behörden ist nicht die einzige Verpflichtung. Genau dieser Aspekt wird in vielen Beiträgen zum CRA häufig übersehen.

Sobald ein Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall Kenntnis erlangt, muss er die betroffenen Nutzer unverzüglich informieren. Gegebenenfalls gilt diese Informationspflicht auch gegenüber allen anderen Nutzern. Dabei müssen sowohl das Problem selbst als auch mögliche Maßnahmen zur Risikominderung kommuniziert werden.

In der Praxis bedeutet das, dass die eigentliche Meldung nur ein Teil des Prozesses ist. Ebenso wichtig sind ein vorbereiteter Kommunikationskanal zu den Kunden und eine bereits abgestimmte Mitteilung.

Wie die Meldung über die ENISA-Plattform funktioniert

Die Meldung wird einmalig über die Single Reporting Platform übermittelt, die von der ENISA gemäß Artikel 16 eingerichtet wird. Eine einzige Übermittlung erreicht gleichzeitig das koordinierende CSIRT und die ENISA. Nationale Behörden in jedem einzelnen Mitgliedstaat müssen daher nicht separat kontaktiert werden.

Bei der Meldung geben Sie die Mitgliedstaaten an, in denen das betroffene Produkt verfügbar ist. Das koordinierende CSIRT leitet die Informationen anschließend an die zuständigen CSIRTs in den jeweiligen Staaten weiter.

Zuständig ist das CSIRT des Mitgliedstaats, in dem sich Ihre Hauptniederlassung befindet, also dort, wo die wesentlichen Entscheidungen zur Cybersicherheit Ihrer Produkte getroffen werden. Lässt sich die Hauptniederlassung nicht eindeutig bestimmen, ist die Niederlassung mit der höchsten Zahl an Beschäftigten innerhalb der EU maßgeblich.

Für Hersteller ohne Hauptniederlassung in der Europäischen Union gelten besondere Regelungen. Abhängig von der jeweiligen Situation können zusätzlich Vorschriften zur Benennung eines bevollmächtigten Vertreters relevant sein.

Unter außergewöhnlichen Umständen kann die Weiterleitung der Meldung an andere CSIRTs auf Antrag des Herstellers und aus begründeten Cybersicherheitsgründen aufgeschoben werden. Es ist sinnvoll, diese Möglichkeit bereits im Vorfeld zu kennen und nicht erst während eines laufenden Vorfalls.

Der praktische Hinweis, den die meisten Artikel auslassen

Zum Zeitpunkt der Veröffentlichung dieses Artikels war die Plattform noch nicht in Betrieb. Die ENISA hat jedoch bestätigt, dass sie spätestens am 11. September 2026 verfügbar sein wird. Die Testphase läuft bereits, und erste Leitfäden wurden im Sommer 2026 veröffentlicht. Die öffentliche Adresse der Plattform soll noch vor dem offiziellen Start bekannt gegeben werden.

Daraus ergibt sich eine wichtige Erkenntnis: Nicht die Plattform ist der entscheidende Faktor.

Die internen Prozesse, die die Plattform später mit Informationen versorgen, können bereits heute aufgebaut werden. Genau diese Prozesse entscheiden darüber, ob die 24-Stunden-Frist eingehalten werden kann.

Die ENISA weist außerdem darauf hin, dass der Zugang zur Plattform über ein EU-Login-Konto erfolgen wird, das bereits im Vorfeld eingerichtet werden kann.

Warum 24 Stunden mehr sind als nur eine administrative Frist

Eine Frist von 24 Stunden mag auf den ersten Blick ausreichend erscheinen. In der Praxis müssen Hersteller in diesem Zeitraum jedoch mehrere Schritte bewältigen, die sowohl technische als auch organisatorische Entscheidungen erfordern.

1. Feststellen, dass ein Vorfall eingetreten ist. Die Information kann aus dem Monitoring, aus Threat-Intelligence-Daten, von Kunden oder von Sicherheitsforschern stammen. Ohne eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD) und eine funktionierende Anlaufstelle werden Unternehmen häufig zu spät informiert.
2. Prüfen, ob ein konkretes Produkt betroffen ist. Welche Versionen sind betroffen? Ist die verwundbare Bibliothek tatsächlich Bestandteil des Produkts? Ohne eine aktuelle SBOM kann die Beantwortung dieser Fragen viel Zeit in Anspruch nehmen.
3. Bewerten, ob eine aktive Ausnutzung vorliegt. Entscheidend ist nicht die Schwere der Schwachstelle, sondern die Frage, ob verlässliche Belege für eine tatsächliche Ausnutzung vorliegen. Eine solche Bewertung erfordert technisches Fachwissen.
4. Entscheiden, ob eine Meldung erforderlich ist. Viele Unternehmen haben bislang nicht eindeutig festgelegt, wer diese Entscheidung trifft. Ist die Entwicklungsabteilung verantwortlich? Das Produktmanagement? Die Rechtsabteilung? Oder die Geschäftsführung?
5. Die Meldung vorbereiten und die Nutzer informieren. Neben der eigentlichen Übermittlung müssen auch die Kommunikation mit den Kunden und Empfehlungen zur Risikominderung vorbereitet werden.

Der kritische Punkt ist Schritt 3. Um beurteilen zu können, ob eine Schwachstelle aktiv ausgenutzt wird, müssen Sie wissen, was in Ihrem Produkt tatsächlich geschieht. Die Unterscheidung zwischen einer bestehenden Schwachstelle und ihrer tatsächlichen Ausnutzung ist eine technische Aufgabe – keine Compliance-Frage.

Was wir bei Produkttests beobachten

Nach unseren Erfahrungen aus Penetrationstests von IoT-Geräten enthält nahezu jedes getestete Gerät mindestens eine als high oder critical eingestufte Schwachstelle. Besonders häufig finden wir fest kodierte Zugangsdaten in der Firmware, unverschlüsselte Kommunikation mit Cloud-Diensten, offen zugängliche Debug-Schnittstellen oder Update-Mechanismen ohne Signaturprüfung.

Ausführlich haben wir diese Probleme bereits in unserem Beitrag zur Sicherheit intelligenter Steckdosen beschrieben.

Bis zum 11. September 2026 handelt es sich dabei lediglich um technische Befunde. Ab diesem Zeitpunkt gilt: Sobald zuverlässige Belege für eine aktive Ausnutzung vorliegen, beginnt die 24-Stunden-Frist zu laufen.

Ausnahmen bei Sanktionen

Ein Verstoß gegen Artikel 14 fällt in die höchste Bußgeldstufe des CRA – bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Die Verordnung sieht jedoch zwei eng begrenzte Ausnahmen vor:

• Gegen Kleinstunternehmen und kleine Unternehmen darf kein Bußgeld wegen der Nichteinhaltung der Frist für die Frühwarnung verhängt werden. Dies gilt jedoch nicht für die 72-Stunden-Meldung, den Abschlussbericht oder die Meldepflicht selbst.
• Gegen Verwalter von Open-Source-Software sollen nach der Verordnung keine Geldbußen verhängt werden. Ihre Verpflichtungen nach Artikel 24 bleiben davon jedoch unberührt.

Was bis September vorbereitet sein sollte

• Eine Übersicht über die betroffenen Produkte. Welche Produkte stellen Sie auf dem EU-Markt bereit? Welche Versionen sind noch im Umlauf? Welche Produkte werden nicht mehr weiterentwickelt, aber weiterhin verkauft?
• Klare Zuständigkeiten und ein definierter Eskalationsprozess. Wer entscheidet über eine Meldung? Wer übermittelt sie? Wer übernimmt die Vertretung? Wie wird außerhalb der regulären Arbeitszeiten vorgegangen?
• Eine CVD-Richtlinie und eine zentrale Anlaufstelle. Der Kanal, über den Sie überhaupt von einer Schwachstelle oder einem Vorfall erfahren. Er sollte sich nicht ausschließlich auf automatisierte Werkzeuge stützen.
• Eine SBOM, die zumindest die wichtigsten Abhängigkeiten erfasst. Nicht aus Dokumentationsgründen, sondern damit Sie schnell beurteilen können, ob eine bestimmte Schwachstelle Ihr Produkt betrifft.
• Eine Schwachstellen-Triage und die Fähigkeit, eine Ausnutzung nachzuweisen. Wer bewertet, ob eine aktive Ausnutzung vorliegt, und auf welcher Grundlage wird diese Entscheidung getroffen?
• Vorbereitete Melde- und Kommunikationsprozesse. Der Zugang zur Plattform sollte bereits eingerichtet sein. Ebenso sollten Vorlagen für Meldungen und Prozesse zur Kommunikation mit den Nutzern vorbereitet werden.
• Üben Sie den Ablauf. Eine einzige Tabletop-Übung zum Szenario „Eine Schwachstelle in unserem Produkt wird aktiv ausgenutzt“ liefert oft mehr Erkenntnisse über den tatsächlichen Reifegrad als die Prüfung von Dokumentationen.

Häufig gestellte Fragen

Müssen wir den Fund eines Sicherheitsforschers melden?

Nein, sofern es sich lediglich um einen Fund handelt. Die Verpflichtung nach Artikel 14 wird erst durch verlässliche Hinweise darauf ausgelöst, dass eine Schwachstelle aktiv ausgenutzt wird. Ein Fund, ein Proof of Concept oder ein hoher CVSS-Wert lösen die Meldepflicht nicht automatisch aus.

Gilt die Meldepflicht auch für ältere Produkte?

Ja. Die Meldepflichten gelten auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, sofern sie weiterhin auf dem EU-Markt bereitgestellt werden.

Melden wir oder unser Händler?

Sie. Die Verpflichtung nach Artikel 14 liegt beim Hersteller. Einführer und Händler, die von einer Schwachstelle erfahren, müssen den Hersteller informieren.

Was passiert, wenn die ENISA-Plattform am Tag des Vorfalls nicht verfügbar ist?

Die Fristen ergeben sich unmittelbar aus der Verordnung und beginnen in dem Moment zu laufen, in dem Sie von einem Vorfall Kenntnis erlangen. Deshalb empfiehlt es sich, den Zugang zur Plattform bereits im Vorfeld einzurichten, die Inhalte der Meldung vorzubereiten und die offiziellen Informationen der ENISA zu verfolgen.

Wir sind ein kleines Unternehmen. Müssen wir trotzdem melden?

Ja. Gegen Kleinstunternehmen und kleine Unternehmen darf zwar kein Bußgeld wegen der Versäumung der Frist für die Frühwarnung verhängt werden, die Meldepflicht selbst gilt jedoch in gleicher Weise wie für alle anderen Hersteller.

Wir sind ein Unternehmen außerhalb der Europäischen Union. Gilt Artikel 14 trotzdem für uns?

Ja. Wenn Sie Produkte auf dem EU-Markt bereitstellen, gelten die Meldepflichten unabhängig davon, wo Ihr Unternehmen seinen Sitz hat. Für Hersteller ohne Hauptniederlassung in der Europäischen Union sieht die Verordnung besondere Regelungen vor.

Fazit

Der Unterschied zwischen den beiden CRA-Fristen ist einfach: Im Dezember 2027 geht es darum, die Einhaltung der Anforderungen nachweisen zu können. Im September 2026 geht es darum, schnell und angemessen reagieren zu können.

Wer die zweite Anforderung erfüllt, hat bereits einen großen Teil der ersten erledigt. Produktinventar, SBOM und Prozesse für das Schwachstellenmanagement bilden die Grundlage für beide Verpflichtungen.

Einen vollständigen Überblick über die Pflichten, Produktkategorien und Fristen finden Sie in unserem Beitrag zum Cyber Resilience Act.

Wenn Sie die Sicherheit Ihres Produkts und seine Bereitschaft für die Anforderungen des CRA unabhängig überprüfen lassen möchten, sprechen Sie uns an. Wir testen Firmware und Hardwareschnittstellen, mobile Anwendungen, Web- und API-Schnittstellen, Cloud-Backends, Authentifizierungs- und Update-Mechanismen sowie Schwachstellen in Komponenten von Drittanbietern.

Rechtlicher Hinweis: Dieser Beitrag dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar.