CRA Vulnerability Reporting: Die technische Realität des 24-Stunden-Fensters
Ab dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen nach dem CRA zu melden: Frühwarnung in 24 Stunden, Meldung in 72. Die rechtliche Seite ist dokumentiert, das hier ist die Engineering-Seite: Was das Fenster von Triage, SBOM und Telemetrie verlangt.
Kontext Meldepflichten gelten ab dem 11. September 2026 (Art. 14, Verordnung (EU) 2024/2847) · Basierend auf den Umsetzungshinweisen der EU-Kommission vom Juli 2026
Ab dem 11. September 2026 treffen Hersteller von Produkten mit digitalen Elementen eine Meldepflicht nach dem Cyber Resilience Act: aktiv ausgenutzte Schwachstellen und schwere Vorfälle sind zu melden, eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme, eine vollständige Meldung innerhalb von 72. Das meiste, was über diese Pflicht geschrieben wurde, ist juristischer Kommentar. Diese Note handelt von der anderen Seite: Wie diese Stunden innerhalb einer Produktorganisation aussehen, und was technische Readiness bedeutet, während die Uhr läuft.
Die Daten sind weniger wichtig als der Mechanismus. Die Meldepflichten nach Art. 14 CRA gelten ab dem 11. September 2026; die Hauptpflichten der Verordnung folgen am 11. Dezember 2027. Die Kommission hat im Juli 2026 Umsetzungshinweise veröffentlicht, einschließlich Details zum Reporting. Gemeldet wird über einen Kanal, die CRA Single Reporting Platform, an den CSIRT der Hauptniederlassung, parallel an ENISA. Aber die Plattform ist der Ort, an dem die Antwort abgelegt wird. Die 24 Stunden passieren davor, in Ihrer Engineering-Organisation.
Wozu die 24 Stunden tatsächlich da sind
Eine Frühwarnung darf unvollständig sein, das ist ihr Zweck. Was bekannt ist: welches Produkt bzw. welche Produktkategorie, was beobachtet wurde, ob Ausnutzung bestätigt ist. Schwierig ist nicht das Aufschreiben. Schwierig ist, es zu wissen. „Ist die Schwachstelle aktiv ausgenutzt?" ist eine Telemetrie-Frage, eine Log-Frage, eine Reproduktionsfrage. Product-Teams ohne Monitoring erfahren die Antwort auf diese Frage vom Reporter, der schlechtestmögliche Quelle für den eigenen Status.
Das 24-Stunden-Fenster ist in der Praxis eine Anforderung an die Triage-Fähigkeit. Die Kette ist immer dieselbe: Die Meldung kommt, von einem Researcher, einem Kunden, einem CERT, und dann: Ist sie reproduzierbar? Betrifft sie das Produkt oder die Komponente? Welche Produkte, welche Versionen? Ist Ausnutzung im Feld beobachtbar? Was ist der tatsächliche Impact? Diese Kette ist exakt der Triage-Workflow, den wir in „Betrifft diese CVE unser Produkt?" beschreiben, der CRA hat ihr lediglich eine Frist gehängt.
Die 72-Stunden-Meldung: Evidenz, zusammengesetzt
Die vollständige Meldung benennt betroffene Produkte, Versionen, Impact und Abhilfestatus. Das in 72 Stunden zu produzieren setzt drei Artefakte voraus, die vor dem Vorfall existieren müssen: eine gepflegte SBOM pro Produktversion (welche Produkte enthalten die Komponente), ein Version-zu-Gerät-Mapping (welche ausgelieferten Geräte laufen auf welcher Firmware) und ein Support-Prozess, der diese Geräte oder ihre Betreiber erreicht. Keines davon lässt sich während des Vorfalls bauen. Alle drei sind ohnehin Dinge, die ein ernsthaftes Produkt-Security-Programm haben sollte, der CRA macht ihre Abwesenheit nur teuer.
Der Schlussbericht, und ein Wert, den man sich absehen kann
Nach Verfügbarkeit der Korrekturmaßnahme folgt der Schlussbericht, bei aktiv ausgenutzten Schwachstellen innerhalb von 14 Tagen (bei schweren Vorfällen innerhalb eines Monats): Was war die Schwachstelle, wie wurde sie ausgenutzt, wie wurde mit der Meldung umgegangen. Teams, die heute schon Coordinated Disclosure mit Researchern betreiben, erkennen die Form. CRA-Reporting ist Coordinated Disclosure mit gesetzlicher Frist und festem Empfänger. Wer heute ein gutes Public Advisory produzieren kann, produziert morgen einen guten CRA-Schlussbericht.
Wie technische Readiness aussieht
Verdichtet zu einer Checkliste, die wir mit Product-Teams verwenden:
- Wissen, was Sie ausliefern. SBOM pro Release, Version-zu-Komponente, ehrliche Versionen. Backports getrackt, nicht hinter Versions-Strings versteckt.
- Wissen, was wo läuft. Firmware-Versions-Telemetrie oder ein Support-Inventar, das „welche ausgelieferten Geräte laufen auf diesem Build" ohne eine Woche manuelle Korrelation beantwortet.
- Erkennen, oder eingestehen, dass Sie es nicht können. Ist Feld-Ausnutzung unbeobachtbar, gehört diese Tatsache in den Incident-Plan. „Ausnutzung nicht feststellbar" ist eine schlechtere Antwort als „keine Ausnutzung beobachtet", aber beide schlagen Schweigen.
- Die Kette proben. Ein Probelauf: ein echtes Advisory, eine Produktlinie, die volle Vier-Stufen-Triage, ein entworfener Frühwarnungs-Text. Ein- bis zweimal im Jahr. Der erste echte Lauf sollte nicht der erste Lauf sein.
- Entscheiden, wer meldet. Jemand besitzt den Zugang zur Single Reporting Platform, den CSIRT-Kontakt und die Legal-/Engineering-Übergabe, vor dem Donnerstagnachmittag, an dem es zählt.
Der Teil, den niemand laut ausspricht
Die CRA-Meldepflicht bestraft die Organisation, die nicht weiß, was sie ausliefert, und sie ist weitgehend neutral gegenüber der Organisation, die es weiß, ehrlich triagiert und schnell behebt. Diese Asymmetrie ist das eigentliche Design. Ein Team, das „sind wir betroffen?" an einem Nachmittag mit Evidenz beantworten kann, erfüllt das 24-Stunden-Fenster nebenbei. Ein Team, das das nicht kann, verpasst es unter jeder Regulierung, die man schreiben könnte. Wenn der CRA für Produkt-Sicherheit sonst nichts bewirkt, dann verwandelt er unsichtbare Engineering-Hygiene in eine Compliance-Frist, und das, zynisch oder nicht, ist das Budget-Argument, auf das Security-Engineer seit Jahrzehnten warten.