Die 24-Stunden-Meldepflicht: Artikel 14 und was er in der Praxis bedeutet

Von allen neuen Anforderungen, die der EU Cyber Resilience Act (CRA) einführt, ist Artikel 14 diejenige, die General Counsel und Chief Information Security Officers (CISOs) nachts wach hält.

Artikel 14 legt eine erschreckend kurze, streng durchgesetzte Frist für die Meldung aktiver Sicherheitsbedrohungen an die Behörden fest. Wenn Ihr Unternehmen Produkte mit digitalen Elementen (PDEs) herstellt, die in der EU verkauft werden, ist das Verständnis der genauen Auslöser und der Mechanik dieses 24-stündigen Meldefensters nicht optional, sondern eine kritische Anforderung an die Geschäftskontinuität.

Schauen wir uns genau an, was Artikel 14 verlangt, wann die Uhr zu ticken beginnt und wie man interne Prozesse aufbaut, die garantieren, dass Sie nie eine Frist verpassen.

Der dreiphasige Meldezeitplan

Artikel 14 verlangt nicht nur einen einzigen Bericht, sondern schreibt einen phasenweisen Ansatz für die Vorfallmeldung vor, der das unmittelbare Bedürfnis nach einem Lagebild mit der Zeit ausbalanciert, die für eine ordnungsgemäße technische Untersuchung nötig ist.

Tritt ein auslösendes Ereignis ein, müssen Hersteller die folgende Abfolge ausführen:

1. Die Frühwarnung (T + 24 Stunden): Innerhalb von 24 Stunden nach Kenntniserlangung des auslösenden Ereignisses müssen Sie eine erste Meldung an ENISA (die Agentur der Europäischen Union für Cybersicherheit) oder das zuständige nationale Computer Security Incident Response Team (CSIRT) übermitteln. Dieser Bericht ist bewusst knapp: Er stellt lediglich fest, dass ein schwerwiegender Vorfall oder eine aktive Ausnutzung eingetreten ist, und liefert den jeweils verfügbaren begrenzten Kontext.
2. Die Schwachstellen-/Vorfallmeldung (T + 72 Stunden): Innerhalb von 72 Stunden müssen Sie einen detaillierten technischen Bericht nachreichen. Dieser muss eine Bewertung des Schweregrads der Schwachstelle (z. B. CVSS-Wert), die Auswirkungen auf das Produkt und alle bekannten Kompromittierungsindikatoren (IoCs) enthalten.
3. Der Abschlussbericht (T + Risikominderung + 14 Tage): Innerhalb von 14 Tagen, nachdem ein Patch oder eine Risikominderungsmaßnahme verfügbar gemacht wurde, müssen Sie eine umfassende Nachbetrachtung einreichen, die die Grundursache, den zeitlichen Ablauf, die Korrektur und die gewonnenen Erkenntnisse darlegt.

Die Auslöser: Wann beginnt die Uhr?

Der kritischste Faktor für die Konformität mit Artikel 14 ist das Verständnis, wann genau die 24-Stunden-Uhr beginnt. Der CRA legt zwei Hauptszenarien fest, die eine verpflichtende Meldung auslösen.

Auslöser 1: Aktiv ausgenutzte Schwachstellen

Sie müssen jede in Ihrem Produkt enthaltene Schwachstelle melden, die aktiv ausgenutzt wird.

• Was das bedeutet: Ein Sicherheitsforscher, der einen theoretischen Fehler privat über Ihr CVD-Portal meldet, löst keinen 24-Stunden-Bericht aus. Liefert dieser Forscher jedoch den Nachweis, dass Kriminelle den Fehler derzeit nutzen, um Ihre Kunden anzugreifen, oder erkennt Ihre eigene Telemetrie eine aktive Ausnutzung in freier Wildbahn, beginnt die Uhr sofort.
• Die Schwelle der „Kenntnis“: Die Uhr beginnt in dem Moment, in dem der Hersteller von der aktiven Ausnutzung „Kenntnis erlangt“. Die genaue regulatorische Definition von „Kenntnis“ wird noch ausgelegt, bezieht sich aber im Allgemeinen auf den Moment, in dem ein qualifiziertes Mitglied der Organisation (z. B. ein Triage-Ingenieur oder Sicherheitsanalyst) die Glaubwürdigkeit der Ausnutzungsmeldung bestätigt.

Auslöser 2: Schwerwiegende Sicherheitsvorfälle

Sie müssen jeden schwerwiegenden Vorfall melden, der sich auf die Sicherheit Ihres Produkts auswirkt.

• Was das bedeutet: Das ist umfassender als eine Schwachstelle in Ihrem Code. Es erfasst Vorfälle, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit des Produkts beeinträchtigen. Beispiele sind eine Lieferkettenkompromittierung, bei der Ihre Update-Server Schadsoftware ausliefern, oder eine Verletzung Ihrer internen Infrastruktur, die kryptografische Schlüssel offenlegt, mit denen Sie Ihre Firmware signieren.
• Die Schwelle „schwerwiegend“: Der CRA definiert den Schweregrad anhand von Faktoren wie der Zahl der betroffenen Nutzer, dem Potenzial für gesellschaftliche oder wirtschaftliche Störungen und der geografischen Ausbreitung der Auswirkungen.

