CRA-Support-Zeitraum, EOL & Update-Pflicht

Die teuerste CRA-Frage stellt sich nicht bei der Markteinführung, sondern in den Jahren danach: Wie lange muss ein Produkt mit kostenlosen Sicherheitsupdates versorgt werden — und was passiert am Ende dieser Zeit? Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlagert damit einen erheblichen Teil der Kosten aus der Entwicklung in den Lebenszyklus. Wer das erst kurz vor der Vollanwendung am 11.12.2027 durchrechnet, hat die Wahl bereits verpasst, die den Aufwand halbiert hätte: die Wahl der Komponenten und der Update-Architektur zu Projektbeginn.

Was der Support-Zeitraum ist — und was nicht

Der CRA verlangt, dass der Hersteller Schwachstellen über einen definierten Support-Zeitraum (support period) hinweg wirksam behandelt und Sicherheitsupdates bereitstellt. Entscheidend ist das Konzept dahinter: Dieser Zeitraum soll die voraussichtliche Nutzungsdauer des Produkts widerspiegeln — nicht ein pauschales Ablaufdatum.

Als Orientierung nennt der CRA-Kontext in der Regel mindestens fünf Jahre. Wichtig ist die Lesart: Das ist eine Leitlinie, keine starre Frist. Bei Produkten, die typischerweise länger im Feld bleiben — industrielle Steuerungen, Gebäudetechnik, Energie- und Netzinfrastruktur — kann ein deutlich längerer Zeitraum angemessen sein. Umgekehrt rechtfertigt eine tatsächlich kürzere erwartbare Nutzungsdauer keinen Freibrief: Die fünf Jahre sind der Referenzpunkt, von dem nach unten schwer wegzuargumentieren ist. Dieser Beitrag ordnet die Regelungslage schematisch ein und ersetzt keine Rechtsberatung.

Was während des Support-Zeitraums gilt

Innerhalb des zugesagten Zeitraums verdichtet sich die Herstellerpflicht (Anhang I der Verordnung) auf einige konkrete Punkte:

• Zeitnahe, kostenlose Sicherheitsupdates. Sicherheitsupdates sind grundsätzlich unverzüglich bereitzustellen und dürfen nicht an kostenpflichtige Funktions-Upgrades gekoppelt werden. Sicherheits- und Feature-Updates sollten trennbar bleiben, damit ein Kunde ein Sicherheitsfix beziehen kann, ohne einen Funktionsschritt kaufen zu müssen.
• Wirksames Schwachstellen-Handling mit CVD-Policy. Über den gesamten Zeitraum braucht es einen dokumentierten Prozess zur koordinierten Offenlegung (Coordinated Vulnerability Disclosure) inklusive Meldekanal und Bearbeitungspfad.
• Update-Fähigkeit „by design“. Auch feldverteilte Geräte ohne Dauerkonnektivität müssen aktualisierbar sein — das betrifft OTA-Mechanismen, signierte Pakete und die Frage, wie ein Update ein Gerät erreicht, das nur gelegentlich online ist.
• Meldepflichten nach Art. 14. Aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle sind zu melden — und zwar in einer klaren Kaskade.

Die Melde-Kaskade wird häufig verwechselt, deshalb im Überblick:

Gemeldet wird über die ENISA Single Reporting Platform (SRP) an das zuständige CSIRT und ENISA. Die Melde- und Berichtspflichten greifen ab dem 11.09.2026 — das ist die erste harte Herstellerpflicht des CRA, deutlich vor der Vollanwendung 2027. Wer bis dahin keinen funktionierenden Vulnerability-Prozess hat, kann die 14-Tage- oder 1-Monats-Frist nicht einhalten.

Den Support-Zeitraum bestimmen und kommunizieren

Der Support-Zeitraum ist kein Bauchgefühl, sondern eine begründete Festlegung. In der Praxis leitet man ihn aus mehreren Faktoren ab: der typischen Einsatzdauer in der Zielbranche, dem Nutzungsverhalten vergleichbarer Produkte, Vertragslaufzeiten und der Frage, wie lange die verbauten Komponenten selbst gepflegt werden. Diese Herleitung gehört in die technische Dokumentation (Anhang VII), die nach dem Inverkehrbringen zehn Jahre aufzubewahren ist.

Nach außen gilt: Der Support-Zeitraum ist dem Nutzer klar zu kommunizieren — als Enddatum oder als Dauer, vor dem Kauf erkennbar. Ein Produkt ganz ohne kommunizierten Support-Horizont lässt sich nicht konform in Verkehr bringen. Die Zusage bindet: Wer „Sicherheitsupdates bis 12/2031“ auf die Verpackung schreibt, hat sich bis dahin gebunden, auch wenn das Produkt kommerziell längst abgelöst ist.

EOL-Management: das Enddatum ist ein Projekt, kein Ereignis

