Ende der Hersteller-Patches: Wie Sie EoL-Hardware sicher weiter betreiben

1. Wenn Hardware länger lebt als der Herstellersupport

In der IT-Sicherheit gilt eine einfache Faustregel: Systeme ohne Sicherheitsupdates gehören aus dem produktiven Netz. Im Alltag sieht es oft anders aus. In Rechenzentren, Produktionshallen und Filialnetzen laufen täglich geschäftskritische Prozesse auf Hardware, die ihren besten Tage längst hinter sich hat. Die Gründe liegen meist tief in der Organisation: mehrjährige Budgetzyklen, hochspezialisierte Fachanwendungen, verschachtelte Lieferketten und enge Abhängigkeiten, gerade in der Operational Technology (OT). Solange die Systeme zuverlässig Transaktionen verarbeiten oder Produktionsanlagen steuern, wirkt eine teure und riskante Migration wenig dringlich. Daher handeln viele Verantwortliche nach dem Grundsatz: “Never touch a running system.”

Kritisch wird es an dem Tag, an dem der Hersteller, der sogenannte Original Equipment Manufacturer, kurz OEM, den Support einstellt. Sobald Firmware-Updates, neue Treiber und Sicherheitspatches ausbleiben, werden aus einst gut abgesicherten Servern, Storage-Systemen und Netzwerkkomponenten attraktive Ziele für Angreifer. Fehlende Patches, unklare Abhängigkeiten und veraltete Architekturen machen sie zu bevorzugten Zielen automatisierter Angriffe und gezielter Kampagnen sogenannter Advanced Persistent Threats (APTs).

Für IT-Verantwortliche, CISOs und Entscheider stellt sich deshalb die Frage: Unter welchen Bedingungen lässt sich EoL-Hardware 2026 noch sicher, rechtskonform und wirtschaftlich vertretbar weiterbetreiben? Wir ordnen die Risiken ein und beschreiben ein praxistaugliches Set an Schutzmaßnahmen, mit dem sich der Lebenszyklus von Hardware kontrolliert verlängern lässt, ohne das Unternehmensnetz zu gefährden.

2. Was bedeutet EoL bei Hardware konkret?

„End of Life“ verwenden viele Administratoren und Einkäufer als Sammelbegriff für alles, was alt ist. Für die Praxis lohnt sich eine genauere Unterscheidung, weil jede Phase ein eigenes Risikoprofil mitbringt. Die großen Hersteller wie Cisco, Dell Technologies und Hewlett Packard Enterprise (HPE) beschreiben ihre Lebenszyklen in klar definierten, teils vertraglich bindenden Stufen.

Abbildung: Verschiedene EoL-Stadien im Produktlebenszyklus

Die folgenden Meilensteine sollten Sie auseinanderhalten:

• End of Sale (EoS) / Last Shipment Date: Ab diesem Datum lässt sich ein Produkt nicht mehr über die regulären Vertriebswege bestellen. Bei HPE zum Beispiel verschwindet es zu diesem Zeitpunkt von der Preisliste. Für den laufenden Betrieb ändert sich zunächst wenig: Wartungsverträge laufen, Firmware-Updates kommen weiterhin.
• End of Engineering Support (EoES) / End of Standard Support: Hier beendet der Hersteller die aktive Entwicklung von Software- und Firmware-Updates. Bei HPE liegt dieser Punkt in der Regel fünf Jahre nach dem End of Sale, in der HPE-Sprache auch “Retired” genannt. Neue Funktionen, Anpassungen an aktuelle Betriebssysteme und routinemäßige Bugfixes entfallen ab jetzt. Dell nennt eine vergleichbare Phase „End of Standard Support“.
• End of Security Support: Der wichtigste Meilenstein für die Sicherheit. Ab diesem Datum gibt es selbst für kritische Schwachstellen (Common Vulnerabilities and Exposures, CVEs) mit einem CVSS-Score von 10.0 keine Patches mehr. Die Hardware steht neu entdeckten Angriffswegen damit offen.
• End of Life (EoL) / Last Date of Support (LDoS / End of Service Life): Das endgültige Aus. Es gibt keinen Support mehr, Wartungsverträge lassen sich nicht mehr verlängern, und Original-Ersatzteile sind über den OEM nicht mehr zu bekommen. Bei Cisco markiert das LDoS-Datum das Ende sämtlicher Service-Verträge und Software-Releases.

