CRA-Supportzeitraum: Wie lange Hersteller Sicherheitsupdates bereitstellen müssen

Der CRA-Supportzeitraum ist die Zeit, in der ein Hersteller Schwachstellen seines Produkts mit digitalen Elementen wirksam behandeln und Sicherheitsupdates bereitstellen muss. Grundsätzlich beträgt dieser Zeitraum mindestens fünf Jahre. Wird ein Produkt voraussichtlich kürzer als fünf Jahre genutzt, kann der Supportzeitraum dieser kürzeren erwarteten Nutzungsdauer entsprechen. Wird ein Produkt typischerweise deutlich länger genutzt, kann auch ein längerer Supportzeitraum erforderlich sein.

Der Supportzeitraum ist damit keine frei gewählte Marketingangabe. Hersteller müssen ihn nachvollziehbar bestimmen, dokumentieren und in ihre Produkt-, Entwicklungs- und Wartungsprozesse einbauen. Den Gesamtzusammenhang aus Produktpflichten, Fristen und Konformität erklärt unser Leitfaden zum Cyber Resilience Act. Die allgemeinen Pflichten des Herstellers sind zusätzlich im Beitrag zu den CRA-Herstellerpflichten zusammengefasst.

Was bedeutet Supportzeitraum im Cyber Resilience Act?

Der Supportzeitraum beschreibt nach dem CRA den Zeitraum, in dem der Hersteller sicherstellen muss, dass Schwachstellen eines Produkts mit digitalen Elementen effektiv behandelt werden. Dazu gehören nicht nur das Erkennen neuer Sicherheitsprobleme, sondern auch Bewertung, Behebung, Bereitstellung von Sicherheitsupdates, Kommunikation mit Nutzern und die Pflege der dafür erforderlichen Prozesse.

Der Begriff ist deshalb weiter als die klassische Garantiezeit oder der Zeitraum, in dem ein Hersteller normalen Kundensupport anbietet. Ein Unternehmen kann beispielsweise den telefonischen Produktsupport reduzieren, während die gesetzlich erforderliche Behandlung von Sicherheitslücken weiterlaufen muss.

Ist der Supportzeitraum dasselbe wie Garantie oder Gewährleistung?

Nein. Garantie, gesetzliche Gewährleistung und CRA-Supportzeitraum verfolgen unterschiedliche Ziele. Der CRA betrachtet die Cybersicherheit des Produkts über dessen erwartete Nutzungsdauer. Maßgeblich ist also nicht, wie lange ein Händler freiwillig Garantie gibt, sondern wie lange das Produkt realistischerweise genutzt wird und wie lange Sicherheitsrisiken behandelt werden müssen.

Wie lang muss der CRA-Supportzeitraum mindestens sein?

Der CRA sieht grundsätzlich einen Mindestzeitraum von fünf Jahren vor. Wird vernünftigerweise erwartet, dass ein Produkt mit digitalen Elementen weniger als fünf Jahre im Einsatz ist, kann der Supportzeitraum der kürzeren erwarteten Nutzungsdauer entsprechen. Umgekehrt bedeutet die Fünf-Jahres-Regel nicht, dass nach fünf Jahren immer Schluss sein darf.

Bei Produkten, die typischerweise länger eingesetzt werden, muss der Hersteller die längere Nutzung berücksichtigen. Das betrifft beispielsweise Netzwerkgeräte, Hardwarekomponenten, Betriebssysteme, professionelle Software oder industrielle Systeme. Der offizielle CRA-Rechtstext auf EUR-Lex nennt für die Bestimmung unter anderem Nutzererwartungen, Produktart, Zweckbestimmung, vergleichbare Produkte, Betriebsumgebung und Supportzeiträume wesentlicher Drittkomponenten.

Darf ein Hersteller einfach fünf Jahre ansetzen?

Nur wenn fünf Jahre zur realistischen Nutzung des Produkts passen. Eine pauschale Unternehmensregel wie „Alle Produkte erhalten genau fünf Jahre“ kann bei kurzlebigen und langlebigen Produkten gleichermaßen problematisch sein. Der CRA verlangt eine produktbezogene, verhältnismäßige Begründung.

Kann der Supportzeitraum kürzer als fünf Jahre sein?

Ja, wenn das Produkt voraussichtlich weniger als fünf Jahre genutzt wird. Diese Ausnahme sollte aber belastbar begründet werden. Ein zeitlich befristetes Produkt oder eine Anwendung, die nach einem klar definierten Zeitraum technisch nicht mehr nutzbar ist, kann anders bewertet werden als ein Router, eine Steuerung oder eine Desktopsoftware, die Nutzer regelmäßig viele Jahre betreiben.

