Unterstützungszeitraum nach dem CRA: Fünf Jahre sind die Untergrenze, nicht die Regel

Von allen Pflichten des Cyber Resilience Act ist der Unterstützungszeitraum die mit der größten wirtschaftlichen Folge und der kürzesten Zusammenfassung. „Fünf Jahre Sicherheitsupdates", heißt es fast überall. Das ist die halbe Vorschrift. Die andere Hälfte sagt, dass der Zeitraum der erwarteten Nutzungsdauer entsprechen muss, und dass er bei kurzlebigen Produkten darunter liegen darf und bei langlebigen darüber liegen sollte. Wer die halbe Vorschrift in einen Vertrag oder eine Produktplanung übernimmt, verpflichtet sich entweder zu mehr, als das Gesetz verlangt, oder zu weniger, als es später einfordern wird.

Dieser Text nimmt Artikel 13 Absatz 8 der Verordnung (EU) 2024/2847 auseinander: was der Zeitraum ist, wie er bestimmt wird, welche anderen Pflichten an ihm hängen, wo er dokumentiert und genannt werden muss, und welche Entscheidungen ein Hersteller damit heute trifft. Wer den CRA insgesamt noch nicht einordnen kann, beginnt besser mit Was ist der Cyber Resilience Act?

Was der Unterstützungszeitraum ist

Der Unterstützungszeitraum ist der Zeitraum, in dem der Hersteller sicherstellen muss, dass Schwachstellen des Produkts wirksam und nach den Anforderungen von Anhang I Teil II behandelt werden. Praktisch heißt das: Schwachstellen erkennen, beheben, Sicherheitsupdates bereitstellen, behobene Schwachstellen veröffentlichen. Die acht Pflichten im Einzelnen stehen in SBOM nach dem Cyber Resilience Act, weil die Software-Stückliste ihr gemeinsamer Ausgangspunkt ist.

Der Zeitraum ist keine Garantie im zivilrechtlichen Sinn und kein Versprechen von Funktionsupdates. Er ist die Dauer der öffentlich-rechtlichen Pflicht, ein Produkt sicher zu halten. Er beginnt mit dem Inverkehrbringen des Produkts und endet an einem Datum, das der Hersteller festlegt und nennen muss.

Wie der Zeitraum bestimmt wird

Artikel 13 Absatz 8 enthält vier Regeln, und alle vier gelten zusammen.

1. Der Zeitraum entspricht der erwarteten Nutzungsdauer. Der Hersteller legt ihn so fest, dass er die Zeit widerspiegelt, in der das Produkt voraussichtlich in Gebrauch ist. Dabei berücksichtigt er die berechtigten Erwartungen der Nutzer, die Art und Zweckbestimmung des Produkts und einschlägiges Unionsrecht, das eine Lebensdauer für das Produkt vorsieht. Er darf sich außerdem an den Unterstützungszeiträumen vergleichbarer Produkte anderer Hersteller orientieren.

2. Mindestens fünf Jahre. Das ist die Untergrenze für den Regelfall.

3. Es sei denn, das Produkt wird kürzer genutzt. Ist das Produkt voraussichtlich weniger als fünf Jahre in Gebrauch, entspricht der Zeitraum der erwarteten Nutzungsdauer. Ein Produkt, das nach drei Jahren durch ein Nachfolgemodell ersetzt und nicht mehr genutzt wird, darf einen Zeitraum von drei Jahren haben. Die Begründung dafür muss aber tragen und dokumentiert sein, dazu gleich mehr.

4. Die Kommission kann für Produktkategorien Mindestzeiträume festlegen. Wenn sich zeigt, dass Hersteller in einer Kategorie systematisch zu kurze Zeiträume wählen, kann die Kommission per delegiertem Rechtsakt einen Mindestzeitraum für diese Kategorie vorschreiben. Wer heute an der Untergrenze plant, sollte das einkalkulieren.

Die Regel ist also nicht „fünf Jahre". Die Regel ist „so lange wie das Produkt genutzt wird, mindestens fünf Jahre, außer es wird nachweislich kürzer genutzt". Für Industriesteuerungen, Gebäudetechnik oder medizinnahe Geräte, die zehn oder fünfzehn Jahre im Einsatz sind, ist fünf Jahre deshalb zu wenig. Für eine Mobile App mit klarem Nachfolgezyklus kann es zu viel sein.