Tabelle: EOL-Terminologien nach Herstellern

Diese Unterscheidung macht klar, dass fehlendes Patch-Management bei EoL-Hardware über ein rein technisches Thema hinausgeht und zur Governance- und Compliance-Frage wird. Wer Systeme jenseits des End of Security Support produktiv betreibt, verliert meist die Grundlage für wichtige Zertifizierungen wie ISO/IEC 27001 und riskiert Verstöße gegen Vorgaben wie die NIS-2-Richtlinie oder, im Finanzsektor, DORA, solange keine nachweisbaren kompensierenden Maßnahmen greifen oder Risiken klar benannt sind und vom Unternehmen akzeptiert werden. Hardware-EoL zwingt damit die Geschäftsführung, das Restrisiko formell zu tragen, statt es allein den Administratoren zu überlassen.

3. Die größten Risiken beim Weiterbetrieb alter Hardware

Wer Hardware ohne Herstellersupport ungesichert weiterlaufen lässt, bewegt sich in einer stark automatisierten Bedrohungslage. Angreifer scannen Netze rund um die Uhr nach bekannten Schwachstellen in alten Edge-Geräten und Servern. Der Gedanke, ein altes Gerät sei „zu unwichtig“ für einen Angriff, trügt. EoL-Geräte dienen oft als unbeobachteter Einstiegspunkt, von dem aus sich Angreifer im Netz ausbreiten (Lateral Movement). Das in Zeiten leistungsfähiger KI, mit denen sich Schwachstellen auch ohne tiefgehende Fachkenntnisse suchen und finden lassen, umso mehr.

Vier Risikokategorien sollten Sie genauer prüfen:

• Ungepatchte Lücken in Management-Interfaces
• Kompatibilitäts- und Zertifikatsprobleme
• Schwachstellen in der Netzinfrastruktur
• Höhere Ausfallwahrscheinlichkeit und Ersatzteilknappheit

3.1 Ungepatchte Lücken in Management-Interfaces

Besonders heikel sind Out-of-Band-Management-Schnittstellen wie HPE iLO (Integrated Lights-Out) oder Dell iDRAC (Integrated Dell Remote Access Controller). Diese Controller laufen auf eigenen Mikro-Betriebssystemen direkt auf dem Mainboard und haben weitreichenden Zugriff auf die Hardware: Power-Steuerung, virtuelle Konsole, das Einbinden von ISO-Images. All das funktioniert unabhängig vom Zustand des Hauptbetriebssystems.

Ein aktuelles Beispiel sind HPE ProLiant Gen9 Server mit iLO-4-Controllern. Für verbreitete Modelle wie den DL380 Gen9 lief der Support bereits 2025 aus. Ältere iLO-4-Firmware enthält dokumentierte Schwachstellen: HPE listet in seinem Security Bulletin mehrere aus der Ferne ausnutzbare Lücken im iLO-4-Interface auf, darunter CVE-2022-23704, über die sich ohne Anmeldung ein Denial-of-Service auslösen lässt. Für Gen9-Systeme jenseits des Supports schließt der Hersteller neu entdeckte Lücken nicht mehr. Wer solche Server ohne strikte Netz-Isolation betreibt, fährt ohne Sicherheitsnetz. Deswegen ist es auch eine der wichtigsten Regeln in der Netzwerk Security, dass Management Netzwerke nur über einen Bastion Host zugänglich sind, weil Out of Band Management Schnittstellen direkten Zugang zum gesamten System ermöglichen.

3.2 Kompatibilitäts- und Zertifikatsprobleme

Mit dem Alter verlieren Systeme den Anschluss an aktuelle Kryptografie. Ein typischer Stolperstein im Alltag ist das Management von TLS-Zertifikaten (Transport Layer Security).

Ältere Dell PowerEdge Server der 13. Generation (etwa R630 oder R730) mit iDRAC8 zeigen das gut. Firmware-Updates scheitern hier oft, weil die Update-Routinen noch auf veraltete Zertifikate oder die abgekündigten Protokolle TLS 1.0 und 1.1 setzen. Die Download-Server der Hersteller verlangen aus Sicherheitsgründen längst TLS 1.2 oder 1.3. Eine Verbindung lässt sich dann nicht aufbauen. Administratoren weichen auf umständliche Workarounds aus: manuelles Einspielen über Netzwerk-Shares, das Booten spezieller ISO-Dateien oder lokale Proxys, die den TLS-Handshake übernehmen.

