Streamlining Innovation and Stability: The New 12.1 PAN-OS Release Cycle & Support Policy

[rohsawhney]

At Palo Alto Networks, we understand that your security operations rely on a delicate balance: you need the latest innovations to stop emerging threats, but you also require absolute stability in your network infrastructure.

To better serve this need, we are standardizing our release cycle and support policy starting with PAN-OS 12.1. This new framework is designed to provide you with a longer (stable, simple), and more predictable roadmap for your firewall upgrades and feature adoption.

Here is a summary of what is changing and how it benefits you.

1. A New 4-Year Support Commitment

We are extending the lifecycle for all Major PAN-OS versions (starting with 12.1). Every major release will now be supported for a total of 48 months, split into two phases:

• Standard Support (3 Years): This includes full support—Software/Content updates, bug and vulnerability fixes, and maintenance releases.
• Extended Support (1 Year): Automatically following the standard period, this phase focuses on end of life and migration to a new version. It covers critical needs only, specifically Priority 1 (P1) stability issues and Critical/High severity vulnerability fixes.

This is reflected publicly on our Palo Alto Networks End-of-Life Policy

2. Faster Access to Innovation

Our new release lifecycle is designed to deliver rapid innovation followed by unwavering predictability.

During the initial Innovation Phase (the first 12 months), we will deliver two targeted Feature Releases (FRs) to introduce new capabilities, enhancements, and hardware support alongside standard maintenance updates. Immediately following this period, the release enters a dedicated Stability Phase for the remainder of its lifecycle, where the focus shifts exclusively to reliability with strictly bug and vulnerability fixes—ensuring your long-term infrastructure remains rock-solid and unchanged. Summary visual of this lifecycle below:

3. Simplified Version Terminology

We are simplifying our release terminology to reduce confusion.

• Major Versions (X.Y): We have streamlined our definitions—releases such as 11.1, 11.2, and 12.1 are all considered Major Versions. Each one undergoes the same rigorous QA process, supports new hardware, and is backed by our support lifecycle.
• Maintenance Releases (.Z): These are standard updates (e.g., 12.1.4) focused strictly on stability, bug fixes, and vulnerability remediation.
• Feature Releases (FR): Beginning with PAN-OS 12.1, select Maintenance releases that introduce new capabilities will be explicitly labeled as Feature Releases (FR) within our Release Notes so you can easily identify when new innovation is included.
• Hotfixes (-h#): Think of these as Targeted Releases. Far from being "unstable patches," these are production-grade builds scoped to deliver specific, high-priority solutions immediately for customers who need them, without waiting for the next general maintenance cycle.
  
  

4. Choosing the Right Version: "TAC Preferred"

For customers prioritizing maximum stability over the newest features, we continue to provide the TAC Preferred release guidance.
A release earns the "Preferred" tag only after it has been proven stable through significant customer adoption. To qualify, a release must have:

• Significant time in the field (minimum 4 weeks)
• Large install base (>10,000 on a Major Maintenance Release)
• No high-impact P1/P2 issues, widespread bugs, or regression

To help you make data-driven decisions, our guidance page now includes monthly adoption metrics, historical preferred releases, and direct links to known and addressed issues for every supported version.

5. Updates to End-of-Life Policy & Support Resources

We have listened to your feedback and updated our policies and external documentation to be clearer and more transparent.

• "Extended Support" is the New Standard: We have officially evolved "Limited Support" to "Extended Support." This isn't just a name change—this now explicitly guarantees fixes for all Critical and High vulnerabilities (CVSS ≥ 7.0).
• Simplified Hardware & Software Tables: We have decluttered our End-of-Life summary pages by removing complex footnotes and consolidating them into clear, example-based notes to answer your most common FAQs.

These updates are reflected on our End-of-Life Policy along with HW End-of-Life Dates and SW End-of-Life Summary pages respectively.
 

Summary

Effective with PAN-OS 12.1, we are standardizing our release cycle to deliver a predictable roadmap with extended support timelines. This new framework balances the agility to adopt innovations quickly via Feature Releases with the confidence of long-term stability.

[Brandon_Wertz]

Very much needed.  Great to see Palo going this direction.

[C.Pfitzer]

I like those changes a lot.

One more wish with regard to new hardware models:

It is not OK that new hardware models always only support the latest major release. This leads to a situation which we had now with the 500 series. It was released around August and just recently in April the first 12.1 version got the preferred tag. For a customer it looks like you release a new model and for many month no PAN-OS version is available for it which you consider stable.

And even the now preferred 12.1.4 version is only preferred for the new models, not for the older ones, which again indicates that you only made it preferred for the new models because the pressure from customers was too high and you had to come up with something at least for the new models.

[Brandon_Wertz]

@C.Pfitzer -- Comments are valid, especially when the hardware is multiple order of six-figures, ie...the new 5500 series hardware.  If there was someway for the second newest software release to work on the newest hardware it would allow customers to migrate to newer hardware while still running a proven stable OS.

When a customer is running the newest hardware with the newest code there 1000% always be instability.  New hardware with proven existing code maybe only 989% chance of instability?  In all seriousness, the user experience in the latter scenario would have to be a more stable experience.