Was am Zeitraum hängt

Der Unterstützungszeitraum ist eine Stellgröße, an der mehrere andere Pflichten hängen. Wer ihn festlegt, legt sie mit fest.

Zwei Folgen daraus sind in der Praxis wichtig. Erstens: Ein Zeitraum von acht Jahren verlängert die Aufbewahrungspflichten von zehn Jahren nicht, ein Zeitraum von zwölf Jahren schon. Zweitens: Die Begründung ist Teil der Dokumentation. Ein Datum ohne die Überlegung, die zu ihm geführt hat, ist eine unvollständige technische Dokumentation, und genau das prüft eine Marktüberwachungsbehörde, wenn sie nach Anhang VII fragt.

Wo der Zeitraum stehen muss

An drei Stellen.

In der technischen Dokumentation, als Begründung: erwartete Nutzungsdauer, berücksichtigte Nutzererwartungen, Vergleichsprodukte, einschlägiges Recht (Anhang VII Nummer 4). Die vollständige Liste: Inhalt der technischen Dokumentation.

In der Nutzerinformation, als Enddatum und als Beschreibung der Art des Supports, die dem Produkt beiliegt (Anhang II Nummer 7). Der Text: Informationen und Anleitungen für den Nutzer.

Zum Zeitpunkt des Kaufs, leicht zugänglich, sodass ein Käufer das Enddatum vor der Entscheidung kennt, und, soweit anwendbar, auf dem Produkt, seiner Verpackung oder auf digitalem Weg. Ein Enddatum, das nur in einer PDF auf Seite vierzig steht, erfüllt diese Anforderung nicht.

Die Entscheidung, die ein Hersteller jetzt trifft

Der Unterstützungszeitraum ist keine Compliance-Formalie, sondern eine Produktentscheidung mit Preis. Vier Fälle kommen immer wieder vor.

Langlebige Hardware. Ein Gerät, das erfahrungsgemäß zwölf Jahre im Feld bleibt, hat einen Unterstützungszeitraum, der das widerspiegelt. Wer fünf Jahre nennt, muss begründen, warum das Gerät danach nicht mehr in Gebrauch ist, und diese Begründung hält bei Industriesteuerungen selten. Die Alternative ist, den Zeitraum ehrlich zu setzen und die Kosten der Pflege in den Preis zu nehmen.

Software mit Nachfolgezyklus. Eine Anwendung, die alle drei Jahre durch eine neue Hauptversion ersetzt wird, hat einen kürzeren Zeitraum, wenn die alte Version danach tatsächlich nicht mehr genutzt wird. Die Beobachtung, dass Kunden alte Versionen weiterbetreiben, ist dann das Gegenargument, und sie gehört in die Begründung.

Produkte mit zugekauften Komponenten. Ein Produkt kann keinen längeren Zeitraum haben, als seine Komponenten gepflegt werden, es sei denn, der Hersteller übernimmt die Pflege selbst. Ein Chip, dessen Firmware der Zulieferer nach vier Jahren nicht mehr aktualisiert, begrenzt den Zeitraum des Endprodukts, oder er zwingt den Hersteller, das Risiko zu übernehmen. Das ist eine Frage für die Lieferverträge, heute.

Produkte mit Fernverarbeitung. Wenn ein Produkt ohne einen Cloud-Dienst nicht funktioniert, ist der Dienst Teil des Produkts, und der Unterstützungszeitraum gilt auch für ihn. Ein Dienst, der nach drei Jahren abgeschaltet wird, beendet den Zeitraum des Produkts vorzeitig.

Was oft falsch läuft