Auch eigene, moderne TLS-Zertifikate, etwa Wildcard-Zertifikate aus einer internen PKI, bereiten Probleme. Dell beschreibt in seiner iDRAC-Dokumentation, wie sich Web-Server-Zertifikate auf dem Controller verwalten lassen. Bei Legacy-Firmware akzeptiert der iDRAC die Zertifikatsketten trotzdem oft nicht. Die Folge sind dauerhafte Browser-Warnungen und Administratoren, die sich angewöhnen, diese wegzuklicken. Genau diese Gewöhnung an Warnungen senkt die Wachsamkeit im ganzen Team.

Abbildung: Veraltete Kryptographie und Zertifikate können bei Updates problematisch sein

3.3 Schwachstellen in der Netzwerkinfrastruktur

Bei Routern, Switches und Firewalls wiegt das EoL-Risiko schwerer als bei reinen Rechenknoten, weil diese Geräte den Datenverkehr ganzer Standorte steuern und oft direkt aus dem Internet erreichbar sind. Die US-Behörde CISA warnt in einem gemeinsamen Merkblatt mit FBI und dem britischen NCSC ausdrücklich vor kompromittierten Edge-Geräten am Support-Ende und hat mit der Binding Operational Directive 26-02 im Februar 2026 verbindliche Vorgaben für US-Bundesbehörden geschaffen.

Wie real die Gefahr ist, zeigt die Kampagne „ArcaneDoor“. Cisco dokumentiert in seiner Event Response, dass Angreifer gezielt Cisco-Firewalls der ASA-5500-X-Serie über Zero-Day-Lücken übernahmen und nicht authentifiziert Code ausführen konnten. Besonders unangenehm: Auf älteren ASA-5500-X-Plattformen ohne Secure Boot manipulierten die Angreifer den ROM (ROMMON), sodass die Schadsoftware Neustarts und sogar Firmware-Upgrades überstand. Daran anknüpfend hat CISA die Emergency Directive ED 25-03 erlassen. Bei noch älteren Geräten, deren Support viele Jahre zurückliegt, stehen Unternehmen automatisierten Botnets und Lateral-Movement-Angriffen weitgehend schutzlos gegenüber. Anforderungen aus PCI-DSS oder HIPAA erfüllen solche Geräte längst nicht mehr.

3.4 Höhere Ausfallwahrscheinlichkeit und Ersatzteilknappheit

Neben dem Sicherheitsrisiko droht bei EoL-Systemen ein Hardware-Defekt durch Materialermüdung. Standardteile wie DDR4-RAM oder gängige CPUs bleiben meist jahrelang verfügbar. Herstellerspezifische Bauteile werden dagegen schnell knapp.

Bei HPE-Gen9-Servern verliert etwa die Smart Storage Battery, die den Schreibcache des RAID-Controllers bei Stromausfall stützt, mit den Jahren an Kapazität. Schwächelt sie bei alter iLO-4-Firmware, kann der Server beim Start (POST) mit Fehlercode 313 hängen bleiben. Fällt in einem Storage-Server eine proprietäre SAS-Expander-Backplane aus, ist oft der ganze Laufwerksstrang tot.

Wer OEM-SSDs durch handelsübliche Modelle ersetzt, erlebt bei Enterprise-Servern häufig Überraschungen: gedrosselte Performance, verweigerte Aufnahme ins RAID-Array oder Lüfter, die dauerhaft auf voller Drehzahl laufen, weil sich die Sensorik der Fremd-SSD nicht über die OEM-Protokolle auslesen lässt.

4. Warum „sofort austauschen“ nicht immer realistisch ist

Die reine Lehre verlangt den sofortigen Austausch jeder nicht mehr unterstützten Hardwarekomponente. Der Alltag in den meisten Unternehmen verlangt dagegen Pragmatismus. Die Abwägung zwischen technischem Idealzustand und wirtschaftlicher Machbarkeit gehört zu den Kernaufgaben jedes CIO.

In Produktion, Medizintechnik und OT gelten andere Lebenszyklen als in der Büro-IT. Ein Webserver-Cluster wird oft alle drei bis fünf Jahre erneuert. Industrierouter, Steuerungsrechner, SCADA-Systeme und medizinische Messgeräte sind dagegen häufig auf 15 bis 20 Jahre Dauerbetrieb ausgelegt. Diese Systeme müssen in Echtzeit und ohne Unterbrechung laufen. Ständige Neustarts für Patches vertragen sie nicht.

