Der Unterstützungszeitraum nach dem Cyber Resilience Act: Warum Hersteller für die Sicherheit ihrer Produkte über Jahre verantwortlich bleiben

Viele Hersteller denken bei der Produktsicherheit an den Zeitpunkt des Inverkehrbringens. Wird die Software ausgeliefert und funktioniert sie ordnungsgemäß, scheint die Arbeit erledigt zu sein.

Genau diese Sichtweise stellt der Cyber Resilience Act (CRA) auf den Kopf.

Die Cyberresilienz-Verordnung verlangt nicht nur sichere Produkte bei Markteinführung, sondern verpflichtet Hersteller, während eines definierten Unterstützungszeitraums aktiv für die Cybersicherheit ihrer Produkte zu sorgen. Die Verantwortung endet daher nicht mit dem Verkauf, sondern begleitet das Produkt über weite Teile seines Lebenszyklus.

Der Unterstützungszeitraum als „Wartungsvertrag des Gesetzgebers"

Zur Veranschaulichung kann man den Unterstützungszeitraum mit einer gesetzlichen Wartungszusage vergleichen.

Wer heute einen Router, eine industrielle Steuerungsanlage oder ein Softwareprodukt erwirbt, erwartet zu Recht, dass neu entdeckte Sicherheitslücken nicht einfach ignoriert werden. Genau diese Erwartung greift der europäische Gesetzgeber auf.

Der Unterstützungszeitraum beschreibt jene Dauer, für die der Hersteller die wirksame Behandlung von Schwachstellen sicherstellen muss. Ziel ist es, die Cybersicherheit während des gesamten vorhersehbaren Produktlebenszyklus zu gewährleisten.

Anders ausgedrückt: Ein Produkt darf nicht deshalb unsicher werden, weil der Hersteller nach kurzer Zeit das Interesse daran verliert.

Fünf Jahre sind künftig die Messlatte

Der CRA legt einen klaren Grundsatz fest: Der Unterstützungszeitraum muss der voraussichtlichen Nutzungsdauer des Produkts entsprechen und beträgt grundsätzlich mindestens fünf Jahre. Dabei sind insbesondere die Erwartungen der Nutzer, die Produktart und einschlägige technische Standards zu berücksichtigen.

Die oft zitierte Fünfjahresregel wird jedoch häufig missverstanden.

Der CRA schreibt nicht vor, dass jedes Produkt exakt fünf Jahre unterstützt werden muss. Vielmehr handelt es sich um eine Untergrenze. Wird ein Produkt typischerweise wesentlich länger verwendet, muss auch der Unterstützungszeitraum länger angesetzt werden.

Praxisbeispiele

Einige typische Beispiele verdeutlichen die Konsequenzen:

Router und Netzwerkkomponenten

Viele Unternehmen nutzen Router oder Switches deutlich länger als fünf Jahre. In solchen Fällen könnte ein deutlich längerer Unterstützungszeitraum erforderlich sein.

Industriesteuerungen

Produktionsanlagen werden häufig zehn bis fünfzehn Jahre betrieben. Hersteller werden sich schwer tun, einen bloß fünfjährigen Unterstützungszeitraum überzeugend zu begründen.

Betriebssysteme und Unternehmenssoftware

Gerade im B2B-Bereich werden Softwarelösungen oftmals über viele Jahre genutzt und aktualisiert. Auch hier kann ein längerer Zeitraum sachgerecht sein.

Kurzfristige Spezialanwendungen

Denkbar sind auch Produkte mit naturgemäß kurzer Lebensdauer. In solchen Ausnahmefällen kann der Unterstützungszeitraum unter fünf Jahren liegen, wenn die tatsächliche Nutzungsdauer entsprechend kürzer ist.

Welche Pflichten bestehen während des Unterstützungszeitraums?

Der Unterstützungszeitraum ist kein bloßer Hinweis auf der Verpackung.

Vielmehr entstehen daraus konkrete Pflichten für den Hersteller.

Sicherheitsupdates müssen bereitgestellt werden

Werden Sicherheitslücken entdeckt, müssen diese wirksam behandelt werden. In der Praxis bedeutet dies regelmäßig die Bereitstellung von Sicherheitsupdates oder anderen geeigneten Abhilfemaßnahmen.

Besonders bedeutsam ist dabei die Vorgabe des CRA, dass Sicherheitsaktualisierungen grundsätzlich kostenlos zur Verfügung gestellt werden müssen. Das wird zahlreiche bisherige Geschäftsmodelle vor neue Herausforderungen stellen.

Die Festlegung muss dokumentiert werden

Hersteller können die Dauer des Unterstützungszeitraums nicht willkürlich festlegen.

