Operationalizing Post-Quantum Cryptography in SASE and SD-WAN

Operationalizing Post-Quantum Cryptography in SASE and SD‑WAN

Versa has demonstrated post-quantum cryptography in IPsec tunnels under formal evaluation conditions where the platform had to prove successful tunnel establishment, encrypted traffic flow, and re-key integrity using post-quantum algorithms.

These “real world” evaluation conditions matter, because most post-quantum security conversations still live in one of three places: standards committees, vendor roadmaps, or lab demos disconnected from production network behavior. The proof point that Versa has demonstrated is the fact that two distributed edge devices can negotiate post-quantum key material, establish IPsec, pass traffic, and survive re-key without silently falling back to classical cryptography.

That is the line Versa tested against for a globally reputable governmental organization.

The quantum problem is no longer theoretical for long-lived traffic

Quantum risk is usually described as a future event. For enterprise networks, the risk has already started because encrypted traffic can be captured today and decrypted later if the key exchange is vulnerable to a cryptographically relevant quantum computer.

That “harvest now, decrypt later” model changes how security teams should evaluate SD-WAN and SASE platforms. A tunnel that is safe only against today’s compute model may not be good enough for government, defense, satellite, financial, healthcare, and critical infrastructure networks whose data has a shelf life measured in years.

NIST finalized its first post-quantum cryptography standards in 2024, including FIPS 203 for ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism. ML-KEM is designed for quantum-resistant key establishment.

It is not enough if the algorithms exist. For Universal SASE, the practical question is whether the platform can use post-quantum key exchange and data encryption ciphers across the full spectrum of network functions that carry enterprise traffic.

PQC across the Versa Universal SASE Platform

Versa Universal SASE is a single-platform architecture spanning SD-WAN, SSE (Security Services Edge, ZTNA, Advanced Security Cloud), SD-LAN, and NGFW — all running on the Versa Operating System (VOS). This is important for PQC because the cryptographic transition cannot be limited to just one function.

In a traditional siloed architecture, upgrading the SD-WAN to support PQC while leaving the SSE gateway, or control plane on classical cryptography creates exactly the kind of partial migration that adversaries can exploit. Versa’s single-OS architecture means PQC is applied uniformly across:

• SD-WAN branch-to-branch and branch-to-controller IPsec tunnels
• SSE cloud gateways protecting internet-bound and SaaS traffic for forward and reverse proxy use cases
• ZTNA sessions connecting remote users to private applications

The image below illustrates how Versa’s management, control, and data planes connect across branch, cloud, and user access deployment options — all of which inherit PQC protection as the platform transitions.

This is the architectural advantage of a Universal SASE platform for post-quantum migration: one codebase, one OS and supporting microservices, one migration path. There is no separate roadmap for the SSE vendor, the SD-WAN vendor, or the NGFW vendor.

What Operational PQC Looks Like in Versa Universal SASE

Implementing PQC is not as simple as swapping a software library. The hard part is inserting post-quantum key exchange into real data-in-transit security for branch onboarding, controller-mediated key distribution, tunnel formation, re-keying, and failover — without breaking operations or forcing a network redesign.

Versa uses NIST-approved post-quantum algorithms delivered through a purpose-built, controller-mediated key distribution architecture — built on BGP SAFI (Subsequent Address Family Identifier), the same scalable routing protocol already running across the network. Key aspects of this key distribution architecture include:

• Hybrid IPsec tunnels: Established with ECDH + ML-KEM512/ML-KEM1024, combining classical and post-quantum key exchange so no single cryptographic assumption carries all the risk.
• Active controller participation: The controller actively receives, stores, and propagates each branch’s post-quantum public keys to peers across the network.
• BGP SAFI key distribution: BGP SAFI is a standard protocol extension that lets BGP carry non-routing information. Versa uses it to distribute post-quantum public keys alongside existing routing updates, with no separate key management infrastructure required. As new sites are added, it scales automatically with zero-touch provisioning.
• Quantum-safe from the first packet: When a branch joins, it shares its public keys with the controller, which distributes them to all peers — so any two branches already have what they need to establish a hybrid tunnel immediately, with no extra configuration steps.

Use Cases: Where PQC Delivers Real Protection

Multi-Site Branch Onboarding

Each new branch establishes a hybrid ECDH + ML-KEM IPsec tunnel to the controller, creates an MP-IBGP (Multiprotocol Internal BGP) session over that PQC-protected path, and shares its post-quantum public keys via BGP SAFI. The control plane — the most sensitive channel in any SD-WAN deployment — is protected against harvest-now-decrypt-later from the moment a branch first connects.

Branch-to-Branch Traffic in Hybrid Mode

Once branches have onboarded, the controller distributes each branch’s PQ public keys to peers. Branches establish a hybrid tunnel: an initial ephemeral ECDH IPsec session carries the ML-KEM ciphertexts, which are decapsulated by the receiving branch. Through Versa’s unique differentiated key derivation, the ECDH and ML-KEM shared secrets are combined before deriving the final IPsec session keys — ensuring both classical and post-quantum components contribute simultaneously. Compromising either alone is not sufficient to break the session.

Not a single data packet traverses the network before PQC-compliant key negotiation is complete.