Wie bestimmt ein Hersteller die erwartete Nutzungsdauer?

Eine belastbare Bestimmung beginnt nicht bei der Rechtsabteilung, sondern bei Produkt und Nutzung. Hersteller sollten dokumentieren, wie Kunden das Produkt tatsächlich einsetzen, welche technischen Abhängigkeiten bestehen und welche Lebensdauer vergleichbare Produkte haben.

Für die interne Prüfung eignen sich insbesondere folgende Fragen:

• Wie lange bleibt das Produkt technisch nutzbar?
• Welche Nutzungsdauer erwarten Kunden bei dieser Produktart?
• Gibt es Hardwareverschleiß oder technische Grenzen?
• Wie lange bleiben Betriebssystem, Laufzeitumgebung oder Cloud-Anbindung verfügbar?
• Wie lange werden kritische Drittkomponenten unterstützt?
• Wie lange werden vergleichbare Produkte am Markt typischerweise gepflegt?
• Gibt es branchenspezifische oder andere EU-rechtliche Vorgaben zur Lebensdauer?
• Wird das Produkt in Industrie, Infrastruktur oder anderen langlebigen Umgebungen eingesetzt?

Diese Antworten sollten nicht nur in einem Meeting besprochen werden. Sie gehören in die nachvollziehbare Dokumentation des Produkts und müssen mit der technischen Realität übereinstimmen.

Welche Rolle spielen Drittkomponenten beim Supportzeitraum?

Drittkomponenten können die Lebenszyklusplanung erheblich beeinflussen. Ein Produkt kann nur dann verlässlich gepflegt werden, wenn zentrale Bibliotheken, Betriebssysteme, Chipsätze, Frameworks oder andere Kernkomponenten ebenfalls ausreichend lange unterstützt werden oder vom Hersteller ersetzt werden können.

Deshalb sollte die Supportplanung bereits bei Architektur und Einkauf beginnen. Ein Produkt, das sieben Jahre unterstützt werden soll, sollte nicht von einer Kernkomponente abhängen, deren Hersteller nach zwei Jahren alle Sicherheitsupdates einstellt, ohne dass eine Ersatzstrategie existiert.

Hier entsteht eine direkte Verbindung zur Software-Lieferkette und zur Nutzung von Open-Source-Komponenten unter dem CRA. Open Source ist nicht automatisch ein Risiko, aber Abhängigkeiten müssen bekannt sein und während des Supportzeitraums überwacht werden.

Was muss während des Supportzeitraums passieren?

Der Hersteller muss während des Supportzeitraums einen funktionsfähigen Prozess für Schwachstellen unterhalten. Dazu gehört wesentlich mehr als das gelegentliche Installieren eines Patches.

Schwachstellen müssen fortlaufend erkannt werden

Hersteller benötigen einen Prozess, der neue Schwachstellen in eigenen und fremden Komponenten erkennt. Quellen können interne Tests, Security Researcher, Kunden, Lieferanten, CVE-Datenbanken, Security Advisories oder andere Meldungen sein.

Schwachstellen müssen bewertet und behoben werden

Nicht jede gefundene Schwachstelle hat dieselbe Bedeutung. Hersteller müssen prüfen, ob das eigene Produkt tatsächlich betroffen ist, wie hoch das Risiko ist und welche Korrektur erforderlich ist. Diese Arbeit hängt eng mit der produktbezogenen Cybersicherheitsrisikobewertung zusammen.

Sicherheitsupdates müssen bereitgestellt werden

Wenn eine Korrektur notwendig ist, muss der Hersteller einen geeigneten Sicherheitsupdate-Prozess haben. Dabei geht es auch um Integrität, Authentizität, sichere Auslieferung und verständliche Informationen an die Nutzer.

Meldepflichtige Fälle brauchen einen eigenen Eskalationsweg

Ab dem 11. September 2026 gelten die vorgezogenen CRA-Meldepflichten. Erkennt ein Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schweren Sicherheitsvorfall, reicht der normale Patchprozess nicht. Dann greifen die kurzen Meldefristen. Unser Beitrag zu den CRA-Meldepflichten erklärt den 24- und 72-Stunden-Ablauf im Detail.

Wie lange müssen Sicherheitsupdates verfügbar bleiben?

Der CRA enthält zusätzlich eine wichtige Verfügbarkeitsregel: Sicherheitsupdates, die während des Supportzeitraums bereitgestellt werden, müssen nach ihrer Veröffentlichung grundsätzlich mindestens zehn Jahre oder für den verbleibenden Supportzeitraum verfügbar bleiben – je nachdem, welcher Zeitraum länger ist.