Viele Systeme kommunizieren über alte, unverschlüsselte Protokolle, und manche Geräte wie einfache I/O-Module oder Temperaturfühler haben nicht einmal ein Webinterface, über das sich Sicherheitseinstellungen vornehmen ließen. IT-Sicherheitsmandate lassen sich auf solche Geräte kaum übertragen, ohne die Produktion zu stoppen.

Hinzu kommt der Investitionsschutz. Gewachsene Legacy-Datenbanken oder monolithische Anwendungen in die Cloud zu migrieren, ist aufwendig, fehleranfällig und bindet viel Kapital und Personal. Der häufigste Fehler bei der Modernisierung ist der Glaube, man müsse alles auf einmal ersetzen („Rip and Replace“). Solche Projekte dauern oft länger als geplant. Läuft in dieser Phase der Wartungsvertrag der alten Hardware aus, bleibt die Wahl zwischen teuren Kurzzeit-Verlängerungen beim Hersteller und einem Betrieb ganz ohne Support.

5. Die Vorteile von Third Party Maintenance (TPM)

Wenn der OEM-Support endet oder für kurze Überbrückungen unverhältnismäßig teuer wird, ist Third Party Maintenance (TPM) eine wirtschaftlich vernünftige Alternative zum sofortigen Neukauf.

Der Hintergrund: Große Hersteller bringen alle fünf bis sieben Jahre eine neue Hardware-Generation heraus. Um Kunden zur Migration zu bewegen, steigen die Wartungskosten für Altsysteme nach dem Erstvertrag deutlich, oft um das Zwei- bis Vierfache, ohne dass sich Ausfallrisiko oder Servicequalität ändern. Ein etablierter TPM-Anbieter durchbricht diesen Zyklus und gibt IT-Verantwortlichen Flexibilität zurück.

Die wichtigsten Vorteile:

• Geringere Kosten: Der Wechsel von OEM- zu TPM-Verträgen senkt die reinen Wartungskosten erheblich. Das frei werdende Budget lässt sich direkt in Migrations- oder Digitalisierungsprojekte stecken.
• Längerer Lebenszyklus: Systeme am EoL sind physisch oft noch top in Schuss. Mit TPM lassen sich Server, Storage und Switches mehrere Jahre länger sicher betreiben. Das schont das Budget und reduziert Elektroschrott, ein Plus für die ESG-Ziele und den Scope-3-Fußabdruck.
• Ein Ansprechpartner für viele Hersteller: Große Umgebungen sind selten homogen, etwa Dell EMC für Storage, HPE für Compute und Cisco im Netz. Ein TPM-Dienstleister bündelt diese Verträge, vereinfacht die Fehlersuche bei unklaren Abstürzen und senkt den Verwaltungsaufwand im Einkauf.

6. Entscheidungsgrundlage: Weiterbetrieb, Isolation oder Ablösung?

Der Umgang mit EoL-Hardware sollte eine bewusste, dokumentierte Managemententscheidung sein, getragen von einer Risikoanalyse. Eine stille Duldung aus Zeitmangel oder Bequemlichkeit reicht nicht. Der IT-Grundschutz des BSI (Standards 200-1 bis 200-3) liefert dafür ein bewährtes Rahmenwerk. Die Bewertung stützt sich auf drei Fragen:

• Kritikalität (Business Impact): Welcher Schaden entsteht bei Ausfall oder Kompromittierung? Geht es um den zentralen ERP-Server, ein Testsystem oder die Klimasteuerung des Gebäudes? Nur wenn das Risiko zum Nutzen passt, kommt ein Weiterbetrieb in Frage.
• Exposition (Attack Surface): Wo steht das System? Direkt am Internet wie ein Edge-Router, im Büronetz mit hunderten PCs oder tief im Produktionsnetz ohne externe Wege? Je höher die Exposition, desto dringender der Austausch.
• Kompensationsmaßnahmen: Lassen sich die fehlenden Patches durch Architektur ausgleichen, etwa durch vorgeschaltete Web Application Firewalls, Intrusion Prevention oder strikte Segmentierung?

Ein Kostenvergleich gehört dazu. Er sollte die Anschaffung neuer Hardware den Vollkosten des sicheren Weiterbetriebs gegenüberstellen: auf der einen Seite TPM-Verträge, Aufwand für Segmentierung und zusätzliches Monitoring, auf der anderen Seite Hardware, Lizenzen, Migrationsdienstleistungen und Ausfallzeiten während der Umstellung. Fällt die Analyse zugunsten des Weiterbetriebs aus, sind die folgenden Maßnahmen Pflicht.

