Der EOL-Prozess — vom Herstellertermin zur Entscheidung in sechs Schritten
End-of-Life-Termine sind öffentlich, und trotzdem überraschen sie. Der Grund ist selten fehlendes Wissen, sondern ein fehlender Ablauf. Sechs Schritte machen aus einzelnen Herstellerschreiben einen wiederholbaren Prozess — vom Bestand mit Versionsangabe über die Betroffenheit bis zur befristeten, begründeten Entscheidung und ihrer Wiedervorlage.
Kaum ein IT-Risiko ist so gut angekündigt wie das Lebensende eines Produkts. Hersteller veröffentlichen ihre Termine, freie Sammlungen wie endoflife.date bündeln Hunderte davon, und Microsoft beschreibt die Phasen seiner Lebenszyklusrichtlinien öffentlich. Trotzdem stehen in vielen Häusern Systeme ohne Sicherheitsaktualisierungen im Betrieb. Das liegt selten daran, dass niemand den Termin kannte. Es liegt daran, dass niemand zuständig war, aus dem Termin eine Entscheidung zu machen.
Ein EOL-Prozess schließt genau diese Lücke. Er besteht aus sechs Schritten, die für Software und Hardware gleich funktionieren.
Schritt 1: Den Bestand mit Version führen
Ein Herstellertermin gilt nie für ein Produkt, sondern für eine Version oder Baureihe. „Oracle-Datenbank" hat kein Wartungsende, „Oracle 19c" schon. Der erste Schritt ist deshalb ein Bestand, der Produkte samt Version führt — auf der Ebene der Klassen, nicht der einzelnen Installationen.
Die gefährlichste Kombination ist ein Termin ohne Version: Er sieht belegt aus, gilt aber womöglich für einen ganz anderen Stand als den, der im Haus läuft.
Schritt 2: Termine beschaffen und ihre Herkunft vermerken
Die Termine kommen vom Hersteller, aus freien Sammlungen oder aus dem Wartungsvertrag. Dabei lohnt es sich, drei Daten statt einem zu führen: das Ende der Sicherheitsaktualisierungen, das endgültige Lebensende und eine gegebenenfalls beauftragte, bezahlte Verlängerung. Nur so bleibt erkennbar, ob ein System „weg muss" oder nur „extra kostet".
Genauso wichtig wie das Datum ist seine Herkunft. Ein Termin aus einer eingelesenen Liste ist ein Vorschlag, bis ihn jemand geprüft hat. Eine Angabe ist so viel wert wie ihre letzte Bestätigung — das gilt für Wartungsenden besonders, weil Hersteller ihre Zeiträume verlängern, verkürzen und aufspalten.
Schritt 3: Die Betroffenheit bestimmen
Aus dem Termin wird erst ein Risiko, wenn klar ist, was daran hängt. Welche Anwendungen setzen auf dem Produkt auf? Welche Geschäftsfähigkeiten tragen diese Anwendungen, und wie kritisch sind sie? Diese Kette — Produkt, Anwendung, Geschäft — steht in keiner Herstellerdatenbank, sondern nur im eigenen Inventar. Warum sie der eigentliche Kern ist, beschreibt der Artikel zum Wartungsende als geführter Angabe.
Schritt 4: Entscheiden — mit einer von vier Antworten
Der Patch-Leitfaden des NIST (SP 800-40 Rev. 4) unterscheidet vier Risikoreaktionen, die sich gut auf das Lebensende übertragen lassen:
- Akzeptieren: befristet weiterbetreiben, mit Begründung, Verantwortlichem und Wiedervorlagetermin.
- Mindern: das System abschotten, etwa durch Netzsegmentierung, oder eine bezahlte Verlängerung beauftragen, die Sicherheitskorrekturen einschließt.
- Übertragen: den Betrieb an einen Anbieter geben, der die Aktualisierung übernimmt, etwa durch den Wechsel auf ein Software-as-a-Service-Angebot.
- Vermeiden: ablösen oder außer Betrieb nehmen.
Bei Hardware kommt eine Zwischenform hinzu: die Drittwartung. Sie sichert Ersatzteile und Service, aber keine neuen Sicherheitsstände. Wann sie trägt und wann nicht, zeigt der Artikel zur Wartung von End-of-Life-Hardware.
Die schlechteste Antwort ist die fünfte, die in keinem Leitfaden steht: gar keine. Ein System, das nach dem Stichtag ohne Entscheidung weiterläuft, hat das Risiko nicht akzeptiert. Es wurde nur nicht bemerkt.
Schritt 5: Umsetzen und den Übergang führen
Eine Ablösung braucht einen benannten Nachfolger und eine klare Einordnung des Altprodukts: Es läuft aus und darf nicht neu verwendet werden. Ohne diese Einordnung entstehen während der Ablösung neue Abhängigkeiten zum Altsystem, und der Termin rückt näher, während die Liste der Betroffenen wächst. Das größte Einzelbeispiel dieser Kategorie ist derzeit das SAP-Wartungsende 2027/2030.
Das IT-Grundschutz-Kompendium des BSI behandelt den geordneten Umgang mit Aktualisierungen und Änderungen im Baustein OPS.1.1.3 Patch- und Änderungsmanagement. Für NIS2-regulierte Einrichtungen gehört der Nachweis dazu: § 30 BSIG verlangt Schwachstellenmanagement und die Verwaltung von IKT-Systemen.
Schritt 6: Bestätigen und wieder vorlegen
Der Prozess endet nicht mit der Entscheidung. Hersteller ändern Termine, Verlängerungen laufen aus, und die Zahl der Anwendungen auf einem Produkt wächst oder schrumpft. Jede akzeptierte Abweichung braucht deshalb einen Wiedervorlagetermin, und jeder Termin einen Menschen, der ihn regelmäßig bestätigt.
Der Maßstab für einen funktionierenden EOL-Prozess ist schlicht: Kein Herstellerschreiben überrascht mehr. Jedes trifft auf einen Termin, der schon im Bestand steht, auf eine Liste der Betroffenen und auf jemanden, der entscheidet.
Häufige Fragen
Was ist ein EOL-Prozess?
Ein fest vereinbarter Ablauf, der Herstellertermine zum Lebensende von Software und Hardware in Entscheidungen übersetzt. Er legt fest, woher die Termine kommen, wer die Betroffenheit bewertet, welche Antworten zulässig sind und wann eine Entscheidung erneut geprüft wird. Ohne ihn bleibt jedes Herstellerschreiben ein Einzelfall, der im Postfach der Person liegt, die es zufällig bekommen hat.
Wer sollte den EOL-Prozess verantworten?
Die Verantwortung für den Ablauf gehört an eine Stelle, die den ganzen Bestand im Blick hat, häufig die Unternehmensarchitektur oder das IT-Risikomanagement. Die Verantwortung für jeden einzelnen Termin gehört dagegen zu dem, der den jeweiligen Baustein fachlich oder technisch führt. Beides zu trennen verhindert, dass der Prozess an einer Person hängt oder die Termine niemandem gehören.
Wann sollte die Prüfung vor dem Termin beginnen?
So früh, dass die Ablösung noch eine echte Option ist. Maßgeblich ist nicht der Kalender, sondern der Aufwand der Ablösung des konkreten Systems: Beschaffung, Migration, Test und Abnahme. Eine Fahrplansicht, die zeigt, was in den nächsten 6, 12 und 24 Monaten ausläuft, macht aus diesem Grundsatz eine Arbeitsliste.
Was tun, wenn der Hersteller keinen Termin veröffentlicht?
Die Lücke sichtbar führen, nicht füllen. Ein Termin mit dem Vermerk „unbekannt" ist ein Arbeitsauftrag: beim Hersteller oder im Wartungsvertrag nachfragen, den Stand datieren und bis zur Klärung als Risiko behandeln. Ein geschätztes Datum ohne Herkunftsangabe sieht dagegen belegt aus und beendet die Nachfrage.
Primärquellen
Der EOL-Prozess als Arbeitsliste
blueprAInt gibt jedem der sechs Schritte einen Ort im Bestand, statt ihn einer Tabelle neben dem Bestand zu überlassen.
- Lücken, die sich melden: Eine Deckungsübersicht zeigt, wie viele IT-Bausteine Version, Termin und angehängte Anwendungen haben — und führt Termine ohne Version als das, was sie sind: scheinbar belegt.
- Herkunft an jedem Termin: Gepflegt, aus einer Herstellerliste übernommen, aus dem Vertrag oder unbekannt — mit dem Datum der letzten Prüfung. Übernommene Termine bleiben Vorschläge, bis ein Mensch sie bestätigt.
- Entscheidungen mit Datenstand: Wer ein Risiko bewusst trägt, hält die Entscheidung samt Messwerten fest — Kosten, Kündigungsfristen, gestützte Anwendungen. Ändert sich die Grundlage, meldet blueprAInt das von selbst.