Das ist organisatorisch relevant. Hersteller sollten nicht nur einen Update-Server betreiben, sondern auch festlegen, wie Sicherheitsupdates langfristig archiviert, versioniert und Nutzern zuverlässig bereitgestellt werden. Ein Produktportal, Downloadbereich oder Update-Dienst darf nicht ohne Migrationsplan abgeschaltet werden, wenn die gesetzlich geforderte Verfügbarkeit dadurch verloren geht.

Muss der Supportzeitraum dokumentiert werden?

Ja. Der Hersteller muss die Informationen, die er zur Bestimmung des Supportzeitraums berücksichtigt hat, in die technische Dokumentation aufnehmen. Eine reine Zahl ohne Begründung ist daher keine saubere Lösung.

Eine gute interne Dokumentation enthält mindestens:

• Produkt und relevante Version oder Produktfamilie,
• festgelegten Supportzeitraum mit Start- und Endpunkt,
• erwartete Nutzungsdauer und deren Begründung,
• relevante Markt- und Nutzererwartungen,
• Abhängigkeiten von Betriebssystemen und Drittkomponenten,
• Vergleich mit ähnlichen Produkten, soweit sinnvoll,
• besondere Einsatzumgebungen,
• Verantwortliche für die Entscheidung,
• Verknüpfung mit Risikoanalyse und Wartungsplan.

Diese Unterlagen gehören in den größeren Nachweisrahmen der CRA-Konformitätsbewertung und technischen Dokumentation.

Wann beginnt der Supportzeitraum?

Für die operative Planung sollten Hersteller den Beginn eindeutig an die Markteinführung und das konkrete Produkt beziehungsweise die Produktversion koppeln. Schwieriger wird es bei kontinuierlich weiterentwickelter Software, SaaS-nahen Produktkomponenten oder Produktfamilien mit häufigen Releases.

In solchen Fällen sollte das Unternehmen definieren, ob der Support für einzelne Major-Versionen, Produktgenerationen oder eine kontinuierliche Produktlinie organisiert wird. Entscheidend ist, dass Kunden und interne Teams klar erkennen können, welche Version wie lange sicherheitsrelevant gepflegt wird.

Was passiert am Ende des Supportzeitraums?

Das Supportende sollte kein überraschender technischer Abbruch sein. Der CRA verlangt, soweit dies angesichts der Produktart technisch machbar ist, eine Mitteilung an Nutzer, wenn das Ende des Supportzeitraums erreicht ist.

In der Praxis empfiehlt sich ein geplanter End-of-Support-Prozess mit frühzeitiger Kommunikation. Nutzer sollten verstehen, ab wann keine Sicherheitskorrekturen mehr bereitgestellt werden und welche sichere Alternative existiert. Je nach Produkt kann das ein Upgrade, Austausch, Migrationspfad oder die Stilllegung einer unsicheren Funktion sein.

Reicht ein Hinweis in alten AGB?

Ein versteckter oder schwer verständlicher Hinweis ist kein guter Prozess. Der Supportzeitraum sollte bereits beim Kauf beziehungsweise bei der Produktinformation nachvollziehbar sein und am Ende aktiv kommuniziert werden. Das reduziert Sicherheitsrisiken und vermeidet Missverständnisse.

Welche typischen Fehler machen Unternehmen beim CRA-Supportzeitraum?

Der häufigste Fehler ist, Support nur als wirtschaftliche Entscheidung zu betrachten. Unter dem CRA wird er Teil der Cybersicherheits- und Konformitätsstrategie.

• Pauschal fünf Jahre: Die reale Nutzungsdauer wird nicht geprüft.
• Keine Komponentenplanung: Kritische Abhängigkeiten verlieren früher ihren Support.
• Kein Budget: Produktentwicklung endet, aber Security-Arbeit bleibt erforderlich.
• Unklare Versionen: Niemand weiß, welche Produktgeneration bis wann gepflegt wird.
• Keine Update-Infrastruktur: Sicherheitsupdates können nicht langfristig zuverlässig ausgeliefert werden.
• Keine End-of-Support-Kommunikation: Nutzer betreiben Produkte weiter und rechnen mit Schutz.
• Fehlende Dokumentation: Die festgelegte Dauer ist gegenüber Prüfern nicht begründbar.

Wie baut man den Supportzeitraum in den Entwicklungsprozess ein?

Am wirksamsten ist eine Entscheidung bereits vor dem Produktrelease. Produktmanagement, Entwicklung, Security, Einkauf und Support sollten gemeinsam festlegen, wie lange das Produkt sicher gepflegt werden kann und muss.

