CRA-Supportzeitraum: 5-Jahres-Untergrenze (Artikel 13(8))

Artikel 13(8) des EU Cyber Resilience Act (Verordnung (EU) 2024/2847) legt eine Mindestfrist von fünf Jahren für die Schwachstellenbehandlung fest, verankert am Datum der Markteinführung des Produkts in der EU. Dieser Leitfaden behandelt die Dauermechanik: wann die Frist beginnt, wie die Ausnahmeregelung bei kürzerer Lebensdauer funktioniert, wie sich Mehrversionsportfolios überschneiden und was Lieferverträge mit vorgelagerten Partnern abdecken müssen. Zur Bereitstellungsmechanik von Sicherheitsupdates siehe CRA-Sicherheitsupdates; zur nutzerseitigen Offenlegung des Support-Enddatums siehe Offenlegung des Support-Endes.

Zusammenfassung

  • Fünf Jahre sind die Mindestanforderung. Artikel 13(8) verlangt eine Schwachstellenbehandlung für mindestens fünf Jahre ab dem Datum der Markteinführung des Produkts in der EU.
  • Die Ausnahmeregelung bei kürzerer Lebensdauer ist eng gefasst. Sie muss vor der Markteinführung bewertet, in der Risikoabschätzung nach Anhang I Teil I dokumentiert und den Nutzern in den Anhang-II-Informationen vor dem Kauf offengelegt werden.
  • Die Frist beginnt mit der Markteinführung, nicht mit dem Kauf durch den Kunden. Lagerware, die vor dem Verkauf monatelang im Lager liegt, hat bereits einen Teil des Unterstützungszeitraums verbraucht.
  • Mehrversionsportfolios erzeugen überlappende Fristen. Jede Version hat ihre eigene Artikel-13(8)-Frist; Hersteller können gleichzeitig für drei oder mehr aktive Versionen in der Pflicht stehen.
  • Das Risiko vorgelagerter Lieferanten liegt beim Hersteller. Das Supportende eines Komponentenlieferanten ist keine Entlastung; Lieferverträge müssen den gesamten Artikel-13(8)-Zeitraum abdecken.
5y
Mindestunterstützungszeitraum
Artikel 13(8) ab Markteinführung
Free
Sicherheitsupdates
Artikel 13(8), kein kostenpflichtiges Patching
10y
Aufbewahrung der technischen Dokumentation
Artikel 31, ab Markteinführung
€15M / 2.5%
Höchstbußgeld
Artikel 64, je nachdem, was höher ist

Die vier Kennzahlen, die den CRA-Unterstützungszeitraum definieren: die Mindestdauer, die Kostenpflicht, die Mindestaufbewahrungsfrist für Dokumentation und die Bußgeldobergrenze.

Der Unterstützungszeitraum beginnt mit der Markteinführung, nicht mit dem Kauf durch den Kunden

Artikel 13(8) verankert die Fünf-Jahres-Frist am Datum der Markteinführung des Produkts in der EU, also dem ersten Zeitpunkt, zu dem es einem Vertriebskanal oder Verkaufskanal zur Verfügung gestellt wird. Ein Exemplar, das 18 Monate im Lager liegt, bevor ein Kunde es kauft, hat bereits 18 Monate seines Unterstützungszeitraums verbraucht. Dies schafft ein Lagerbestandsrisiko: Hersteller, die keine Markteinführungsdaten nach Produktversion verfolgen, können die Einhaltung von Artikel 13(8) nicht nachweisen.

Was der CRA zum Unterstützungszeitraum verlangt

Artikel 13(8) des Cyber Resilience Act legt fest, dass der Hersteller "sicherstellt, dass Schwachstellen des Produkts mit digitalen Elementen für einen Zeitraum von mindestens fünf Jahren ab dem Datum der Markteinführung oder für die erwartete Nutzungsdauer des Produkts, je nachdem, welcher Zeitraum kürzer ist, wirksam behandelt werden." (Übersetzung aus dem englischen Originalwortlaut; eine amtliche deutsche Konsolidierungsfassung von Verordnung (EU) 2024/2847 war zum Zeitpunkt der Erstellung dieses Leitfadens nicht verfügbar.)

