Ihre ASA ist ohne Support. Der Weg zu FTD bleibt eine Migration

Für die ASA 5506-X, 5508-X und 5516-X endete der Cisco-Support am 31. August 2026. Wenn diese Geräte noch Traffic durchlassen, läuft die anstehende Migration ohne Herstellernetz, und der Umstieg auf Ciscos eigenen Nachfolger macht sie nicht kleiner. Der Wechsel von ASA auf Firepower Threat Defense (FTD) übersetzt das gesamte Regelwerk, genau wie ein Herstellerwechsel. Damit gehört FTD in eine Ausschreibung mit allen anderen.

In denselben zwei Wochen sind zwei Dinge passiert. Die Supportfrist ist abgelaufen. Eine Woche später, am 7. September, veröffentlichte Gartner den Magic Quadrant 2026 für Hybrid Mesh Firewall: Fortinet, Palo Alto Networks und Check Point sind die einzigen Leader, Cisco steht als Visionary im Quadranten. Keiner der beiden Punkte sagt einem ASA-Betrieb allein, was zu tun ist. Zusammen kippen sie die Annahme, auf der die meisten Verlängerungspläne stillschweigend beruhen: dass Cisco zu bleiben die Option mit der geringsten Änderung sei.

Welche ASA-Modelle jetzt ohne Support sind

Die ASA-5500-X-Familie ist in Wellen aus dem Support gefallen, und die Welle, die gerade gebrochen ist, ist die letzte große. Die Daten stehen in Ciscos eigenen End-of-Life-Bekanntmachungen; Tracker-Seiten von Drittanbietern weichen davon teils ab, maßgeblich sind Ciscos Angaben.

Modell	Verkaufsende	Letzter Supporttag	Von Cisco genannter Nachfolger
ASA 5512-X, 5515-X	25.08.2017	31.08.2022	ASA-5506-X-Serie (inzwischen selbst ohne Support)
ASA 5525-X, 5545-X, 5555-X	04.09.2020	30.09.2025	Firepower 2100
ASA 5506-X	02.08.2021	31.08.2026	Firepower 1000
ASA 5508-X, 5516-X	02.08.2021	31.08.2026	Firepower 1000

Für die 5512-X und 5515-X hat Cisco als Migrationsziel die 5506-X-Serie empfohlen, und auch dieser Pfad ist jetzt abgelaufen. Wer 2017 Ciscos Empfehlung wörtlich gefolgt ist, hat eine Migration hinter sich und die nächste vor sich. Die Bekanntmachung für 5508-X und 5516-X hat außerdem schon am 28. Oktober 2025 die Verlängerung von Serviceverträgen beendet, zehn Monate vor dem eigentlichen Supportende.

Warum eine Migration nach der Frist ein anderes Projekt ist

Eine Migration, die vor dem letzten Supporttag geplant ist, hat einen Rückweg: Geht die Umschaltung schief, fällt man auf eine unterstützte Box zurück und versucht es im nächsten Wartungsfenster erneut. Nach diesem Datum gibt es keinen unterstützten Zustand mehr, auf den man zurückkehren kann. Die alte ASA steht noch da, aber sie ist jetzt ein bekannter Endzustand, kein sicherer. Das verändert drei Dinge an der Durchführung der Änderung.

• Rollback wird zur Überbrückung. Der Rückfall auf die ASA kauft eine Nacht. Jeder Rollback-Plan braucht ein Ablaufdatum, dieselbe Disziplin wie bei einer Notfall-Änderung, die sich selbst zurücknimmt.
• Zeitdruck führt zu Lift-and-Shift. Unter Fristdruck wird das Regelwerk so migriert, wie es ist, inklusive redundanter und verschatteter Regeln, mit dem Versprechen, später aufzuräumen. Vorher aufzuräumen ist billiger. Regelwerk-Optimierung und das Außerbetriebnehmen alter Regeln verkleinern, was übersetzt werden muss.
• Das Change Advisory Board bewertet das Risiko anders. Ein Board, das 2025 „Firewall ersetzen“ freigegeben hat, hat eine geplante Änderung freigegeben. Dieselbe Arbeit ist heute eher eine Behebung, und die Nachweise sollten das auch so sagen: was ohne Support lief, wie lange und warum.

ASA zu FTD ist kein Upgrade, sondern eine Übersetzung