Ein praxistauglicher Ablauf sieht so aus:

1. Produkt und vorgesehenen Einsatz beschreiben.
2. Erwartete Nutzungsdauer bestimmen.
3. Kritische Komponenten und deren Supportfenster prüfen.
4. Supportzeitraum begründen und freigeben.
5. Ressourcen für Vulnerability Management und Updates einplanen.
6. Update- und Kommunikationswege testen.
7. Supportzeitraum in technische Dokumentation und Nutzerinformationen übernehmen.
8. Während des Lebenszyklus regelmäßig prüfen, ob Annahmen noch stimmen.
9. End-of-Support rechtzeitig vorbereiten und kommunizieren.

Diese Arbeit sollte nicht isoliert erfolgen. Die CRA-Fristen bis zur Vollanwendung 2027 geben den äußeren Zeitrahmen vor; die Herstellerpflichten und die Konformitätsbewertung bestimmen, welche Nachweise für das Produkt benötigt werden.

Wie sollte der Supportzeitraum wirtschaftlich eingeplant werden?

Der CRA-Supportzeitraum erzeugt reale Kosten nach dem Verkauf. Hersteller müssen deshalb schon bei Produktkalkulation und Geschäftsmodell berücksichtigen, dass Security-Monitoring, Schwachstellenbewertung, Patchentwicklung, Tests, Update-Infrastruktur und Kundenkommunikation über Jahre weiterlaufen können.

Wer den Produktpreis nur anhand von Entwicklung und Markteinführung kalkuliert, unterschätzt die Lebenszykluskosten. Besonders bei günstiger Hardware oder einmalig verkaufter Software kann ein langer Supportzeitraum wirtschaftlich relevant werden.

Welche Kostenblöcke sollten berücksichtigt werden?

• Monitoring neuer Schwachstellen und Advisories,
• Pflege von SBOM und Komponentenübersicht,
• Security-Analyse und Incident Response,
• Entwicklung und Test von Sicherheitsupdates,
• Betrieb von Update- und Download-Infrastruktur,
• Pflege älterer Produktversionen,
• Kommunikation mit Nutzern und Partnern,
• Dokumentation und regulatorische Nachweise.

Kann ein Hersteller Support vertraglich an einen Dienstleister auslagern?

Technische Tätigkeiten können ausgelagert werden, die regulatorische Verantwortung des Herstellers verschwindet dadurch aber nicht. Verträge mit Entwicklungs- oder Security-Dienstleistern sollten deshalb Reaktionszeiten, Informationspflichten, Zugriff auf Quellcode und Build-Systeme, Patchfähigkeit und Übergaberechte eindeutig regeln.

Wie sollte das Ende des Supports geplant werden?

Ein belastbarer End-of-Support-Prozess beginnt deutlich vor dem letzten Tag. Das Unternehmen sollte festlegen, wann Nutzer informiert werden, wie lange letzte Sicherheitsupdates verfügbar bleiben und welche sichere Alternative angeboten wird.

Für vernetzte Geräte kann auch die Frage wichtig sein, ob Cloud-Dienste, APIs oder Zertifikate nach Supportende weiterlaufen. Werden zentrale Dienste abgeschaltet, sollte geklärt sein, ob das Produkt dadurch unbrauchbar oder unsicher wird. Diese Entscheidung gehört in Produktplanung und Nutzerkommunikation.

Was ist bei Unternehmenskunden wichtig?

B2B-Kunden planen Geräte und Software häufig über längere Investitionszyklen. Wenn ein Produkt technisch acht oder zehn Jahre eingesetzt wird, kann ein sehr kurzer Security-Support nicht einfach mit internen Produktzyklen begründet werden. Erwartete Nutzung und vertragliche Zusagen sollten deshalb früh abgeglichen werden.

Was sollten Hersteller im September 2026 konkret tun?

Unternehmen, die den Supportzeitraum bislang nur als späteres 2027-Thema behandelt haben, sollten jetzt eine Produktinventur starten. Gleichzeitig gelten ab 11. September 2026 bereits die Meldepflichten. Dadurch werden funktionierende Schwachstellen- und Incident-Prozesse schon jetzt praktisch relevant.

Für jedes Produkt sollte klar sein, wer verantwortlich ist, welche Komponenten enthalten sind, welche Versionen im Feld stehen und wie Sicherheitsprobleme an Kunden ausgeliefert werden. Wer diese Grundlagen heute aufbaut, reduziert den Aufwand für die vollständige CRA-Konformität erheblich.