CRA: Den Supportzeitraum nachvollziehbar herleiten

Das Datenblatt nennt zehn Jahre Support. Die Entwicklungsabteilung fragt sich, wie das eingesetzte Betriebssystem das leisten soll. Der Service plant mit Verlängerungsverträgen für drei Jahre. Die Rechtsabteilung hat die Supportaussage noch nie als regulatorische Pflicht gelesen. Dieses Szenario ist ein strukturelles Problem im Maschinenbau und in der produzierenden Industrie.

Mit dem Cyber Resilience Act (CRA) wird das Marketing-Versprechen zur regulatorischen Herstellerpflicht. Wer einen Supportzeitraum angibt, muss begründen können, wie er zu dieser Zahl kommt, und er muss das Versprechen über den gesamten Zeitraum technisch erfüllen. Eine zu lange Zusage erzeugt Konformitäts- und Haftungsrisiken. Eine zu kurze Zusage schadet der Marktposition. Den richtigen Wert zu finden setzt voraus, Nutzungsprofil, Architektur, Lieferkette und Updatefähigkeit gemeinsam zu betrachten.

Der Supportzeitraum als Herstellerpflicht

Bisher haben viele Hersteller Supportaussagen aus Vertriebssicht festgelegt: Was klingt attraktiv, was macht der Wettbewerb, welche Zahl passt auf die Produktbroschüre? Eine allgemeine Regulierung, die einen nachweisbaren Supportzeitraum fordert, gab es für die meisten Branchen bislang nicht.

In regulierten Branchen ist diese Anforderung allerdings nicht neu. Die EU-Medizinprodukteverordnung (MDR, EU 2017/745) verpflichtet Hersteller, die Lebensdauer eines Produkts selbst festzulegen und zu begründen. Überwachung, Risikomanagement und Dokumentation müssen den gesamten Lebenszyklus abdecken und laufen gesetzlich mindestens zehn Jahre (bei Implantaten fünfzehn Jahre) nach dem letzten Inverkehrbringen. Die UN-Regulationen UNECE R155 und R156 für Fahrzeuge setzen vergleichbare Maßstäbe: Hersteller müssen Cyber Security Management und Software Update Management über den gesamten Fahrzeuglebenszyklus nachweisen, mit Reaktionspflichten noch mindestens zehn Jahre nach dem Ende der Produktion.

Der CRA überträgt dieses Prinzip nun auf Produkte mit digitalen Elementen quer durch alle Branchen. Die Europäische Kommission beschreibt die Herstellerpflichten explizit: Hersteller müssen das Produkt für die erwartete Nutzungsdauer pflegen, den Supportzeitraum angeben und Schwachstellen während dieses Zeitraums behandeln.

Was sich ändert, ist die Natur der Aussage. Der Supportzeitraum wird zum Lieferversprechen. Wer nicht nachweisen kann, dass die genannte Dauer technisch, organisatorisch und über die Lieferkette tragfähig ist, riskiert entweder, das Versprechen zu brechen, oder nachträgliche Einschränkungen vorzunehmen. Beides ist aus Compliance-Sicht problematisch.

Was der CRA konkret verlangt

Der CRA fordert Sicherheit über den gesamten Zeitraum, in dem das Produkt erwartbar genutzt wird, nicht nur bei Auslieferung. Hersteller müssen das Support-Enddatum beim Kauf klar angeben und Schwachstellen während des gesamten Supportzeitraums behandeln. Die meisten Herstellerpflichten gelten ab dem 11. Dezember 2027. Produkte, die ab diesem Datum ohne CRA-konforme CE-Kennzeichnung in der EU verkauft werden, sind nicht zugelassen. Wer heute ein Produkt entwirft, trifft Architekturentscheidungen, die den gesamten Supportzeitraum tragen müssen.

Ein verbreitetes Missverständnis ist, dass die Länge des Supportzeitraums eine freie Wahl des Herstellers ist. Tatsächlich verankert der CRA im Gesetzestext eine Mindestdauer von fünf Jahren, es sei denn, die erwartete Nutzungsdauer ist kürzer. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bestätigt diese Einordnung. Bei Industrieprodukten, die zehn bis fünfzehn Jahre im Feld bleiben, kann die real erwartete Nutzungsdauer deutlich darüber liegen.

Eine wichtige Abgrenzung: Der CRA verlangt kostenlose Security Updates, also Patches, Konfigurationsänderungen und Software-Updates. Hardware-Erneuerung ist keine Updatepflicht, kann aber zur technischen Voraussetzung werden, wenn ein Sicherheitsupdate ohne Komponentenwechsel nicht realisierbar ist. Wer im Rahmen der Komponenten- und Architekturanalyse frühzeitig erkennt, dass ein Sicherheitsupdate ohne Komponentenwechsel langfristig nicht realisierbar sein wird, muss das von Anfang an transparent kommunizieren. Nachträgliche Einschränkungen des ursprünglichen Versprechens sind rechtlich kritisch.

Drei Lebenszyklen, ein Supportzeitraum

