Palo Alto beendet den Verkauf von CN-Series. Die Regeln sind der leichte Teil des Umzugs

Palo Alto Networks verkauft die Container-Firewall CN-Series ab dem 1. November 2026 nicht mehr und unterstützt sie bis zum 1. November 2029. So steht es in der End-of-Sale-Mitteilung vom 30. April 2026. Nachfolger ist die AI Runtime Firewall (AIRS), vermarktet als Prisma AIRS. Unserer Einschätzung nach ist das eine Firewall-Migration, erzwungen durch die Neupositionierung eines Produkts, und das Risiko liegt im Verkehrsweg, in der Management-Ebene und in der Tag-Quelle, nicht im Regelwerk.

Die Mitteilung nennt den Nachfolger „AI Runtime Firewall (AIRS), a new product that supports all the use cases of CN-series and VM-series“. Bestandskunden können demnach migrieren und dabei weiter Software NGFW Credits nutzen, Neukunden sollen direkt AIRS einsetzen. Drei Jahre Support klingen großzügig, und für die heute laufenden Cluster sind sie das auch. Ab dem 1. November sind Neukäufe aber AIRS, und unserer Einschätzung nach folgen neue Cluster.

Was ändert sich am 1. November 2026?

Am 1. November 2026 endet die Bestellbarkeit von CN-Series, der Support für bestehende Installationen läuft bis zum 1. November 2029 weiter. An diesem Tag fällt nichts aus. Es ändert sich der Standard: Ab diesem Datum sind Neukäufe Prisma AIRS, und unserer Einschätzung nach folgen neue Kubernetes-Cluster mit Palo-Alto-Schutz. Eine Umgebung, die heute CN-Series nutzt, wird also zur Zwei-Produkt-Umgebung, wenn sie wächst.

Meilenstein	Datum oder Detail
End-of-Sale angekündigt	30. April 2026
Letzter Bestelltag CN-Series	1. November 2026
Supportende	1. November 2029
Von Palo Alto genannter Nachfolger	AI Runtime Firewall (AIRS), deckt laut Hersteller alle Einsatzfälle von CN-Series und VM-Series ab
Lizenzierung für Bestandskunden	Migration unter Weiternutzung der Software NGFW Credits

Alle fünf Zeilen stammen von der End-of-Sale-Seite von Palo Alto. Die Migration selbst beschreibt eine eigene Anleitung, „Migrate Your CN-Series Firewall to Prisma AIRS Network Intercept“. Erst dort wird die eigentliche Änderungsarbeit sichtbar.

Worin unterscheidet sich Prisma AIRS von CN-Series?

CN-Series betreibt die Firewall innerhalb des Kubernetes-Clusters. Prisma AIRS Network Intercept läuft nach Palo Altos eigener Beschreibung des Container-Designs außerhalb des Clusters und erhält den Pod-Verkehr über Tunnel. Dieser eine Unterschied verschiebt den Prüfpunkt und die Fehlerdomäne und eröffnet eine zweite Wahl bei der Management-Konsole.

Palo Altos Seite zu den Kernbausteinen von CN-Series beschreibt einen Management-Pod, CN-MGMT, der als StatefulSet läuft, und einen Datenebenen-Pod, CN-NGFW, der als DaemonSet oder als Kubernetes-Service bereitgestellt werden kann. Im DaemonSet-Modus sichert jede CN-NGFW-Instanz laut Dokumentation 30 Anwendungs-Pods auf demselben Knoten. Panorama ist die zentrale Stelle für Konfiguration und Lizenzierung und beherbergt das Kubernetes-Plugin, das Namespaces, Services und Labels aus den Clustern ausliest und daraus Tags für die Zuordnung von IP-Adressen zu Tags erzeugt.

Die Übersicht zur Container-Sicherheit mit Prisma AIRS beschreibt das andere Modell: „The CNI chaining redirects container traffic out of your Kubernetes cluster to Prisma AIRS AI Runtime: Network intercept, which is deployed outside the cluster.“ Geprüft wird eingehender, ausgehender und Ost-West-Verkehr. Unterstützt werden Kubernetes ab Version 1.30 auf EKS, AKS, GKE, Rancher sowie OpenShift 4.18 bis 4.21. Für On-Premises-Cluster veröffentlicht Palo Alto ein eigenes Helm-Chart.

	CN-Series	Prisma AIRS Network Intercept
