Seit dem 11. September 2026 gelten für Hersteller die Meldepflichten aus Artikel 14 der Verordnung (EU) 2024/2847, des Cyber Resilience Act (CRA). Zu melden sind aktiv ausgenutzte Schwachstellen in Produkten mit digitalen Elementen sowie schwere Sicherheitsvorfälle mit Auswirkungen auf deren Sicherheit. Die operative Schwierigkeit liegt regelmäßig nicht in der Übermittlung über die Single Reporting Platform (SRP), sondern davor: Organisationen müssen nachvollziehbar entscheiden, wann ein Hinweis zu einer meldepflichtigen Lage geworden ist.
Für diese Entscheidung braucht es einen belastbaren Triage-Workflow. Er muss externe Exploitation-Hinweise, den technischen Bezug zum eigenen Produkt und die Evidenz einer aktiven Ausnutzung getrennt bewerten. Zugleich muss er Daten so strukturieren, dass sie von der Frühwarnung bis zum Abschlussbericht konsistent fortgeschrieben werden können.
Abgrenzung des Meldeauslösers: Nicht jede CVE startet die CRA-Uhr
Eine veröffentlichte CVE, ein Eintrag in einer Schwachstellenliste, eine Lieferantenmeldung oder ein Medienbericht sind wichtige Untersuchungsimpulse. Sie belegen jedoch für sich genommen weder, dass das eigene Produkt betroffen ist, noch, dass eine Schwachstelle im Sinne des CRA aktiv ausgenutzt wird.
Artikel 3 Nummer 42 CRA definiert die aktiv ausgenutzte Schwachstelle als eine Schwachstelle, für deren Ausnutzung durch einen böswilligen Akteur in einem System ohne Erlaubnis des Systeminhabers zuverlässige Belege vorliegen. Die Triage sollte deshalb mindestens drei Fragen separat beantworten:
- Ist die betreffende Schwachstelle oder der Vorfall technisch dem eigenen Produkt zuzuordnen?
- Welche Produktversionen, Build- oder Firmwarestände, Konfigurationen und integrierten Komponenten sind betroffen?
- Liegen belastbare Hinweise auf aktive Ausnutzung vor, oder handelt es sich bislang um einen externen Hinweis ohne bestätigten Produktbezug?
Diese Trennung verhindert zwei typische Fehler: Eine allgemeine Warnung wird nicht vorschnell als eigene Meldepflicht behandelt. Umgekehrt bleibt eine bestätigte Ausnutzung nicht deshalb ohne Eskalation, weil die technische Betroffenheitsanalyse noch nicht vollständig abgeschlossen ist. Offene Punkte sollten als Untersuchungsstand dokumentiert und fristgerecht fortgeschrieben werden.
Der Awareness-Zeitpunkt als beweisbare Triageentscheidung
Die Fristen nach Artikel 14 knüpfen an die Kenntniserlangung des Herstellers an. Die Frühwarnung ist unverzüglich und spätestens binnen 24 Stunden abzugeben; die weitergehende Schwachstellen- oder Vorfallsmeldung folgt unverzüglich und spätestens binnen 72 Stunden. Damit ist der Awareness-Zeitpunkt kein bloßer Zeitstempel aus einem Ticketsystem, sondern ein entscheidungsrelevanter Nachweis.
Ein praxistauglicher Ereignisdatensatz sollte die Quelle des Hinweises, dessen Eingangszeit, die Erstbewertung, die verfügbaren Belege, die verantwortlichen Entscheider und den Zeitpunkt der belastbaren Kenntnisentscheidung enthalten. Der Veröffentlichungszeitpunkt einer CVE oder der Eingang eines unqualifizierten Support-Tickets darf dabei nicht automatisch mit dem Zeitpunkt der Kenntniserlangung gleichgesetzt werden.
Die SRP erfasst Datum und Uhrzeit des Awareness-Zeitpunkts in UTC. Ist der genaue Zeitpunkt nicht bekannt, sieht das SRP Glossary eine bestgestützte Schätzung vor; diese ist in der Beschreibung der Schwachstelle oder des Vorfalls als Schätzung kenntlich zu machen. Eine dokumentierte Begründung für die Schätzung ist daher Teil einer belastbaren Nachweisführung.
Triage-Workflow: Produkt, Version und Komponente einordnen
Die technische Triage benötigt eine gemeinsame Referenz von PSIRT, Entwicklung, Produktmanagement und Vulnerability Management. Erforderlich sind mindestens Produktname, unterstützte und betroffene Versionen, integrierte Komponente sowie relevante Konfigurations- und Distributionsinformationen. Die SRP verlangt bereits in der Frühwarnung unter anderem Produktname, Produktversion, betroffene Mitgliedstaaten und den Zeitpunkt der Kenntniserlangung; der Komponentenname kann ergänzend angegeben werden.
Eine Software Bill of Materials (SBOM) ist ein wichtiges Zuordnungsartefakt. Sie kann zeigen, ob eine betroffene Drittkomponente in einem Produktbestandteil enthalten ist. Für die Meldeentscheidung genügt sie aber regelmäßig nicht allein. Zusätzlich zu bewerten sind die konkrete Produktversion, die tatsächliche Einbindung der Komponente, ihre Erreichbarkeit und der belastbare Bezug zwischen Exploitation-Hinweis und Produkt.
Ein belastbarer Ablauf kann daher mit dem Eingang eines Hinweises beginnen, den Produktcontainment und Komponentenabgleich durchführen, die Versionsgrenzen und mögliche Exponierung bestimmen und anschließend Ausnutzungsevidenz sowie Schwere bewerten. Das Ergebnis ist nicht nur „melden“ oder „nicht melden“, sondern eine dokumentierte Entscheidung mit klaren offenen Prüfpunkten und einem Eskalationspfad.
Zwei Meldepfade: Schwachstelle oder schwerer Sicherheitsvorfall
Artikel 14 unterscheidet den Meldeweg für aktiv ausgenutzte Schwachstellen und für schwere Sicherheitsvorfälle. Beide Pfade können eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden auslösen. Die fachliche Begründung ist jedoch unterschiedlich: Bei der Schwachstelle steht die belastbar nachgewiesene aktive Ausnutzung im Vordergrund.
Ein Sicherheitsvorfall ist nach Artikel 14 Absatz 5 schwer, wenn er die Fähigkeit eines Produkts beeinträchtigt oder beeinträchtigen kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit wichtiger oder sensibler Daten oder Funktionen zu schützen. Gleiches gilt, wenn er zur Einführung oder Ausführung bösartigen Codes geführt hat oder führen kann. Die Schwerebewertung sollte deshalb nachvollziehbar zwischen bestätigten Auswirkungen, möglichen Auswirkungen und noch zu prüfenden Annahmen unterscheiden.
Auch die Abschlussfristen unterscheiden sich: Für aktiv ausgenutzte Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme einzureichen. Bei schweren Sicherheitsvorfällen ist er binnen eines Monats nach der 72-Stunden-Meldung fällig.
Meldedaten als kontrollierte Evidenzfortschreibung
Die Frühwarnung ist kein vollständiger Untersuchungsbericht. Sie sollte ein vorab freigegebenes Mindestdatenpaket abbilden: Meldungstyp, präziser Produkttitel, bekannte Versionsgrenzen, betroffene Mitgliedstaaten, Awareness-Zeitpunkt, knappe Faktenlage sowie erste Eindämmungs- und gegebenenfalls Nutzermaßnahmen.
In der 72-Stunden-Meldung wird diese Basis vertieft. Für aktiv ausgenutzte Schwachstellen erfasst die SRP insbesondere allgemeine Angaben zur Schwachstelle und ihrer Ausnutzung. Bei schweren Sicherheitsvorfällen sind unter anderem Art des Vorfalls, erste Bewertung sowie ergriffene oder geplante Minderungsmaßnahmen anzugeben. Die Abschlussberichte vertiefen Schweregrad, Auswirkungen und Abhilfemaßnahmen beziehungsweise die wahrscheinliche Ursache.
Wichtig ist daher eine versionierte Evidenzablage: technische Analyse, Entscheidungen zur Ausnutzung und Schwere, Forensik- oder Root-Cause-Status, Verfügbarkeit von Patch oder Workaround sowie Kundenhinweise müssen aufeinander bezogen fortgeschrieben werden. Hypothesen und nicht bestätigte Attributionen sollten ausdrücklich von festgestellten Tatsachen getrennt bleiben.
SRP-Realität: Zuständigkeit und Fristensteuerung
Eine über die SRP eingereichte Meldung wird an den ausgewählten CSIRT als Coordinator und zugleich an ENISA übermittelt. Der koordinierende CSIRT verbreitet relevante Informationen an weitere betroffene CSIRTs. Hersteller müssen den zuständigen Coordinator bestimmen und auswählen.
Die gegenwärtige Plattform unterstützt verpflichtende Meldungen nach Artikel 14; freiwillige Meldungen nach Artikel 15 sollen erst in einer späteren Phase verfügbar sein. Für die erste SRP-Version ist keine API vorgesehen, sodass Meldungen über die Plattformoberfläche einzureichen sind. Das Rollenmodell darf deshalb kein Einzelpersonenprozess sein: primäre und sekundäre Assigned Representatives, Vertretungsregeln außerhalb üblicher Arbeitszeiten sowie ein getesteter Freigabe- und Einreichungsweg sind organisatorisch naheliegend.
Die derzeitige SRP-Implementierung zeigt für die 72-Stunden-Meldung eine Fälligkeit 48 Stunden nach Übermittlung der Frühwarnung an. ENISA weist darauf hin, dass dies in Einzelfällen vor Ablauf von 72 Stunden seit Kenntniserlangung zu einer Überfälligkeitsanzeige führen kann. Der Plattformzähler ersetzt daher nicht die eigene Fristensteuerung ab dem tatsächlichen Awareness-Zeitpunkt.
PSIRT, Engineering und Kommunikation verzahnen
Eine CRA-Triage funktioniert nur als abgestimmtes Operating Model. Das PSIRT steuert Aufnahme, Evidenz und Eskalation; Entwicklung und Produktteams bewerten Komponente, Version, Exponierung und Abhilfe; Incident Response trägt Vorfallanalyse und Eindämmung bei. Legal und Compliance unterstützen die Einordnung und Nachweisführung. Support und Kommunikationsverantwortliche benötigen belastbare Nutzermaßnahmen und konsistente Produktinformationen.
Meldung, koordinierte Schwachstellenoffenlegung und Kundenkommunikation sind dabei getrennte, aber abgestimmte Arbeitsstränge. Technische Details eines noch nicht behobenen Ausnutzungspfads erfordern eine Sensitivitätsbewertung. Gleichzeitig sollten handlungsorientierte Nutzerhinweise vorbereitet werden, sobald Maßnahmen für betroffene Kunden erforderlich sind.
Kontrollfragen für einen testbaren Prozess
- Ist der Zeitpunkt der Kenntniserlangung mit Quelle, Evidenz und Entscheidungsverantwortung dokumentiert?
- Sind Produkt, Versionen, Komponenten und betroffene Mitgliedstaaten nachvollziehbar bestimmt?
- Wurde zwischen externem Hinweis, technischer Betroffenheit und belastbarer aktiver Ausnutzung unterschieden?
- Sind Schwerebewertung, Minderungsmaßnahmen und offene Untersuchungsfragen nachvollziehbar fortgeschrieben?
- Funktionieren Coordinator-Auswahl, Vertretung und manuelle SRP-Einreichung auch unter Zeitdruck?
Die belastbare CRA-Meldung entsteht damit nicht erst beim Ausfüllen der SRP. Sie beruht auf einer nachvollziehbaren Triageentscheidung, einer produktbezogenen Evidenzkette und einer kontrollierten Fortschreibung der Erkenntnisse über alle Meldephasen hinweg.