CRA-Unterstützungszeiträume: das Enddatum auf eine dokumentierte Entscheidung zurückführen

Der Cyber Resilience Act verlangt von Herstellern, einen Unterstützungszeitraum für Produkte mit digitalen Elementen festzulegen. Das ist kein nachträglich ausgefülltes „EOL“-Feld. Die Entscheidung bestimmt unter anderem, wie lange eine wirksame Schwachstellenbehandlung fortgesetzt werden muss. Ihre Begründung muss in die technische Dokumentation aufgenommen werden.

Grundsätzlich beträgt der Unterstützungszeitraum mindestens fünf Jahre. Wird erwartet, dass ein Produkt weniger als fünf Jahre genutzt wird, entspricht der Unterstützungszeitraum dieser erwarteten Nutzungsdauer.

Im CRA festgelegte Kriterien

Der Hersteller muss insbesondere berücksichtigen:

• berechtigte Erwartungen der Nutzer;
• die Art des Produkts;
• seine Zweckbestimmung;
• einschlägiges EU-Recht, das die Lebensdauer des Produkts bestimmt.

Der CRA erlaubt außerdem die Berücksichtigung von:

• Unterstützungszeiträumen von Produkten mit ähnlicher Funktionalität;
• Verfügbarkeit der Betriebsumgebung;
• Unterstützungszeiträumen integrierter Drittanbieterkomponenten, die Kernfunktionen bereitstellen;
• einschlägigen Leitlinien der Kommission und der ADCO.

Die Kriterien müssen verhältnismäßig angewendet werden.

Beginnen Sie nicht mit dem Datum

Ein schwacher Prozess beginnt mit:

„Tragen wir fünf Jahre ein, weil das im CRA steht.“

Ein stärkerer Prozess beginnt mit den Annahmen:

1. Wie lange werden Nutzer berechtigterweise erwarten, das Produkt zu verwenden?
2. Wie lange können zentrale Abhängigkeiten unterstützt werden?
3. Welchen Lebenszyklus haben die Hardware oder die Betriebsumgebung?
4. Wird das Produkt in einer industriellen oder anderen Umgebung eingesetzt, in der die praktische Lebensdauer länger ist?
5. Welche Verpflichtungen folgen aus Verträgen und anderem anwendbarem Recht?
6. Kann der Prozess für Sicherheitsupdates über den gewählten Zeitraum realistisch aufrechterhalten werden?

Genehmigen Sie das Enddatum erst, nachdem diese Fragen berücksichtigt wurden.

Nachweise für die Entscheidung

Eine Mindestaufzeichnung kann Folgendes enthalten:

Feld	Beispielinhalt
Produkt / Fassung	Eindeutige Identifikation
Entscheidungsdatum	Wann der Unterstützungszeitraum genehmigt wurde
Enddatum	Mindestens Monat und Jahr
Erwartete Nutzungsdauer	Annahme + Quelle
Nutzererwartungen	Verträge, Produktdaten, Marktnachweise
Zentrale Abhängigkeiten	Unterstützungszeiträume Dritter
Betriebsumgebung	Erforderliche Systeme/Plattformen
Rechts-/Leitliniengrundlage	Bei der Entscheidung verwendete Quellen
Genehmigende Person	Verantwortliche Person/Rolle
Prüftermin	Wann Annahmen erneut geprüft werden

Nutzer benötigen ein klares Datum für das Unterstützungsende

Artikel 13 verlangt, dass das Enddatum des Unterstützungszeitraums — mindestens Monat und Jahr — zum Kaufzeitpunkt klar und verständlich in leicht zugänglicher Form und gegebenenfalls auf dem Produkt, der Verpackung oder digital angegeben wird.

Das verbindet eine interne Lebenszyklusentscheidung mit der Produktkommunikation. Unterscheidet sich das Datum in technischer Dokumentation, Preisangaben, Benutzeroberfläche und Vertrag, tritt das Problem im normalen Kundenbetrieb lange vor einem Audit auf.

Der Unterstützungszeitraum ist eine operative Verpflichtung, nicht bloß ein Datum

Während des Unterstützungszeitraums muss der Hersteller Schwachstellen nach den CRA-Anforderungen wirksam behandeln. Die Aufzeichnung zum Unterstützungszeitraum sollte deshalb verbunden sein mit:

