CRA-Support-Zeitraum, EOL & Update-Pflicht

Eine kostspielige CRA-Frage stellt sich erst in den Jahren nach der Markteinführung: 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 am stärksten beeinflusst: 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 (Art. 13 Abs. 8).

Art. 13 Abs. 8 schreibt mindestens fünf Jahre vor; kürzer darf der Zeitraum nur sein, wenn das Produkt voraussichtlich weniger als fünf Jahre im Betrieb ist. Bei Produkten, die länger im Feld bleiben - industrielle Steuerungen, Gebäudetechnik, Energie- und Netzinfrastruktur - kann ein deutlich längerer Zeitraum angemessen sein. Eine kürzere voraussichtliche Nutzungsdauer ist zu begründen: Die dafür berücksichtigten Informationen gehören in die technische Dokumentation (Art. 13 Abs. 8, Anhang VII Nr. 4). 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:

• Unverzügliche, kostenlose Sicherheitsupdates. Sicherheitsupdates sind unverzüglich und kostenlos zu verbreiten, sofern mit einem gewerblichen Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart ist, und soweit technisch machbar getrennt von Funktionsupdates (Anhang I Teil II Nr. 2 und 8). So kann ein Kunde einen Sicherheitsfix beziehen, 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 schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Sicherheit des Produkts sind gestaffelt zu melden.

Die Fristen im Überblick:

Gemeldet wird über die einheitliche Meldeplattform (Single Reporting Platform, Art. 16) gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA. Die Melde- und Berichtspflichten greifen seit dem 11.09.2026; das ist die erste harte Herstellerpflicht des CRA, deutlich vor der Vollanwendung 2027. Ohne funktionierenden Prozess zur Schwachstellenbehandlung sind diese Fristen kaum planbar einzuhalten.

Den Support-Zeitraum bestimmen und kommunizieren

Der Support-Zeitraum ist eine begründete Festlegung des Herstellers. 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 Nr. 4), die mindestens zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufzubewahren ist, je nachdem, welcher Zeitraum länger ist.

Nach außen gilt: Das Enddatum des Unterstützungszeitraums ist zum Zeitpunkt des Kaufs leicht zugänglich und klar anzugeben, mindestens mit Monat und Jahr, sofern zutreffend auf dem Produkt, der Verpackung oder mit digitalen Mitteln (Art. 13 Abs. 19). Eine bloße Dauer genügt dafür nicht. 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 planen

Am End of Life (EOL) endet die Pflicht, Schwachstellen zu behandeln und neue Sicherheitsupdates bereitzustellen. Andere Pflichten wirken fort: Bereitgestellte Sicherheitsupdates bleiben nach ihrer Bereitstellung mindestens zehn Jahre verfügbar (Art. 13 Abs. 9), die technische Dokumentation ist weiter aufzubewahren (Abs. 13), und wo technisch machbar ist der Nutzer darüber zu informieren, dass das Ende des Unterstützungszeitraums erreicht ist (Abs. 19). Auch die Meldepflichten nach Art. 14 enden nicht mit dem Unterstützungszeitraum. 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 bis zum Ende des Support-Zeitraums betriebsbereit bleiben, auch wenn das Entwicklungsteam längst an anderen Produkten arbeitet.

Warum das strategisch teuer ist: die SBOM-Kopplung

Die Update-Pflicht macht jede Fremdkomponente zum Planungsrisiko. In der Software Bill of Materials (SBOM - in einem gängigen maschinenlesbaren Format, zumindest mit den obersten Abhängigkeiten, Teil der technischen Doku; die BSI TR-03183-2 nennt CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1) 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 schon heute in Roadmap und Budget. 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: Frühwarnung unverzüglich, spätestens nach 24 Stunden, Meldung spätestens nach 72 Stunden, Abschlussbericht spätestens 14 Tage, nachdem die Korrektur verfügbar ist. Wer das erst 2037 durchdenkt, hat zehn 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 %. Art. 64 gehört nicht zu den vorgezogenen Vorschriften und gilt ab dem 11.12.2027 (Art. 71 Abs. 2); das deutsche Durchführungsgesetz (Bundestag-Drucksache 21/6134), das Behörde und Bußgeldverfahren regeln soll, ist zum 9. Oktober 2026 weder beschlossen noch verkündet.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) unterstützt Hersteller dabei, den Unterstützungszeitraum herzuleiten und in der technischen Dokumentation zu begründen. Dazu bauen wir mit Ihnen die SBOM-Kette aus dem Build auf, die die Fremdkomponenten je Release erfasst und laufend gegen Schwachstellendatenbanken abgleicht. So wird früh sichtbar, welche Komponenten für den zugesagten Zeitraum ersetzt oder selbst gepflegt werden müssen.

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: Kontakt aufnehmen.