Meldepflichten unter dem Cyber Resilience Act

Problem in der Praxis

Viele Hersteller behandeln Schwachstellen- und Vorfallmeldung als technische Detailfrage des Security-Teams. Im CRA-Kontext ist sie aber ein regulatorischer Prozess mit Beweischarakter, Fristdruck und Außenwirkung gegenüber Behörden.

Das eigentliche Problem zeigt sich im Moment der Kenntnisnahme. Plötzlich muss in sehr kurzer Zeit entschieden werden: Ist diese Schwachstelle aktiv ausgenutzt? Ist dieser Vorfall schwerwiegend im Sinne der Verordnung? Wer darf die Meldung freigeben? Welche Informationen gehen an die Behörde, ohne dass laufende Abwehr oder noch nicht verfügbare Patches gefährdet werden? Ohne vorab definierte Schwellen, Rollen und Eskalationswege wird jede dieser Fragen im Krisenmodus neu verhandelt. Das kostet genau die Stunden, die die Verordnung nicht gibt.

Hinzu kommt die Mehrfachbetroffenheit. Ein Unternehmen kann gleichzeitig Hersteller nach CRA und Betreiber nach NIS2 sein, im Finanzsektor zusätzlich DORA unterliegen. Ohne klare Abgrenzung droht entweder Doppelmeldung mit widersprüchlichen Inhalten oder eine Meldelücke, weil sich alle Beteiligten auf das jeweils andere Regime verlassen.

CISO-Einordnung

Der CRA verpflichtet Hersteller, zwei Auslöser zu melden: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts betreffen. Empfänger sind das zuständige nationale CSIRT und die EU-Agentur ENISA, angebunden über eine zentrale Meldeplattform (single reporting platform).

Die Meldung ist mehrstufig angelegt:

• Frühwarnung binnen 24 Stunden nach Kenntnis. Sie ist bewusst knapp gehalten: eine erste Information, dass etwas vorliegt.
• Folgemeldung binnen 72 Stunden, inklusive Angaben zu ersten Korrektur- oder Abhilfemaßnahmen.
• Abschlussbericht: bei einer Schwachstelle binnen 14 Tagen nach Verfügbarkeit einer Abhilfe oder eines Patches; bei einem schwerwiegenden Vorfall binnen eines Monats.

Diese gestufte Logik ähnelt dem Muster, das CISOs aus NIS2 kennen: eine schnelle Erstmeldung, gefolgt von angereicherten Berichten. Der maßgebliche Unterschied liegt jedoch im Gegenstand: Der CRA meldet produktbezogen, NIS2 organisationsbezogen.

NIS2 (Richtlinie (EU) 2022/2555) verpflichtet wesentliche und wichtige Einrichtungen, erhebliche Vorfälle der eigenen Dienste an die zuständige Behörde beziehungsweise das CSIRT zu melden. Der CRA verpflichtet den Hersteller, ein Problem seines Produkts zu melden, unabhängig davon, ob er selbst eine NIS2-Einrichtung ist. DORA (Verordnung (EU) 2022/2554) ist sektorspezifisch für den Finanzbereich und regelt die Meldung IKT-bezogener Vorfälle von Finanzunternehmen; der CRA bleibt horizontal und produktbezogen. Ein Unternehmen kann damit mehreren Meldepflichten parallel unterliegen, mit unterschiedlichen Auslösern, Adressaten und Inhalten.

Für den CISO heißt das: Es geht nicht um eine Meldung, sondern um eine Landkarte von Meldepflichten, die sich überlagern, aber nicht ersetzen.

Umsetzungsperspektive

Sinnvoll ist, die CRA-Meldepflicht als eigenständigen, geprobten Prozess innerhalb der Product-Security-Funktion aufzusetzen, typischerweise verankert in einer PSIRT-Funktion (Product Security Incident Response Team), die ohnehin für Schwachstellenbehandlung und Coordinated Vulnerability Disclosure zuständig ist.

Ein belastbarer Meldeprozess braucht:

• Klare Trigger-Definitionen: Was gilt intern als aktiv ausgenutzt, was als schwerwiegend? Diese Schwellen müssen vorab dokumentiert und mit Recht abgestimmt sein, nicht im Vorfall.
• Eindeutige Rollen und Freigabe: Wer bewertet, wer entscheidet über die Meldung, wer ist Stellvertretung außerhalb der Geschäftszeiten? Die 24-Stunden-Frist läuft auch nachts und am Wochenende.
• Vorbereitete Meldewege: Zugang zur zentralen Meldeplattform, Kontakt zum zuständigen nationalen CSIRT, vorbereitete Meldevorlagen für die drei Stufen.
• Verzahnung mit dem Patch-Prozess: Der Abschlussbericht hängt bei Schwachstellen an der Verfügbarkeit der Abhilfe. Melde- und Update-Bereitstellung müssen daher synchron laufen.
• Mapping zu NIS2 und gegebenenfalls DORA: eine Entscheidungshilfe, die im Vorfall klärt, welche Pflicht greift (oft mehrere gleichzeitig).

Wer eine technische Orientierung für den Umgang mit Schwachstellenberichten sucht, findet in der BSI TR-03183 (insbesondere im Teil zu Schwachstellenberichten und zum Umgang mit Schwachstellen) eine frei zugängliche Umsetzungshilfe. Sie ist nicht rechtsverbindlich und erzeugt keine Vermutungswirkung, hilft aber, Prozesse praxisnah zu strukturieren.

