Thought Leadership
Palo Alto Stops Selling CN-Series. The Rules Are the Easy Part of the Move
Palo Alto Networks stops selling its CN-Series container firewall on 1 November 2026 and supports it until 1 November 2029, according to the end-of-sale notice dated 30 April 2026. The named successor is AI Runtime Firewall (AIRS), sold as Prisma AIRS. In our view this is a firewall migration forced by product repositioning, and the risk sits in the traffic path, the management plane and the tag source, not in the rule base.
The notice calls the successor "AI Runtime Firewall (AIRS), a new product that supports all the use cases of CN-series and VM-series". It says existing customers can migrate while continuing to use Software NGFW Credits, and that new customers should adopt AIRS. Three years of support sounds generous, and it is, for the clusters running today. From 1 November, new purchases are AIRS, and in our view new clusters will follow.
What changes on 1 November 2026?
On 1 November 2026 CN-Series stops being orderable, while support for existing deployments runs to 1 November 2029. Nothing breaks on the day. What changes is the default: from that date new purchases are Prisma AIRS, and in our view new Kubernetes clusters protected by Palo Alto will follow, so an estate with CN-Series today becomes a two-product estate as it grows.
| Milestone | Date or detail |
|---|---|
| End-of-sale announced | 30 April 2026 |
| Last date to order CN-Series | 1 November 2026 |
| End of support | 1 November 2029 |
| Successor named by Palo Alto | AI Runtime Firewall (AIRS), "supports all the use cases of CN-series and VM-series" |
| Licensing for existing customers | Migrate "while continuing to use Software NGFW Credits" |
All five rows come from the Palo Alto end-of-sale page. The migration itself is documented in a separate guide, "Migrate Your CN-Series Firewall to Prisma AIRS Network Intercept", and that guide is where the change work becomes visible.
How is Prisma AIRS different from CN-Series?
CN-Series runs the firewall inside the Kubernetes cluster. Prisma AIRS Network Intercept, in Palo Alto's own description of its container design, runs outside the cluster and receives pod traffic through tunnels. That one difference moves the inspection point and the failure domain, and it opens a second choice of management console.
Palo Alto's page on CN-Series core building blocks describes a management pod, CN-MGMT, that "runs as a StatefulSet", and a data-plane pod, CN-NGFW, that "can be deployed as a DaemonSet or as a Kubernetes Service". In DaemonSet mode, "each instance of the CN-NGFW pod can secure 30 application pods running on the same node." Panorama "functions as the hub for managing the configuration and licensing" and hosts the Kubernetes plugin, which "collects namespaces, services, and labels from your Kubernetes clusters to create tags for the IP-address-to-tag mapping…"
The Prisma AIRS container security overview describes the other model: "The CNI chaining redirects container traffic out of your Kubernetes cluster to Prisma AIRS AI Runtime: Network intercept, which is deployed outside the cluster." It inspects inbound, outbound and east-west traffic, and lists Kubernetes 1.30 or later on EKS, AKS, GKE, Rancher and OpenShift 4.18 to 4.21. For on-premises clusters Palo Alto publishes a separate Helm chart.
| CN-Series | Prisma AIRS Network Intercept | |
|---|---|---|
| Where inspection runs | Pods in the cluster (DaemonSet or Kubernetes Service) | Outside the cluster, reached by CNI-chaining tunnels |
| Management | Panorama only | Strata Cloud Manager or Panorama |
| Kubernetes plugin on Panorama | Required; builds the IP-to-tag mapping | Removed if managed by Strata Cloud Manager, kept if managed by Panorama |
| Extra licence named in the migration guide | None | Strata Logging Service, must be active |
| Path from one to the other | Remove the CN-Series deployment, then deploy Prisma AIRS 11.2.x or later | |
Why is this a migration and not a licence swap?
The CN-Series to Prisma AIRS move is a migration because Palo Alto's guide removes the old firewall before the new one is deployed. There is no in-place upgrade in the documented path, so the change has the shape of a cutover, with every risk that comes with one.
The migration guide lists four steps: remove the CN-Series deployment, download Prisma AIRS 11.2.x or later, create a deployment profile, deploy. Removal means deleting the persistent volumes, the persistent volume claims and the Kubernetes deployment, where possible with kubectl delete -f against the original YAML. For on-premises clusters the guide says to "delete the directories containing CN-Series firewall data on each node." The guide we read does not describe how security policy or configuration carries over, and it says nothing about downtime.
For a change board, that shape matters more than the product name. Rolling back a rip-and-replace means redeploying the old firewall from files somebody kept, which is a different exercise from reverting a commit. Our rollback guide applies here in full, and the migration failure taxonomy lists most of the ways a cutover like this goes wrong.
Where does the change risk sit?
In our view the risk in a CN-Series to Prisma AIRS migration sits in four places, and the rule base is not one of them. Rules can be compared line by line. Everything below changes how those rules are reached, owned and matched, and none of it shows up in a rule diff.
- The traffic path. Inspection moves from a pod on the node to a target outside the cluster, reached through a tunnel. Latency, the failure domain and what happens to pod traffic when the tunnel target is unavailable all become questions to test, not assume.
- The management plane. The guide says: "Remove the Kubernetes plugin if your Prisma AIRS: Network Intercept deployment is managed by Strata Cloud Manager. If the deployment is managed by Panorama, do not uninstall the Kubernetes plugin." Choosing between the two is a decision about who owns the container firewall policy after the move.
- The tag source. CN-Series policies can match on tags that the plugin builds from namespaces and labels. If the plugin goes, something else has to fill those tags. The migration guide points to a separate Harvest IP tags page, and the CNI chaining overview names a tag collector for deployments managed by Strata Cloud Manager, for "automated IP tag harvesting". Before cutover, confirm that it reproduces every tag your rules match. A rule that matches an empty tag fails without an error, which is exactly the kind of gap drift detection exists to catch.
- The new dependencies. The guide warns twice that the Strata Logging Service licence must be active, "to avoid issues with onboarding or Terraform generation." The AIRS prerequisites add Terraform above 1.3 and below 2, and enabling cloud management in Strata Cloud Manager through Palo Alto support. Each dependency has an owner who now belongs in the change record.
What does the "AI" label change for the firewall owners?
Prisma AIRS is the brand Palo Alto uses for securing AI. Its Prisma AIRS 3.0 announcement of 23 March 2026 describes a product that "secures the entire Agentic AI lifecycle". The Kubernetes firewall now sits inside that family, next to agent gateways and AI red teaming.
Our view is that the budget and the owning team can follow the brand. A container firewall bought as part of an AI security programme may be approved by people who have never sat on the network change board, and its policy may end up in a console the firewall team does not run. None of that is wrong in itself. It becomes a problem when nobody decides it on purpose. Write down who owns the container firewall policy before the purchase order decides it for you.
What should a firewall team do before 1 November?
A firewall team running CN-Series should use the weeks before 1 November 2026 to make the decisions the migration guide leaves open. The technical cutover can wait for a maintenance window in 2027 or 2028. The ownership and design decisions should not, because, in our view, new clusters will force them anyway.
- Inventory every CN-Series cluster: deployment mode, PAN-OS and plugin versions, and which policies match on Kubernetes tags.
- Choose Strata Cloud Manager or Panorama per cluster first. That choice settles whether the plugin stays and therefore where tags come from.
- Accept the mixed estate and plan for it. New purchases after 1 November are AIRS, and in our view new clusters will follow, while existing ones can stay on CN-Series until support ends on 1 November 2029. Treat it like any multi-platform estate, with one change process across both.
- Build a test cluster on AIRS and compare rule hit counts against the same workload on CN-Series before any production cutover.
- Write the rollback as a redeploy, with the CN-Series YAML or Helm values kept and tested, not deleted with the persistent volumes.
The general sequencing in our Palo Alto migration best practices still holds. What is new is how much of the work lives outside the firewall.
Why it matters
Three years of support makes CN-Series feel like a problem for later. In our view the date that matters is 1 November 2026, because from then on new purchases are a product with a different architecture, a different management option and a different set of dependencies, and we expect the estate to grow on it. Across hundreds of migrations, the ones that hurt were rarely the ones with complicated rules. They were the ones treated as a product swap when the traffic path had changed underneath. The same lesson applied when Cisco customers learned that an ASA replacement is still a migration.
Could your team say today which tags your container firewall policies depend on, and what fills them after the move? The free NIS2 Readiness Check walks through the evidence a firewall change process has to produce.
