Der CRA-Zeitplan: Was ab September 2026 gilt
Der Cyber Resilience Act ist seit dem 10. Dezember 2024 in Kraft, entfaltet seine Pflichten aber gestaffelt. Die meisten Anforderungen - sichere Entwicklung, Konformitätsbewertung, CE-Kennzeichnung - greifen erst ab dem 11. Dezember 2027 (EU-Kommission). Vorgezogen ist jedoch die Meldepflicht: Die Bestimmungen aus Artikel 14 gelten bereits ab dem 11. September 2026, und die Regeln zur Notifizierung von Konformitätsbewertungsstellen aus Kapitel IV ab dem 11. Juni 2026 (EU-Kommission). Für Hersteller heißt das: Die Pflicht, Schwachstellen und Vorfälle zu melden, kommt mehr als ein Jahr vor dem eigentlichen Vollanwendungstermin.
Betroffen sind Hersteller von Produkten mit digitalen Elementen - das umfasst Software, vernetzte Hardware und deren Fernverarbeitungslösungen sehr breit. Laut Bundesamt für Sicherheit in der Informationstechnik gelten die gestaffelten Meldefristen für alle Produkte mit digitalen Elementen auf dem EU-Markt, einschließlich bereits in Verkehr gebrachter Bestandsprodukte (BSI). Auch das ist eine wichtige Abgrenzung: Es geht nicht nur um Neuentwicklungen, sondern um den gesamten unterstützten Bestand.
| Frist ab Kenntnis | Was zu melden ist | Empfänger |
|---|---|---|
| 24 Stunden | Frühwarnung: betroffenes Produkt, betroffene Mitgliedstaaten, erste Einschätzung der aktiven Ausnutzung | Zuständiges CSIRT und ENISA (EU-Kommission) |
| 72 Stunden | Vollmeldung: Art der Schwachstelle, Auswirkung auf das Produkt, getroffene und geplante Korrekturmaßnahmen | Zuständiges CSIRT und ENISA (EU-Kommission) |
| 14 Tage | Abschlussbericht bei aktiv ausgenutzter Schwachstelle, nachdem eine Korrekturmaßnahme verfügbar ist | Single Reporting Platform (EU-Kommission) |
| 1 Monat | Abschlussbericht bei einem schweren Sicherheitsvorfall | Single Reporting Platform (EU-Kommission) |
Die Meldung läuft künftig zentral über eine einzige Single Reporting Platform (SRP), die von der EU-Agentur für Cybersicherheit ENISA betrieben und bis zum 11. September 2026 betriebsbereit sein soll (EU-Kommission). Hersteller melden dort einmal; die Plattform leitet an das zuständige nationale CSIRT - in Deutschland das BSI - weiter. Das senkt die bürokratische Hürde, ändert aber nichts an der eigentlichen Schwierigkeit: Die Uhr beginnt mit der Kenntnis zu laufen, und wer eine Ausnutzung erst spät bemerkt, hat seine 24 Stunden schon teilweise verbraucht.
Aktiv ausgenutzte Schwachstelle und schwerer Vorfall - der Auslöser
Nicht jede entdeckte Schwachstelle löst die 24-Stunden-Uhr aus. Der CRA knüpft die Frühwarnpflicht an zwei Ereignistypen: eine aktiv ausgenutzte Schwachstelle und einen schweren Sicherheitsvorfall, der die Sicherheit des Produkts mit digitalen Elementen beeinträchtigt (EU-Kommission). Entscheidend ist das Wort aktiv ausgenutzt: Es geht um Schwachstellen, für die es Anzeichen einer tatsächlichen Ausnutzung gibt - nicht um jede theoretisch denkbare Lücke. Genau diese Unterscheidung macht die Frühwarnung so anspruchsvoll, denn der Hersteller muss erkennen, dass etwas ausgenutzt wird, und nicht nur, dass es ausgenutzt werden könnte.
Die 24-Stunden-Frist beginnt, sobald der Hersteller Kenntnis von der aktiven Ausnutzung oder dem Vorfall erlangt. In der Praxis ist das oft der gefährlichste Punkt: Wer keine kontinuierliche Beobachtung der eigenen Angriffsfläche hat, erfährt von einer Ausnutzung häufig erst durch Dritte - und die Uhr tickt dann längst. Wer ein neues, unbekanntes Zertifikat für die eigene Domain oder ein verändertes Dritt-Skript frühzeitig sieht, gewinnt genau die Stunden, die später fehlen.
Hinzu kommt eine erhebliche Sanktionsdrohung: Verstöße gegen die Kernpflichten des CRA können mit Bußgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (EU-Kommission, Art. 64 CRA). Geringere Stufen sehen bis zu 10 Millionen Euro oder 2 Prozent sowie bis zu 5 Millionen Euro oder 1 Prozent vor (EU-Kommission). Neben Geldbußen können Marktüberwachungsbehörden zudem Rückrufe oder die Marktrücknahme eines Produkts anordnen - eine Folge, die für viele Hersteller schwerer wiegt als jedes Bußgeld.
CRA-Meldepflicht ist nicht security.txt - aber beide gehören zusammen
Eine häufige Verwechslung: Die CRA-Meldepflicht und eine security.txt-Datei klingen verwandt, betreffen aber zwei verschiedene Richtungen. Die security.txt ist ein standardisiertes Verfahren (RFC 9116), mit dem ein Hersteller Sicherheitsforschern mitteilt, wohin sie eine entdeckte Schwachstelle melden können - sie regelt also den Eingang von Hinweisen. Die CRA-Meldepflicht regelt den Ausgang: die Meldung des Herstellers an die Behörden, sobald eine Schwachstelle aktiv ausgenutzt wird.
Beides greift ineinander, denn der CRA verlangt in Artikel 13 ohnehin eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) und einen zentralen Kontaktpunkt für Schwachstellenmeldungen (EU-Kommission, Art. 13 CRA). Eine erreichbare, korrekt hinterlegte security.txt ist das technische Mittel, diesen Kontaktpunkt aufzufinden - und genau deshalb sollte ihre Erreichbarkeit überwacht werden. Wie ein sauberes Disclosure-Setup aussieht und wie es kontinuierlich geprüft wird, vertieft der Beitrag zur Überwachung von security.txt und Vulnerability Disclosure.
Eingehender Kanal: teilt Findern den Kontaktpunkt mit. Eine fehlende oder nicht erreichbare Datei verzögert externe Hinweise - genau die, die eine Frühwarnung auslösen könnten.
Ausgehende Pflicht: 24-h-Frühwarnung, 72-h-Vollmeldung, 14-Tage-Abschluss an CSIRT und ENISA, sobald eine Schwachstelle aktiv ausgenutzt wird.
Organisatorischer Rahmen: dokumentierte Prozesse zur Aufnahme und Behebung gemeldeter Schwachstellen sowie ein einziger Kontaktpunkt.
Inventar der Software-Komponenten, mindestens der obersten Abhängigkeitsebene - die Basis, um zu wissen, welche eigene oder fremde Komponente eine gemeldete Lücke betrifft.
Warum die 24-Stunden-Frist ohne Monitoring kaum zu halten ist
Eine Frist von 24 Stunden ab Kenntnis ist organisatorisch hart - aber das eigentliche Problem ist die Kenntnis selbst. Ein Hersteller kann nur melden, was er bemerkt. Bemerkt er die Ausnutzung erst, wenn Kunden sich beschweren oder ein Sicherheitsforscher öffentlich wird, ist ein erheblicher Teil der Reaktionszeit bereits verstrichen. Die Reaktionsgeschwindigkeit der Branche ist hier ernüchternd: Die mittlere Zeit bis zur Entdeckung eines Angriffs lag zuletzt bei 181 Tagen, und die durchschnittliche Gesamtdauer eines Datenschutzvorfalls von der Entdeckung bis zur Eindämmung bei 241 Tagen (IBM Cost of a Data Breach Report 2025). Wer von solchen Zeiträumen ausgeht, kann eine 24-Stunden-Frist strukturell nicht halten.
Gleichzeitig steigt das Tempo der Ausnutzung. Im Verizon Data Breach Investigations Report 2025 stieg der Anteil der Sicherheitsverletzungen, bei denen die Ausnutzung von Schwachstellen der initiale Zugangsvektor war, um 34 Prozent gegenüber dem Vorjahr und machte rund 20 Prozent aller untersuchten Vorfälle aus (Verizon DBIR 2025). Die Zahl bekannter, aktiv ausgenutzter Schwachstellen wächst kontinuierlich: Der KEV-Katalog der US-Behörde CISA listet inzwischen über 1.300 Einträge (CISA Known Exploited Vulnerabilities Catalog). Jeder neue Eintrag, der eine im eigenen Produkt eingesetzte Komponente betrifft, kann die CRA-Uhr auslösen.
Bemerkenswert ist auch, dass die Meldepflicht nicht an die eigene Programmierung gebunden ist. Ein erheblicher Teil moderner Produkte besteht aus Open-Source- und Fremdkomponenten, und gerade dort entstehen viele aktiv ausgenutzte Schwachstellen. Wird eine solche Komponente angegriffen, kann das die CRA-Uhr auslösen, obwohl der Code aus einer fremden Quelle stammt. Wer ein aktuelles Komponenten-Inventar pflegt und es laufend gegen öffentliche Verzeichnisse abgleicht, erkennt schneller, ob eine gemeldete Lücke das eigene Produkt betrifft - und kann die knappe Frist mit belastbaren Informationen statt mit Vermutungen angehen. Dieselbe Inventarisierung ist später auch die Grundlage für den Software-Bestandteil-Nachweis nach Anhang VII.
Die 24-Stunden-Frist beginnt mit der Kenntnis. Kontinuierliches Monitoring verkürzt die Zeit bis zur Kenntnis - und genau das ist der Hebel. Wer ein neues Phishing-Zertifikat für die eigene Marke, ein heimlich verändertes Dritt-Skript oder einen weggebrochenen Security-Header binnen Minuten gemeldet bekommt, hat die maximale Spanne, um zu prüfen, einzudämmen und fristgerecht zu melden - statt die Frist schon beim Start angerissen zu haben.
Verwandte Meldepflichten verschärfen den Druck zusätzlich: Die NIS2-Richtlinie kennt eine sehr ähnliche 24-Stunden-Frühwarnung für wesentliche und wichtige Einrichtungen. Wie sich diese Pflichten für Website- und Diensteanbieter konkret auswirken, beschreibt der Beitrag zu den NIS2-Meldepflichten für Website-Betreiber. Für viele Unternehmen überlappen sich CRA und NIS2 - und beide verlangen, dass man Vorfälle schnell überhaupt erkennt.
Was XICTRAQ kontinuierlich überwacht
XICTRAQ rendert die hinterlegten Websites und Endpunkte in einem echten Browser, prüft sie regelmäßig von mehreren Standorten aus und vergleicht den aktuellen Zustand mit einer freigegebenen Baseline. Ändert sich etwas Sicherheitsrelevantes, entsteht ein Signal - und damit die Kenntnis, die die CRA-Uhr überhaupt erst sinnvoll startbar macht. Die folgenden Bausteine zahlen direkt auf die Frühwarnfähigkeit ein.
Neue Zertifikate für die eigene Marke oder Lookalike-Domains aus den öffentlichen CT-Logs werden gegen Marken- und Tippfehler-Muster geprüft - eine Frühwarnung für Phishing und Domain-Missbrauch. Details im Beitrag zum Certificate-Transparency-Monitoring.
Der SHA-256-Fingerabdruck eingebundener Dritt-Skripte wird überwacht. Ändert sich ein Skript unbemerkt - das klassische Magecart-Muster - schlägt die Drift-Erkennung an. Mehr dazu im Beitrag zur Überwachung von Subresource Integrity.
Wegbrechende HSTS-, CSP- oder X-Content-Type-Options-Header und schwache TLS-Konfigurationen werden erkannt - oft das erste sichtbare Zeichen einer Fehlkonfiguration nach einem Deploy.
Ob die in RFC 9116 vorgesehene Datei am erwarteten Ort erreichbar bleibt, wird laufend geprüft - damit der von Artikel 13 geforderte Kontaktpunkt nicht still verschwindet.
Hinzu kommt das CRA-Komponenten-Cockpit: Es hält die im Produkt eingesetzten Komponenten samt Versionsstand nach und warnt heuristisch vor veralteten Bausteinen sowie vor nahenden CRA-Fristen. Wird eine eingesetzte Bibliothek in einem öffentlichen Verzeichnis aktiv ausgenutzter Schwachstellen gelistet, ist das genau das Signal, das eine Prüfung und gegebenenfalls eine Frühwarnung auslöst. So wird aus der abstrakten Pflicht ein konkreter, nachvollziehbarer Arbeitsablauf.
- Echtes Rendering - Seiten und Skripte werden in einem echten Browser geladen, nicht nur als HTML abgerufen, damit dynamisch nachgeladene Änderungen sichtbar werden
- Baseline-Diff - der aktuelle Zustand wird gegen den letzten freigegebenen Stand verglichen, sodass nur echte Abweichungen alarmieren
- Mehrere Standorte - Prüfungen laufen von mehreren Knoten aus, um lokale Verzerrungen zu vermeiden
- Zentrale Inventarisierung - Zertifikate, Skripte und Komponenten werden inventarisiert, sodass eine gemeldete Lücke schnell der eigenen Angriffsfläche zugeordnet werden kann
Der Alerting-Workflow als Fristen-Versicherung
Ein Signal nützt nur, wenn es die richtigen Menschen rechtzeitig erreicht. Deshalb ist der Alerting-Workflow das Herzstück der CRA-Vorbereitung. Erkennt XICTRAQ eine sicherheitsrelevante Abweichung, löst das eine Benachrichtigung über mehrere Kanäle aus - per E-Mail, Slack, Discord oder Telegram. So beginnt die interne Prüfung in Minuten, nicht in Tagen, und die 24-Stunden-Frist startet mit dem größtmöglichen Puffer.
Entscheidend ist die Eskalation: Bleibt ein Alert unbestätigt, wird die nächste verantwortliche Person benachrichtigt. Gerade bei einer 24-Stunden-Frist, die auch an einem Freitagabend oder im Urlaub laufen kann, verhindert eine Eskalationskette, dass ein kritisches Signal liegen bleibt. Die Dedupe-Logik fasst gleichartige Meldungen zusammen, damit aus einem echten Vorfall nicht hunderte Einzel-Alerts werden, die das Team abstumpfen lassen.
Wenn Sie ein Zertifikat bewusst erneuern, ein Dritt-Skript planmäßig aktualisieren oder Header anpassen, ändert sich der Sollzustand. Geben Sie die neue Baseline nach jedem geplanten Release frei - dann alarmiert das Monitoring nur noch bei echten, ungewollten Abweichungen und nicht bei jeder geplanten Änderung. So bleibt das Signal-Rausch-Verhältnis hoch und das Team reagiert auf das, was zählt.
Wie viel Zeit am Ende bleibt, ist eine Frage des Fehlerbudgets und der Reaktionsschwellen. Wer seine Alarmierung an klaren Schwellen ausrichtet, statt auf jedes Rauschen zu reagieren, hält die Mannschaft handlungsfähig. Das gleiche Prinzip aus dem SLO-Umfeld - früh, aber nicht übermäßig alarmieren - beschreibt der Beitrag zu Error-Budget- und Burn-Rate-Alerts. Für die CRA-Frist bedeutet es: lieber ein verifizierbares Signal in Minuten als eine Flut, die niemand mehr ernst nimmt.
Bis September 2026 vorbereitet sein
Die CRA-Meldepflicht ist kein Grund zur Panik, aber ein klarer Anlass, die eigene Erkennungsfähigkeit zu prüfen. Der Stichtag 11. September 2026 ist fix, und die 24-Stunden-Frist verzeiht keine blinden Flecken. Drei Schritte helfen, vorbereitet zu sein: erstens einen dokumentierten, koordinierten Offenlegungsprozess samt erreichbarer security.txt aufsetzen; zweitens die eigene Angriffsfläche - Zertifikate, eingebundene Skripte, Security-Header, eingesetzte Komponenten - kontinuierlich überwachen; drittens einen eskalierenden Alerting-Workflow etablieren, der ein Signal zuverlässig an einen Menschen bringt.
Der gemeinsame Nenner dieser drei Schritte ist Zeit. Jede Stunde, die zwischen Ausnutzung und Kenntnis vergeht, ist eine Stunde, die für Prüfung, Eindämmung und Meldung fehlt. Kontinuierliche Überwachung kann eine Schwachstelle nicht verhindern - aber sie verschiebt den Moment der Kenntnis nach vorne und macht die engen CRA-Fristen technisch überhaupt erst erreichbar. Genau darin liegt der praktische Wert eines Monitoring- und Alerting-Setups: Es verwandelt einen unsichtbaren Vorgang in ein sichtbares, meldbares Signal. Und es liefert nebenbei einen dokumentierten Nachweis, dass Abweichungen erkannt und bearbeitet wurden - eine Belegspur, die im Fall einer Behördenanfrage erfahrungsgemäß ebenso wertvoll ist wie die fristgerechte Meldung selbst.
Dieser Artikel basiert auf Daten und Dokumenten von: Europäische Kommission - 'Cyber Resilience Act: Reporting obligations' und 'Cyber Resilience Act' (digital-strategy.ec.europa.eu, Fristen 24 h / 72 h / 14 Tage, Single Reporting Platform, Geltungsbeginn Art. 14 am 11.09.2026 und Vollanwendung am 11.12.2027, Sanktionsrahmen Art. 64), CRA-Verordnungstext Art. 13 und Art. 14 (koordinierte Offenlegung, Meldepflichten), Anhang VII (SBOM), Bundesamt für Sicherheit in der Informationstechnik (BSI, Cyber Resilience Act, Einordnung der gestaffelten Meldefristen und Bestandsprodukte), IBM Cost of a Data Breach Report 2025 (mittlere Entdeckungs- und Eindämmungsdauer), Verizon Data Breach Investigations Report 2025 (Anteil Exploit-basierter Erstzugriffe), CISA Known Exploited Vulnerabilities Catalog (Umfang aktiv ausgenutzter Schwachstellen), RFC 9116 (security.txt). Rechtliche Würdigungen sind keine Rechtsberatung.