Ab 11. September 2026 müssen Hersteller bestimmte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei Produkten mit digitalen Elementen melden. Das operative Problem ist nicht das Ausfüllen eines Formulars. Es ist der Moment davor: Ein Support-Ticket, ein Forscherhinweis oder ein Telemetriealarm muss schnell als mögliches CRA-Ereignis erkannt, dem richtigen Produkt und Hersteller zugeordnet, belastbar zeitgestempelt und durch autorisierte Rollen entschieden werden. Wer erst bei bestätigter Root Cause nach dem Meldeweg sucht, hat die ersten 24 Stunden bereits als Ermittlungsprojekt missverstanden.
Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.
Die Uhr startet ereignis- und rollenbezogen
Die CRA-Meldepflichten gelten ab 11. September 2026, während die Hauptpflichten der Verordnung überwiegend erst ab 11. Dezember 2027 anwendbar werden. Nach der offiziellen Informationsseite der Europäischen Kommission betrifft die Meldung Hersteller und zwei unterschiedliche Ereignisklassen: eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen sowie einen schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit eines solchen Produkts auswirkt. Diese Trennung gehört in die Triage, weil sie den weiteren Berichtspfad bestimmt.
Für beide verlangt die Kommission eine Frühwarnung innerhalb von 24 Stunden ab Kenntniserlangung und eine vollständige Meldung innerhalb von 72 Stunden. Die Fristen knüpfen also nicht pauschal an jeden Bug, jede CVE oder jede Betriebsstörung an. Ebenso wenig sollte ein Unternehmen die Uhr intern erst dann starten lassen, wenn Technik, Recht und Kommunikation vollständige Gewissheit erreicht haben.
Das ist eine Governance-Aufgabe. Der Prozess muss festlegen, wann organisatorisch belastbare Kenntnis vorliegt, welche Rolle das Ereignis klassifizieren darf, welche juristische Person Hersteller ist und welche Produkte und Versionen betroffen sind. Ebenso muss er bestätigte Fakten von Annahmen trennen. Diese Punkte sind unter Zeitdruck zu führen, ohne aus Unsicherheit Untätigkeit zu machen.
Die trockene Wahrheit: Ein Severity-Feld mit „critical“ ist noch keine Rechtsrolle. Ticketsysteme sind bei Organigrammen erstaunlich gleichgültig.
Eine hypothetische Betriebsszene zeigt, wie früh diese Fragen zusammenlaufen. Am Freitag um 16:20 Uhr meldet ein Unternehmenskunde, dass unbekannte Dritte offenbar eine Schwachstelle in einer älteren Produktversion ausnutzen. Support eröffnet ein Ticket. Engineering sieht einen plausiblen technischen Zusammenhang, aber noch keinen bestätigten Angriffsvektor. Das Produkt wird von der deutschen Mutter entwickelt, in einem anderen Rechtsträger vertrieben und in mehreren Märkten bereitgestellt. Um 17:00 Uhr ist die Faktenlage unvollständig, die Uhrfrage aber bereits real.
Der Prozess muss jetzt den Kenntniszeitpunkt sichern, ohne ihn durch interne Abstimmung nach hinten zu verhandeln. Product Security prüft Produktbezug und Ausnutzung; Compliance und Product Owner klären die Herstellerrolle; die autorisierte Rolle entscheidet, ob und auf welcher Grundlage der Meldepfad eröffnet wird. Offene Tatsachen werden nicht erraten, sondern mit Owner und nächster Prüfzeit geführt. Die praktische Entscheidungsfolge lautet damit: Signal sichern, Fall zuordnen, Unsicherheit strukturieren, Entscheidung autorisieren. Ein zusätzliches Meeting ist nur dann ein Kontrollschritt, wenn am Ende jemand mehr entscheiden darf als vorher.
Im Beispiel wird um 17:10 Uhr ein gemeinsamer Fall eröffnet. Der ursprüngliche Kundenhinweis bleibt unverändert als Eingangsevidenz erhalten; daneben entsteht ein Arbeitsstand, in dem jede Aussage als bestätigt, bewertet oder offen gekennzeichnet ist. Support ergänzt Kundenkontakt und betroffene Version, Engineering sichert technische Artefakte und Product Security formuliert die vorläufige Ereignishypothese. Der Product Owner liefert die Produkt- und Vertriebszuordnung, statt technische Teams im Handelsregister rätseln zu lassen. Compliance prüft die Rolle, nicht den Exploit. Diese Arbeitsteilung verhindert, dass alle alles prüfen und am Ende niemand die Entscheidung besitzt.
Um 18:00 Uhr ist die aktive Ausnutzung weiterhin nicht abschließend bestätigt. Es gibt aber genügend Anhaltspunkte, um die Eskalationsschwelle auszulösen. Die autorisierte Rolle hält fest, welche Tatsachen die Bewertung tragen, welche Alternativerklärung noch geprüft wird und wann die nächste Entscheidung fällt. Gleichzeitig beginnt der Sender mit dem Frühwarnungsentwurf. Das ist keine Vorwegnahme des Ergebnisses, sondern Parallelisierung reversibler Arbeit: Ein Entwurf kann verworfen werden, verlorene Stunden lassen sich schlechter zurückholen.
Am Samstagmorgen bestätigt ein zweiter technischer Befund den Produktbezug; der genaue Angriffsweg bleibt offen. Für das Management verändert sich damit die Frage. Es geht nicht mehr nur darum, ob ein Bericht fristgerecht versendet werden kann, sondern ob Engineering-Kapazität, Kundenkommunikation und mögliche Abhilfe auf denselben Fallstand ausgerichtet sind. Wird ein Hotfix priorisiert, muss klar sein, welche Versionen er adressiert und wie diese Information in Untersuchung und Meldung fortgeschrieben wird. Wird die externe Kommunikation zurückgehalten, braucht auch das einen Owner und einen festgelegten Überprüfungspunkt. Zeitdruck hebt Governance nicht auf; er macht ihre fehlenden Verbindungen sichtbar.
24 und 72 Stunden sind zwei verschiedene Arbeitsprodukte
Innerhalb von 24 Stunden: frühe Warnung, nicht fertige Forensik
Die 24-Stunden-Stufe ist eine Frühwarnung. Operativ braucht das Team dafür einen knappen, kontrollierten Datensatz. Er hält Zeitpunkt und Quelle der Kenntniserlangung, den betroffenen Hersteller-Rechtsträger sowie Produkt, Versionen und bekannte Verbreitung fest. Hinzu kommen die vermutete Ereignisklasse mit Begründung, aktuell bestätigte Auswirkungen, laufende Sofortmaßnahmen und benannte Ansprech- und Entscheidungsrollen. Offene Fragen erhalten eine nächste Aktualisierung statt eines leeren Feldes.
Das Ziel ist nicht, Unsicherheit zu verstecken. Das Ziel ist, bestätigte Fakten, plausible Bewertung und Unbekanntes sauber zu trennen. Ein bewusst unvollständiger, aber kontrollierter Frühstand ist belastbarer als eine verspätete „perfekte“ Darstellung.
Innerhalb von 72 Stunden: strukturierte Vollmeldung
Bis zur 72-Stunden-Stufe müssen Untersuchung und Governance zusammenlaufen. Produktsecurity, Engineering, Betrieb, Support, Legal/Compliance und Management sollten einen gemeinsamen Fall führen statt parallele Wahrheiten in Chat, Tickets und Tabellen zu pflegen.
Der 72-Stunden-Datensatz aktualisiert die technische Beschreibung und die betroffenen Produktstände. Er führt die Evidenz für aktive Ausnutzung oder die Schwere des Vorfalls mit den bekannten Nutzer-, Markt- und Sicherheitsauswirkungen zusammen. Angriffsvektor, Indikatoren und vermutete Ursache werden aufgenommen, soweit sie verfügbar sind. Ebenso gehören ergriffene Eindämmungs- und Abhilfemaßnahmen, der Kommunikations- und Updateplan sowie verbleibende Unsicherheit mit Owner und nächster Frist in denselben Fall.
Die beiden Stufen brauchen deshalb getrennte Vorlagen, aber dieselbe Identität. Die 72-Stunden-Meldung darf nicht als neues Dokument ohne Herkunft entstehen; sie muss den Erkenntnisstand der Frühwarnung nachvollziehbar fortschreiben. Korrigierte Annahmen werden kenntlich gemacht, nicht still ersetzt. Die Versionierung ermöglicht später zu erklären, was zu welchem Zeitpunkt bekannt und entschieden war.
Ein praktikables Fallmodell trennt dabei vier Ebenen. Die Eingangsevidenz bleibt quellengetreu erhalten. Der aktuelle technische Befund fasst reproduzierbare Beobachtungen zusammen. Das Entscheidungsprotokoll verbindet diese Befunde mit Ereignisklasse, Herstellerrolle, Freigabe und Zeitstempel. Die übermittelte Fassung bildet schließlich genau den genehmigten Stand ab. Diese Trennung ist keine Dokumentationsakrobatik. Sie verhindert, dass eine später korrigierte technische Annahme rückwirkend wie eine damalige Gewissheit wirkt oder eine Managemententscheidung unbemerkt mit jedem Ticket-Edit ihren Inhalt ändert.
Für die 72-Stunden-Arbeit braucht der Fall außerdem einen festen Aktualisierungsrhythmus. Engineering kann fortlaufend untersuchen, doch zu vereinbarten Zeitpunkten wird der meldefähige Stand eingefroren, auf Widersprüche geprüft und freigegeben. So geraten neue Indikatoren nicht unkontrolliert in einen bereits abgestimmten Bericht. Umgekehrt bleibt eine relevante Erkenntnis nicht bis zum nächsten großen Lagegespräch liegen. Der Mechanismus verbindet fachliche Geschwindigkeit mit kontrollierter Veröffentlichung: laufende Analyse, definierter Cut-off, gezielte Prüfung und nachvollziehbare neue Version.
Die offizielle CRA-Seite nennt außerdem unterschiedliche Abschlussstufen: Bei aktiv ausgenutzten Schwachstellen ist ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrekturmaßnahme verfügbar ist, vorgesehen; bei schwerwiegenden Vorfällen innerhalb eines Monats. Diese nachgelagerten Pfade sollten nicht in einem generischen Feld „final report due“ verschwinden.
Ein Meldekanal bedeutet nicht nur eine interne Rolle
Hersteller nutzen nach der Kommissionsseite für denselben meldepflichtigen Sachverhalt einen Meldeweg über die CRA Single Reporting Platform (SRP), statt getrennt an mehrere Stellen zu berichten. Die Meldung ist an das CSIRT am Ort der Hauptniederlassung gerichtet und wird – abgesehen von besonders außergewöhnlichen Umständen – gleichzeitig ENISA zugänglich gemacht. Das zuerst empfangende CSIRT teilt sie ohne Verzögerung mit den weiteren CSIRTs, in deren Gebiet das Produkt bereitgestellt wurde. Nach dem Stand vom 31. Juli 2026 laufen Funktions- und Sicherheitstests; die Plattform soll bis zum 11. September 2026 betriebsbereit sein.
Intern bleiben jedoch mehrere Übergaben nötig. Im Intake nehmen Support, SOC, Forscherkontakt, Bug Bounty, Lieferant oder Telemetrie ein Signal an. Die Triage durch PSIRT oder Product Security prüft Produktbezug, Ausnutzung und Sicherheitsauswirkung. In der Rollenprüfung klären Compliance oder Legal gemeinsam mit Product Owner und Unternehmensdaten, welcher Rechtsträger als Hersteller handelt. Danach entscheidet eine ausdrücklich autorisierte Rolle über Klassifizierung und Meldung; unklare Fälle werden zeitgebunden eskaliert. Ein benannter Sender mit Stellvertretung nutzt die SRP und sichert Eingangsbeleg, Fassung und Zeitstempel. Engineering und Product Security schreiben den Fall fort, während Kommunikation und Management konsistente Aussagen führen.
Ein gemeinsamer Fall-Identifier sollte Signal, Entscheidung, Plattformbeleg, technische Evidenz, Maßnahmen und externe Kommunikation verbinden. Das reduziert nicht nur Suchzeit. Es verhindert auch, dass die 24-Stunden-Meldung zu einem isolierten PDF ohne Folgeverantwortung wird.
Die organisatorische Wirkung reicht weiter als PSIRT und Legal. Portfolioverantwortliche müssen Produkt- und Versionsdaten liefern können; Corporate Functions müssen die Hersteller-Rechtsträger verlässlich zuordnen; der Betrieb muss relevante Telemetrie bewahren; der Einkauf muss Lieferanten zu zeitnaher Zuarbeit befähigen. Kommunikation benötigt einen freigegebenen Faktenstand, ohne die technische Untersuchung zu ihrem Redaktionssystem zu machen. Management wiederum muss Konflikte um Kapazität und Risikobehandlung entscheiden können. Fehlen diese Verbindungen, wird die Frist operativ an genau die Funktion delegiert, die gerade am wenigsten Zeit hat: das Untersuchungsteam.
Ein sinnvolles Management-Dashboard zählt daher nicht nur offene Fälle. Es zeigt Zeit seit Kenntniserlangung, nächste Entscheidungsfrist, zuständige Herstellerrolle, Evidenzstatus, blockierende Abhängigkeiten und die Verfügbarkeit von Sender und Stellvertretung. Damit werden Ressourcenentscheidungen konkret. Ein Fall, dessen Ereignisklasse offen ist, weil ein externer Anbieter keine Artefakte liefert, braucht eine andere Eskalation als ein fertiger Bericht, dem nur die Freigabe fehlt. Beide als „in Bearbeitung“ zu markieren beruhigt vor allem die Ampel.
In einer zweiten hypothetischen Szene trifft der Eingangsbeleg zwar rechtzeitig ein, wird aber nur im persönlichen Postfach des Senders gespeichert. Zwei Tage später übernimmt die Vertretung und kann weder die übermittelte Fassung noch die zugrunde liegende Klassifizierungsentscheidung finden. Technisch wurde gemeldet; organisatorisch ist der Fall dennoch unterbrochen. Ein gemeinsamer Identifier und ein kontrollierter Ablageort machen aus dem persönlichen Versandakt einen fortsetzbaren Unternehmensprozess. Persönliche Postfächer sind vieles, aber selten ein überzeugendes Langzeitarchiv für kollektive Verantwortung.
Vier typische Fehlkonstruktionen vor dem Stichtag
Incident Response allein lässt Produktsignale außen vor
Nicht jeder Product-Security-Fall ist ein betrieblicher Incident des Herstellers. Eine aktiv ausgenutzte Schwachstelle kann über Forschung, Kunden oder Lieferkette bekannt werden. Intake und Klassifizierung müssen deshalb Produktentwicklung, Vulnerability Management und externe Hinweise einschließen.
Vollständige Gewissheit ist kein zulässiges Prozessdesign
Die 24-Stunden-Frühwarnung und die 72-Stunden-Vollmeldung bilden gerade einen gestuften Erkenntnisprozess ab. Der interne Ablauf muss mit unvollständigen Fakten umgehen können. Fehlende Gewissheit braucht einen Owner und eine nächste Prüfzeit – keinen stillen Pausenknopf.
Dienstleister ersetzen die Herstellerzuordnung nicht
Die Pflicht ist rollenbezogen. Der CRA nennt auf der offiziellen Reporting-Seite den Hersteller. Dienstleister können untersuchen, hosten oder übermitteln helfen; die Zuordnung des verantwortlichen Hersteller-Rechtsträgers und der Autorisierung darf aber nicht als implizite Annahme im Vertrag verschwinden.
Nicht bindende Leitlinien unterstützen, aber entscheiden nicht
Die Kommission veröffentlichte am 27. Juli 2026 praktische CRA-Leitlinien mit Beispielen, Flussdiagrammen und Erläuterungen, unter anderem zu Meldepflichten. Die Kommission bezeichnet diese Leitlinie ausdrücklich als nicht bindend. Sie ist wertvolle Umsetzungshilfe, aber keine stillschweigende Änderung des Verordnungstextes und keine Einzelfallentscheidung.
Für die Umsetzung bedeutet das: Die Leitlinie kann interne Fragen, Vorlagen und Übungsszenarien präzisieren. Die konkrete Rollen- und Ereignisbewertung bleibt trotzdem am Produkt, Rechtsträger und Sachverhalt auszurichten. Wird eine Passage als Begründung verwendet, sollte die Entscheidung festhalten, welche Fakten des Falls dazu passen und wo Unsicherheit verbleibt. So dient die Leitlinie als Orientierung, ohne zur ausgelagerten Entscheidungsinstanz zu werden.
Managementcheckliste für den 11. September 2026
- Produktportfolio, Hersteller-Rechtsträger und getrennte Triagekriterien für beide Ereignisklassen sind dokumentiert.
- Kenntniszeitpunkt, Fall-Identifier, technische Evidenz, Entscheidungen und externe Kommunikation bleiben nachvollziehbar verbunden.
- Support, SOC, PSIRT, Engineering, Legal/Compliance und Management kennen Übergaben, Autorität und Stellvertretung.
- Vorlagen und Fristen für 24-Stunden-, 72-Stunden- und ereignisspezifische Abschlussberichte sind getrennt geführt.
- SRP-Zugang, Versand und Eingangsbelege sind getestet; Lieferanten- und Forscherhinweise erreichen die Product-Security-Triage direkt.
- Eine Tabletop-Übung mit unvollständigen Fakten und abwesender Hauptrolle liefert Management ein priorisiertes Backlog.
Fazit und A-R-C-Handlungsimpuls
Die CRA-Meldepflicht ist kein Portalprojekt. Sie ist ein zeitkritischer Entscheidungsprozess über Produkt, Ereignis, Herstellerrolle, Evidenz und Kommunikation. Gute Vorbereitung verkürzt nicht nur die Übermittlung. Sie macht sichtbar, wer unter Unsicherheit entscheiden darf und wie jede Aussage später belegt wird.
Der nächste konkrete Schritt: Spielen Sie innerhalb von 90 Minuten einen Fall durch, der an einem Freitag über den Support eingeht, aktive Ausnutzung nur vermuten lässt und den primären Meldeverantwortlichen nicht erreicht. Messen Sie die Zeit bis zu Rechtsträgerzuordnung, Kenntniszeitpunkt, Klassifizierungsentscheidung und freigabefähiger Frühwarnung. Die Lücken aus dieser Übung sind Ihr echtes Backlog.
Abgrenzung
Dieser Beitrag ist eine fachliche Einordnung zu Product Security, Governance und Umsetzungspraxis. Er ersetzt keine Rechtsberatung, behördliche Auskunft, Konformitätsbewertung, Zertifizierung oder unabhängige Prüfung. CRA-Anwendbarkeit, Herstellerrolle, Ereignisklassifizierung und Meldepflicht sind anhand des konkreten Produkts, Rechtsträgers und Sachverhalts zu prüfen. A-R-C garantiert weder Rechtskonformität noch Zertifizierung oder ein bestimmtes Prüfungsergebnis.
Primärquellen
- Europäische Kommission, „Commission publishes new guidance to support timely Cyber Resilience Act implementation“, veröffentlicht am 27.07.2026; die Leitlinie wird dort ausdrücklich als nicht bindend bezeichnet; abgerufen am 02.08.2026: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
- Europäische Kommission, „Cyber Resilience Act – Reporting obligations“, abgerufen am 02.08.2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- Europäische Kommission, „Cyber Resilience Act“, abgerufen am 02.08.2026: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Über den Autor
Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.