Die Verpflichtung hat drei Bestandteile:

Dauer

Mindestens fünf Jahre. Die Ausnahme "erwartete Nutzungsdauer des Produkts, sofern kürzer" ist eng gefasst und muss vor dem Kauf dokumentiert und offengelegt werden. Ein Hersteller kann sich nicht nachträglich darauf berufen. Wenn die Dokumentation fünf Jahre ausweist, schuldet der Hersteller fünf Jahre.

Behandlung

Schwachstellen müssen gemäß Anhang I Teil II "wirksam" behandelt werden: identifizieren und dokumentieren, ohne ungebührliche Verzögerung beheben, nach der Behebung offenlegen und eine koordinierte Offenlegungsrichtlinie betreiben. Nicht nur das Bereitstellen von Patches, sondern der gesamte Schwachstellenlebenszyklus.

Kostenlos

Sicherheitsupdates müssen für Nutzer kostenlos bereitgestellt werden. Feature-Updates und kostenpflichtige Support-Stufen sind davon getrennt. Das Bündeln von Fixes in einem kostenpflichtigen Abonnement erfüllt Artikel 13(8) nicht. Zur Bereitstellungsmechanik siehe Sicherheitsupdates.

Wann die Fünf-Jahres-Frist beginnt

Artikel 13(8) verankert den Unterstützungszeitraum am Datum der "Markteinführung" des Produkts. Nach EU-Produktrecht ist die Markteinführung der erste Zeitpunkt, zu dem das Produkt einem beliebigen Glied in der Vertriebskette zur Verfügung gestellt wird, nicht der Einzelhandelsverkauf an den Endkunden.

Fristbeginn: Das Datum, an dem der Hersteller (oder ein Bevollmächtigter) das Produkt erstmals einem Händler, Einzelhändler oder Importeur zum Zweck des Vertriebs in der EU zur Verfügung stellt.

Fristbeginn nicht: Kundenkauf, Kundenaktivierung, Versand eines bestimmten Exemplars oder das Datum, an dem ein Kunde das Produkt installiert.

Praxisbeispiel:

  1. Januar 2028. Produkt v1.0 wird auf dem EU-Markt eingeführt. Der fünfjährige Unterstützungszeitraum beginnt. Der Hersteller schuldet Sicherheitsupdates bis mindestens Januar 2033.
  2. Juni 2029. Ein Kunde kauft v1.0 bei einem Einzelhändler. Der Kunde hat noch ungefähr 3,5 Jahre Support, nicht fünf Jahre ab dem Kaufdatum.
  3. Januar 2033. Der Unterstützungszeitraum endet. Die Pflicht des Herstellers, v1.0 zu patchen, erlischt. Der Kunde nutzt das Produkt weiterhin auf eigenes Risiko.

Empfohlene Vorgehensweise: Markteinführungsdaten je Produktversion verfolgen, nicht je Einzelexemplar. Ein einziger Markteinführungsdatensatz je SKU ist für die Zwecke von Artikel 13(8) ausreichend.

Die Ausnahmeregelung bei kürzerer erwarteter Lebensdauer

