CRA-Meldepflicht im Praxisbeispiel: Von der ersten Warnung bis zum Abschlussbericht

Eine CRA-Meldepflicht entsteht nicht erst, wenn der Hersteller die Ursache vollständig verstanden oder einen Patch fertiggestellt hat. Liegen verlässliche Nachweise einer aktiven Ausnutzung vor, muss die frühe Warnung unverzüglich und spätestens binnen 24 Stunden nach Kenntnis erfolgen. Weitere Informationen werden stufenweise ergänzt.

Das folgende Beispiel zeigt einen fiktiven Fall bei einem industriellen Gateway. Alle Namen, Versionen und Uhrzeiten dienen der Erläuterung. Es handelt sich nicht um einen dokumentierten Angriff auf ein reales Unternehmen. Im Mittelpunkt stehen Entscheidungen, die ein Produktteam auch mit unvollständigen Informationen treffen muss.

Für die gesetzlichen Grundlagen empfehlen sich die CRA-Meldepflichten. Der Cyber Resilience Act im Überblick erläutert die Verbindung zwischen Produktsicherheit, Schwachstellenbehandlung und Herstellerverantwortung.

Wann beginnt im Beispiel die Meldefrist?

Die Frist beginnt hier am Montag um 09:20 Uhr, weil dem Hersteller zu diesem Zeitpunkt verlässliche Nachweise einer aktiven Ausnutzung vorliegen. Der spätere Beginn der Teamsitzung oder die Zustimmung der Geschäftsleitung verschiebt diesen Zeitpunkt nicht. Ein früherer unbestätigter Verdacht wird separat dokumentiert.

Am Montag um 08:40 Uhr erreicht den Support eine Kundenmeldung: Ein Gateway hat seine Konfiguration ohne erkennbaren Auftrag geändert. Das kann verschiedene Ursachen haben. Der Support sichert die Nachricht, fragt nach Version und Protokollen und leitet den Fall sofort an die Produktsicherheitsfunktion weiter. Eine normale Antwortfrist von drei Werktagen wäre für diese Eingangsklasse ungeeignet.

Um 09:20 Uhr liegen nachvollziehbare Protokolle vor. Sie zeigen, dass ein fremder Zugriff über die Wartungsschnittstelle eine geschützte Einstellung verändert hat. Die technische Prüfung bestätigt, dass es sich nicht um einen autorisierten Servicevorgang handelt. Damit besteht die für dieses Beispiel vorausgesetzte verlässliche Beweislage.

Einordnung vor Bewertungsschablonen

Das Team vergibt zunächst eine Fallnummer, benennt eine Fallleitung und hält den Kenntniszeitpunkt fest. Anschließend prüft es, welche Meldekategorie einschlägig ist. Eine aktiv ausgenutzte Schwachstelle und ein schwerwiegender Sicherheitsvorfall sind unterschiedliche Tatbestände. Ein Fall kann eine Prüfung beider Wege erfordern.

Ein hoher CVSS-Wert allein belegt keine aktive Ausnutzung. Umgekehrt ist ein niedrigerer technischer Score kein Grund, verlässliche Ausnutzungsnachweise zu ignorieren. Der Hersteller muss das konkrete Produkt und die bekannten Betriebsbedingungen berücksichtigen. Diese Trennung verhindert, dass eine automatische Scannerbewertung über die gesetzliche Meldeentscheidung bestimmt.

Die erste Fristberechnung

Für das Beispiel endet die äußere 24-Stunden-Frist am Dienstag um 09:20 Uhr. Die äußere 72-Stunden-Frist endet am Donnerstag um 09:20 Uhr. Beide beziehen sich auf denselben Ausgangspunkt. Die frühe Warnung startet keine neue 72-Stunden-Frist.

In der internen Akte stehen Datum, Uhrzeit und Zeitzone. Zusätzlich wird die Zeit in UTC gespeichert, damit internationale Teams nicht mit verschiedenen Ortszeiten arbeiten. Kalenderalarme gehen an Fallleitung und Vertretung. Ein zweiter Alarm kurz vor Fristablauf ersetzt jedoch keine rechtzeitige Bearbeitung.

Was tut das Team vor der frühen Warnung?

Das Team sichert die Beweise, grenzt betroffene Produkte vorläufig ein und bereitet eine handlungsfähige erste Meldung vor. Es wartet nicht auf einen abschließenden Bericht. Zugleich laufen technische Risikominderung und Nutzerkommunikation als eigene Aufgaben.

Um 10:00 Uhr vergleicht die Entwicklung das betroffene Gateway mit der freigegebenen Firmware. Die Wartungsschnittstelle ist in den Versionen 3.4 und 3.5 vorhanden. Ob beide ausnutzbar sind, steht noch nicht fest. Für Version 3.3 fehlt zunächst ein Testgerät. Der vorläufige Umfang wird deshalb als offene Untersuchungsfrage geführt.