7. Sicherheitsmaßnahmen für den kontrollierten Weiterbetrieb

„Kontrolliertes Altern“ heißt: Die wegfallenden Hersteller-Mechanismen wie automatisches Patching werden durch eigene Schutzkonzepte und mehr Wachsamkeit ersetzt.

7.1 Inventarisierung und Transparenz

Schützen lässt sich nur, was man kennt. Ein lückenloses Asset-Inventory ist Pflicht. Zudem müssen bestehende Netzwerke aktiv nach undokumentierten und veralteten Geräten gescannt werden. Erfassen Sie Modellnummern, Firmware-Stände aller Sub-Komponenten (BIOS, RAID-Controller, Netzwerkkarten), IP-Adressen, offene Ports und die genauen Support-Termine.

Ein Praxis-Tipp: Prüfen Sie jedes System einzeln im Herstellerportal anhand der Service Tags (Dell) oder Machine Types (Lenovo), denn das EoL-Datum hängt vom Versanddatum und der Region ab.

7.2 Netzwerksegmentierung und Isolation

EoL-Systeme ohne Patches gelten als kompromittierbar. Die wirksamste Gegenmaßnahme ist Isolation. Verschieben Sie Altsysteme aus dem Kernnetz in abgeriegelte VLANs. Die Kommunikation dorthin regeln Next-Generation-Firewalls nach dem Zero-Trust-Prinzip: Erlaubt ist nur, was ausdrücklich freigegeben wurde (etwa Modbus TCP auf Port 502). Direkten Internetzugriff für EoL-Server schließen Sie aus und löschen auf diesen Geräten auch die Default-Route ins Internet. Management-Schnittstellen wie iLO oder iDRAC gehören in ein eigenes, physisch getrenntes Management-Netz, erreichbar nur über überwachte Jump-Hosts.

7.3 Härtung der Systeme

Reduzieren Sie die Angriffsfläche auf das Nötigste. Schalten Sie nicht benötigte Dienste, Schnittstellen (etwa USB) und Protokolle ab. Konkret:

• Management-Ports absichern: lange, einzigartige Passwörter für jeden Controller.
• Starke Authentifizierung: phishing-resistente Multi-Faktor-Authentifizierung (MFA) vor dem Zugriff auf die Jump-Hosts.
• Kryptografie aufräumen: Telnet zugunsten von SSH abschalten und TLS 1.0/1.1 deaktivieren, wo die Hardware TLS 1.2 zulässt.

7.4 Monitoring und Angriffserkennung

Wenn Patches fehlen, muss das automatisch erkannt werden. Überwachen Sie den Netzverkehr und protokollieren Sie alle Zugriffe. Ein SIEM-System (Security Information and Event Management) sammelt und korreliert die Logs von Firewalls, Switches und EoL-Servern. Wichtig: Senden Sie die Logs in Echtzeit und unveränderbar an einen externen Speicher, damit ein Angreifer seine Spuren auf dem System nicht löschen kann.

Legacy-Systeme erledigen oft sehr gleichförmige Aufgaben, ihr Normalverhalten lässt sich gut beschreiben. Alles, was aus dieser Baseline fällt, etwa eine SSH-Verbindung zum Storage-Controller um drei Uhr nachts oder ein ungewöhnlich hoher Datenabfluss, sollte sofort einen Alarm im Security Operations Center (SOC) auslösen.

7.5 Schwachstellen- und Risikomanagement

Ein verbreiteter Irrtum: EoL-Systeme bräuchten keine Schwachstellenscans mehr, weil es ohnehin keine Patches gibt. Das Gegenteil stimmt. Scannen Sie diese Systeme weiter. Das Ziel verschiebt sich dabei von der Patch-Installation hin zur laufenden Bewertung neuer CVEs und zur Suche nach Workarounds. Wird etwa eine Lücke im Webserver eines EoL-Routers bekannt, lässt sich der Webserver abschalten und die Verwaltung auf SSH umstellen. Die Risikoakzeptanz gehört regelmäßig auf den Prüfstand, mindestens quartalsweise, und sollte von der Geschäftsführung gegengezeichnet werden.

7.6 Backup, Wiederherstellung und Notfallplanung