Typische Fehler

1. Die Meldepflicht wird als reine Security-Aufgabe behandelt, ohne Recht, Kommunikation und Geschäftsführung einzubinden.
2. Trigger-Schwellen ("aktiv ausgenutzt", "schwerwiegend") werden erst im Vorfall diskutiert.
3. Die 24-Stunden-Frühwarnung wird als vollständiger Bericht missverstanden, wodurch unnötig Zeit verloren geht.
4. Es gibt keine Bereitschaft außerhalb der Geschäftszeiten, obwohl die Fristen durchlaufen.
5. CRA-, NIS2- und DORA-Meldungen werden vermengt oder gegeneinander ausgespielt, statt sie sauber zu trennen.
6. Der Abschlussbericht wird vergessen, weil nach dem Patch der Druck nachlässt.

Risiken und Trade-offs

Die kurzen Fristen erzeugen ein echtes Spannungsfeld. Wer zu früh und zu detailliert meldet, riskiert, Angreifern oder der Öffentlichkeit Informationen zu einer noch nicht behebbaren Schwachstelle zu liefern. Wer zu spät oder zu zurückhaltend meldet, verletzt die Pflicht. Die mehrstufige Logik mit knapper Frühwarnung und späterem Abschlussbericht ist genau die Antwort des Gesetzgebers auf dieses Spannungsfeld. Sie funktioniert aber nur, wenn der Hersteller den Reifegrad der Information bewusst steuert.

Ein zweiter Trade-off liegt zwischen Vorsicht und Überlast. Eine zu defensive Auslegung der Trigger führt zu vielen Meldungen, bindet Ressourcen und schwächt die Aussagekraft. Eine zu enge Auslegung riskiert Pflichtverletzungen. Die Schwelle gehört daher dokumentiert und mit Recht abgestimmt.

Drittens besteht ein Vertraulichkeits- und Reputationsrisiko. Behördliche Meldungen, parallele Kundeninformation und Coordinated Vulnerability Disclosure müssen konsistent sein. Widersprüchliche Aussagen gegenüber CSIRT, Kunden und Öffentlichkeit schaden mehr als ein etwas späterer, aber stimmiger Bericht.

Entscheidungspunkte

• Welche internen Schwellen definieren "aktiv ausgenutzt" und "schwerwiegend", und wer verantwortet diese Definition?
• Wer ist meldeberechtigt und wie ist die Rufbereitschaft außerhalb der Geschäftszeiten organisiert?
• Wie wird der Meldeprozess an den Schwachstellen- und Patch-Prozess gekoppelt?
• Wie werden CRA-, NIS2- und gegebenenfalls DORA-Meldepflichten im konkreten Vorfall auseinandergehalten und koordiniert?
• Welche Information geht in welcher Stufe an die Behörde, und wie wird sie mit Kundenkommunikation und CVD synchronisiert?
• Wer trägt die Verantwortung dafür, dass auch der Abschlussbericht fristgerecht erstellt wird?

Praktische Empfehlungen

1. Etablieren Sie den CRA-Meldeprozess vor dem 11.09.2026 und üben Sie ihn mindestens einmal als Trockenübung mit realistischem Zeitdruck.
2. Verankern Sie Meldepflicht und Schwachstellenbehandlung in einer benannten PSIRT-Funktion mit klarer Vertretung.
3. Dokumentieren Sie Trigger-Schwellen und Freigaberegeln gemeinsam mit Recht, bevor der erste Fall eintritt.
4. Bereiten Sie Zugang zur zentralen Meldeplattform und Kontakt zum zuständigen CSIRT technisch und organisatorisch vor.
5. Erstellen Sie eine Mehrfach-Meldelandkarte (CRA, NIS2, DORA), die im Vorfall sofort zeigt, welche Pflicht greift.
6. Behandeln Sie die 24-Stunden-Frühwarnung als knappe Erstinformation, nicht als vollständigen Bericht.
7. Koppeln Sie den Abschlussbericht fest an Ihren Patch- und Release-Prozess, damit er nicht untergeht.

Relevante Normreferenzen

• Cyber Resilience Act (Verordnung (EU) 2024/2847): zitierfähiger Rechtstext für die Meldepflichten; Geltung der Meldepflichten ab 11.09.2026, gestaffelte Anwendungstermine geregelt in den Anwendungsbestimmungen der Verordnung. Für verbindliche Einzelheiten ist der Verordnungstext heranzuziehen.
• BSI TR-03183 "Cyber-Resilienz-Anforderungen an Hersteller und Produkte": frei zugängliche Orientierungs- und Umsetzungshilfe (insbesondere zu Schwachstellenberichten); nicht rechtsverbindlich, keine Vermutungswirkung. Aktuellen Versionsstand vor Nutzung prüfen.
• ISO/IEC 27001/27002: organisatorischer Bezugsrahmen für sichere Entwicklung und Schwachstellenbehandlung (Reference-only, lizenzpflichtig).
• NIST SSDF (SP 800-218): prozessuale Referenz für sichere Softwareentwicklung und Schwachstellenbehandlung (Public Domain).