• der Richtlinie zur koordinierten Offenlegung von Schwachstellen;
• der Ersteinschätzung und Behebung von Schwachstellen;
• Sicherheitsreleases;
• Drittanbieterkomponenten;
• Nutzerkommunikation;
• Überwachung des Unterstützungsendes.

Der CRA enthält auch Anforderungen zur fortdauernden Verfügbarkeit veröffentlichter Sicherheitsupdates und zur Aufbewahrung der Dokumentation für bestimmte Zeiträume. Lebenszyklusmanagement lässt sich nicht auf ein einzelnes Feld in einem CRM oder Produktkatalog reduzieren.

Erwartete Nutzung mit Tatsachen begründen

Die folgende Lebenszyklusmethode ist unsere praktische Empfehlung zur Vorbereitung der Entscheidung. Sammeln Sie Tatsachen, bevor ein bequemes Enddatum gewählt wird. Produktspezifikation, Verträge, Einbauumgebung, Austauschzyklen und Nutzeranweisungen können Hinweise auf erwartete Nutzung geben. Ein kurzer Verkaufszeitraum belegt keine kurze Produktlebensdauer. Ein Hersteller kann den Vertrieb eines Geräts beenden, während Kunden es berechtigterweise noch jahrelang einsetzen. Diese tatsächliche Nutzungserwartung muss bei der begründeten Entscheidung berücksichtigt und mit ihrer Informationsgrundlage dokumentiert werden.

Trennen Sie bestätigte Tatsachen von Schätzungen. Eine dokumentierte Kundenanforderung an langen Betrieb hat eine andere Qualität als die interne Vermutung eines schnellen Austauschs. Fehlen belastbare Nutzungsdaten, wird diese Grenze festgehalten und nach einschlägigen Nachweisen gesucht. Wählen Sie nicht allein die kürzeste Schätzung, um Kosten zu senken. Die Entscheidung soll zeigen, wie gesetzliche Kriterien berücksichtigt wurden und weshalb der Zeitraum zum konkreten Produkt passt. Unsichere Annahmen benötigen gegebenenfalls einen späteren Prüftermin.

Bei einem hypothetischen Industriesteuergerät kann der Austausch Stillstandsplanung, passende Ausrüstung und eine erneute Inbetriebnahme erfordern. Das beeinflusst möglicherweise berechtigte Nutzungserwartungen. Bei einem hypothetischen kurzlebigen Softwareprodukt kann der Kontext anders sein. Keines der Beispiele legt automatisch einen gesetzlichen Zeitraum fest. Sie erklären, warum ein gemeinsames Datum für das gesamte Portfolio Eigenschaften, Zweckbestimmung und Betriebsumgebung nicht ausreichend abbilden kann. Die Bewertung muss die tatsächliche Produktnutzung betrachten und darf nicht nur einer internen Vertriebsplanung folgen.

Die Zusage auf ihre Durchführbarkeit prüfen

Prüfen Sie nach der Begründung des vorgeschlagenen Zeitraums, welche Fähigkeiten ihn tragen. Benennen Sie unterstützte Produktzweige, Build-Umgebung, Updateverteilung, Sicherheitskontakt und Personen für Schwachstellenuntersuchung. Eine Vertragszusage erhält diese Fähigkeiten nicht von selbst. Der Herstellerplan muss zeigen, wie Zuständigkeiten, Werkzeuge und notwendige Informationen verfügbar bleiben, wenn sich das ursprüngliche Entwicklungsteam verändert. Dazu können geregelte Übergaben und gepflegte Anleitungen gehören. Das Ziel ist eine tatsächlich ausführbare Unterstützungsaufgabe und keine ausschließlich auf einzelne Personen gestützte Hoffnung.

Vergleichen Sie zentrale Abhängigkeiten mit dem vorgeschlagenen Zeitraum. Ein früheres Unterstützungsende einer Komponente oder Betriebsumgebung erzeugt ein zu lösendes Problem. Es rechtfertigt nicht automatisch die Verkürzung des Produktzeitraums entgegen geltenden Kriterien. Prüfen Sie Ersatz, Migration oder einen anderen begründbaren Wartungsweg. Halten Sie Machbarkeit, Kosten und Risiken fest. Vor Genehmigung werden daraus notwendige Maßnahmen abgeleitet. Ein unbekannter Lieferantenhorizont bleibt als offene Frage sichtbar und darf nicht mit einer eigenen vermeintlich sicheren Zusage überdeckt werden.