Artikel 13(8) erlaubt einen kürzeren Unterstützungszeitraum als fünf Jahre, wenn die erwartete Nutzungsdauer des Produkts kürzer ist. Diese Ausnahmeregelung ist enger gefasst als sie erscheint:

  • Die "erwartete Nutzungsdauer des Produkts" wird aus der Perspektive angemessener Nutzererwartungen bewertet, basierend auf der Art des Produkts, der typischen Nutzung ähnlicher Produkte und den Angaben des Herstellers.
  • Der kürzere Zeitraum muss in der Risikoabschätzung des Produkts (Anhang I Teil I) dokumentiert und den Nutzern in den Anhang-II-Produktinformationen offengelegt werden, bevor sie das Produkt kaufen.
  • Ein Hersteller kann die Ausnahmeregelung nicht geltend machen, nachdem eine Schwachstelle entdeckt wurde. Die Bewertung muss vor der Markteinführung vorgenommen und in der technischen Dokumentation festgehalten werden.
  • Für die meisten Softwareprodukte, IoT-Geräte und vernetzte Hardware gelten fünf Jahre als praktische Mindestanforderung. Die Ausnahmeregelung gilt für Produkte mit einer objektiv kurzen Nutzungsdauer, wie Einweg- oder begrenzt nutzbares Hardware, nicht für Produkte, bei denen der Hersteller lediglich eine kürzere Verpflichtung bevorzugt.

Unterstützung mehrerer Versionen

Die meisten Hersteller haben mehrere Produktversionen gleichzeitig auf dem Markt, jede mit ihrem eigenen Unterstützungszeitraum nach Artikel 13(8).

Gestaffelte Unterstützungszeiträume erzeugen überlappende Pflichten:

Drei Produktversionen überschneiden sich vier Jahre lang gemäß Artikel 13(8) Gantt-Diagramm als Zeitachse. v1.0 wird von Januar 2028 bis Januar 2033 unterstützt. v1.1 wird von Juli 2028 bis Juli 2033 unterstützt. v2.0 wird von Januar 2029 bis Januar 2034 unterstützt. Zwischen Januar 2029 und Januar 2033 stehen alle drei Versionen gleichzeitig unter Support. Vier-Jahres-Fenster: alle drei Versionen gleichzeitig im Support v1.0 v1.1 v2.0 2028 2029 2030 2031 2032 2033 2034
Jeder Balken stellt einen fünfjährigen Unterstützungszeitraum nach Artikel 13(8) dar, verankert am EU-Markteinführungsdatum der jeweiligen Version. Das schattierte Band markiert das Fenster, in dem der Hersteller gleichzeitig Patches für das gesamte Portfolio schuldet.
Version Markteinführung Support-Ende (5 J.)
v1.0 Jan 2028 Jan 2033
v1.1 Jul 2028 Jul 2033
v2.0 Jan 2029 Jan 2034

Von Januar 2029 bis Januar 2033 (vier Jahre) schuldet der Hersteller gleichzeitig Sicherheitsupdates für alle drei Versionen. Jede Version hat ihr eigenes CVE-Risikoprofil, ihren eigenen Abhängigkeitsbaum und potenziell ihre eigene Kundenbasis. Das Zurückportieren von Patches über große Versionssprünge hinweg ist technisch komplex und kostspielig.

Strategien zur Reduzierung des Aufwands bei mehreren Versionen:

  1. Gemeinsame Codebasis. Wo möglich eine einzige sicherheitsgepatchte Kernkomponente pflegen, auf der alle Versionen aufbauen. Einmal angewendete Sicherheitsfixes werden so an alle Versionen weitergegeben.
  2. Aktive Anreize zur Migration. Kürzere Abstände zwischen Kunden auf alten Versionen reduzieren die aktive Support-Matrix. Upgrade-Preismodelle, kostenlose Migrationswerkzeuge und Support-Gutschriften beschleunigen die Versionskonsolidierung.
  3. Klarer Versionsplan mit Support-Ende. Das Support-Enddatum je Version bei der Markteinführung veröffentlichen. Kunden, die wissen, dass v1.0 im Januar 2033 ausläuft, haben Zeit, die Migration ohne Notfalldruck zu planen.

Pflichten gegenüber Lieferanten und im vorgelagerten Bereich

Artikel 13(8) legt die Pflicht zum Unterstützungszeitraum dem Hersteller auf. Ein Hersteller, der sein Produkt nicht patchen kann, weil ein Komponentenlieferant den Support eingestellt hat, verstößt dennoch gegen Artikel 13(8). Die Lücke im vorgelagerten Vertrag ist keine Entlastung.