Wo geprüft wird	Pods im Cluster (DaemonSet oder Kubernetes-Service)	Außerhalb des Clusters, erreicht über CNI-Chaining-Tunnel
Management	Nur Panorama	Strata Cloud Manager oder Panorama
Kubernetes-Plugin auf Panorama	Erforderlich, erzeugt die IP-zu-Tag-Zuordnung	Entfällt bei Strata Cloud Manager, bleibt bei Panorama
Zusätzliche Lizenz laut Migrationsanleitung	Keine	Strata Logging Service, muss aktiv sein
Weg vom einen zum anderen	CN-Series-Installation entfernen, dann Prisma AIRS ab Version 11.2.x bereitstellen

Warum ist das eine Migration und kein Lizenztausch?

Der Wechsel von CN-Series zu Prisma AIRS ist eine Migration, weil Palo Altos Anleitung die alte Firewall entfernt, bevor die neue bereitgestellt wird. Ein In-Place-Upgrade sieht der dokumentierte Weg nicht vor. Die Änderung hat also die Form eines Cutovers, mit allen Risiken, die dazugehören.

Die Migrationsanleitung nennt vier Schritte: CN-Series-Installation entfernen, Prisma AIRS ab 11.2.x herunterladen, ein Deployment-Profil anlegen, bereitstellen. Entfernen heißt, Persistent Volumes, Persistent Volume Claims und das Kubernetes-Deployment zu löschen, wenn möglich per kubectl delete -f mit den ursprünglichen YAML-Dateien. Bei On-Premises-Clustern sollen laut Anleitung auf jedem Knoten die Verzeichnisse mit CN-Series-Daten gelöscht werden. Die Anleitung, die wir gelesen haben, beschreibt nicht, wie Sicherheitsrichtlinien oder Konfiguration übernommen werden, und sie sagt nichts zu Ausfallzeiten.

Für ein Change Advisory Board zählt diese Form mehr als der Produktname. Ein Rip-and-Replace zurückzurollen heißt, die alte Firewall aus Dateien neu aufzubauen, die hoffentlich jemand aufbewahrt hat. Das ist etwas anderes, als einen Commit rückgängig zu machen. Unser Leitfaden zum Rollback gilt hier vollständig, und die Fehler-Taxonomie für Migrationen führt die meisten Arten auf, wie ein solcher Cutover scheitert.

Wo liegt das Änderungsrisiko?

Unserer Einschätzung nach liegt das Risiko bei der Migration von CN-Series zu Prisma AIRS an vier Stellen, und das Regelwerk gehört nicht dazu. Regeln lassen sich Zeile für Zeile vergleichen. Alles Folgende ändert, wie diese Regeln erreicht, verantwortet und gematcht werden, und nichts davon taucht in einem Regel-Diff auf.

• Der Verkehrsweg. Die Prüfung wandert von einem Pod auf dem Knoten zu einem Ziel außerhalb des Clusters, erreicht über einen Tunnel. Latenz, Fehlerdomäne und das Verhalten des Pod-Verkehrs, wenn das Tunnelziel nicht erreichbar ist, müssen getestet werden, nicht angenommen.
• Die Management-Ebene. Die Anleitung sagt, das Kubernetes-Plugin sei zu entfernen, wenn Strata Cloud Manager die Installation verwaltet, und bei Verwaltung durch Panorama nicht zu deinstallieren. Die Wahl zwischen beiden ist eine Entscheidung darüber, wem die Container-Firewall-Richtlinie nach dem Umzug gehört.
• Die Tag-Quelle. CN-Series-Richtlinien können auf Tags matchen, die das Plugin aus Namespaces und Labels erzeugt. Fällt das Plugin weg, muss etwas anderes diese Tags befüllen. Die Migrationsanleitung verweist dafür auf eine eigene Seite zum Harvesting von IP-Tags, und die Übersicht zum CNI-Chaining nennt für Installationen unter Strata Cloud Manager einen Tag-Collector, der IP-Tags automatisch erfasst. Prüfen Sie vor dem Cutover, ob er jedes Tag liefert, auf das Ihre Regeln matchen. Eine Regel, die auf ein leeres Tag matcht, scheitert ohne Fehlermeldung, genau die Art Lücke, für die es Drift-Erkennung gibt.
• Die neuen Abhängigkeiten. Die Anleitung warnt zweimal, dass die Lizenz für den Strata Logging Service aktiv sein muss, sonst drohen Probleme beim Onboarding oder bei der Terraform-Generierung. Die AIRS-Voraussetzungen verlangen zusätzlich Terraform über 1.3 und unter 2 sowie die Freischaltung des Cloud-Managements in Strata Cloud Manager über den Palo-Alto-Support. Jede dieser Abhängigkeiten hat einen Verantwortlichen, der jetzt in den Change-Datensatz gehört.

