Schwachstellenbehandlung, Meldung & CVD unter dem CRA

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt von Herstellern nicht nur, ihre Produkte einmalig sicher zu bauen, sondern sie über den gesamten Support-Zeitraum sicher zu halten. Zwei Pflichtenkreise greifen dabei ineinander: die laufende Schwachstellenbehandlung nach Anhang I Teil II und die kurzfristige Meldepflicht nach Art. 14. Dieser Beitrag erklärt beides – und schärft die eine Stelle, an der die meisten Fehler passieren: die Melde-Kadenz. Er ist allgemeine technisch-organisatorische Orientierung, keine Rechtsberatung.

Teil 1 – Schwachstellenbehandlung (Anhang I Teil II)

Anhang I Teil II beschreibt, was ein Hersteller über den gesamten Support-Zeitraum dauerhaft tun muss. Es geht nicht um ein Dokument, sondern um einen gelebten Prozess. Die Kernpflichten:

• Identifizieren & dokumentieren. Schwachstellen und Komponenten des Produkts systematisch erfassen – einschließlich einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Der CRA schreibt kein bestimmtes Format vor; etablierte Formate wie CycloneDX, SPDX oder SWID erfüllen die Anforderung (das ist Orientierung, kein Gesetzeswortlaut). Details im Beitrag SBOM-Anforderungen unter dem CRA.
• Unverzüglich beheben. Schwachstellen ohne Verzögerung durch Sicherheitsupdates schließen. Wo möglich, Sicherheitsupdates von Funktionsupdates trennen, damit ein reiner Sicherheitsfix nicht an einer Feature-Freigabe hängt.
• Regelmäßig testen & prüfen. Wirksamkeit der Sicherheitsmaßnahmen durch regelmäßige Tests und Reviews überprüfen.
• Öffentlich offenlegen. Behobene Schwachstellen offenlegen, sobald ein Update verfügbar ist – mit Informationen, die Anwendern ein Aufspielen ermöglichen.
• Eine CVD-Policy durchsetzen. Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) ist verpflichtend – nicht optional. Sie regelt, wie Dritte Schwachstellen melden können und wie der Hersteller damit umgeht.
• Kontaktadresse bereitstellen. Eine erreichbare Meldeadresse für Schwachstellenmeldungen veröffentlichen.
• Sicher & kostenlos aktualisieren. Updates sicher verteilen, unverzüglich bereitstellen und – bei Sicherheitsupdates – kostenfrei anbieten.

Teil 2 – Meldepflicht (Art. 14)

Neben der laufenden Behandlung verlangt Art. 14 eine kurzfristige Meldung an das koordinierende CSIRT (bestimmt nach Art. 15) und die ENISA – abgewickelt über die Single Reporting Platform (Art. 16). Es gibt zwei Auslöser:

1. Aktiv ausgenutzte Schwachstellen in einem Produkt mit digitalen Elementen.
2. Schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts beeinträchtigen.

Für beide Auslöser gilt dieselbe dreistufige Kaskade – aber der Abschlussbericht folgt je nach Auslöser einer anderen Frist. Genau hier liegt die Falle.

Die Kadenz im Überblick

Die 24-Stunden-Frühwarnung und die 72-Stunden-Meldung sind für beide Auslöser identisch. Erst der Abschlussbericht trennt sich: Bei einer Schwachstelle knüpft die Frist an die Verfügbarkeit der Korrektur (≤ 14 Tage danach), bei einem Vorfall an die Meldung selbst (ein Monat danach). Wer diese beiden Bezugspunkte verwechselt, meldet zur falschen Zeit.

Ab wann und für welche Produkte?

Die Meldepflicht nach Art. 14 gilt ab dem 11. September 2026. Sie trifft ausdrücklich auch Produkte, die bereits am Markt sind – nicht nur Neuentwicklungen. Die Single Reporting Platform soll bis zu diesem Datum operativ bereitstehen. Der weitere Kontext zu Fristen steht im Beitrag CRA-Meldepflicht ab September 2026.

