CRA-Schwachstellenprozess eines Herstellers vorbereiten: Meldungseingang, Beweise und Meldefristen

Ziel

Stand: 25. Oktober 2026. Den Schwachstellenprozess eines Herstellers so vorbereiten, dass bei einem Vorfall Beweise, Produktverantwortlichkeiten und Meldefristen abrufbar sind. Bei der Aktualisierung des Prozesses Artikel 14, Anhang I und die aktuellen ENISA-SRP-Anweisungen erneut prüfen. Dies ist ein vorgeschlagenes Vorbereitungsverfahren, keine Behauptung, dass eine Organisation eine Konformitätsprüfung bestanden hat.

Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026. Artikel 71 legt den 11. Dezember 2027 für die umfassenderen Anforderungen fest, einschliesslich der Pflichten zum Umgang mit Schwachstellen in Anhang I. Die Vorbereitung auf diese späteren Pflichten kann schon jetzt das Meldewesen unterstützen, die Geltungsdaten müssen jedoch getrennt bleiben. Meldehinweise der Kommission.

Voraussetzungen

Die relevanten Produkte des Herstellers, die zuständigen Entwicklungsteams, eine für Meldungen verantwortliche Person und deren Stellvertretung bestimmen. Eine zugriffsbeschränkte Vorfallakte, Zugang zu Versions- und Komponenteninformationen sowie einen Kanal zur Kommunikation mit betroffenen Nutzern bereitstellen. Dies sind vorgeschlagene organisatorische Vorkehrungen. Das zuständige koordinierende CSIRT anhand von Artikel 14(7) bestimmen, statt es lediglich wegen einer passenden Sprache auszuwählen.

Schritte

1. Dem Meldungseingang eine namentlich benannte verantwortliche Person zuordnen. Die in Anhang I, Teil II beschriebene Richtlinie zur koordinierten Offenlegung von Schwachstellen und die Meldestelle vorbereiten. Eine optionale security.txt nach RFC 9116 kann Forschende darauf hinweisen: HTTPS unter /.well-known/security.txt verwenden, die Pflichtfelder Contact und Expires aufnehmen und die Richtlinie über Policy verlinken. Die Datei und ihre Verweisziele aktuell halten. RFC 9116, Abschnitte 2, 3 und 5.

2. Sofort eine Fallakte anlegen. Für eine zweckmässige Dokumentation Eingangszeit, erhaltene Beweise, Zeitpunkt der Kenntnisnahme eines meldepflichtigen Ereignisses, Entscheidungsverantwortung und spätere Überarbeitungen getrennt erfassen. Die ursprünglichen Beweise aufbewahren und Änderungen der Bewertung erläutern. Interne Freigaben sollten den Zeitpunkt der Kenntnisnahme nicht stillschweigend neu setzen.

3. Das Problem den Versionen zuordnen. Neben Produkt- und Versionskennungen eine Software-Stückliste (SBOM) pflegen. Anhang I, Teil II(1) verlangt, sobald diese Anforderung gilt, ein gängiges maschinenlesbares Format, das mindestens die direkten Abhängigkeiten erfasst. Dieses Verfahren schlägt vor, diese Nachweise mit ausgelieferten Versionen zu verknüpfen, damit sich die Liste betroffener Produkte rekonstruieren lässt. Eine SBOM ist eine Bestandsaufnahme, kein Beweis für eine Ausnutzung.

4. Die gesetzlichen Auslöser getrennt beurteilen. Nach Artikel 3(42) erfordert aktive Ausnutzung zuverlässige Beweise dafür, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des Systemeigentümers ausgenutzt hat. Schwerwiegende Vorfälle anhand beider Kriterien in Artikel 14(5) prüfen. Beweise und offene Fragen dokumentieren; ein Schweregradwert allein kann eine aktive Ausnutzung nicht belegen. Die Schritte 1, 3 und 4 stützen sich auf die Verordnung.

5. Die Fristenübersicht pflegen. Die 24- und 72-Stunden-Stufen ab Kenntnisnahme planen und dabei die Pflicht zum unverzüglichen Handeln beibehalten. Die Frist für den Abschlussbericht zur Schwachstelle ab Verfügbarkeit einer Korrektur- oder Eindämmungsmassnahme verfolgen, diejenige für den Vorfallabschlussbericht ab Übermittlung der Vorfallmeldung. Bestätigungen, eingereichte Fassungen und Behördenanfragen zusammen aufbewahren.

6. Plattformzugang und Kommunikation vorbereiten. ENISA verlangt persönliche EU Login-Konten mit Mehrfaktor-Authentifizierung. Die FAQ vom Oktober empfiehlt, die SRP-Registrierung einzuleiten, sobald eine Meldung erforderlich ist; den EU Login-Zugang vorher vorbereiten. Neben Behördenmeldungen auch die Kommunikation mit betroffenen Nutzern sicherstellen. ENISA-SRP-FAQ, Frage 9.

7. Intern üben. Einen fiktiven Produktfall verwenden und Meldungsentwürfe ausserhalb der produktiven Meldeplattform erstellen. Die Stellvertretung die Beweise auffinden, Fristen rekonstruieren und die Empfängerauswahl erklären lassen. Fehlende Angaben dokumentieren und die fehlgeschlagene Übergabe nach deren Ergänzung wiederholen.

Erwartetes Ergebnis

Eine prüfende Person kann einen Fall vom Eingang über die Produktzuordnung, die Bewertung der Meldeauslöser und die Übermittlung bis zur Nutzerkommunikation nachvollziehen, ohne den Zeitablauf aus verstreuten Nachrichten rekonstruieren zu müssen.

Grenzen und Prüfbasis

Es werden weder eine durchgeführte Übung noch Ergebnisse aus der Praxis behauptet. Der Vorschlag verbindet die Verordnung, die Hinweise der Kommission, die am 15. Oktober 2026 aktualisierte FAQ von ENISA und RFC 9116. Weder eine veröffentlichte Kontaktdatei noch eine erfolgreiche Übung belegt Konformität; der produktbezogene Geltungsbereich und strittige Bewertungen der Meldeauslöser bedürfen weiterhin einer fachkundigen Prüfung.