In einem Cisco-Betrieb liegt die Annahme nahe, dass die Änderung klein bleibt, wenn man bei Cisco bleibt. Für das Regelwerk stimmt das nicht. FTD ist ein anderes Betriebssystem mit einem anderen Policy-Modell und wird in der Regel über das Firewall Management Center verwaltet statt über die ASA-Kommandozeile. Ciscos eigener Leitfaden zum Secure Firewall Migration Tool benennt offen, was nicht automatisch mitkommt:

• Die Systemkonfiguration wird nicht migriert.
• Ausgehende ACLs werden ignoriert, Kommentare in Access-Listen werden nicht unterstützt.
• Dynamisches Routing wird nicht migriert, und bei Route-Maps mit mehreren Sequenznummern kommt nur die erste mit.
• Eine einzelne ACL, die auf mehr als 50 Interfaces angewendet ist, wird nicht unterstützt.
• Beim Remote-Access-VPN werden SSL-Einstellungen nicht migriert, LDAP-Server kommen mit der Verschlüsselung „none“ an, und die Standard-Gruppenrichtlinie bleibt zurück.

Jede dieser Zeilen ist Handarbeit, und einige davon sind stille Sicherheitsrückschritte, wenn niemand sie bemerkt. Ein LDAP-Server ohne Verschlüsselung besteht jeden Funktionstest und fällt im Audit durch. Das Werkzeug markiert unterwegs auch redundante und verschattete Regeln, und die Liste oben beschreibt schlicht, woraus die Arbeit besteht: eine Übersetzung zwischen zwei Policy-Modellen, mit Punkten, die ein Mensch neu aufbauen und prüfen muss.

Dasselbe Cisco-Werkzeug akzeptiert Check Point, Palo Alto Networks und Fortinet als Quelle. Fortinets FortiConverter führt Cisco ASA 7.x, 8.x und 9.x als unterstützte Quelle, mit ACLs, NAT, Objekten und VPN unter den konvertierten Objekten. Die Wettbewerber bauen Werkzeuge, um ASA-Konfigurationen zu übernehmen, und Cisco baut Werkzeuge, um deren Konfigurationen zu übernehmen. Die Übersetzung fällt an, egal welches Logo auf der neuen Box steht.

Die Option, die in den meisten Plänen fehlt: ASA-Software auf neuer Hardware

Es gibt einen dritten Weg, und nur er hält die Änderung wirklich klein. Ciscos aktuelle Appliances können beide Anwendungen betreiben. Der Reimage-Leitfaden für ASA und Threat Defense nennt unter anderem Firepower 1000, Secure Firewall 1200, Firepower 2100, Secure Firewall 3100 und 4200 als Modelle, die entweder ASA-Software oder FTD unterstützen. Ein ASA-Bestand kann also auf unterstützte Hardware wechseln und dabei die ASA-Konfigurationssprache, die Kommandozeile und das dazugehörige Betriebswissen behalten.

Dieser Weg hat echte Kosten, und die sollten aufgeschrieben statt später entdeckt werden. Er verschiebt die Migration auf das neue Policy-Modell, statt sie zu vermeiden. Die Übersetzung wird also später bezahlt, nach eigenem Zeitplan statt nach Ciscos. Wer dieselbe Box später von ASA auf FTD umstellt, macht ein Reimage, und der Leitfaden sagt deutlich, was das bedeutet: „All existing configuration will be lost and the default configuration applied.“ Die gesamte Konfiguration geht verloren. Für ein Team unter Fristdruck kann dieser Tausch richtig sein. Er gehört als Entscheidung ins Protokoll.

Drei Optionen, verglichen an der Änderung selbst

Option	Arbeit am Regelwerk	Betriebliche Änderung	Was aufgeschoben wird
ASA-Software auf neuer Cisco-Hardware	Am geringsten: gleiche Konfigurationssprache	Gering: gleiche CLI und Werkzeuge	Der Wechsel auf ein neues Policy-Modell
FTD mit dem Cisco-Migrationswerkzeug	Volle Übersetzung, dokumentierte manuelle Lücken	Hoch: neuer Manager, neues Policy-Modell	Nichts, aber die Herstellerwahl fällt per Voreinstellung
Anderer Hersteller mit dessen Konverter	Volle Übersetzung, herstellerspezifische Lücken	Hoch: neuer Manager, neue Plattform, Schulung	Nichts; die Ausstiegskosten fallen jetzt an