Wie Behandlung und Meldung zusammenspielen

Beide Pflichtenkreise sind kein Widerspruch, sondern zwei Enden desselben Prozesses. Die laufende Schwachstellenbehandlung (Anhang I Teil II) liefert die Erkennungs- und Reaktionsfähigkeit; die Meldepflicht (Art. 14) schaltet sich ein, sobald eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Vorfall eintritt. Eine funktionierende CVD-Policy und eine gepflegte Meldeadresse sind dabei die Brücke: Sie sorgen dafür, dass eine von außen gemeldete Schwachstelle intern schnell die Kaskade auslösen kann. Ohne diesen Unterbau wird die 24-Stunden-Frühwarnung praktisch unerreichbar.

Praktisch heißt das: Die 24 Stunden beginnen nicht erst, wenn ein Vorstand entscheidet, sondern sobald die verantwortliche Stelle im Unternehmen von der aktiven Ausnutzung oder dem Vorfall Kenntnis erlangt. Deshalb müssen Erkennung, Bewertung und Meldeentscheidung eng verzahnt sein – ein langer interner Freigabeweg frisst die Frist auf. Ebenso wichtig ist die saubere Abgrenzung der beiden Auslöser: Nicht jede entdeckte Schwachstelle ist meldepflichtig, sondern erst die aktive Ausnutzung; und nicht jede Störung ist ein schwerwiegender Vorfall. Eine klare, vorab dokumentierte Schwelle verhindert im Ernstfall stundenlange Diskussionen darüber, ob überhaupt gemeldet werden muss.

„Jetzt vorbereiten“ – Checkliste

Die folgenden Schritte sind allgemeine organisatorisch-technische Orientierung, keine Rechtsberatung:

• CVD-Policy formulieren und veröffentlichen – inklusive einer erreichbaren, überwachten Kontakt-/Meldeadresse für Schwachstellen.
• SBOM aufbauen in einem gängigen, maschinenlesbaren Format (mindestens Top-Level-Abhängigkeiten) und in den Build-Prozess integrieren.
• Sicherheits- von Funktionsupdates trennen, wo technisch möglich, damit Sicherheitsfixes schnell und kostenfrei ausgeliefert werden können.
• Meldeprozess für die Single Reporting Platform definieren – Zuständigkeiten, Eskalationswege und ein Ablauf, der die 24h/72h-Fristen realistisch einhält.
• Beide Abschlussbericht-Fristen dokumentieren: 14 Tage (nach verfügbarer Korrektur, Schwachstelle) und ein Monat (nach Meldung, Vorfall) – als getrennte Playbooks.
• Kaskade proben. Führen Sie eine Trockenübung durch (Tabletop), damit 24 Stunden im Ernstfall nicht die erste Übung sind.
• Bestandsprodukte einbeziehen. Die Meldepflicht gilt auch für bereits vertriebene Produkte – prüfen Sie, welche davon im Support-Zeitraum sind.
• Support-Zeitraum festlegen (mindestens 5 Jahre bzw. erwartete Nutzungsdauer) – er bestimmt, wie lange Behandlung und Meldung gelten.

Ob und in welchem Umfang Ihre Produkte betroffen sind, klären Sie am besten zuerst mit dem Betroffenheits-Check. Erst wenn feststeht, welche Produkte in Scope sind, lohnt sich der Aufbau der hier beschriebenen Prozesse.

Die einschlägigen Fundstellen: Schwachstellenbehandlung in Anhang I Teil II; Meldepflicht in Art. 14; das koordinierende CSIRT in Art. 15; die Single Reporting Platform in Art. 16; die zugrunde liegenden Herstellerpflichten in Art. 13. Für den exakten Wortlaut ist stets der Amtsblatt-Text maßgeblich.