Was das in der Praxis bedeutet:

  • Enthält ein Produkt ein Betriebssystem, eine Middleware oder eine Chipset-Firmware eines Drittanbieters, muss der Hersteller eine Liefervereinbarung sicherstellen, die den gesamten Unterstützungszeitraum abdeckt. Ein vorgelagerter Anbieter, der Sicherheitspatches nur drei Jahre lang liefert, zwingt den Hersteller, die Patches nach dem dritten Jahr entweder selbst zu pflegen oder das Produkt nach dem vorgelagerten Support-Ende nicht mehr auf dem EU-Markt anzubieten.
  • Das SBOM-basierte Abhängigkeits-Tracking (siehe den SBOM-Cluster-Leitfaden) ist der operative Mechanismus: Ohne Kenntnis der Produktinhalte kann der Hersteller vorgelagerte Schwachstellen nicht überwachen.
  • Lieferverträge sollten Folgendes festlegen: Dauer der vorgelagerten Patch-Verpflichtung, Benachrichtigungspflichten bei neu entdeckten Schwachstellen, Zugang zu Quellcode oder Patch-Werkzeug bei Einstellung der Komponente durch den vorgelagerten Anbieter sowie Entschädigungsklauseln für Schwachstellen, die ihren Ursprung in vorgelagerten Komponenten haben.

Importeure, die die Rolleneskalation nach Artikel 22 auslösen (durch Umbranding oder wesentliche Produktmodifikation), übernehmen die vollständige Pflicht nach Artikel 13(8) einschließlich des vorgelagerten Vertragsrisikos. Den Entscheidungsablauf für Artikel 22 finden Sie im Leitfaden zu Importeurspflichten.

End-of-Life-Planung und verantwortungsvolle Produktübergänge

Wenn der Unterstützungszeitraum nach Artikel 13(8) endet, erlischt die Pflicht des Herstellers, Schwachstellen zu patchen, doch eine Reihe von Verantwortlichkeiten bleibt bestehen.

Was Artikel 13(8) und verwandte Vorschriften am Support-Ende verlangen:

  • Das in Anhang II angegebene Support-Enddatum, das vor dem Kauf offengelegt wurde, gilt als verbindliche Zusage. Die Nutzer müssen rechtzeitig angemessen informiert worden sein.
  • Die technische Dokumentation muss mindestens 10 Jahre ab dem Datum der Markteinführung aufbewahrt werden (Artikel 31), unabhängig davon, wann der Support endet.
  • Die EU-Konformitätserklärung muss für die Marktüberwachungsbehörden zugänglich bleiben.
  • Wenn der Hersteller von einer kritischen, aktiv ausgenutzten Schwachstelle in dem nicht mehr unterstützten Produkt erfährt, die eine erhebliche installierte Basis betrifft, besteht nach Ablauf des Support-Zeitraums keine Meldepflicht nach Artikel 14. Verantwortungsvolle Offenlegung und Nutzerbenachrichtigung werden jedoch nachdrücklich empfohlen. Zur Artikel-14-Fristmechanik, die während des Unterstützungszeitraums gilt, siehe Schwachstellenmeldung.

Kommunikationspflichten am Support-Ende:

Der CRA schreibt keine gesetzliche Ankündigungsfrist für das Support-Ende vor. Die Anforderung aus Anhang II, das Support-Enddatum vor dem Kauf offenzulegen, bedeutet, dass Nutzer, die das Produkt nach der Anhang-II-Offenlegung erworben haben, bereits informiert waren. Für Produkte, bei denen die ursprüngliche Anhang-II-Offenlegung fehlte oder unklar war, gilt eine Vorlaufzeit von 12 Monaten als branchenübliches Minimum.

Nach dem Support-Ende: Der Hersteller ist nicht verpflichtet, neue Schwachstellen zu patchen, sollte jedoch einen Sicherheitskontakt für die verantwortungsvolle Offenlegung von Schwachstellen bereithalten, die Produktdokumentation zugänglich halten und bei Untersuchungen einer Marktüberwachungsbehörde nach Artikel 58 kooperieren.