Am End of Life (EOL) entfällt die Update-Pflicht — aber das Ende muss geplant und kommuniziert werden, nicht stillschweigend eintreten. Ein sauberes EOL-Management umfasst:

• Frühzeitige Ankündigung gegenüber Kunden und Distributoren, mit konkretem Stichtag und Handlungsempfehlung (Migration, Nachfolgeprodukt).
• Ein letztes definiertes Update-Fenster, damit kein Gerät mit einer bekannten, aber ungepatchten Schwachstelle in die update-freie Phase geht.
• Dokumentierte Restrisiken für die Zeit nach EOL, damit Betreiber ihre eigene Risikoentscheidung treffen können.
• Eine funktionierende Update-Infrastruktur bis zum letzten Tag — OTA-Backend, Signaturschlüssel und Build-Umgebung müssen so lange betriebsbereit bleiben wie der Support-Zeitraum reicht, nicht nur solange das Entwicklungsteam am Produkt arbeitet.

Warum das strategisch teuer ist: die SBOM-Kopplung

Die Update-Pflicht macht jede Fremdkomponente zum Planungsrisiko. In der Software Bill of Materials (SBOM — maschinenlesbar, CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1, mindestens auf Top-Level-Ebene, Teil der technischen Doku) steht jede Bibliothek, deren eigener Upstream-Support irgendwann endet. Läuft dieser Upstream-Support vor dem Ende des zugesagten Zeitraums aus, entsteht eine Lücke: Der Hersteller muss die Komponente dann vorab ersetzen oder selbst weiterpflegen. Support-Zeitraum, SBOM und EOL-Monitoring sind untrennbar — wer das eine plant, muss die anderen mitdenken.

Ein durchgespieltes Beispiel

Ein Hersteller bringt 2027 ein vernetztes Steuergerät für die Gebäudeautomation auf den Markt. Typische Verweildauer im Feld: rund zehn Jahre. Er setzt den Support-Zeitraum daher schematisch auf zehn Jahre bis 12/2037 und kommuniziert das im Datenblatt.

Jetzt die Konsequenzenkette: Das Gerät nutzt ein Embedded-Linux, dessen LTS-Kernel-Pflege 2032 endet, und eine TLS-Bibliothek mit Wartung bis 2030. Beide enden vor 2037. In der Planung bedeutet das: Für die TLS-Bibliothek braucht es ab 2030 entweder einen Versionssprung oder ein eigenes Backporting von Fixes; für das Betriebssystem ab 2032 ebenso. Diese Übergänge gehören heute in die Roadmap und ins Budget, nicht ins Jahr, in dem sie eintreten. Parallel muss das OTA-Backend so ausgelegt sein, dass es auch 2036 noch signierte Updates an Geräte ausliefert, die nur wöchentlich online gehen. Und für den Fall einer aktiv ausgenutzten Schwachstelle im Feld steht der Art.-14-Pfad: 24 h Frühwarnung, 72 h Meldung, 14 Tage Abschlussbericht nach Verfügbarkeit des Fixes. Wer das erst 2037 durchdenkt, hat neun Jahre Verpflichtung ohne Vorsorge angesammelt.

Vertrags- und Produktplanung

Der Support-Zeitraum gehört in mehrere Dokumente gleichzeitig: in die Produkt-Roadmap (als Komponenten-Refresh-Plan), in Lieferantenverträge (Zusicherung von Security-Fixes durch Upstream-Anbieter über die passende Dauer) und in die eigenen Kunden-AGB (klar abgegrenzte Support-Zusage). Bußgeldseitig ist der Einsatz nicht klein: Verstoß gegen die Anforderungen aus Anhang I oder gegen die Meldepflichten kann mit bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden (der höhere Betrag), weitere Pflichtverstöße mit bis zu 10 Mio. Euro / 2 %, Falschangaben gegenüber Behörden mit bis zu 5 Mio. Euro / 1 %.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) unterstützt Hersteller dabei, den Support-Zeitraum belastbar herzuleiten, in der technischen Dokumentation zu begründen und mit einem tragfähigen EOL- und Update-Prozess zu unterlegen — von der SBOM-gestützten Komponentenanalyse über die Auslegung der OTA-Update-Infrastruktur bis zur Auslauf-Kommunikation. Der Schwerpunkt liegt darauf, spätere Pflichtlücken heute sichtbar zu machen, statt sie am EOL-Datum zu entdecken.

Ein guter Einstieg ist der Betroffenheits-Check: Er ordnet ein, welche CRA-Pflichten für Ihr Produkt relevant sein dürften. Vertiefend erklärt die Übersicht zum Cyber Resilience Act die Fristen und Rollen; speziell für kleinere Hersteller lohnt der Blick auf die KMU-Seite und die passenden Branchen. Für ein konkretes Gespräch zum Support-Zeitraum und zur Update-Architektur: Kontakt aufnehmen.