Die Ausfallrate alter Hardware steigt mit den Jahren spürbar (Stichwort Badewannenkurve). Ein getestetes Backup, idealerweise nach der 3-2-1-1-0-Regel mit unveränderbaren Kopien gegen Ransomware, und ein regelmäßig geprüfter Disaster-Recovery-Plan sind Pflicht.

Abbildung: Die 3-2-1-1-0-Regel

Doch das beste Backup nützt wenig, wenn die proprietäre Hardware für den Restore fehlt. Ein AIX-Backup läuft nicht einfach auf einem x86-Standardserver. Hier zählt eine gesicherte Ersatzteillogistik oder eine Standby-Strategie. Heikel wird es, wenn ein Migrationsprojekt länger dauert als geplant und genau dann die Wartungsverträge auslaufen.

8. Organisatorische Anforderungen

Das Problem der EoL-Hardware beschränkt sich nicht auf den Serverraum. Die Rollen müssen im Rahmen eines funktionierenden Informationssicherheits-Managementsystems (ISMS) klar verteilt sein. IT-Betrieb, Einkauf, Fachbereiche, Compliance und Geschäftsleitung müssen sich abstimmen. Der BSI-Standard 200-1, kompatibel mit ISO/IEC 27001, verlangt dafür sichtbare Rückendeckung aus dem Management. Für Entscheider braucht es verständliche Vorlagen ohne Technik-Jargon, die die finanziellen Folgen beziffern: Was kostet ein dreitägiger Produktionsausfall im Vergleich zu einer vorgezogenen Migration oder zur Absicherung über TPM? Erst damit lassen sich Budgets rational freigeben.

9. Compliance und Audit: Nachweisbarkeit zählt

Prüfer und Behörden akzeptieren den Weiterbetrieb alter Systeme durchaus, sie kennen die wirtschaftliche Realität. Voraussetzung ist, dass der Zustand dokumentiert, bewertet und prozessual abgesichert ist. Nach den NIST-Vorgaben (SP 800-53 für allgemeine Sicherheitskontrollen, SP 800-82 für ICS) müssen für EoL-Geräte „Compensating Controls“ nachgewiesen werden. Findet ein Auditor eine kritische Lücke in einem nicht mehr patchbaren System, sollten Sie sofort vorlegen können:

• Geräte-Limitierung dokumentiert: Modell, Firmware-Version und eine Bewertung, die belegt, dass keine Updates mehr kommen und native Sicherheitsfunktionen fehlen.
• Compensating Controls nachgewiesen: Netzpläne und Firewall-Regeln, die zeigen, wie das Risiko begrenzt wird, etwa das isolierte VLAN.
• Risiko-Akzeptanz unterschrieben: ein formales Dokument mit Risiken, Maßnahmen und verbleibendem Restrisiko, abgezeichnet von IT-Sicherheit, Prozessverantwortlichen und Management.

Wiederholen Sie die Bewertung jährlich, nach jedem internen Audit und bei größeren Architekturänderungen. Ohne diese Nachweise drohen bei einem Vorfall erhebliche rechtliche und finanzielle Folgen, unter NIS-2 bis hin zur persönlichen Haftung von Entscheidern.

10. Migrationsstrategie: Der Weg aus der Abhängigkeit

TPM und kompensierende Maßnahmen verlängern den Lebenszyklus, sind allerdings nicht als Dauerlösung ohne Enddatum geeignet. Jede genehmigte Ausnahme sollte in eine terminierte Ablösestrategie münden. Priorisiert wird nach Risiko und Business Impact. Das aus der Softwarearchitektur bekannte „Strangler-Fig“-Muster lässt sich gut auf Hardware übertragen: Statt eines riskanten Big Bang migrieren Sie Modul für Modul auf neue Plattformen, während die Altsysteme, abgesichert durch TPM und Segmentierung, im Hintergrund weiterlaufen, bis sie gefahrlos abgeschaltet werden können. Das verlangt mehrjährige Budgetplanung und ausreichend Test- und Pilotphasen. Damit dieselbe Falle nicht in ein paar Jahren erneut zuschnappt, sollte schon beim Kauf neuer Hardware deren späteres EoL eingeplant und das Austauschbudget gedanklich reserviert werden.

11. Fazit: EoL-Hardware ist ein kontrollierbares Risiko