Der Support kann aus dem Inventar erkennen, welche Kunden die betroffenen Zweige einsetzen könnten. Eine Versionsliste allein genügt aber nicht: Manche Geräte sind vom Kunden aktualisiert, andere seit Monaten offline. Die Fallleitung unterscheidet deshalb ausgelieferte Versionen, bestätigte aktuelle Versionen und unbekannte Betriebsstände.

Sofortmaßnahmen auf Umsetzbarkeit prüfen

Die Entwicklung schlägt vor, den externen Wartungszugang bis zum Update zu deaktivieren. Vor der Empfehlung wird geprüft, ob dadurch notwendige Betriebsfunktionen ausfallen und ob Nutzer den Zugang ohne spezielle Herstellerwerkzeuge sperren können. Eine Schutzmaßnahme, die nur im Labor funktioniert, ist für betroffene Kunden nicht ausreichend.

Parallel prüft das Team die Zugriffsschutzmaßnahmen und die Ereignisprotokollierung. Es verändert Beweisgeräte nicht unkontrolliert. Für eine nötige Sicherung wird festgehalten, welche Daten vor und nach einer Maßnahme vorhanden waren. Technische Eile rechtfertigt keine vermeidbare Vernichtung der Ausgangsbefunde.

Die frühe Warnung formulieren

Am Montag um 14:30 Uhr liegt ein abgestimmter Sachstand vor: Produktfamilie, bekannte Ausnutzung, vorläufige Versionsspanne, mögliche Sicherheitswirkung und bereits vorbereitete Risikominderung. Nicht gesicherte Angaben werden als vorläufig bezeichnet. Die Meldung enthält keine Vermutungen über den Angreifer, die aus den Belegen nicht hervorgehen.

Die befugte Meldeperson übermittelt die frühe Warnung über die Single Reporting Platform. Sie kontrolliert anschließend die Fallreferenz und den Übermittlungsstatus. Der interne Vorgang enthält den abgesendeten Stand und die Bestätigung. Das Formular wurde nicht nur als Entwurf gespeichert.

Der Eingang erfolgt damit deutlich vor der äußeren Frist. Der Zeitgewinn wird für Untersuchungen genutzt, nicht für die Annahme, der Fall sei nun behördlich „erledigt“. Die Verantwortung für Abhilfe und weitere zutreffende Informationen bleibt beim Hersteller.

Welche Erkenntnisse gehören in die 72-Stunden-Meldung?

Die 72-Stunden-Meldung konkretisiert die Schwachstelle, ihre Auswirkungen und die verfügbaren Maßnahmen. Im Beispiel muss sie spätestens am Donnerstag um 09:20 Uhr vorliegen. Neue belastbare Erkenntnisse werden nachvollziehbar auf den ursprünglichen Fall bezogen.

Am Dienstag bestätigt die Untersuchung: Die Schwachstelle liegt in der Prüfung einer Berechtigung innerhalb der Wartungsschnittstelle. Version 3.4 und 3.5 sind betroffen; die ältere Version 3.3 verwendet einen anderen Ablauf und wurde mit gezielten Tests ausgeschlossen. Zwei Hardwarevarianten nutzen denselben Softwarezweig.

Diese Eingrenzung wird nicht lediglich als neue Liste gespeichert. Das Team dokumentiert den Testaufbau und warum die Ergebnisse auf die jeweiligen Varianten übertragbar sind. Ein abweichender Chip oder ein anderes Betriebssystem könnte diese Übertragbarkeit verändern. Deshalb wird der Ausschluss weiterer Varianten begründet.

Schutzmaßnahmen konkret beschreiben

Eine nutzbare Zwischenmaßnahme beschreibt das betroffene Menü, die benötigte Berechtigung und die Kontrolle des Ergebnisses. Der Kunde muss erkennen können, ob der Wartungszugang nach seiner Handlung tatsächlich deaktiviert ist. Gibt es unterschiedliche Oberflächen, werden die Schritte nach Version getrennt.

Der Hinweis „Firewall richtig konfigurieren“ reicht in diesem Fall nicht. Viele Kunden kennen weder den relevanten Port noch die vorgesehene Netzgrenze. Das Team erläutert die konkrete Einschränkung und benennt verbleibende Risiken. Es vermeidet die Zusicherung vollständiger Sicherheit, wenn nur ein Angriffsweg unterbrochen wurde.

Die Maßnahmen werden mit der CRA-Risikobewertung abgeglichen. Die Änderung darf beispielsweise nicht den Zugriff des Betreibers auf notwendige Alarme abschalten. Wenn Risiken gegeneinander abgewogen werden müssen, gehört diese Abwägung in die technische Akte.