Das vollständige operative Playbook für End-of-Life, das Benachrichtigungsvorlagen, Migrationsframeworks, Szenarien bei übernommenen Produkten und den 18-Monats-Planungszeitplan enthält, finden Sie unter CRA End-of-Life-Planung: Verantwortungsvolle Produktübergänge.

Häufige Fehler

Keine Erfassung der Markteinführungsdaten. Ohne einen Markteinführungsdatensatz je Version kann der Hersteller weder berechnen, wann die Pflichten nach Artikel 13(8) beginnen oder enden, noch das Anhang-II-Support-Enddatum ermitteln oder die Einhaltung gegenüber Marktüberwachungsbehörden nachweisen.

Kein Plan für das vorgelagerte Support-Ende. Wenn ein Chipset-, Betriebssystem- oder Middleware-Anbieter den Support einstellt, bevor der Unterstützungszeitraum des Herstellers nach Artikel 13(8) abläuft, muss der Hersteller einen Plan haben. Reaktive Entdeckung des vorgelagerten Support-Endes ohne Liefervereinbarung ist ein verbreitetes und kostspieliges Versagensmuster.

Kopplung von Sicherheitspatches an Feature-Releases. Das Bündeln von Sicherheitsfixes in größere Versions-Upgrades zwingt Kunden, neue Features und neue Angriffsfläche zu akzeptieren, um einen Sicherheitsfix zu erhalten. Artikel 13(8) verlangt die Bereitstellung von Fixes ohne ungebührliche Verzögerung. Ein sechsmonatiger Release-Zyklus entspricht bei einer kritischen Schwachstelle nicht dem Gebot "ohne ungebührliche Verzögerung".

Häufig gestellte Fragen

Wann beginnt der fünfjährige Unterstützungszeitraum?

Artikel 13(8) verankert den Unterstützungszeitraum am Datum der Markteinführung des Produkts in der EU: dem ersten Zeitpunkt, zu dem der Hersteller das Produkt einem beliebigen Glied in der Vertriebskette zum Zweck des EU-Vertriebs zur Verfügung stellt. Er beginnt nicht mit dem Kaufdatum des Kunden, mit der Aktivierung oder mit dem Versand eines bestimmten Exemplars. Ein im Januar 2028 auf dem Markt eingeführtes Produkt schuldet Sicherheitsupdates bis mindestens Januar 2033, unabhängig davon, wann ein einzelner Kunde es kauft.

Kann der Unterstützungszeitraum kürzer als fünf Jahre sein?

Ja, gemäß der Artikel-13(8)-Ausnahmeregelung, wenn die erwartete Nutzungsdauer des Produkts kürzer als fünf Jahre ist. Der kürzere Zeitraum muss jedoch vor der Markteinführung festgelegt, in der Risikoabschätzung (Anhang I Teil I) dokumentiert und den Nutzern in den Anhang-II-Produktinformationen vor dem Kauf offengelegt werden. Ein Hersteller kann die Ausnahmeregelung nicht geltend machen, nachdem eine Schwachstelle entdeckt wurde; die Bewertung muss angemessene Nutzererwartungen widerspiegeln, keine internen Kostenpräferenzen. Für die meisten IoT-Geräte, vernetzte Hardware und Softwareprodukte sind fünf Jahre die praktische Mindestanforderung.

Gilt die Artikel-14-Meldepflicht nach Ablauf des Unterstützungszeitraums?