Unterscheiden Sie neue Funktionen von Cybersicherheitsunterstützung. Ein Produkt kann wenige neue Funktionen erhalten und trotzdem wirksame Schwachstellenbehandlung sowie Sicherheitsupdates benötigen. Häufige Funktionsreleases beweisen umgekehrt nicht, dass ältere unterstützte Fassungen gepflegt werden. Die Aufzeichnung beschreibt Umfang der Unterstützung, Eingang von Sicherheitsmeldungen und unterstützte Release-Familien. Kundenaussagen müssen diese Grenzen erklären, ohne geltende Pflichten abzuschwächen. Eine klar begrenzte Funktionsplanung ist damit vereinbar, solange die tatsächlich notwendigen Sicherheitsaufgaben und zugesagten Leistungen weiterhin zuverlässig durchgeführt werden.

Hypothetischer Fall einer kürzeren Lieferantenwartung

Ein hypothetisches Gateway soll mehrere Jahre in Kundenanlagen bleiben. Der Anbieter des eingebetteten Betriebssystems kündigt einen kürzeren Wartungshorizont an, als der Hersteller vorgesehen hatte. Das Team eröffnet ein Lebenszyklusrisiko, identifiziert Produktfamilien und untersucht Alternativen. Eine Änderung des Datums in einer Tabelle löst die technische Lücke nicht. Sie erklärt auch nicht, was Nutzer erwarten dürfen. Der Vorgang muss daher als konkrete Abhängigkeit mit Folgen für unterstützte Produkte und die genehmigte Zusage behandelt werden.

Die Entwicklung prüft, ob eine unterstützte Betriebssystemfassung wesentliche Produktfunktionen erhalten kann. Das Produktmanagement klärt Migrationsgrenzen der Kunden. Der Einkauf bestätigt die tatsächlichen Lieferantenleistungen und deren Zeitraum. Die Leitung bewertet Kosten und genehmigt den gewählten Weg. Die Entscheidung bleibt produktbezogen. Eine Lieferantenankündigung hebt Herstellerpflichten nicht automatisch auf. Insbesondere darf der interne Plan nicht so formuliert werden, als wäre die Beendigung fremder Wartung bereits eine vollständige Lösung für die gegenüber Nutzern zugesagte Unterstützung.

Die Nachweiskette enthält Lieferantenmitteilung, betroffene Fassungen, Bewertung, genehmigte Maßnahme und spätere Prüfung. Ist die Lösung noch nicht getestet, bleibt sie als geplant gekennzeichnet. Eine ungeprüfte Migration darf Kunden nicht als verfügbares Update gezeigt werden. Der hypothetische Fall erklärt die Verbindung zwischen Begründung des Zeitraums und laufender Entwicklung. Er behauptet keinen tatsächlich erzielten Kundenerfolg. Erst ein bestätigtes Ergebnis kann belegen, welche technische Maßnahme funktioniert und für welche Produktfassung sie wirklich bereitgestellt werden kann.

Unterschiedliche Produkttermine getrennt halten

Ein Lebenszyklusregister kann Einführung, letzten Verkauf, letztes Funktionsrelease, Sicherheitsunterstützungsende und Aufbewahrungstermine enthalten. Sie beschreiben unterschiedliche Ereignisse. Legen Sie fest, welches Feld welcher Entscheidung dient, und prüfen Sie die Rechtsgrundlage der Berechnung. Ein mehrdeutiges „EOL“-Datum darf Vertrieb, Entwicklung und Dokumentenlenkung nicht für verschiedene Zwecke verwenden. Sonst kann eine noch unterstützte Fassung zu früh aus dem Schwachstellenverfahren entfernt werden. Eine verständliche Felddefinition verhindert diesen Fehler besser als eine spätere Suche nach dem ursprünglichen Tabellenverfasser.

Produktunterstützung, weitere Verfügbarkeit veröffentlichter Sicherheitsupdates und Aufbewahrung der Dokumentation sind unterschiedliche CRA-Anforderungen. Prüfen Sie die jeweiligen Bestimmungen, statt alle Unterlagen am Unterstützungsende zu löschen. Wir empfehlen getrennte Zuständigkeiten und Termine. So lässt sich eine spätere Entscheidung prüfen, ohne Erinnerung oder alten Vertrag rekonstruieren zu müssen. Die Trennung hilft auch bei Aufbewahrungsänderungen: Ein abgelaufener operativer Aufgabenzeitraum bedeutet nicht zwangsläufig, dass eine vorhandene Updatekopie oder eine gesetzlich aufzubewahrende Aufzeichnung ebenfalls entfernt werden darf.