(Hinweis: ENISA wird voraussichtlich weitere technische Leitlinien dazu geben, wie genau „aktive Ausnutzung“ und „schwerwiegender Vorfall“ einzustufen sind, doch Hersteller sollten in den frühen Tagen der Durchsetzung im Zweifel eher zu viel als zu wenig melden.)

Eine 24-Stunden-Fähigkeit aufbauen

Sie können einen 24-Stunden-Prozess zur Reaktion auf Vorfälle (Incident Response, IR) nicht während eines aktiven Brandes aufbauen. Bis Ihre Juristen darüber debattieren, ob ein Vorfall die Schwelle „schwerwiegend“ erreicht, wird das 24-Stunden-Fenster geschlossen sein. Sie müssen die Fähigkeit jetzt aufbauen.

1. Triage-Befugnis festlegen

Die häufigste Ursache für verpasste Fristen ist die Entscheidungslähmung. Wer sitzt mitten in der Nacht und trifft die Entscheidung, dass ein Exploit „aktiv“ ist?

• Maßnahme: Statten Sie eine bestimmte Rolle (z. B. den diensthabenden Incident Commander oder den PSIRT-Leiter) mit der strikten Befugnis aus, einen schwerwiegenden Vorfall zu erklären und das Meldeprotokoll auszulösen. Verlangen Sie keine Freigabe auf C-Ebene für eine Frühwarnmeldung, wenn dadurch die Frist verpasst zu werden droht.

2. Die Vorlagen vorab entwerfen

Mitten in einer Krise ist der falsche Zeitpunkt, um herauszufinden, in welches Portal man sich einloggt oder welches Formular man ausfüllt.

• Maßnahme: Entwerfen Sie die Vorlagen für die Frühwarnung und die 72-Stunden-Meldung vorab. Wissen Sie genau, welchem nationalen CSIRT Sie gesetzlich Bericht erstatten müssen (in der Regel nach Ihrer Hauptniederlassung in der EU). Halten Sie die URLs, Zugangsdaten und API-Schlüssel getestet und bereit.

3. Automatisierte Telemetrie umsetzen

Sie können nicht melden, was Sie nicht sehen. Wenn Sie sich allein auf externe Parteien verlassen, um über aktive Ausnutzung informiert zu werden, hinken Sie immer hinterher.

• Maßnahme: Statten Sie Ihre Produkte mit ausreichender Protokollierung und Telemetrie aus, um anomales Verhalten zu erkennen. Ist Ihr Produkt ein SaaS, stellen Sie sicher, dass die Alarme Ihrer WAF und Ihres SIEM darauf abgestimmt sind, Ausnutzungsversuche gegen neu entdeckte (aber ungepatchte) Zero-Days zu erkennen.

4. Ihre CVD-Erfassung integrieren

Ihre Eingangstür zur koordinierten Offenlegung von Schwachstellen (CVD) ist oft der erste Ort, an dem Sie von einer aktiven Ausnutzung erfahren.

• Maßnahme: Stellen Sie sicher, dass Ihr CVD-Erfassungsprozess (wie CVD Portal) ein gut sichtbares Kontrollkästchen oder Feld enthält, das Forscher fragt: „Gibt es Hinweise darauf, dass diese Schwachstelle aktiv ausgenutzt wird?“ Ist es angekreuzt, sollte dies sofort den diensthabenden PSIRT-Ingenieur alarmieren und die normalen SLAs umgehen.

Die Schnittstelle zu DSGVO und NIS2

Artikel 14 existiert nicht im luftleeren Raum. Führt ein schwerwiegender Sicherheitsvorfall unter dem CRA zugleich zu einer Verletzung des Schutzes personenbezogener Daten, müssen Sie die zuständige Datenschutzbehörde nach Artikel 33 DSGVO innerhalb von 72 Stunden benachrichtigen.

Ist Ihr Unternehmen eine wesentliche oder wichtige Einrichtung nach der NIS2-Richtlinie, können sich für denselben Vorfall überlappende Meldepflichten gegenüber verschiedenen Behörden ergeben. Sie müssen das Venn-Diagramm Ihrer Meldepflichten sorgfältig abbilden.

Fazit

Das Gebot der 24-Stunden-Frühwarnung ist der scharfe Zahn der Durchsetzung im CRA. Es verlagert das Schwachstellenmanagement von einer entspannten, internen Entwicklungsaufgabe zu einem hochsichtbaren, rechtsverbindlichen, zeitkritischen Betrieb.

Hersteller, die unter dem CRA erfolgreich sind, werden diejenigen sein, die klare Triage-Befugnisse festlegen, ihre Erkennungsfähigkeiten automatisieren und ihre Notfallpläne für die Reaktion auf Vorfälle nicht als verstaubte Dokumente behandeln, sondern als aktiv eingeübte, tief verankerte operative Muskeln.