Nutzerinformation und Meldestand abstimmen

Am Mittwoch erhalten betroffene Nutzer eine verständliche Sicherheitsinformation. Sie enthält Versionen, Zwischenmaßnahme, Kontakt und den Bezugspunkt für weitere Updates. Die Behördenmeldung und die Nutzerinformation unterscheiden sich im Detailgrad, dürfen aber nicht widersprüchlich sein.

Die 72-Stunden-Meldung wird am Mittwoch um 16:10 Uhr übermittelt. Sie verweist auf die frühe Warnung und beschreibt die bestätigte Eingrenzung. Der dokumentierte Kenntniszeitpunkt bleibt unverändert. Die frühzeitige Übermittlung verhindert, dass ein technisches Portalproblem am Donnerstagmorgen zum einzigen verbleibenden Handlungsspielraum wird.

Wie werden Patch und Abschlussbericht organisiert?

Der Patch braucht nachvollziehbare Sicherheits- und Regressionstests sowie einen sicheren Bereitstellungsweg. Der Abschlussbericht folgt einer eigenen gesetzlichen Frist. Bei einer aktiv ausgenutzten Schwachstelle ist er grundsätzlich spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Risikominderungsmaßnahme erforderlich.

Für dieses Beispiel wurde bereits am Montag um 15:00 Uhr eine tatsächlich anwendbare Risikominderungsmaßnahme verfügbar gemacht. Das Team setzt deshalb nicht automatisch den späteren Patchtermin als Beginn der Abschlussfrist an. Es prüft und dokumentiert den rechtlich maßgeblichen Zeitpunkt. Die verwendete Fristenberechnung darf einen früher verfügbaren Mitigationsschritt nicht übersehen.

Freigabe der Sicherheitsaktualisierung

Die Entwicklung korrigiert die Berechtigungsprüfung. Ein Test reproduziert zunächst den ursprünglichen Angriff auf dem alten Stand und weist anschließend die Wirksamkeit der Korrektur nach. Zusätzliche Tests kontrollieren legitime Wartungsvorgänge und die Behandlung fehlerhafter Eingaben. Nur ein bestandener Funktionstest des Hauptmenüs wäre zu wenig.

Das Update wird signiert, über den vorgesehenen Kanal bereitgestellt und nach Version zugeordnet. Ein vollständiges Paket und ein Differenzupdate können unterschiedliche Voraussetzungen haben. Der Downloadhinweis benennt diese Voraussetzungen, damit Nutzer nicht versehentlich ein unpassendes Paket installieren.

Die Dokumentation der CRA-Sicherheitsupdates umfasst auch den Umgang mit unterbrochenen Installationen und Rückfällen. Das Team muss feststellen können, welches Gerät welchen Sicherheitsstand erreicht hat, soweit dies im jeweiligen Produktkonzept technisch und datenschutzgerecht möglich ist.

Bericht und Wirksamkeit getrennt betrachten

Der Abschlussbericht beschreibt Schwachstelle, Sicherheitswirkung, betroffene Produkte und Maßnahmen. Außerdem hält die interne Akte fest, welche Nutzer erreicht wurden und welche Umsetzungsfragen offenbleiben. Die Meldung „Patch veröffentlicht“ bedeutet nicht, dass jedes Gerät aktualisiert wurde.

Nach Abschluss wird der Fall intern nachbearbeitet. Warum war die Berechtigungsprüfung unzureichend? Warum wurde sie durch vorhandene Tests nicht erkannt? Welche ähnlichen Schnittstellen müssen geprüft werden? Daraus entstehen gezielte Änderungen im Entwicklungsprozess. Eine allgemeine Schulung ohne Bezug zur Ursache wäre weniger wirksam.

Was wäre bei einem schwerwiegenden Sicherheitsvorfall anders?

Bei einem schwerwiegenden Sicherheitsvorfall gelten ebenfalls frühe Warnung und Vorfallmeldung, aber andere Inhalte und Regeln für den Abschlussbericht. Die Einordnung darf deshalb nicht automatisch aus einem Schwachstellenformular übernommen werden. Entscheidend ist die negative Wirkung auf die Sicherheit des Produkts.

Ein zweites fiktives Szenario verdeutlicht den Unterschied: Ein Angreifer erhält Zugriff auf den produktiven Signierungsdienst und manipuliert ein bereits bereitgestelltes Update. Der Hersteller muss prüfen, welche Produkte das manipulierte Paket erhalten konnten und ob die gesetzlichen Kriterien eines schwerwiegenden Vorfalls erfüllt sind.