Bei Vertrieb über Zeit und mehrere Fassungen bleibt die Beziehung zwischen kommuniziertem Enddatum und Produktfamilie sichtbar. Leiten Sie sie nicht nur aus dem heutigen Katalog ab. Prüfen Sie tatsächliche Zeitpunkte und gesetzliche Regeln gegen das Bereitstellungsmodell. Kundeninformationen werden neben der internen Entscheidung auffindbar gehalten. Eine prüfende Person kann dann erkennen, was zum einschlägigen Kaufzeitpunkt angegeben war. Das ist wichtig, wenn spätere Katalogänderungen sonst den Eindruck erwecken würden, sämtliche früheren Lieferungen hätten dieselben Angaben erhalten.

Kaufmännische Zusagen mit der Entscheidung abstimmen

Vergleichen Sie vor Veröffentlichung Produktseite, Vertrag, Anleitung und digitale Anzeige. Sie müssen dasselbe Produkt und Enddatum beschreiben. Eine allgemeine Aussage „langfristige Unterstützung“ ersetzt die erforderliche klare Information nicht. Sie kann Erwartungen schaffen, die nicht in der Entwicklungsplanung stehen. Der Vertrieb benötigt deshalb die genehmigte Lebenszyklusentscheidung vor einer Zusage. Die Kommunikation soll verständlich erklären, was gilt. Eine vage positive Formulierung spart diese Entscheidung nicht ein, sondern verschiebt die Unklarheit in den späteren Kundenbetrieb.

Kommuniziert ein Händler Produktinformationen, klären Sie Zugang zu Änderungen und die verwendete Fassung der Aussage. Ein Hersteller kann intern korrekt arbeiten, während eine ältere Händlerseite ein anderes Datum nennt. Diese Abweichung muss erkannt und bearbeitet werden. Halten Sie Kommunikationsnachweis und zuständigen Kontakt fest. Eine einmal gesendete Datei bleibt nicht automatisch überall aktuell. Der konkrete Vertriebsweg braucht deshalb einen angemessenen Ablauf zur Änderung von Informationen, die für Kaufentscheidung und späteren Betrieb des Produkts wesentlich sind.

Ändert sich eine Unterstützungsannahme, prüfen Sie technisches Problem und Kundenzusage gemeinsam. Verkürzen Sie eine veröffentlichte Frist nicht stillschweigend. Geltendes Recht und Vertrag werden untersucht, danach Maßnahmen und Kommunikation verantwortlich entschieden. Diese Empfehlung schützt Genauigkeit und Vertrauen. Sie schafft kein automatisches Recht, jeden Zeitraum zu verlängern oder zu kürzen. Tatsachen und Pflichten bestimmen die Entscheidung. Die Aufzeichnung muss deren Grund erkennen lassen und zeigen, welche Konsequenzen für die bereits bereitgestellten Produkte und betroffenen Nutzer bestehen.

Wartungsaufwand ausdrücklich einplanen

Eine praktische Kostenschätzung unterscheidet Schwachstellenbeobachtung, Untersuchung, Korrektur, Regressionstests, Updateverteilung, Dokumentationspflege und Kommunikation. Manche Kosten treten regelmäßig, andere ereignisbezogen auf. Verwenden Sie realistische Produktannahmen statt eines symbolischen Betrags „Wartung“. Berücksichtigen Sie die Fähigkeit, ältere unterstützte Releases bei Bedarf weiter zu bauen und zu testen. Wenn dafür Geräte, Werkzeuge oder spezielle Kenntnisse nötig sind, gehören diese Abhängigkeiten in die Planung. Eine reine Stundenannahme ohne verfügbare Umgebung beschreibt den tatsächlichen Unterstützungsaufwand nur unvollständig.

Kleine Hersteller setzen häufig dieselben Menschen für neue Entwicklung und Unterstützung ein. Machen Sie diesen Konflikt sichtbar. Eine von neuen Funktionen dominierte Aufgabenliste kann Sicherheitsarbeit für ältere Fassungen immer wieder verschieben. Legen Sie Zuständigkeit und Eskalation für zeitkritische Fälle fest. Das konkrete Personalmodell darf unterschiedlich sein. Die Annahme, irgendwann finde jemand freie Zeit, ist jedoch kein belastbarer Wartungsplan. Die Leitung muss erkennen können, welche Kapazität die Zusage trägt und wo Prioritätsentscheidungen nötig werden.