Industrieprodukte haben selten einen einheitlichen Lebenszyklus. Typisch sind drei überlagerte Zyklen: der physische Produktlebenszyklus, der Software- und Komponentenlebenszyklus und der Security-Lebenszyklus. Diese drei Zyklen laufen in der Praxis schnell auseinander. Viele eingebettete Betriebssysteme erreichen End of Life (EOL), noch bevor die Maschine abgeschrieben ist. Eine Open-Source-Bibliothek verliert ihren Maintainer. Ein Zulieferer stellt seine API ein.

Der belastbare Supportzeitraum ergibt sich deshalb aus dem konservativsten Schnittpunkt dieser drei Zyklen. Wer diesen Schnittpunkt nicht kennt und trotzdem eine Zahl auf das Datenblatt schreibt, macht eine Aussage, die er möglicherweise nicht einhalten kann.

Ein praxistaugliches Kriterienmodell

Ein wiederholbares Bewertungsmodell übersetzt die drei Lebenszyklen in konkrete Bewertungsdimensionen und schafft so die Grundlage für eine sachliche Ableitung. Der Supportzeitraum ergibt sich als konservativster tragfähiger Wert aus diesen Dimensionen:

Besonders kritisch ist die Dimension Updatefähigkeit. Ohne eine technische Grundlage, Fixes auszurollen, bleibt jeder lange Supportzeitraum ein Versprechen ohne Erfüllungsmechanik. Wie du diese Grundlage schaffst, beschreibt unser Artikel: CRA & Updates: Welche Mechanismen sich für welche Produkte eignen. Um Komponentenverfügbarkeit und Lieferkette systematisch zu bewerten, ist eine gepflegte Software Bill of Materials (SBOM) das zentrale Werkzeug. Den Einstieg in SBOM-Tooling und -Prozesse beschreibt unser Artikel: Governance: Software Bill of Materials (SBOM).

Für jede Dimension schätzt du einen realistischen Zeithorizont. Die Dimension mit dem kürzesten tragfähigen Wert bestimmt deinen Ausgangspunkt.

Für die Feldlebensdauer liefern die AfA-Tabellen des Bundesministeriums der Finanzen einen dokumentierten Ausgangswert: Die betriebsgewöhnliche Nutzungsdauer ist zwar eine steuerliche Größe, entspricht aber in der Regel einem anerkannten Mindestwert für die erwartete Einsatzdauer. Im Maschinenbau liegt die tatsächliche Feldlebensdauer häufig darüber.

Liegt dieser Ausgangspunkt unterhalb deines Ziel-Supportzeitraums, hast du eine Lücke. Um diese Lücke zu schließen, gibt es grundsätzlich zwei Wege: Entweder verlängerst du die einschränkende Dimension aktiv, zum Beispiel durch einen geplanten Komponentenwechsel oder durch Architekturmaßnahmen, die das Risiko der nicht mehr aktualisierbaren Komponente kompensieren, etwa durch Netzwerksegmentierung, Isolation per Firewall oder den Entzug von Remotezugriff. Oder du dokumentierst die Lücke als begründete Einschränkung, kommunizierst sie transparent und passt den Ziel-Supportzeitraum entsprechend an. Wie das in der Praxis aussieht und welche Strategien dabei helfen, zeigt das folgende Szenario aus dem Maschinenbau.

Wenn Hardware länger lebt als Software

Das Auseinanderlaufen von Maschinenlaufzeit und Software-Supportzeitraum ist der Normalfall im Maschinenbau. Eine Maschine bleibt oft 15 Jahre und mehr im Feld. Der Hersteller plant den Software-Support für zehn Jahre. Wie lange das Betriebssystem des eingebauten IPC (Industrie-PC) dabei mitspielt, hängt stark von der OS-Wahl ab. Windows IoT Enterprise LTSC bietet nach der Fixed Lifecycle Policy bis zu zehn Jahre Security-Support. Das klingt komfortabel, lässt bei einer 15-jährigen Maschine aber dennoch eine Lücke von fünf Jahren. Wer keinen dedizierten IoT-Kanal einsetzt, steht oft noch früher ohne Patches da. Ohne Gegenmaßnahmen bestimmt die kurzlebigste Komponente den effektiven Supportzeitraum, unabhängig davon, was auf dem Datenblatt steht. Wichtig ist dabei: Der Hersteller bleibt verantwortlich, auch wenn die Engpass-Komponente von einem Zulieferer stammt.

Der CRA-konforme Supportzeitraum muss technisch vollständig haltbar sein: Sicherheitsupdates müssen kostenlos und ohne unzumutbare Verzögerung bereitgestellt werden, vom ersten bis zum letzten Tag. Drei Strategien helfen, dieses Ziel auch bei langen Maschinenlaufzeiten zu erreichen:

Hard Limit

Beim Hard Limit begrenzt du den Supportzeitraum auf das EOL der schwächsten Komponente. Diese Strategie ist rechtlich sauber und einfach umzusetzen, für viele Maschinenbauer aber nicht marktfähig.