Hier stehen Ausmaß, Auswirkungen, Ursache, Wiederherstellung und Risikominderung des Vorfalls im Vordergrund. Der Abschlussbericht ist grundsätzlich spätestens einen Monat nach Übermittlung der entsprechenden Vorfallmeldung vorgesehen. Dauert der Vorfall zu diesem Zeitpunkt an, sind die gesetzlichen Regeln zum Fortschrittsbericht und späteren Abschluss zu berücksichtigen.

Die Fallleitung führt getrennte Prüfpunkte für aktive Ausnutzung und schwerwiegenden Vorfall. Sie klärt die erforderliche Meldung mit Bezug auf den konkreten Sachverhalt. Der einfachste Formulartyp ist kein rechtliches Auswahlkriterium. Ebenso wenig ersetzt eine Anzeige bei der Polizei eine CRA-Meldung.

Was passiert bei einer späteren Ausweitung?

Im Gateway-Beispiel könnte am Freitag ein weiterer Hardwarezweig betroffen sein. Die erste Eingrenzung war auf Grundlage der damaligen Belege zutreffend, muss aber nun ergänzt werden. Das Team erklärt, welche neue Erkenntnis die Änderung ausgelöst hat, und aktualisiert Produktumfang, Nutzermaßnahmen und den vorgesehenen Meldestand. Ein neuer Befund darf nicht aus Sorge vor einem widersprüchlichen Eindruck verschwiegen werden.

Gleichzeitig wird geprüft, ob die bereits bereitgestellte Zwischenmaßnahme auf den zusätzlichen Zweig anwendbar ist. Ein anders aufgebautes Wartungsmenü kann eine andere Anleitung benötigen. Die technische Maßnahme und der Kommunikationsumfang werden deshalb gemeinsam überprüft. Ein pauschaler Hinweis an alle Kunden ohne Versionsbezug kann sonst gerade die neu betroffenen Nutzer verwirren.

Die Akte behält den früheren Stand und markiert die Ergänzung. Sie ersetzt die alte Aussage nicht kommentarlos. So bleibt nachvollziehbar, dass der Hersteller den Sachverhalt fortlaufend bewertet hat. Diese Arbeitsweise hilft auch bei Rückfragen der zuständigen Stellen.

Welche Zeitpunkte werden zusätzlich benötigt?

Neben der Kenntnis werden im Beispiel Zeitpunkt und Umfang der Risikominderung, Patchverfügbarkeit und Nutzerinformation festgehalten. Diese Ereignisse sind nicht identisch. Eine intern fertiggestellte Korrektur ist noch kein für Nutzer verfügbares Paket; eine vorbereitete Nachricht ist noch keine versandte Warnung.

Die Fallleitung kontrolliert deshalb das tatsächliche Ergebnis. Ist der Download erreichbar? Passt das Paket zur betroffenen Variante? Wurde die Warnung über den vorgesehenen Kanal zugestellt? Erst diese Prüfung macht aus internen Statusmeldungen eine belastbare Dokumentation der Maßnahmen.

Welche Fehler zeigt das Beispiel besonders deutlich?

Die häufigsten Fehler entstehen durch verspätete Eskalation, falsche Fristrechnung und ungeprüfte Vollständigkeitsansprüche. Ein belastbarer Prozess ermöglicht zutreffende frühe Informationen und nachvollziehbare Ergänzungen. Er muss nicht bereits am ersten Tag jede Detailfrage beantworten.

• Der Support behandelt einen Sicherheitsbefund wie eine gewöhnliche Reklamation.
• Die 24-Stunden-Frist wird erst ab interner Freigabe gerechnet.
• Nach der frühen Warnung werden weitere 72 Stunden angenommen.
• Ein gespeicherter Entwurf wird mit einer eingereichten Meldung verwechselt.
• Eine hohe Scannerbewertung wird als Nachweis aktiver Ausnutzung behandelt.
• Der Zeitpunkt einer verfügbaren Zwischenmaßnahme wird bei der Abschlussfrist übersehen.
• Behördenmeldung, Nutzerwarnung und Patchfreigabe erzählen unterschiedliche Sachstände.

Für eine eigene Übung können Unternehmen die Uhrzeiten und Versionszweige dieses Beispiels anpassen. Behalten Sie jedoch die entscheidenden Prüfstellen bei: belegte Kenntnis, dokumentierte Zuständigkeit, fristgerechte Übermittlung, umsetzbare Maßnahmen und ein nachvollziehbarer Abschluss. So lässt sich prüfen, ob die Schwachstellenbehandlung und Meldung tatsächlich funktioniert.

Quelle und fachlicher Prüfstand: Cyber Resilience Act, insbesondere Artikel 14 und Begriffsbestimmungen. Quellen geprüft am 4. Oktober 2026. Redaktion: Jörn Poppenhäger.