Der Weiterbetrieb von EoL-Hardware ist in vielen Unternehmen unvermeidbar, wirtschaftlich nachvollziehbar und in spezialisierten Produktionsumgebungen oft die einzige praktikable Option. Als kontrollierbares und messbares Risiko verstanden, ist EoL kein Tabu. Wer veraltete Systeme dagegen unverändert und ungeschützt im Netz lässt, handelt fahrlässig, verstößt gegen gängige Compliance-Vorgaben und öffnet Ransomware-Gruppen und staatlichen Akteuren den Weg.

Tragend für einen sicheren, audit-festen Weiterbetrieb sind vollständige Transparenz im Asset-Management, konsequente Segmentierung nach Zero-Trust, engmaschiges Monitoring auf Anomalien und klare, vom Management getragene Verantwortlichkeiten. Eine professionelle Drittanbieter-Wartung übernimmt dabei die physische Absicherung, die Fehlerbehebung und die Ersatzteillogistik; die IT-Sicherheit kommt über kompensierende Maßnahmen aus der Architektur. Für jedes Altsystem sollte am Ende trotzdem eine terminierte, budgetierte und in kleine Schritte zerlegte Ablösestrategie stehen.

12. Checkliste EoL-Hardware für IT-Entscheider

Abbildung: Checkliste EoL-Hardware für IT-Entscheider

13. Häufige Fragen (FAQ)

Ab wann ist Hardware offiziell „End of Life“?

Mit dem Last Date of Support (LDoS). Ab diesem Datum bietet der Hersteller keinen Support mehr, Wartungsverträge lassen sich nicht mehr verlängern und Original-Ersatzteile sind über den OEM nicht mehr erhältlich. Sicherheitsrelevant wird es schon früher, nämlich am End of Security Support, ab dem keine Sicherheitspatches mehr erscheinen.

Darf ich EoL-Hardware überhaupt noch betreiben?

Ja. Es gibt kein generelles Verbot. Entscheidend ist, dass der Weiterbetrieb dokumentiert, bewertet und durch kompensierende Maßnahmen abgesichert ist. Prüfer akzeptieren das, solange Sie eine unterschriebene Risikoentscheidung, einen Nachweis der Schutzmaßnahmen und einen Plan zur Ablösung vorlegen können.

Was ist der Unterschied zwischen End of Sale, End of Support und End of Life?

End of Sale bedeutet, dass das Produkt nicht mehr verkauft wird; der Betrieb läuft normal weiter. End of (Engineering) Support beendet die Entwicklung neuer Updates. End of Life ist das endgültige Ende von Support und Ersatzteilversorgung. Dazwischen liegt das sicherheitskritische End of Security Support.

Reicht Third Party Maintenance als alleiniges Sicherheitskonzept aus?

Nein. TPM deckt Hardware-Wartung, Fehlerbehebung und Ersatzteile ab und verlängert den physischen Lebenszyklus. Die IT-Sicherheit müssen Sie zusätzlich über Segmentierung, Härtung und Monitoring absichern. Erfahrene TPMs wie Hardwarewartung.com verfügen über geschulte Security Teams, die bei der Bewertung und Absicherung von Risiken unterstützen können.

Wie sichere ich ein EoL-System konkret gegen Angriffe ab?

In dieser Reihenfolge: lückenlos inventarisieren, in ein isoliertes VLAN verschieben und vom Internet trennen, nicht benötigte Dienste und Protokolle abschalten, starke Authentifizierung und Jump-Hosts vorschalten, alle Zugriffe über ein SIEM überwachen und ein getestetes, unveränderbares Backup vorhalten.

Was muss ich für ein Audit nachweisen?

Drei Dinge: eine Dokumentation der Geräte-Limitierung (Modell, Firmware, fehlende Updates), den Nachweis der kompensierenden Maßnahmen (Netzpläne, Firewall-Regeln, VLAN-Konfiguration) und eine unterschriebene Risiko-Akzeptanz von IT-Sicherheit, Fachbereich und Management. Die Bewertung sollte mindestens jährlich erneuert werden.

Verstoße ich mit EoL-Hardware automatisch gegen NIS-2?

Nicht automatisch. Problematisch wird es, wenn kritische Komponenten ungeschützt und ohne nachweisbare Maßnahmen betrieben werden. NIS-2 verlangt ein angemessenes Risikomanagement und kann Entscheider persönlich in die Haftung nehmen. Wer EoL-Systeme dokumentiert absichert und eine Ablösung plant, bewegt sich im Rahmen der Vorgaben.