Was ändert das „AI“-Etikett für die Verantwortlichen der Firewall?

Prisma AIRS ist Palo Altos Marke für die Absicherung von KI. Die Ankündigung von Prisma AIRS 3.0 vom 23. März 2026 beschreibt ein Produkt, das „the entire Agentic AI lifecycle“ absichern soll. Die Kubernetes-Firewall gehört jetzt zu dieser Familie, neben Agent-Gateways und KI-Red-Teaming.

Wir gehen davon aus, dass Budget und verantwortliches Team der Marke folgen können. Eine Container-Firewall, die im Rahmen eines KI-Sicherheitsprogramms gekauft wird, genehmigen womöglich Leute, die nie im Change Advisory Board für das Netz saßen, und ihre Richtlinie landet vielleicht in einer Konsole, die das Firewall-Team nicht betreibt. Das ist für sich genommen nicht falsch. Zum Problem wird es, wenn niemand es bewusst entscheidet. Legen Sie fest, wem die Container-Firewall-Richtlinie gehört, bevor die Bestellung es für Sie entscheidet.

Was sollte ein Firewall-Team vor dem 1. November tun?

Ein Firewall-Team mit CN-Series sollte die Wochen vor dem 1. November 2026 nutzen, um die Entscheidungen zu treffen, die die Migrationsanleitung offenlässt. Der technische Cutover kann bis zu einem Wartungsfenster 2027 oder 2028 warten. Die Entscheidungen über Verantwortung und Design nicht, denn neue Cluster erzwingen sie unserer Einschätzung nach ohnehin.

1. Jeden CN-Series-Cluster inventarisieren: Bereitstellungsmodus, PAN-OS- und Plugin-Versionen und welche Richtlinien auf Kubernetes-Tags matchen.
2. Zuerst pro Cluster zwischen Strata Cloud Manager und Panorama wählen. Diese Wahl entscheidet, ob das Plugin bleibt, und damit, woher die Tags kommen.
3. Die gemischte Umgebung akzeptieren und einplanen. Neukäufe nach dem 1. November sind AIRS, und unserer Einschätzung nach folgen neue Cluster, während bestehende bis zum Supportende am 1. November 2029 auf CN-Series bleiben können. Behandeln Sie das wie jede Umgebung mit mehreren Plattformen, mit einem Änderungsprozess für beide.
4. Einen Testcluster auf AIRS aufbauen und die Regeltreffer mit derselben Last auf CN-Series vergleichen, bevor ein Produktiv-Cutover ansteht.
5. Den Rollback als Neuaufbau beschreiben, mit aufbewahrten und getesteten CN-Series-YAML-Dateien oder Helm-Werten, statt sie mit den Persistent Volumes zu löschen.

Die grundsätzliche Reihenfolge aus unseren Best Practices für Palo-Alto-Migrationen gilt weiter. Neu ist, wie viel der Arbeit außerhalb der Firewall stattfindet.

Warum das wichtig ist

Drei Jahre Support lassen CN-Series wie ein Thema für später wirken. Unserer Einschätzung nach ist das entscheidende Datum der 1. November 2026, denn ab dann sind Neukäufe ein Produkt mit anderer Architektur, anderer Management-Option und anderen Abhängigkeiten, und wir erwarten, dass die Umgebung darauf wächst. Bei Hunderten von Migrationen taten selten die mit komplizierten Regeln weh. Es waren die, die man als Produkttausch behandelte, während sich darunter der Verkehrsweg geändert hatte. Dieselbe Lektion lernten Cisco-Kunden, als klar wurde, dass ein ASA-Ersatz trotzdem eine Migration ist.

Könnte Ihr Team heute sagen, auf welche Tags Ihre Container-Firewall-Richtlinien angewiesen sind und was sie nach dem Umzug befüllt? Der kostenlose NIS2-Readiness-Check geht die Nachweise durch, die ein Firewall-Änderungsprozess erbringen muss.