CRA-Unterstützungszeitraum: Fünf-Jahres-Untergrenze

Der EU Cyber Resilience Act macht die Planung des Unterstützungszeitraums zu einer Entscheidung vor dem Produktstart, nicht zu einem Thema danach. Ein Hersteller muss festlegen, wie lange Nutzer mit der Behandlung von Schwachstellen rechnen können, das Enddatum des Unterstützungszeitraums beim Kauf veröffentlichen und Sicherheitsupdates für den vorgeschriebenen Zeitraum verfügbar halten. Dieser Leitfaden behandelt die Dauermechanik: wann die Frist beginnt, wie die Ausnahme bei kürzerer erwarteter Nutzung wirkt, wie sich Mehrversionsportfolios stapeln und was vorgelagerte Lieferverträge abdecken müssen. Zur Bereitstellungstaktung siehe CRA-Sicherheitsupdates; zum nutzerseitigen Enddatum siehe Offenlegung zum Support-Ende.

Was der CRA für den Unterstützungszeitraum verlangt

Der Unterstützungszeitraum ist das Fenster, in dem der Hersteller den Prozess zur Behandlung von Schwachstellen am Produkt aktiv halten muss. Er erfasst das Produkt und seine Komponenten, beginnt mit dem Inverkehrbringen in der EU und muss lang genug sein, um der vernünftigerweise erwartbaren Nutzung zu entsprechen. Der Hersteller sollte ihn anhand praktischer Nachweise festlegen: Produktart, Zweckbestimmung, vergleichbare Produkte, einschlägige Unionsvorschriften zur Lebensdauer, Verfügbarkeit der Betriebsumgebung, Unterstützung zentraler Drittkomponenten und Leitlinien von ADCO oder Kommission. Das praktische Ergebnis ist einfach: Die Supportplanung muss vor dem Launch festgelegt und während des erklärten Supportfensters aufrechterhalten werden.

Die Verpflichtung hat drei Komponenten:

Wann die Fünf-Jahres-Frist beginnt

Die Unterstützungsfrist beginnt, wenn das Produkt auf den EU-Markt gelangt, nicht wenn der Endkunde es kauft. Im EU-Produktrecht ist das die erste Bereitstellung des Produkts auf dem Unionsmarkt zum Vertrieb oder zur Verwendung. Für die Supportplanung ist das Datum des Inverkehrbringens maßgeblich.

Fristbeginn: Das Datum, an dem das Produkt erstmals einem Händler, Einzelhändler, Einführer oder Nutzer zum Vertrieb oder zur Verwendung auf dem EU-Markt bereitgestellt wird.

Die Frist beginnt nicht bei: Kundenkauf, Kundenaktivierung, Versand einer bestimmten Einheit oder dem Datum, an dem ein Kunde das Produkt installiert.

Praxisbeispiel:

1. Januar 2028. Produkt v1.0 wird in der EU in Verkehr gebracht. Der fünfjährige Unterstützungszeitraum beginnt. Der Hersteller schuldet Sicherheitsupdates mindestens bis Januar 2033.
2. Juni 2029. Ein Kunde kauft v1.0 bei einem Einzelhändler. Der Kunde hat noch ungefähr 3,5 Jahre Unterstützung, nicht fünf Jahre ab Kauf.
3. Januar 2033. Der Unterstützungszeitraum endet. Die grundlegende Zusage zur Schwachstellenbehandlung für v1.0 endet. Weitere Nutzerhinweise oder regulatorische Schritte hängen vom Sachverhalt ab.

Best Practice: Verfolgen Sie das Datum des Inverkehrbringens je Produktversion, nicht je einzelner Einheit. Ein Datensatz je SKU ist normalerweise die praktische Nachweisbasis für die Berechnung von Enddaten.

Die Ausnahme bei kürzerer erwarteter Nutzung

Die Fünf-Jahres-Untergrenze kann nur verkürzt werden, wenn das Produkt tatsächlich voraussichtlich weniger als fünf Jahre genutzt wird. Diese Ausnahme ist enger, als sie wirkt, und stammt aus dem Artikel zum Unterstützungszeitraum:

