Skip to main content
PQVPN

Vendor compatibility

Palo Alto Networks post-quantum VPN support

PA-Series appliances, VM-Series virtual firewalls and CN-Series running PAN-OS and terminating site-to-site IPsec, managed standalone or through Panorama.

Last reviewed

2 compatibility records

Direct answer

Palo Alto Networks post-quantum VPN capability is determined by the PAN-OS release running on each firewall, and by whether the specific hardware model is supported on that release. Establish the PAN-OS version per device, confirm the model is on the supported list for the target release, and confirm the peer's capability. Panorama version constraints apply separately where configuration is centrally managed.

Practical status

What this means in a real estate

PAN-OS estates tend to be well documented, which makes the inventory step faster than average, but they are often deliberately held on a specific maintenance release for stability reasons. The realistic constraint is usually change appetite rather than capability: the migration plan has to fit the estate's existing PAN-OS upgrade cadence rather than fight it. Record PAN-OS version, model and Panorama version for every firewall before proposing waves.

Key establishment

What to establish about key exchange

Establish per PAN-OS release which IKEv2 mechanism is available — RFC 8784 preshared key mixing, RFC 9370 additional key exchanges, or neither — and how it is expressed in the IKE crypto profile. Confirm whether the setting is available through Panorama templates as well as locally, since a capability that cannot be pushed centrally does not scale across a large estate.

Authentication

Why authentication is a separate question

A hybrid key exchange on a PAN-OS tunnel does not alter peer authentication. The IKE gateway continues to authenticate with its configured certificate or preshared key, and post-quantum authentication remains a separate question about certificate and PKI support for post-quantum signature algorithms.

Products and versions

Compatibility records

Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.

Palo Alto Networks post-quantum support by product and version range. Every row carries its own review date; none of them is a statement about the vendor as a whole.
ProductKey establishment
PA-Series, VM-Series and CN-Series running PAN-OSPost-quantum key establishment: Requires exact-version review
PA-Series and VM-Series running PAN-OSPost-quantum key establishment: Unsupported

PA-Series, VM-Series and CN-Series running PAN-OS

11.x

Establish which mechanism the specific PAN-OS maintenance release exposes in the IKE crypto profile, and whether it can be set from a Panorama template.

Migration implication: Where Panorama manages both ends of a tunnel, the migration artifact is a template change with a defined push order, not two independent device changes.

Caveats

  • Older PA-Series models reach end of support on newer PAN-OS trains
  • Configuration reachable only locally does not scale in a Panorama-managed estate

Last reviewed · low confidence · 2 sources

PA-Series and VM-Series running PAN-OS

10.2.x

Estates held on an older maintenance train for stability need the capability question answered for that train specifically, not for the current one.

Migration implication: If the capability requires a train upgrade, the migration plan inherits the estate's PAN-OS upgrade governance and its timeline, which is usually the longer of the two.

Caveats

  • A train upgrade may be a larger change than the migration it enables

Last reviewed · medium confidence · 1 source

Prerequisites

Establish these before assessing migratability.

  • PAN-OS version per firewall, including maintenance release
  • Hardware model support status for the intended target release
  • Panorama version where templates and device groups are in use
  • Content and application release compatibility for the target PAN-OS version

Peer compatibility

A tunnel is governed by the weaker of its two peers.

  • Both gateways must support and negotiate the same mechanism
  • Where Panorama manages both ends, the push order must be planned so the tunnel is not left mismatched
  • Third-party peers require independent confirmation of their release capability

Operational limitations

Constraints that shape the plan rather than block it.

  • Older PA-Series models reach end of support on the newer PAN-OS trains
  • PAN-OS upgrades are typically governed by a slower change cadence than a configuration change
  • Template-driven configuration requires the change to be modelled in Panorama first

Migration paths

The routes available when the current state is not the target.

  • Upgrade PAN-OS to a release carrying the capability where the model is supported
  • Replace models that will not be supported on the target release
  • Terminate an overlay gateway where a PAN-OS upgrade cannot be scheduled in time
  • Defer and track against the estate's existing PAN-OS roadmap

Verification requirements

What must be evidenced before a change is recorded as complete.

  • Confirm the negotiated key exchange on the established IKE SA
  • Verify on both members of an active/passive HA pair
  • Capture evidence before and after the change for the change record

Sources

No primary sources have been recorded for this entry yet. Until they are, nothing here is presented as a confirmed capability.

Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.

Related reading

Need this mapped to your actual Palo Alto Networks estate?

A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.

Scope Your VPN EstateExplore the Compatibility Matrix
Or schedule a call