Anhang I Teil II der Verordnung (EU) 2024/2847 legt acht nummerierte Pflichten fest, die jeder Hersteller eines Produkts mit digitalen Elementen über den gesamten Unterstützungszeitraum hinweg erfüllen muss: SBOM-gestützte Identifikation, unverzügliche Behebung, regelmäßige Tests, öffentliche Offenlegung von Korrekturen, eine Richtlinie zur koordinierten Schwachstellenoffenlegung, einen externen Meldekanal, sichere Update-Verteilung und kostenlose Sicherheitsupdates. Diese Seite geht jede Pflicht durch und zeigt, wo die Behandlung nach Anhang I endet und die Meldung nach Artikel 14 beginnt.
Zusammenfassung
- Anhang I Teil II ist die technische Spezifikation für die Schwachstellenbehandlung nach dem CRA, anwendbar auf jeden Hersteller für jedes Produkt mit digitalen Elementen.
- Acht nummerierte Pflichten: identifizieren (mit SBOM), unverzüglich beheben, regelmäßig testen, behobene Schwachstellen öffentlich offenlegen, eine CVD-Richtlinie betreiben, Schwachstellenmeldungen erleichtern, Updates sicher verteilen, Sicherheitsupdates kostenlos bereitstellen.
- Kostenlosigkeit ist nicht verhandelbar: Sicherheitsupdates müssen nach Anhang I Teil II Nummer 8 kostenlos bereitgestellt werden, mit der einzigen Ausnahme für maßgeschneiderte Produkte an gewerbliche Nutzer.
- Die CVD-Richtlinie ist verpflichtend, nicht optional: Anhang I Teil II Nummer 5 macht die koordinierte Schwachstellenoffenlegung zu einer CE-Kennzeichnungspflicht, nicht zu einer bewährten Praxis.
- Die Schwachstellenbehandlung läuft über den gesamten Unterstützungszeitraum nach Artikel 3(20) und Artikel 13(8); der Mindestzeitraum beträgt fünf Jahre ab Bereitstellung auf dem Markt.
- Schwachstellenbehandlung ist nicht Meldepflicht nach Artikel 14: die Behandlung ist der laufende Engineering-Prozess; die Meldung ist der 24h/72h/14d-Takt, der nur durch aktiv ausgenutzte Schwachstellen oder schwerwiegende Vorfälle ausgelöst wird (siehe CRA Artikel-14-Meldung).
Die vier Ankerpunkte, die die CRA-Schwachstellenbehandlung rahmen: Geltungsbereich, Dauer, Kostenregel und Bußgeldobergrenze.
Die acht Pflichten aus Anhang I Teil II
Anhang I Teil II der Verordnung (EU) 2024/2847 listet acht nummerierte Pflichten auf. Sie sind keine Checkliste: sie beschreiben einen kontinuierlichen Lebenszyklus, der über den gesamten Unterstützungszeitraum läuft. Die nachstehende Gruppierung ordnet sie der operativen Phase zu, in der sie jeweils greifen.
Nummern 1, 6. SBOM-gestützte Identifikation von Komponenten und bekannten Schwachstellen sowie ein öffentlicher Kontaktkanal, über den externe Parteien melden können, was Ihre Scanner übersehen haben.
Nummern 2, 3. Unverzügliche Behebung (schweregradabhängig, kein fester SLA) und wirksame regelmäßige Tests des Codes und seiner Abhängigkeiten.
Nummern 7, 8. Sicherer Update-Kanal (signiert, authentifiziert, automatisch wo zutreffend), mit Sicherheitsupdates trennbar von Funktionen und kostenlos, außer bei maßgeschneiderten B2B-Produkten.
Nummern 4, 5. Eine eingeführte und durchgesetzte CVD-Richtlinie sowie öffentliche Advisories, sobald eine Korrektur verfügbar ist, mit einer engen Ausnahme für "hinreichend begründete" Verzögerungen.
Was jede Pflicht in der Praxis bedeutet
| # | Pflicht | Was sie tatsächlich verlangt |
|---|---|---|
| 1 | Schwachstellen und Komponenten identifizieren und dokumentieren | Eine SBOM in CycloneDX oder SPDX, die mindestens die obersten Abhängigkeiten abdeckt. Die SBOM ist der Index, der CVE-Abgleich erst möglich macht: Sie können nicht beheben, was Sie nicht katalogisiert haben. |
| 2 | Unverzügliche Behebung, getrennt von Funktionen | Kein fester SLA; das erwartete Tempo skaliert mit dem Schweregrad. Sicherheitszweige müssen von Funktionszweigen trennbar sein, damit Nutzer einen Patch nicht durch Aufschieben eines Releases verzögern können. |
| 3 | Wirksame und regelmäßige Tests | Statische Analyse, dynamische Tests, Abhängigkeits-Scans gegen Schwachstellen-Feeds und Penetrationstests. "Regelmäßig" muss zu Risiko und Änderungsrate des Codes passen. |
| 4 | Öffentliche Offenlegung behobener Schwachstellen | Sobald ein Fix ausgeliefert ist, Beschreibung, betroffenes Produkt, Auswirkung, Schweregrad und Behebung veröffentlichen. Verzögerung nur "in hinreichend begründeten Fällen", bis Nutzer patchen können. CVE plus CSAF ist der De-facto-Träger. |
| 5 | Richtlinie zur koordinierten Schwachstellenoffenlegung | Eine schriftliche, durchgesetzte CVD-Richtlinie mit Eingangskanal, Antwort-SLA und Offenlegungsbedingungen. ISO/IEC 29147 und 30111 bieten einen formalen Rahmen. |
| 6 | Externe Schwachstellenmeldung erleichtern | Eine Kontaktadresse für Meldungen zu Problemen im Produkt und seinen Drittanbieter-Komponenten. security.txt nach RFC 9116 erfüllt die Kanal-Anforderung. |
| 7 | Sichere Update-Verteilung | Signierte, authentifizierte Updates, automatisch wo zutreffend. Produkte ohne Update-Kanal müssen einen aufbauen oder dokumentieren, warum Automatisierung nicht zutrifft. Siehe Sicherheitsupdates. |
| 8 | Kostenlos, mit Hinweistexten | Sicherheitsupdates müssen unverzüglich und kostenlos verteilt werden (einzige Ausnahme: maßgeschneiderte Produkte für gewerbliche Nutzer, sofern die Parteien etwas anderes vereinbart haben). Jedes Update muss einen Hinweistext tragen, der das Problem und die erforderliche Nutzeraktion beschreibt. Eine kostenpflichtige Wartungs-Schranke oder ein stiller Patch ohne Hinweistext verstößt gegen Nummer 8. |
Schwachstellenbehandlung und der Unterstützungszeitraum
Die Anforderungen aus Anhang I Teil II gelten über den gesamten Unterstützungszeitraum, der in Artikel 3(20) definiert und durch Artikel 13(8) gefordert wird. Der Unterstützungszeitraum beträgt mindestens fünf Jahre ab dem Datum, an dem das Produkt auf dem EU-Markt bereitgestellt wurde, oder die erwartete Produktnutzungsdauer, falls kürzer und offengelegt. Das Enddatum des Unterstützungszeitraums muss in den Produktinformationen nach Anhang II erscheinen. Endet der Unterstützungszeitraum, entfallen die Pflichten aus Anhang I Teil II für diese Produktversion, aber die Pflicht zur Aufbewahrung der Dokumentation nach Artikel 31 (zehn Jahre ab Bereitstellung auf dem Markt) bleibt bestehen. Siehe CRA-Unterstützungszeitraum.
Schwachstellenbehandlung ist nicht Meldepflicht nach Artikel 14
Der CRA unterscheidet zwei Pflichten, die auf unterschiedlichen Oberflächen und mit unterschiedlichen Adressaten arbeiten:
- Die Schwachstellenbehandlung nach Anhang I Teil II ist der Engineering-Prozess: SBOM, Behebung, CVD-Richtlinie, öffentliche Offenlegung, sichere Updates. Sie gilt für alle Schwachstellen, jederzeit, über den gesamten Unterstützungszeitraum. Sie wird durch die Produktsicherheitsorganisation des Herstellers geleistet.
- Die Meldung nach Artikel 14 ist die regulatorische Benachrichtigung, die durch eine aktiv ausgenutzte Schwachstelle (Artikel 3(42)) oder einen schwerwiegenden Vorfall mit Auswirkung auf die Sicherheit des Produkts ausgelöst wird. Sie wird über die ENISA Single Reporting Platform im Takt 24h / 72h / 14d an ENISA und das als Koordinator benannte CSIRT geleistet. Zur SRP-Onboarding-Mechanik siehe ENISA-SRP-Onboarding.
Ein Produktteam kann vollständig konform mit Anhang I Teil II sein, ohne jemals eine Meldung nach Artikel 14 einzureichen, weil die meisten Schwachstellen behoben werden, bevor sie aktiv ausgenutzt werden. Artikel 14 greift nur, wenn die Behebung mit der aktiven Ausnutzung noch nicht Schritt gehalten hat. Siehe CRA Artikel-14-Meldung.
Bußgelder bei Verstößen
Die Nichteinhaltung der wesentlichen Anforderungen aus Anhang I, einschließlich der Schwachstellenbehandlung nach Teil II, fällt in die höchste Stufe der Bußgelder nach Artikel 64(2): bis zu 15.000.000 EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes, je nachdem was höher ist. Die Pflicht gilt ab dem 11. Dezember 2027 für Produkte, die ab diesem Datum auf dem Markt bereitgestellt werden.
Häufig gestellte Fragen
Muss die SBOM nach Anhang I Teil II Nummer 1 transitive Abhängigkeiten abdecken?
Der wörtliche Text verlangt "zumindest die obersten Abhängigkeiten", was die regulatorische Untergrenze ist. Transitive Komponenten werden durch Nummer 1 nicht vorgeschrieben, sind aber durch Nummer 2 in der Praxis vorgeschrieben: Sie können eine CVE in einer transitiven Komponente, die Sie nie katalogisiert haben, nicht "unverzüglich beheben". Die meisten Aufsichtsbehörden und Kunden erwarten eine tiefe SBOM, die BSI TR-03183 oder vergleichbaren Leitlinien folgt. CycloneDX und SPDX qualifizieren sich beide als "weit verbreitete und maschinenlesbare" Formate. Siehe CRA-SBOM-Anforderungen.
Was bedeutet "unverzüglich" in der Praxis für die Behebung nach Nummer 2?
Der CRA legt keinen festen Behebungs-SLA fest. "Unverzüglich" skaliert mit dem Cybersicherheitsrisiko: eine kritische Schwachstelle mit aktiver Ausnutzung in freier Wildbahn verlangt einen Fix in Tagen, während ein Problem mit niedrigem Schweregrad bis zum nächsten regulären Zyklus warten kann. Der Schweregrad wird mit CVSS festgestellt, durch EPSS-Ausnutzungswahrscheinlichkeitsdaten geschärft und durch Belege aus dem CISA-KEV-Katalog bestätigt, sofern die Schwachstelle auf der Liste aktiv ausgenutzter Schwachstellen der CISA steht. Siehe Schweregradbewertung für die operative Skala, die Marktbehörden bei der Beurteilung anlegen, ob ein Hersteller "unverzüglich" behoben hat.
Können Sicherheitsupdates unter irgendwelchen Umständen kostenpflichtig sein?
Es existiert nur eine Ausnahme: Anhang I Teil II Nummer 8 erlaubt eine kostenpflichtige Vereinbarung für maßgeschneiderte Produkte, die an einen gewerblichen Nutzer geliefert werden, sofern Hersteller und gewerblicher Nutzer etwas anderes vereinbart haben. Für jedes andere Produkt, einschließlich aller Verbraucherprodukte und standardmäßiger B2B-SaaS oder Hardware, müssen Sicherheitsupdates über den gesamten Unterstützungszeitraum kostenlos sein. Einen Sicherheitspatch hinter eine kostenpflichtige Wartungsstufe zu stellen, verstößt direkt gegen Nummer 8 und setzt den Hersteller den höchsten Bußgeldern nach Artikel 64(2) aus.
Bestehen die Pflichten aus Anhang I Teil II nach dem Ende des Unterstützungszeitraums fort?
Nein. Die acht Pflichten aus Anhang I Teil II gelten über den gesamten Unterstützungszeitraum nach Artikel 13(8) und entfallen für diese Produktversion, sobald der Unterstützungszeitraum endet. Zwei Pflichten überdauern den Unterstützungszeitraum: die Pflicht zur Aufbewahrung der technischen Dokumentation nach Artikel 31 (zehn Jahre ab Bereitstellung auf dem Markt) sowie jede Meldung nach Artikel 14, die zum Zeitpunkt des Endes bereits lief. Neue Schwachstellen, die nach dem Ende des Unterstützungszeitraums entdeckt werden, müssen für diese Version nicht behoben werden, aber der Hersteller muss ein klares End-of-Support-Datum in den Produktinformationen veröffentlicht haben, damit Nutzer migrieren können. Siehe Unterstützungszeitraum und End-of-Support-Offenlegung.
Wann wird ein CVD-Eingang zu einem Auslöser nach Artikel 14?
Der Auslöser ist "aktiv ausgenutzt" nach Artikel 3(42), nicht "gemeldet" oder "ausnutzbar". Ein funktionierender Proof-of-Concept, der einer CVD-Meldung beigefügt ist, ist für sich allein kein Auslöser nach Artikel 14; er wird zu einem solchen, wenn eine begründete Annahme besteht, dass ein böswilliger Akteur den Fehler gegen ein reales Ziel eingesetzt hat. Sobald diese Schwelle überschritten ist, beginnt die 24-Stunden-Frühwarnung an ENISA und das Koordinator-CSIRT, gefolgt von der 72-Stunden-Meldung und einem Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme. Siehe CRA Artikel-14-Meldung.