• Die "erwartete Nutzungsdauer des Produkts" wird aus Sicht vernünftiger Nutzererwartungen beurteilt, anhand der Art des Produkts, der typischen Nutzung ähnlicher Produkte und der Herstellerkommunikation.
• Der kürzere Zeitraum muss in der technischen Dokumentation dokumentiert und Nutzern beim Kauf offengelegt werden, einschließlich mindestens Monat und Jahr des Enddatums.
• Ein Hersteller kann sich nicht erst nach Entdeckung einer Schwachstelle auf die Ausnahme berufen. Die Bewertung muss vor dem Inverkehrbringen erfolgen und in der technischen Akte festgehalten werden.
• Für die meisten Softwareprodukte, IoT-Geräte und vernetzte Hardware sind fünf Jahre die praktische Mindestdauer. Die Ausnahme passt zu Produkten mit objektiv kurzer Nutzungsdauer, etwa Einweg- oder Hardware mit begrenztem Zyklus, nicht zu Produkten, bei denen der Hersteller schlicht eine kürzere Pflicht bevorzugt.

Unterstützung mehrerer Versionen

Die meisten Hersteller haben mehrere Produktversionen gleichzeitig am Markt. Hardwareprodukte und unabhängig gepflegte Softwareversionen können überlappende Unterstützungsfenster erzeugen. Softwareprodukte haben außerdem einen begrenzten Nur-neueste-Version-Weg für nachfolgende wesentlich geänderte Versionen, sofern Nutzer früherer Versionen kostenlos und ohne zusätzliche Hardware- oder Softwareumgebungskosten auf die neueste Version wechseln können.

Gestaffelte Unterstützungszeiträume erzeugen überlappende Pflichten:

Von Januar 2029 bis Januar 2033, also vier Jahre lang, kann der Hersteller Sicherheitsupdates für alle drei Versionen gleichzeitig schulden, sofern kein zulässiger Nur-neueste-Version-Softwareweg greift. Jede Version hat ihr eigenes CVE-Risiko, ihren eigenen Abhängigkeitsbaum und möglicherweise eine eigene Kundenbasis. Patch-Backports über Hauptversionen hinweg sind technisch komplex und teuer.

Strategien zur Verringerung der Mehrversionslast:

1. Gemeinsame Codebasis. Pflegen Sie, wo möglich, einen einzigen sicherheitsgepatchten Kern, auf dem alle Versionen aufbauen. Ein einmal eingespielter Sicherheitsfix erreicht so alle Versionen.
2. Starke Migrationsanreize. Kürzere Verweildauern von Kunden auf alten Versionen verkleinern die aktive Unterstützungsmatrix. Upgrade-Preise, kostenlose Migrationstools und Supportgutschriften beschleunigen die Versionskonsolidierung.
3. Expliziter Versions-EOL-Plan. Veröffentlichen Sie das Enddatum jeder Version beim Inverkehrbringen. Kunden, die wissen, dass v1.0 im Januar 2033 endet, können ohne Notfalldruck migrieren.
4. Route nur für die jüngste Version bei geeigneter Software. Wenn Sie diese Route nutzen, dokumentieren Sie, wie Nutzer früherer Versionen die jüngste Version kostenlos und ohne Anpassungskosten für die Umgebung erhalten.

Pflichten gegenüber Lieferanten und vorgelagerten Verträgen

Der Hersteller trägt die Unterstützungspflicht auch dann, wenn eine Schwachstelle aus einer vorgelagerten Komponente stammt. Wenn das Produkt nicht gepatcht werden kann, weil ein Komponentenlieferant den Support eingestellt hat, braucht der Hersteller trotzdem einen Abhilfeweg. Die Lücke im vorgelagerten Vertrag ist keine Entlastung unter der Unterstützungszeitraum-Regel.

Was das in der Praxis bedeutet:

• Enthält ein Produkt ein Betriebssystem, Middleware oder Chipset-Firmware eines Drittanbieters, muss der Hersteller eine Liefervereinbarung sichern, die den gesamten Unterstützungszeitraum abdeckt. Ein vorgelagerter Anbieter, der nur drei Jahre Sicherheitspatches liefert, zwingt den Hersteller, die Patches ab Jahr drei selbst zu pflegen oder das Produkt nach dem vorgelagerten Support-Ende nicht mehr auf dem EU-Markt bereitzustellen.
• SBOM-basiertes Tracking von Abhängigkeiten, siehe den SBOM-Cluster-Leitfaden, ist der operative Mechanismus: Der Hersteller kann vorgelagerte Schwachstellen nicht überwachen, ohne zu wissen, was im Produkt steckt.
• Lieferverträge sollten festlegen: Dauer der vorgelagerten Patch-Zusage, Benachrichtigungspflichten bei neu entdeckten Schwachstellen, Zugang zu Quellcode oder Patchwerkzeugen, falls der vorgelagerte Anbieter die Komponente einstellt, und Freistellungsregeln für Schwachstellen aus vorgelagerten Komponenten.