Zu beachten: Das Hard Limit darf nie unter fünf Jahren liegen, denn das ist die gesetzliche Mindestdauer laut CRA. Wenn eine zugekaufte Drittkomponente, etwa eine kommerzielle Bibliothek oder ein SDK, keinen Support über diesen Zeitraum hinaus bietet, muss gehandelt werden. Entweder wird die Komponente durch eine Alternative mit ausreichendem Support-Commitment ersetzt, oder der Hersteller schließt mit dem Anbieter eine vertragliche Vereinbarung, die mindestens fünf Jahre Sicherheits-Support absichert. Eine Drittkomponente ohne nachweisbaren Support-Zeitraum ist für ein CRA-konformes Produkt keine akzeptable Wahl.

Geplanter Plattformwechsel

Der Austausch einer Teilkomponente wird als fester Bestandteil des Produktdesigns eingeplant. Das erfordert ein Austauschkonzept, Migrationsfähigkeit und definierte Serviceprozesse.

Architekturtrennung

Kurzlebige Komponenten wie ein HMI (Human Machine Interface) oder Laptop werden vom Produktkern entkoppelt und kommunizieren über stabile Schnittstellen. Ob eine solche Komponente tatsächlich außerhalb des CRA-Scopes des Kernprodukts liegt, hängt davon ab, wie das Gesamtsystem auf dem Markt platziert und beworben wird. Das erfordert eine rechtliche Einzelfallprüfung und ist nicht allein durch Architekturentscheidungen sichergestellt.

Der entscheidende Gedanke hinter allen drei Strategien: Der kommunizierte Supportzeitraum muss technisch vollständig haltbar sein. Was auf dem Datenblatt steht, gilt.

Belastbare Begründung in der Dokumentation

Die folgende Vorlage überträgt die Anforderungen aus dem CRA-Text in ein kompaktes Dokumentationsmuster am Beispiel einer industriellen Steuerungseinheit:

• Produkt: Industrielle Steuerungseinheit XYZ
• Festgelegter Supportzeitraum: 8 Jahre ab Inverkehrbringen (Herleitung auf Basis von Feldlebensdauer, Komponentenverfügbarkeit und Updatefähigkeit)
• Feldlebensdauer: 12 Jahre (betriebsgewöhnliche Nutzungsdauer laut AfA: 10 Jahre)
• Softwarebasis: Windows IoT Enterprise LTSC; 10 Jahre Security-Support durch Microsoft ab LTSC-Release; deckt den Supportzeitraum von 8 Jahren ab, sofern das verwendete LTSC-Release nicht älter als 2 Jahre zum Zeitpunkt des Inverkehrbringens ist
• IPC-Plattform: Hersteller-Support für das verwendete Board bis Jahr 8 schriftlich zugesichert; Hardware-EOL ist die bindende Grenze für den Supportzeitraum
• Updatefähigkeit: Remote-Update über validierten OTA-Prozess; Rollout-Fähigkeit getestet und dokumentiert
• Lieferkette: Alle sicherheitsrelevanten Drittkomponenten mit schriftlich zugesichertem Support bis mindestens Jahr 8
• Einschränkungen: Nach Ablauf des Supportzeitraums ist für den sicheren Weiterbetrieb ein Hardware-Refresh oder Plattformwechsel erforderlich. Diese Voraussetzung ist Bestandteil der Produktdokumentation und wird beim Kauf kommuniziert.

Ergänzend sollten die Annahmen, Restrisiken, der Prüfintervall und die Trigger für eine Neubewertung dokumentiert sein.

Supportfähigkeit als Architekturprinzip

Der Supportzeitraum entsteht nicht in der Produktbroschüre, sondern in der Produktdefinition, der Architektur und dem Lieferantenmanagement. Eine belastbare Governance-Regel lautet daher: Keine externe Supportaussage ohne dokumentierte Herleitung und einen klar benannten Verantwortlichen für die Nachpflege. Produktmanagement, Entwicklung, Service, Einkauf und Rechtsabteilung sollten die Zahl gemeinsam freigeben, bevor sie nach außen geht.

Wer den Supportzeitraum sauber herleitet, schafft Compliance-Sicherheit. Gleichzeitig wird intern sichtbar, welche Architekturentscheidungen, Lieferantenverträge und organisatorischen Strukturen notwendig sind, um das Versprechen einzuhalten.

Re-Assessments sind ein strukturierter Pflichtschritt. Neue Schwachstellen, EOL-Ankündigungen von Kerntechnologien, Lieferkettenwechsel oder Architekturänderungen sind jeweils konkrete Auslöser. Wer diese Neubewertung fest in seinen Entwicklungsprozess integriert, reduziert Compliance-Risiken und vermeidet Folgekosten. Gleichzeitig baut er Vertrauen bei Kunden und Marktüberwachungsbehörden auf.

Wie gehst du in deinem Unternehmen mit der technischen Grundlage für Supportzusagen um? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.