Bildquelle: Bildquelle: Pexels / Field Engineer / https://www.pexels.com/photo/electronics-engineer-fixing-cables-on-server-442150/
Auslaufende Firewalls und VPN-Gateways müssen früher in die IT-Steuerung
Viele IT-Organisationen entdecken Supportenden bei Edge-Systemen erst dann mit voller Wucht, wenn bereits ein Projekt unter Zeitdruck gestartet werden muss. Eine Firewall erreicht ihr End-of-Support-Datum, ein VPN-Gateway bekommt keine Sicherheitsupdates mehr, ein Load Balancer hängt auf alter Firmware fest, und plötzlich geht es nicht mehr nur um ein Technikthema. Es geht um Risiko, Budget, Beschaffung, Wartungsfenster und die Stabilität geschäftskritischer Zugänge.
Genau hier setzt die neue CISA-Richtlinie BOD 26-02 vom Februar 2026 an. Sie beschreibt End-of-Support-Edge-Devices ausdrücklich als erhebliches und dauerhaftes Risiko, weil diese Systeme am Netzwerkrand sitzen, aus dem Internet erreichbar sind und oft tief mit Identitätsdiensten, Routing, Segmentierung oder Fernzugriff verzahnt bleiben. Auch wenn die Richtlinie formal für US-Bundesbehörden gilt, ist die Managementlogik universell: Unsupported Edge Devices dürfen nicht wie normale Altlasten behandelt werden, sondern brauchen ein eigenes Steuerungsmodell.
Für IT-Management ist das wichtig, weil genau diese Systeme selten isoliert ausfallen. Wenn an der Perimeter-Schicht etwas hängen bleibt, betrifft das meist nicht nur ein Admin-Team, sondern Nutzerzugänge, Partneranbindungen, Standorte, Dienstleister, Remote-Arbeit und im Zweifel die Incident-Lage des gesamten Hauses. Fünf Steuerungsschritte sollten deshalb 2026 verbindlich werden.
1. Das Edge-Portfolio vollständig inventarisieren, nicht nur einzelne Herstellerprodukte
Der häufigste Fehler ist ein zu enger Blick auf klassische Firewalls. In der Praxis gehören aber deutlich mehr Komponenten zur Edge-Schicht: VPN-Konzentratoren, Web Application Firewalls, Reverse Proxys, SD-WAN-Appliances, Load Balancer, Internet-Router, WAN-Controller, NAC-nahe Gateways und teils auch drahtlose Controller oder virtuelle Netzwerkfunktionen in Colocation- und Cloud-Umgebungen.
Ein belastbares Inventar braucht deshalb mehr als Gerätelisten. Pro Komponente sollten mindestens Produkt, Version oder Firmware-Stand, Supportstatus, Standort oder Mandant, technischer Owner, betroffener Business Service, Internet-Exponierung und angebundene Identitäts- oder Managementsysteme erfasst sein. Erst dann sieht das Management, welche Systeme wirklich kritisch sind. Eine alte Appliance im Nebenstandort ist etwas anderes als ein zentrales VPN-Gateway für externe Mitarbeitende und Dienstleister.
Wichtig ist außerdem die logische Sicht. Viele Teams wissen, wo ein Gerät physisch steht, aber nicht sauber, welche Services darüber tatsächlich laufen. Genau diese Transparenz entscheidet später darüber, ob ein Austausch als Standard-Change reicht oder als größeres Migrationsvorhaben geführt werden muss.
2. Supportdaten mit Exponierung und Betriebsabhängigkeit zu einer Prioritätenliste verdichten
Ein End-of-Support-Datum allein sagt noch nicht, was zuerst angefasst werden muss. Entscheidend ist die Kombination aus Termin, Angriffsfläche und Betriebsabhängigkeit. CISA formuliert das sehr klar: Gerade öffentlich erreichbare und nicht mehr gepflegte Edge-Systeme erhöhen das Risiko unverhältnismäßig stark. In ihrer Bad-Practices-Liste bezeichnet die Behörde unsupported Software in internetnahen Umgebungen ausdrücklich als gefährliche Praxis.
Für die Steuerung heißt das: IT-Management sollte eine Prioritätenlogik einziehen, die mindestens drei Fragen beantwortet. Erstens, ist die Komponente direkt oder indirekt aus dem Internet erreichbar? Zweitens, welche Kernprozesse hängen daran? Drittens, wie aufwendig ist eine Ablösung technisch und organisatorisch? Eine auslaufende Außenstellen-Firewall mit einfacher Konfiguration hat eine andere Migrationslogik als ein hoch integrierter zentraler Zugangspunkt mit MFA, Standortkopplungen, Partnerzugängen und Change-Abhängigkeiten.
Aus dieser Sicht entsteht eine echte Heatmap. Sie trennt Geräte mit hohem Risiko und kurzer Restlaufzeit von jenen, die zwar ebenfalls abgelöst werden müssen, aber nicht sofort Programmpriorität bekommen. Ohne diese Verdichtung bleiben Lifecycle-Listen oft operative Excel-Artefakte statt belastbarer Managementgrundlage.
3. Für Ausnahmen ein hartes EOS-Register mit Owner, Restlaufzeit und Exit-Pfad einführen
In fast jedem Unternehmen gibt es Fälle, in denen ein Gerät nicht rechtzeitig ersetzt werden kann. Vielleicht hängt ein Providerwechsel daran, vielleicht fehlt ein Wartungsfenster, vielleicht kommt neue Hardware nicht rechtzeitig oder die Zielarchitektur ist noch nicht entschieden. Solche Fälle lassen sich nicht immer vermeiden. Gefährlich wird es dann, wenn Ausnahmen stillschweigend laufen.
Jede Abweichung vom vendor-gestützten Zielzustand sollte deshalb in ein zentrales Register. Dort gehören ein benannter Business Owner, ein technischer Owner, der Grund für die Ausnahme, das exakte Enddatum, kompensierende Maßnahmen und ein dokumentierter Exit-Pfad hinein. Kompensierende Maßnahmen können zum Beispiel engere Logging- und Monitoring-Regeln, beschränkte Managementzugänge, zusätzliches Segmentieren oder beschleunigte Backout-Vorbereitung sein. Sie ersetzen den Austausch nicht, machen das Risiko aber wenigstens transparent und steuerbar.
Der entscheidende Punkt ist die Restlaufzeit. Eine Ausnahme ohne klares Ablaufdatum wird in der Praxis fast immer zur neuen Normalität. Genau das widerspricht der CISA-Linie, unsupported Komponenten so schnell wie möglich aus dem Betrieb zu nehmen und Migrationen in Planung und Budget verbindlich zu verankern.
4. Beschaffung, Migrationsbudget und Change-Fenster deutlich früher binden
Edge-Modernisierung scheitert selten an der Einsicht, sondern an der Taktung. Neue Appliances brauchen Vorlauf, Architekturentscheidungen ziehen Freigaben nach sich, Managed-Service-Verträge müssen angepasst werden, Zertifikate, Routing, Policies, Hochverfügbarkeit und Rollback-Szenarien kosten Testzeit. Wer damit erst kurz vor dem Supportende beginnt, verschiebt das Risiko einfach in ein hektisches Umsetzungsprogramm.
IT-Management sollte deshalb für alle priorisierten EOS-Fälle mindestens zwölf Monate vor Fristablauf prüfen, welcher Beschaffungs- und Umsetzungsweg realistisch ist. Das gilt besonders für zentrale Firewalls, SASE- oder SD-WAN-Komponenten und VPN-Plattformen mit vielen Abhängigkeiten. In solchen Fällen muss die Lifecycle-Planung direkt in Budgetrunden, Portfoliosteuerung und CAB-nahe Terminplanung hinein.
Praktisch bewährt sich ein Dreischritt: zuerst das Zielbild und den Migrationspfad festlegen, dann Budget und Lieferweg absichern, danach die Betriebsumstellung mit klaren Test- und Fallback-Fenstern terminieren. So wird aus einem Sicherheitsproblem ein steuerbares Investitions- und Betriebsprojekt.
5. Decommissioning als eigene Führungsroutine behandeln, nicht als letzten Technikschritt
Viele Organisationen konzentrieren sich stark auf die Inbetriebnahme der Nachfolgeplattform und behandeln das Abschalten des Altgeräts als Formsache. Genau dort entstehen aber Rest-Risiken: alte Managementpfade bleiben offen, Konfigurationen werden nicht bereinigt, DNS- oder Routing-Reste zeigen weiter auf Altkomponenten, Dokumentation bleibt widersprüchlich und der Service Desk arbeitet noch mit veralteten Eskalationswegen.
CISA verlangt in ihrer Richtlinie nicht ohne Grund ausdrücklich die Decommissionierung identifizierter EOS-Geräte und den Aufbau eines kontinuierlichen Discovery- und Inventurprozesses. Für Unternehmen lässt sich daraus eine klare Führungsroutine ableiten: Ein Austausch ist erst abgeschlossen, wenn Altgeräte technisch entfernt, Zugänge geschlossen, Monitoring angepasst, Betriebsdokumentation aktualisiert und Verantwortlichkeiten für den neuen Stand bestätigt sind.
Gerade für ITSM-nahe Organisationen ist dieser Punkt wichtig. Incident-, Change- und Problem-Management müssen wissen, wann ein Altgerät offiziell nicht mehr im Regelbetrieb ist. Sonst entstehen Schattenkonfigurationen, falsche Runbooks und unnötige Eskalationen im Störungsfall.
Fazit
Auslaufende Firewalls und VPN-Gateways sind 2026 kein Randthema der Netzwerkteams mehr. Sie sind ein Managementthema an der Schnittstelle von Risiko, Servicekontinuität, Beschaffung und Architektur. Wer Edge-Systeme nur als technische Assets betrachtet, reagiert zu spät. Wer sie als eigenes Steuerungsobjekt führt, kann Prioritäten setzen, Ausnahmen sauber begrenzen und Migrationen rechtzeitig durch den Betrieb bringen. Genau das macht den Unterschied zwischen hektischem Austausch unter Druck und kontrollierter Lifecycle-Steuerung.