Subsequent re-keys maintain the same PQC algorithms — no downgrade, no exceptions. Private key material never traverses the network.

Sovereign and Air-Gapped Deployments

For government, defense, and critical infrastructure customers, Versa’s on-premises Private SASE / Sovereign SASE model means PQC operates entirely within the customer’s infrastructure. There is no cloud-based key management dependency. Controller, Director, and branch appliances exchange PQC key material within the customer’s perimeter — relevant for satellite ground stations, defense networks, and national infrastructure operators with strict data residency requirements.

Long-Haul and High-Value Data Paths

Financial transactions, healthcare records, and intellectual property traversing WAN links today may be subject to retrospective decryption if classical key exchange is used. Versa’s unified platform applies PQC consistently across all traffic types — branch-to-branch, branch-to-DC, remote user ZTNA, and cloud-destined SSE traffic — rather than selectively hardening one path while leaving others exposed.

What was Actually Tested

The evaluation plan centered on three concrete checks.

• Devices had to negotiate a PQC key exchange algorithm during IKEv2 Phase 1 and reach an established Security Association (SA) state — no classical Diffie (DH)-only result permitted.
• IPsec ESP Child SA had to be installed and pass bidirectional traffic with incrementing counters.
• Re-key had to maintain the same PQC algorithm with no silent fallback to classical Diffie-Hellman.

That last requirement is critical. A platform that starts quantum-safe but reverts during re-key is not operationally quantum-safe under any compliance standard.

What about data-in-transit encryption?

Post-quantum key exchange protects how session keys are established. Data in transit continues to be encrypted with AES-256-GCM, a widely validated symmetric cipher that provides both confidentiality and integrity — and remains quantum-safe for the foreseeable future.

The Packet Evidence matters

The packet capture from the evaluation shows IKE_SA_INIT traffic with AES-GCM-256, ECP group 19, and ADDKE transforms with IDs 35 and 37. These are the IANA-assigned identifiers for ML-KEM512 and ML-KEM1024. This is consistent with the multiple-key-exchange design used for hybrid IKEv2. Hybrid post-quantum IKEv2 is the practical migration path: combining classical ECDH with ML-KEM means the session is not dependent on a single cryptographic assumption.

Because key material is derived from both ECDH and ML-KEM, a vulnerability in either component alone does not compromise the session — giving enterprises a verifiable migration path without replacing proven cryptographic primitives wholesale.

Hardware Support for PQC

Versa supports post-quantum cryptography across its full appliance, hub and gateway portfolio. All platforms run ML-KEM without functional limitation; higher-end appliances benefit from hardware acceleration for deployments at greater scale.

Customers can adopt PQC on existing hardware today. For high-scale deployments, the accelerated platforms deliver the best performance without a forklift upgrade.

Why this Changes the SASE Conversation

SASE buyers usually compare platforms on convergence, policy, private access, secure web gateway, firewalling, and operations. PQC adds a new axis: cryptographic agility in the transport fabric itself.

That is especially relevant for a single-vendor SASE platform as secure SD-WAN is the foundational layer. It is the underlay-aware, policy-aware fabric that connects branches, users, cloud workloads, and security enforcement points. If the fabric cannot evolve cryptographically, the rest of the architecture inherits that weakness.

Versa’s PQC work is notable because it is being tested where the risk actually sits: site-to-site IPsec tunnels, branch onboarding, branch-to-branch key exchange, and re-key behavior. Those are the places where long-lived encrypted enterprise traffic is created and needs to be most protected.

For regulated and sovereign environments, the implication is direct. The future requirement will not be “does the vendor mention PQC?” It will be “show me the tunnel, show me the negotiated algorithm, show me the Child SA, show me the traffic counters, and show me the re-key.”

CNSA 2.0 and the Path to Full Compliance

Versa’s hybrid model — ECDH + ML-KEM — is the correct transition posture. CNSA 2.0, the NSA’s mandatory quantum-resistant cryptography standard for security systems, explicitly anticipates a hybrid period before pure post-quantum key exchange becomes the standard. Full compliance requires ECDH to eventually be retired in favor of ML-KEM alone, and digital signatures to migrate from ECDSA to ML-DSA or SLH-DSA by 2030. Versa’s roadmap is structured to meet that timeline.

For updates on additional use cases — including TLS forward and reverse proxy and client-to-gateway TLS — contact your Versa account team for the latest results.

What to ask your SASE Vendor

Post-quantum readiness should not be evaluated through a feature checklist. It should be evaluated through observable tunnel behavior. A few questions to consider:

• Does the platform support NIST-standardized algorithms such as ML-KEM?
• Does it use a hybrid key exchange model with classical and post-quantum components?
• Does PQC apply only to both control and data plane connections?
• Does the tunnel re-key preserve the post-quantum exchange or does it permit downgrade?
• Is the solution demonstrable with actual packet captures?

Most importantly, ask whether the vendor can demonstrate PQC within the operational constraints of a real SASE deployment.

Versa’s testing shows a practical path: hybrid ECDH plus ML-KEM, controller-assisted branch key distribution, IPsec Child SA validation, bidirectional traffic confirmation, and re-key checks designed to catch downgrade behavior.

To learn more click here.