Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle nach Artikel 14 des Cyber Resilience Act melden. Die Frühwarnung ist innerhalb von 24 Stunden nach Kenntniserlangung fällig, die Folgemeldung innerhalb von 72 Stunden. Die übrigen zentralen CRA-Vorgaben gelten ab dem 11. Dezember 2027, doch die Meldepflicht erfasst auch Produkte im CRA-Geltungsbereich, die vorher auf dem EU-Markt bereitgestellt wurden.
Die CRA-Meldepflicht ist primär ein Produkt- und Incident-Prozess, keine nachgelagerte Rechtsprüfung. Die rechtliche Bewertung bleibt unverzichtbar, doch ohne versionsgenaue Produktdaten und technische Belege kann sie die Fristen nicht absichern. Der Ablauf beginnt deshalb mit dem Produktumfang und führt über die Trigger-Klassifikation bis zum Abschlussbericht.
1. Geltungsbereich prüfen: Erfasst der CRA das Produkt?
Ein Produkt mit digitalen Elementen umfasst Software oder Hardware, wenn eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk vorgesehen oder vernünftigerweise vorhersehbar ist. Lösungen für die entfernte Datenverarbeitung gehören ebenfalls dazu, wenn der Hersteller sie entwickelt hat oder entwickeln ließ und das Produkt ohne sie eine seiner Funktionen nicht erfüllen würde.
Für die Geltungsbereichsprüfung reicht der Produktname nicht aus. Der Datensatz muss die ausgelieferte Version, den Support-Zeitraum, das Datum der Bereitstellung auf dem EU-Markt und die Rolle des eigenen Unternehmens abbilden. Auch sektorspezifische Ausnahmen sowie freie und quelloffene Software außerhalb einer kommerziellen Tätigkeit gehören in die Prüfung.
- Der Produkteintrag nennt die Produktfamilie, die Versionen und die Releases
- Die Versionsmatrix enthält das Support-Ende, den Lieferstatus und die eingesetzten Komponenten
- Das Rollenblatt erfasst den Hersteller, die Importeure, die Händler und die Bevollmächtigten
- Die Prüfung dokumentiert sektorspezifische Ausnahmen und den kommerziellen Kontext
- Das Incident-Log verknüpft den Produkteintrag mit späteren Sicherheitsmeldungen
Mit dem abgegrenzten Produktumfang lässt sich prüfen, ob ein Sicherheitsbefund einen der beiden CRA-Meldetrigger erfüllt.
2. Wann löst eine Schwachstelle die CRA-Meldung aus?
Ein CVE-Eintrag oder ein hoher CVSS-Wert genügt nicht. Meldepflichtig wird eine Schwachstelle, sobald verlässliche Belege zeigen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemverantwortlichen ausgenutzt hat. Unabhängig davon löst ein schwerer Sicherheitsvorfall eine Meldung aus, wenn er geschützte Daten oder wesentliche Produktfunktionen beeinträchtigt oder beeinträchtigen kann.
Ein öffentliches Proof of Concept belegt die technische Machbarkeit, aber noch keinen tatsächlichen Angriff. Als Nachweis einer aktiven Ausnutzung kommen bestätigte Telemetrie, nachvollziehbare Angriffsspuren oder verifizierte externe Meldungen infrage. Ein schwerer Sicherheitsvorfall kann zusätzlich vorliegen, wenn ein Ereignis schädlichen Code in ein Produkt oder in das Netzwerk eines Nutzers einschleust oder ausführt.
| Befund | Beleglage | CRA-Klassifikation |
|---|---|---|
| Gewöhnliche Schwachstelle | CVE, Scan-Treffer oder Sicherheitshinweis ohne Nachweis einer aktiven Ausnutzung | Keine Meldung allein aufgrund dieses Befunds, aber reguläre Schwachstellenbehandlung und Risikobewertung |
| CRA actively exploited vulnerability | Bestätigte Telemetrie, Angriffsspuren oder verifizierte Meldungen über eine unbefugte Ausnutzung | Frühwarnung nach 24 Stunden, Folgemeldung nach 72 Stunden und späterer Abschlussbericht |
| CRA severe security incident | Tatsächliche oder mögliche Beeinträchtigung geschützter Daten, wesentlicher Funktionen oder der Produktsicherheit durch schädlichen Code | Frühwarnung nach 24 Stunden, Folgemeldung nach 72 Stunden und Abschlussbericht innerhalb eines Monats nach der Folgemeldung |
Im Incident-Log hält das Team die Belege, die verbleibenden Unsicherheiten und die Begründung der Klassifikation fest. CVSS-Werte unterstützen die technische Priorisierung, ersetzen aber weder den Nachweis der aktiven Ausnutzung noch die Bewertung eines schweren Sicherheitsvorfalls.
Sobald die verfügbaren Fakten einen Meldetrigger belegen, bestimmt der Zeitpunkt der Kenntniserlangung den Beginn beider Fristen.
3. Wann beginnt die 24-Stunden-Frist?
Der gesetzliche Fristbeginn richtet sich nach der tatsächlichen Kenntnis des Herstellers. Ein internes Freigabegremium verschiebt diesen Zeitpunkt nicht. Ein unbestätigter Scanner-Alarm belegt noch keine aktive Ausnutzung, während bestätigte SOC-Telemetrie, eine nachvollzogene Angriffskette oder eine verifizierte Kundenmeldung die erforderliche Beleglage herstellen kann.
Das Incident-Log sollte jeden Schritt mit Zeitstempel erfassen:
- Den Eingang des ersten Hinweises
- Die technische Verifikation
- Die betroffenen Produkte und Versionen
- Die Belegquellen und offenen Fragen
- Die Klassifikationsentscheidung und ihre Freigabe
- Widersprüchliche Informationen und spätere Korrekturen
Unsicherheit allein ist kein eigener gesetzlicher Meldetrigger. Die interne Eskalationsregel sollte jedoch verhindern, dass ungeklärte Belege ohne Verantwortlichen liegen bleiben und die tatsächliche Kenntniserlangung erst nach Ablauf der Frist dokumentiert wird.
Der Zeitstempel und die bestätigten Ausgangsdaten liefern die Datengrundlage für die Frühwarnung.
4. Frühwarnung innerhalb von 24 Stunden übermitteln
Die ENISA Single Reporting Platform dient als zentraler Meldeweg. Über sie erhält der zuständige nationale CSIRT-Koordinator gemeinsam mit ENISA die Meldung. Zugriffsrechte, Stellvertretungen und interne Freigaben müssen deshalb vor dem ersten Vorfall feststehen.
Datengrundlage für die Frühwarnung
- Das betroffene Produkt und die derzeit bekannten Versionen
- Der angenommene Meldetrigger und der Zeitpunkt der Kenntniserlangung
- Die bekannten Auswirkungen und der Stand der Untersuchung
- Die Trennung zwischen bestätigten Fakten, Annahmen und offenen Prüfungen
- Die bekannten betroffenen Mitgliedstaaten, soweit diese Angabe einschlägig ist
Bei einem schweren Sicherheitsvorfall beschreibt die Frühwarnung die Art des Vorfalls und nennt, ob rechtswidrige oder böswillige Handlungen vermutet werden. Bei einer aktiv ausgenutzten Schwachstelle dokumentiert der Hersteller auch, in welchen Mitgliedstaaten das betroffene Produkt nach seinem Kenntnisstand bereitgestellt wurde, soweit diese Angabe erforderlich ist.
Die Meldung an Behörden ersetzt nicht die Information der betroffenen Nutzer. Der Hersteller informiert sie ohne unangemessene Verzögerung über die aktiv ausgenutzte Schwachstelle oder den schweren Sicherheitsvorfall und nennt erforderliche Korrektur- oder Schutzmaßnahmen.
Eine vollständige Ursachenanalyse ist für die Frühwarnung nicht nötig. Die technische Untersuchung ergänzt den Vorgang bis zur 72-Stunden-Meldung.
5. Welche Angaben sind nach 72 Stunden fällig?
Auch die 72-Stunden-Frist beginnt mit der Kenntniserlangung, nicht mit dem Versand der Frühwarnung. Die Folgemeldung aktualisiert den ersten Datensatz und unterscheidet anschließend zwischen den beiden Meldetriggern.
Aktiv ausgenutzte Schwachstelle
Die Meldung beschreibt das betroffene Produkt sowie die allgemeine Art der Schwachstelle und ihrer Ausnutzung. Bereits umgesetzte Korrektur- oder Minderungsmaßnahmen gehören ebenso hinein wie Maßnahmen, die Nutzer selbst ergreifen können.
Schwerer Sicherheitsvorfall
Die Meldung enthält eine erste Bewertung von Schweregrad und Auswirkungen. Verfügbare Kompromittierungsindikatoren, auch Indicators of Compromise oder IoC genannt, ergänzen die Bewertung. Bestätigte und noch ungeklärte Auswirkungen bleiben getrennt.
Die Fachbereiche liefern dafür getrennte Beiträge:
- Die Produktsicherheit dokumentiert den Trigger und die technischen Belege
- Das SOC sichert Telemetrie, Angriffsspuren und Kompromittierungsindikatoren
- Die Entwicklung erfasst Korrekturen, Tests und betroffene Releases
- Recht und Compliance prüfen Fristen sowie regulatorische Angaben
Für die versionsgenaue Meldung braucht das Team eine Verbindung zwischen Komponenten, Builds und ausgelieferten Produktversionen. Diese Verbindung entsteht aus SBOM und VEX.
6. SBOM und VEX für die Produkt-Triage nutzen
Eine Software Bill of Materials zeigt, welche Releases eine betroffene Bibliothek enthalten. Formate wie SPDX 2.3 und CycloneDX 1.6 erfassen Komponenten, Versionen, Beziehungen und Kennungen. Package URLs, CPE-Namen und Hashwerte unterscheiden Pakete, die ähnlich oder gleich benannt sind.
Vulnerability Exploitability eXchange ergänzt die Komponentenliste um den Produktkontext. Ein VEX-Datensatz kann den Status betroffen, nicht betroffen, behoben oder in Untersuchung dokumentieren. CycloneDX VEX und CSAF 2.0 verknüpfen den Status mit einer konkreten Produktversion und einer Begründung.
Ein VEX-Status beweist keine aktive Ausnutzung. Er dokumentiert, ob und warum eine bekannte Schwachstelle ein bestimmtes Produkt betrifft. Lieferanteninformationen werden dafür mit Build-Daten, erreichbaren Codepfaden, Konfigurationen und Laufzeitbeobachtungen abgeglichen.
Im Cyber Resilience Act Training zu SBOM und Secure by Design wird die Verbindung aus CVE-Triage, VEX-Status, Incident-Runbook und Release-Gate praktisch bearbeitet. Weitere technische Grundlagen behandeln die IT-Security-Schulungen.
Sobald eine Korrektur oder Minderungsmaßnahme verfügbar ist, beginnt bei einer aktiv ausgenutzten Schwachstelle die Frist für den Abschlussbericht.
7. Abschlussbericht und Folgefristen planen
Frist bei einer aktiv ausgenutzten Schwachstelle
Der Abschlussbericht ist spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme fällig. Er beschreibt die Schwachstelle, ihren Schweregrad und ihre Auswirkungen. Hinzu kommen verfügbare Informationen über den Angreifer sowie Angaben zum Sicherheitsupdate oder zu anderen Schutzmaßnahmen.
Frist bei einem schweren Sicherheitsvorfall
Der Abschlussbericht ist spätestens einen Monat nach der 72-Stunden-Meldung fällig. Er dokumentiert Art, Schweregrad und Auswirkungen des Vorfalls sowie die Ursache und die umgesetzten Maßnahmen. Liegen beide Trigger vor, führt das Incident-Log beide Klassifikationen und überwacht die jeweiligen Fristen.
Produktversionen, SBOM-Stände, Entscheidungsprotokolle und Kommunikationsfreigaben müssen dem Vorgang eindeutig zugeordnet bleiben. Harmonisierte Standards können technische Nachweise konkretisieren, ändern aber nicht die gesetzlichen Fristen aus Artikel 14.
Die getrennten Fristen und Nachweise bestimmen, welche Fachbereiche im CRA-Incident-Modell Verantwortung übernehmen.
8. Rollen im CRA-Incident-Modell festlegen
- Die Produktsicherheit bewertet die Schwachstelle, den Produktkontext und die betroffenen Releases
- Das SOC validiert Alarme, sichert Kompromittierungsindikatoren und untersucht weitere Angriffsspuren
- Die Entwicklung und das DevOps-Team analysieren Komponenten, implementieren Minderungsmaßnahmen und testen neue Releases
- Recht und Compliance führen die Klassifikation, die Fristen und die regulatorischen Angaben zusammen
- Das Kommunikationsteam erstellt Nutzerinformationen ohne ausnutzbare technische Details
Die Arbeit mit Alerts, Incidents, Threat Hunting und Untersuchungsdaten lässt sich im SC-200 Training für Microsoft Security Operations Analysts vertiefen. Die CRA-Klassifikation benötigt zusätzlich die Produktversionen, die VEX-Aussagen und die rechtliche Bewertung.
Ein gemeinsamer Test zeigt anschließend, ob Übergaben, Zugriffsrechte und Stellvertretungen innerhalb der Meldefristen funktionieren.
9. Den Ablauf in einer 90-Minuten-Übung testen
Das Übungsszenario kombiniert eine ältere, noch unterstützte Produktversion mit einer Schwachstelle in einer Drittanbieter-Komponente. Ein Teil der Telemetrie deutet auf eine Ausnutzung hin, während der Lieferant noch keine abschließende VEX-Aussage bereitstellt. Das Team muss den Befund als aktiv ausgenutzte Schwachstelle, schweren Sicherheitsvorfall oder gewöhnliche Schwachstelle klassifizieren.
- In den ersten 15 Minuten erfasst das Team das Eingangssignal, den Produktumfang und den Zeitpunkt der Kenntniserlangung
- Bis Minute 35 dokumentiert das Team die Belege, die Unsicherheiten und die vorläufige Klassifikation
- Bis Minute 55 entsteht ein Entwurf der 24-Stunden-Frühwarnung
- Bis Minute 75 ergänzt das Team die Angaben für die 72-Stunden-Meldung
- Die letzten 15 Minuten erfassen Prozesslücken, fehlende Belege, unklare Rollen und zugewiesene Korrekturmaßnahmen
Der Test liefert einen verwertbaren Befund, wenn der Zeitpunkt der Kenntniserlangung, die Klassifikation und die offenen Angaben nach 90 Minuten dokumentiert sind. Das Ergebnis besteht aus dem Zeitprotokoll, den beiden Meldungsentwürfen und den zugewiesenen Prozessänderungen.
Plane den ersten Tabletop-Termin mit einer realen Produktstückliste. Nur so wird sichtbar, ob die SBOM tatsächlich zu den ausgelieferten Versionen und ihren Support-Zeiträumen passt.