Prüfen Sie die Schätzung bei geänderten Abhängigkeiten oder Portfolio. Zwei verwandte Softwarefassungen können viele Arbeiten teilen. Eine neue Hardwareausgabe kann andere Prüfausrüstung benötigen. Dokumentieren Sie Ressourcengrund und Unsicherheit. Das sind empfohlene Planungspraktiken und kein eigenständiger Konformitätsnachweis. Sie erklären, welche Kapazität hinter einer Lebenszykluszusage steht. Neue Tatsachen können die Schätzung verändern, ohne automatisch die Zusage zu verändern. Deshalb müssen wirtschaftliche Neubewertung und Prüfung der bestehenden Pflichten als getrennte Entscheidungen nachvollziehbar bleiben.

Das Unterstützungsende als Übergang vorbereiten

Wir empfehlen eine Übergangsprüfung vor dem Enddatum. Prüfen Sie Nutzerinformationen, erreichbare Release-Aufzeichnungen und Zuständigkeit offener Fälle. Stellen Sie fest, welche Updates und Dokumente nach den einschlägigen Bestimmungen verfügbar bleiben müssen. Definieren Sie den Umgang mit einer Meldung kurz vor oder nach dem Termin einschließlich der Prüfung fortbestehender Pflichten. Das Schließen einer Warteschlange ersetzt diese Bewertung nicht. Auch die verantwortliche Person für späte Rückfragen und die Ablage früherer Entscheidungen müssen danach noch erkennbar sein.

Ein Übergangshinweis erklärt Produktfamilie, Datum, verfügbare Migrations- oder Ersatzwege und notwendige Nutzerhandlungen. Behaupten Sie nicht, das Produkt werde am Datum körperlich unbrauchbar, wenn dies nicht seinem Verhalten entspricht. Behaupten Sie ebenso wenig unbegrenzte Sicherheitswartung, wenn sie nicht angeboten wird. Die Nachricht muss Lebenszyklusentscheidung und tatsächliche Fähigkeiten widerspiegeln. Prüfen Sie daher technische Beschreibung und kaufmännische Zusagen gemeinsam. Ein sachlicher Hinweis kann den Zustand präzise erklären, ohne unnötige Dringlichkeit zu erzeugen oder verbleibende Risiken zu verschweigen.

Testen Sie den Ablauf an einem unterstützten Produkt. Das Team muss Begründung, Lieferantenannahmen, kommuniziertes Datum, Wartungsverantwortung und nötige Aufzeichnungen finden können, ohne den ursprünglichen Autor zu befragen. Fehlende Informationen werden zu Aufgaben. Eine Entscheidung zum Unterstützungszeitraum bleibt wertvoll, wenn sie Jahre später noch verständlich und ausführbar ist. Das gepflegte Register ist deshalb Teil verantwortlicher Produktbetreuung. Es muss mit dem laufenden Schwachstellenverfahren und den tatsächlichen Release-Aufzeichnungen verbunden bleiben, statt lediglich ein einmal ausgefülltes Formular aufzubewahren.

Wie Pulsar die Entscheidung verwalten kann

Pulsar kann Entscheidung, Begründung, verantwortliche Menschen, Maßnahmen und Nachweise bewahren und mit Risiken und Dokumentation verbinden. Bei einer späteren Prüfung sieht das Team, was sich seit der vorherigen Entscheidung geändert hat, statt die ursprüngliche Begründung zu rekonstruieren.

Das bedeutet nicht, dass Pulsar selbstständig über den richtigen Unterstützungszeitraum entscheidet. Annahmen und Genehmigung bleiben in der Verantwortung des Herstellers.

Pulsar GRC an einem Entscheidungslebenszyklus ansehen

Verwandte Leitfäden

• Technische CRA-Dokumentation
• SBOM und Produktabhängigkeiten
• Zurück zum CRA-Leitfaden

Quellen

• Verordnung (EU) 2024/2847 — Artikel 13 und Anhang VII
• Europäische Kommission — CRA-Leitlinien vom 27. Juli 2026

Quellen geprüft: 2. Oktober 2026.

• Pulsar GRC — Zugriff, Datenisolierung und Export (Polnisch)