• „Fünf Jahre für alles." Für langlebige Produkte zu kurz, für kurzlebige unnötig lang, und in beiden Fällen ohne die Begründung, die Anhang VII verlangt.
• Support mit Funktionsupdates verwechseln. Der Zeitraum betrifft Sicherheitsupdates und Schwachstellenbehandlung. Neue Funktionen sind nicht geschuldet, und Sicherheitsupdates sollen, wo technisch möglich, getrennt von Funktionsupdates bereitgestellt werden.
• Das Enddatum nirgends nennen. Anhang II verlangt es in der Nutzerinformation, und es muss zum Zeitpunkt des Kaufs zugänglich sein.
• Den Zeitraum als Ende aller Pflichten verstehen. Die Aufbewahrungspflichten laufen mindestens zehn Jahre, und die Meldepflichten aus Artikel 14 knüpfen im Wortlaut nicht an den Unterstützungszeitraum an. Wer nach dem Ende des Zeitraums von einer aktiv ausgenutzten Schwachstelle erfährt, sollte die Frage der Meldung nicht mit einem Verweis auf das Enddatum abtun.

Was jetzt zu tun ist

1. Erwartete Nutzungsdauer je Produkt bestimmen, aus Erfahrungswerten, Vergleichsprodukten und Kundenverhalten, nicht aus dem Wunsch nach einem kurzen Zeitraum.
2. Zeitraum festlegen und begründen. Datum plus die Überlegung dahinter, in der technischen Dokumentation. Liegt der Zeitraum unter fünf Jahren, die Begründung doppelt sorgfältig.
3. Enddatum in die Nutzerinformation und an den Kaufzeitpunkt bringen, auf die Produktseite, in den Shop, in das Angebot.
4. Lieferverträge prüfen: Welche Komponenten werden wie lange gepflegt, und wer trägt das Risiko danach.
5. Aufbewahrungsfristen anpassen: Bei Zeiträumen über zehn Jahren verlängern sich die Fristen für Dokumentation und Konformitätserklärung mit.
6. Den Zeitraum in das Nachweisregister aufnehmen, mit Enddatum und Begründung, sodass er bei jeder Prüfung vorliegt.

Für den letzten Punkt gibt es einen Weg ohne eigenes Werkzeug: Der Legalithm-Befehl cra support nimmt Enddatum und Begründung in den Nachweis auf und weist einen Zeitraum ohne Begründung zurück, weil ein Datum allein nach Anhang VII nicht genügt. Quelloffen, ohne Konto: Entwicklerwerkzeuge.

Häufig gestellte Fragen

Sind fünf Jahre Pflicht? Fünf Jahre sind die Untergrenze für den Regelfall. Wird das Produkt voraussichtlich kürzer genutzt, darf der Zeitraum kürzer sein. Wird es länger genutzt, muss der Zeitraum das widerspiegeln.

Darf ich den Zeitraum später verlängern oder verkürzen? Verlängern ja; das ist dann ein neues Versprechen an die Nutzer. Verkürzen widerspricht dem genannten Enddatum, auf das Käufer sich verlassen haben, und der Begründung in der technischen Dokumentation. Wer verkürzen will, braucht einen Grund, der die ursprüngliche Begründung überholt, und muss die Nutzer informieren.

Gilt der Zeitraum pro Produkt oder pro Version? Pro Produkt mit digitalen Elementen, so wie es in Verkehr gebracht wurde. Eine wesentlich veränderte Version ist ein neues Inverkehrbringen mit eigenem Zeitraum.

Was ist mit Produkten, die schon auf dem Markt sind? Die Anforderungen von Anhang I und damit der Unterstützungszeitraum gelten für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, nur, wenn sie danach wesentlich verändert werden (Artikel 69 Absatz 2). Die Meldepflichten aus Artikel 14 gelten unabhängig davon ab dem 11. September 2026.

Muss ich Sicherheitsupdates auch nach dem Enddatum bereitstellen? Geschuldet sind sie nur während des Zeitraums. Einmal bereitgestellte Updates müssen aber danach verfügbar bleiben, mindestens zehn Jahre nach dem Inverkehrbringen. Wer freiwillig weiter Updates liefert, tut das außerhalb der Pflicht.

Quellen

• Verordnung (EU) 2024/2847, Artikel 13 Absätze 8 und 9, Artikel 18, Anhang II Nummer 7, Anhang VII Nummer 4, Anhang VIII, deutsche Fassung: eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
• Alle Pflichten des CRA mit Wortlaut: Pflichten aus dem Cyber Resilience Act, insbesondere Pflichten der Hersteller

Dieser Text ist eine zitierte Einordnung, keine Rechtsberatung. Maßgeblich ist der Text der Verordnung.