Nein. Die Artikel-14-Meldepflichten (die 24-Stunden-Frühwarnung, die 72-Stunden-Meldung und der 14-tägige Abschlussbericht für aktiv ausgenutzte Schwachstellen) gelten für den Hersteller während des Unterstützungszeitraums. Sobald der Unterstützungszeitraum nach Artikel 13(8) abläuft, besteht für den Hersteller keine Pflicht zur Artikel-14-Meldung von Schwachstellen, die in dieser Produktversion entdeckt werden. Marktüberwachungsbehörden behalten die Befugnis, nach Artikel 58 zu ermitteln, wenn ein nicht mehr unterstütztes Produkt ein erhebliches Cybersicherheitsrisiko darstellt; die laufenden Pflichten zur Schwachstellenverwaltung und Meldung nach Artikel 13 und Artikel 14 sind jedoch beendet.

Was gilt, wenn ein vorgelagerter Komponentenanbieter seinen Support vor Ablauf unseres Artikel-13(8)-Zeitraums einstellt?

Artikel 13(8) legt die Pflicht dem Hersteller auf, nicht vorgelagerten Anbietern. Wenn ein Chipset-, Betriebssystem- oder Middleware-Anbieter den Support für eine Komponente einstellt, bevor der Fünf-Jahres-Zeitraum des Herstellers abläuft, muss der Hersteller Patches entweder eigenständig pflegen, eine alternative unterstützte Komponente beschaffen oder das Produkt vom EU-Markt nehmen. Die Support-Ende-Entscheidung eines vorgelagerten Anbieters ist keine Entlastung gegenüber einer Feststellung der Marktüberwachungsbehörde über eine Nichteinhaltung von Artikel 13(8). Lieferverträge, die bei der Produktentwicklung ausgehandelt werden, sollten die Dauer der vorgelagerten Patch-Verpflichtung, den Zugang zu Quellcode oder Patch-Werkzeug sowie Benachrichtigungspflichten festlegen, verifiziert anhand des erwarteten Unterstützungszeitraums des Produkts vor der Markteinführung.

Was Sie vor dem 11. Dezember 2027 tun sollten

  1. Für jedes Produkt mit digitalen Elementen in Ihrem Portfolio: das Markteinführungsdatum je Version erfassen. Dies ist der Startpunkt der Artikel-13(8)-Frist und der Ankerpunkt für die Anhang-II-Offenlegung. Ohne diese Angabe können Sie das Support-Enddatum weder berechnen noch nachweisen.
  2. Prüfen, ob die Fünf-Jahres-Mindestfrist gilt oder ob die Ausnahmeregelung bei kürzerer Nutzungsdauer vertretbar ist. Die Bewertung in der Risikoabschätzung (Anhang I Teil I) dokumentieren und in der technischen Dokumentation festhalten. Im Zweifelsfall auf fünf Jahre festlegen.
  3. Vorgelagerte Abhängigkeiten gegen den Unterstützungszeitraum prüfen. Für jedes Drittanbieter-Betriebssystem, jede Chipset-Firmware, Middleware oder Bibliothek im SBOM sicherstellen, dass die Patch-Verpflichtung des vorgelagerten Anbieters den gesamten Artikel-13(8)-Zeitraum abdeckt. Neu verhandeln oder Alternativen identifizieren, wo dies nicht der Fall ist. Den Dependency-Tracking-Rahmen finden Sie im SBOM-Cluster-Leitfaden.
  4. End-of-Support-Kommunikation für Produkte planen, deren Artikel-13(8)-Zeitraum im Fenster 2028-2033 ausläuft. Nutzer sollten das Enddatum vor dem Kauf kennen; sie sollten rechtzeitig informiert werden, bevor der Support endet. Den 18-Monats-Kommunikationszeitplan und Benachrichtigungsvorlagen finden Sie im End-of-Life-Planungsleitfaden.
  5. Wenn die Verwaltung von Unterstützungszeiträumen, Abhängigkeitsmonitoring und Artikel-14-Meldung über mehrere Produktversionen hinweg das Team überfordert, verfolgt CRA Evidence Markteinführungsdaten und Support-Enddaten je SKU, überwacht SBOM-Abhängigkeiten auf neu gemeldete CVEs im gesamten Support-Fenster und weist auf Article-14-Meldepflichten hin, wenn aktiv ausgenutzte Schwachstellen erkannt werden.