Vielmehr müssen die herangezogenen Kriterien dokumentiert werden. Dazu zählen insbesondere:

• die erwartete Nutzungsdauer,
• die Art des Produkts,
• berechtigte Nutzererwartungen,
• technische Normen und Branchenstandards,
• die übliche Lebensdauer vergleichbarer Produkte.

Diese Überlegungen sind Teil der technischen Dokumentation und müssen gegenüber Behörden nachvollziehbar sein.

Transparenz gegenüber den Nutzern

Der Unterstützungszeitraum darf nicht im Kleingedruckten versteckt werden.

Nutzer sollen bereits vor dem Kauf erkennen können, wie lange Sicherheitsupdates bereitgestellt werden. Der Hersteller muss diese Information daher klar und verständlich kommunizieren.

Gerade bei Softwareprodukten dürfte dies künftig auch wettbewerbliche Bedeutung erlangen. Ein Anbieter, der zehn Jahre Sicherheitsupdates garantiert, schafft deutlich mehr Vertrauen als ein Konkurrent mit einem wesentlich kürzeren Zeitraum.

Was passiert nach Ablauf des Unterstützungszeitraums?

Der CRA zwingt Hersteller nicht dazu, ein Produkt unbegrenzt zu unterstützen.

Dennoch enthält die Verordnung interessante Anreize für einen längeren Sicherheitslebenszyklus.

So erwähnt der Gesetzgeber ausdrücklich die Möglichkeit, den Quellcode nach Ablauf des Unterstützungszeitraums anderen Unternehmen oder der Öffentlichkeit zugänglich zu machen. Dadurch könnten Sicherheitsupdates künftig etwa durch Dritte oder durch die Open-Source-Community weiterentwickelt werden.

Aus Sicht des Gesetzgebers soll damit vermieden werden, dass Produkte unmittelbar nach Ende des offiziellen Supports zu Sicherheitsrisiken werden.

Zehn Jahre Archivierungspflicht für Sicherheitsupdates

Eine wenig bekannte, aber äußerst praxisrelevante Bestimmung betrifft die langfristige Verfügbarkeit von Sicherheitsaktualisierungen.

Sicherheitsupdates, die während des Unterstützungszeitraums bereitgestellt werden, müssen archiviert und weiterhin verfügbar gehalten werden. Dies soll gewährleisten, dass auch Nutzer verspätet installierter Systeme noch auf wichtige Sicherheitskorrekturen zugreifen können.

Für Hersteller bedeutet dies zusätzliche Anforderungen an Dokumentation, Release-Management und Software-Repositorys.

Besondere Herausforderungen für Open-Source-Komponenten

Der CRA nimmt ausdrücklich Bezug auf Open-Source-Software.

Da moderne Softwareprodukte regelmäßig Open-Source-Komponenten enthalten, müssen Hersteller Prozesse etablieren, um Schwachstellen auch in diesen Komponenten zu erkennen, zu bewerten und zu behandeln. Gleichzeitig werden Verwalter quelloffener Software in bestimmten Konstellationen ebenfalls in den regulatorischen Rahmen einbezogen.

Gerade die Abhängigkeit von externen Open-Source-Projekten wird dadurch zu einem Compliance-Thema.

Warum Unternehmen bereits heute handeln sollten

Viele Unternehmen betrachten den CRA noch immer primär als technisches Regelwerk.

Tatsächlich handelt es sich um ein Produktsicherheitsgesetz für das digitale Zeitalter.

Der Unterstützungszeitraum wird dabei zu einer der zentralen organisatorischen Herausforderungen. Hersteller müssen künftig bereits während der Produktentwicklung überlegen:

• Wie lange wird das Produkt realistischerweise genutzt?
• Welche Ressourcen sind für Sicherheitsupdates erforderlich?
• Wer überwacht neue Schwachstellen?
• Wie werden Updates verteilt?
• Wann endet der Support tatsächlich?

Wer diese Fragen erst nach dem Inverkehrbringen beantwortet, wird die Anforderungen des CRA nur schwer erfüllen können.

Fazit

Der Unterstützungszeitraum ist weit mehr als eine Informationspflicht.

Er bildet das Herzstück des CRA-Gedankens, wonach Cybersicherheit kein einmaliger Zustand, sondern ein fortlaufender Prozess ist. Hersteller müssen künftig nicht nur sichere Produkte entwickeln, sondern auch über Jahre hinweg für deren Sicherheit Verantwortung übernehmen.

Für Unternehmen bedeutet das einen Paradigmenwechsel: Der Verkauf eines Produkts markiert nicht mehr das Ende der Verantwortung, sondern vielfach erst den Beginn eines langfristigen Sicherheitsversprechens.

‍