Einführer und Händler, die ein Produkt unter eigenem Namen oder eigener Marke auf den Markt bringen oder ein bereits auf dem Markt befindliches Produkt wesentlich verändern, gelten als Hersteller und übernehmen die Herstellerpflichten, einschließlich des vorgelagerten Vertragsrisikos. Den Rollenwechsel finden Sie im Leitfaden zu Einführerpflichten.

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

Wenn der Unterstützungszeitraum endet, endet die grundlegende Zusage zur Schwachstellenbehandlung für diese Produktversion, aber einige Verantwortlichkeiten bleiben bestehen.

Was am Support-Ende bleibt:

• Das beim Kauf offengelegte Enddatum bleibt die nutzerseitige Zusage.
• Die technische Dokumentation und die EU-Konformitätserklärung müssen mindestens 10 Jahre ab dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufbewahrt werden, je nachdem, was länger ist.
• Informationen und Anleitungen für Nutzer müssen Nutzern und Marktüberwachungsbehörden auf derselben 10-Jahres-oder-Unterstützungszeitraum-Basis zugänglich bleiben, unabhängig vom Bereitstellungskanal; werden sie online bereitgestellt, müssen sie auch für diesen Zeitraum online zugänglich bleiben.
• Soweit technisch machbar, sollte der Hersteller den Nutzern eine Benachrichtigung anzeigen, dass das Produkt das Ende seines Supportzeitraums erreicht hat.
• Schwachstellen in nicht mehr unterstützten Produkten brauchen weiterhin sorgfältige Behandlung. Der CRA enthält keinen pauschalen Safe-Harbour-Satz für jede Meldepflicht-Frage am Support-Ende, und Marktüberwachungsbehörden können weiterhin tätig werden, wenn ein Produkt ein erhebliches Cybersicherheitsrisiko darstellt. Die Bußgeldexposition behandelt der Leitfaden zu Sanktionen und Durchsetzung.

Kommunikationspflichten am Support-Ende:

Der CRA legt keine gesetzliche Ankündigungsfrist für das Support-Ende fest. Die Offenlegung des Enddatums beim Kauf bedeutet, dass Nutzer, die das Produkt nach Einführung dieser Offenlegung gekauft haben, bereits informiert waren. Bei Produkten, bei denen die ursprüngliche Offenlegung fehlte oder unklar war, ist eine Vorabinformation eine operative Risikokontrolle und keine CRA-Frist mit eigener Artikelnummer.

Nach dem EOL: Der Hersteller sollte einen Sicherheitskontakt für verantwortliche Schwachstellenoffenlegung weiter betreiben, Produktdokumentation zugänglich halten und bei Untersuchungen der Marktüberwachungsbehörden kooperieren.

Häufige Fehler

• Daten des Inverkehrbringens nicht erfassen. Ohne Datensatz je Version kann der Hersteller nicht berechnen, wann die Unterstützungspflichten beginnen oder enden, das nutzerseitige Enddatum nicht erstellen und die Einhaltung gegenüber den Marktüberwachungsbehörden nicht belegen.

• Vorgelagertes Support-Ende nicht einplanen. Wenn ein Chipset-, OS- oder Middleware-Anbieter die Unterstützung beendet, bevor der Unterstützungszeitraum des Herstellers abläuft, braucht der Hersteller einen Plan. Reaktive Entdeckung eines vorgelagerten Support-Endes ohne Liefervereinbarung ist ein verbreiteter und teurer Fehler.

• Sicherheitspatches an Feature-Releases koppeln. Wer Sicherheitsfixes in Hauptversions-Upgrades bündelt, zwingt Kunden, neue Funktionen und neue Angriffsfläche zu akzeptieren, um einen Sicherheitsfix zu erhalten. Sicherheitsfixes sollten als Sicherheitsfixes ausgeliefert werden, ohne bezahlte Stufen oder große Funktions-Upgrades zu erzwingen.