Lesen Sie die Tabelle spaltenweise, nicht zeilenweise. Die mittlere und die untere Option tragen dieselbe Art von Arbeit am Regelwerk. Über Hunderte Migrationen hinweg zeigt sich dasselbe Muster: Der Aufwand steckt in der Übersetzung und in der Prüfung dessen, was das Werkzeug nicht mitnehmen konnte, nicht im Auspacken der Hardware. Die Fehler-Taxonomie ist bei einem Wechsel innerhalb eines Herstellers dieselbe wie bei einem Herstellerwechsel, weil die Fehler im Policy-Modell sitzen.

Was der Magic Quadrant ändert und was nicht

Gartners Einordnung sagt nichts darüber, ob eine FTD-Migration funktioniert. Sie zeigt, wohin sich der Markt bewegt, und dieses Signal ist ein Jahr alt. Schon in der ersten Ausgabe im August 2025 stand Cisco als Visionary im Quadranten, und Gartner vermerkte eines der niedrigsten Neukundenvolumen im Markt. In der Ausgabe 2026 schreibt Gartner laut SDxCentral, Ciscos Angebot werde für neue Kundenprojekte selten in die engere Wahl gezogen, und einige Kunden berichteten weiterhin von „bugs, unstable firmware, and frequent patching“.

Für einen ASA-Betrieb ist die nützliche Lesart enger als „weg von Cisco“. In beiden bisherigen Ausgaben hat das Analystenhaus, auf das sich die meisten Einkaufsabteilungen berufen, Cisco außerhalb der Leader eingeordnet. Das reicht, um eine offene Ausschreibung gegenüber einer Finanzabteilung zu begründen, die sonst fragen würde, warum man nicht einfach verlängert hat. Es reicht nicht, um den Gewinner zu bestimmen. Das erledigt die Ausschreibung.

So führen Sie die Entscheidung als Ausschreibung

Eine ASA-Ablösung, die Datenblätter vergleicht, gewinnt der Hersteller mit der besten Durchsatzzahl auf Seite eins. Eine Ausschreibung, die die Änderung vergleicht, entscheidet sich an dem, was tatsächlich Geld kostet. Vier Fragen leisten den Großteil der Arbeit.

• Lassen Sie jeden Bieter, Cisco eingeschlossen, seinen Konverter auf Ihre echte Konfiguration anwenden und die Liste der nicht konvertierten Objekte zurückgeben. Länge und Inhalt dieser Liste sind das ehrlichste Preissignal im ganzen Verfahren.
• Bepreisen Sie die betriebliche Änderung, nicht nur die Lizenz. Ein neuer Manager, ein neues Policy-Modell und Schulungen kosten Aufwand in derselben Größenordnung, ob die neue Plattform FTD heißt oder nicht. Die Beiträge zu Palo Alto zu Fortinet und Check Point zu Palo Alto zeigen, wo dieser Aufwand tatsächlich anfällt.
• Legen Sie den Umfang der Bereinigung vor der Ausschreibung fest. Jede Regel, die Sie vorher stilllegen, muss kein Bieter übersetzen und niemand prüfen.
• Halten Sie das Übergangsrisiko schriftlich fest. Laufen ASAs während der Ausschreibung über den letzten Supporttag hinaus weiter, sollte die Änderungsdokumentation sagen, welche, hinter welchem Schutz und bis wann. Genau dieses Dokument wird später jemand verlangen.

Ist die Umgebung bereits gemischt, gehört die Frage der Multi-Vendor-Verwaltung ebenfalls in die Ausschreibung: Eine zweite Plattform, die aus Bequemlichkeit dazukommt, wird zu dauerhaften Betriebskosten.

Warum das wichtig ist

Der letzte Supporttag wird oft als Hardware-Ereignis behandelt, und die Budgets folgen dieser Sicht: Box tauschen, Hersteller behalten, Änderung minimieren. Bei der ASA war es ein Policy-Ereignis. Jeder realistische Weg bis auf einen verlangt, das Regelwerk in ein neues Modell zu übersetzen, und dieser eine Weg verschiebt die Übersetzung nur. Sobald das klar ist, lautet die Frage nicht mehr „welche Box ersetzt die ASA“, sondern „in welchem Policy-Modell wollen wir das nächste Jahrzehnt arbeiten, und was kostet es, sauber dorthin zu kommen“. Diese Frage beantworten eine Ausschreibung und ein bereinigtes Regelwerk.

Würde Ihre Änderungsdokumentation zeigen, welche ASAs nach dem 31. August weiterliefen, und warum? Der kostenlose NIS2-Readiness-Check geht die Nachweise durch, die ein Firewall-Änderungsprozess erbringen muss.