Post-Quantum Cryptography on WAN Technologies: Current State and Performance Impact

Executive summary

For WAN and SD-WAN teams, post-quantum cryptography (PQC) is now a deployment decision rather than a planning exercise. The NIST algorithms are final, and Fortinet, Cisco and Palo Alto Networks all shipped production PQC across 2025 and 2026. 

The practical cost of adopting it lies in one place: the connection handshake, where larger keys and signatures add bandwidth overhead, while compute impact stays microsecond-scale and steady-state throughput is unchanged once the tunnel is up. That makes a WAN-first, hybrid migration both viable today and urgent, because harvest now, decrypt later (HNDL) collection is already underway, and set U.S. commercial and government timelines to 2030-2035 for networking equipment.

In August 2024, NIST published its first finalized PQC standards: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for signatures and SLH-DSA (FIPS 205) as a hash-based alternative, based on CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+. This note covers those algorithms, current SD-WAN vendor readiness, performance versus classical cryptography, hybrid implementation guidance and a phased migration strategy.

Performance testing supports the WAN-first case. With AVX2 hardware optimization, ML-KEM (Kyber) completes its operations in roughly 0.022 to 0.047 milliseconds, depending on the security level. Once a tunnel is established, the AES-256 data plane performs identically to classical implementations. The tradeoff is on-wire size: Larger keys, ciphertext and signatures add about 2 to 4 KB to the handshake, which is negligible on healthy links but can slow connection setup on constrained or high-latency networks.

WAN modernization should not happen in isolation. The PKI and certificate changes this migration requires are the same ones needed on the campus LAN, so WAN and LAN PQC planning should be coordinated. For the campus and MACsec side of that work, see our companion WWT Research Note, Post-Quantum Cryptography Support in the Campus LAN.

About the harvest now, decrypt later (HNDL) threat

Adversaries are already collecting encrypted traffic today to decrypt once a cryptographically relevant quantum computer (CRQC) arrives, potentially within the next decade. Long-lived WAN data is the prime target, which is why WAN infrastructure is first in line for migration.

Remember, Q-Day — when quantum computers get powerful enough to break today's widely used public-key cryptography — is merely when the bad guys cash out on HNDL attacks. There is nothing you can do to prevent HNDL until you apply NIST PQC algorithms, since that's when HNDL threats stop being valuable.

Who should read this note

This WWT Research Note is intended for network architects, engineers and IT business stakeholders who run, maintain or build complex global networks.

Summary of PQC threats

Here is a simple table outlining what's vulnerable versus what is safe in the current landscape.

*See https://csrc.nist.gov/projects/post-quantum-cryptography

NIST PQC standards and adoption timeline
 

Standardized algorithms

In August 2024, NIST released three finalized post-quantum cryptography standards after years of rigorous evaluation:

1. ML-KEM (FIPS-203) - Module-Lattice-Based Key-Encapsulation Mechanism

• Based on CRYSTALS-Kyber
• Primary use: Secure key exchange for encryption
• Three security levels: Kyber-512, Kyber-768, Kyber-1024

2. ML-DSA (FIPS-204) - Module-Lattice-Based Digital Signature Algorithm

• Based on CRYSTALS-Dilithium
• Primary use: Digital signatures for authentication
• Three security levels: Dilithium-2, Dilithium-3, Dilithium-5

3. SLH-DSA (FIPS-205) - Stateless Hash-Based Digital Signature Algorithm

• Based on SPHINCS+
• Primary use: Alternative signature scheme
• Hash-based security foundation

Hamming Quasi-Cyclic (HQC): Backup KEM

In March 2025, NIST selected Hamming Quasi-Cyclic (HQC) as a backup key-encapsulation mechanism alongside ML-KEM, with formal FIPS standardization expected in 2026–2027. HQC's significance lies in its mathematical foundation: It is code-based rather than lattice-based, providing algorithmic diversity in the event a structural weakness is discovered in lattice cryptography. 

For crypto-agility planning, this means enterprise platforms should be designed to support both lattice (ML-KEM) and code-based (HQC) KEMs, with the ability to switch primary algorithms without infrastructure replacement. HQC's public keys and ciphertexts are larger than ML-KEM's, so its bandwidth profile differs and warrants separate performance modeling once vendor implementations are available.

Regulatory and compliance drivers

U.S. government mandates: The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) and NSM-10 set the federal timeline that is shaping enterprise planning, even though they bind national security systems and federal agencies rather than private networks. CNSA 2.0 calls for exclusive use of quantum-resistant algorithms in networking equipment such as VPNs and routers by 2030, in operating systems and applications by 2033, and across all national security systems by 2035, aligning with the 2035 federal goal under NSM-10. Complementary frameworks, including FIPS validation and Common Criteria, govern how those PQC implementations are certified.

Industry Urgency: According to the 2025 Cisco Cybersecurity Readiness Index, 31% of respondents ranked the network as the most challenging area to protect against cyberattacks — more than any other infrastructure component.

Harvest Now, Decrypt Later (HNDL) Threat: Adversaries are already collecting encrypted traffic today to decrypt once a cryptographically relevant quantum computer (CRQC) arrives, potentially within the next decade. Long-lived WAN data is the prime target, which is what puts WAN infrastructure first in line for migration.

Symmetric encryption perspective

AES (Advanced Encryption Standard) remains quantum-resistant for symmetric encryption. AES-256 is considered secure against quantum attacks using Grover's algorithm, though the effective security level is reduced to approximately AES-128 equivalent in a quantum computing environment.

Critical distinction: The quantum vulnerability lies not in AES itself but in the asymmetric cryptography (RSA, ECDH, ECC) used to establish and exchange AES session keys.

SD-WAN vendor implementations
 

Fortinet – FortiOS 7.6 (July 2025)

Fortinet has emerged as a commercial leader in PQC implementation for SD-WAN environments. In July 2025, Fortinet released FortiOS 7.6 with comprehensive post-quantum cryptography capabilities across its firewall and SD-WAN platforms. Fortinet's subsequent FortiOS 8.0 release further expands this offering.

Implementation details:

• PQC algorithms integrated: ML-KEM, ML-DSA for quantum-safe key exchange and digital signatures
• Platform support: FortiGate Next-Generation Firewalls with Secure SD-WAN capabilities
• Quantum-safe features: Algorithm stacking (crypto-agility), support for hybrid modes combining classical and PQC algorithms

Partnership with Quantum Xchange: Fortinet partnered with Quantum Xchange to deliver quantum-safe SD-WAN solutions using Phio TX, a key delivery and management system. Phio TX from Quantum Xchange works with FortiGate Next-Generation Firewalls to provide immediate quantum-safe security to Fortinet Secure SD-WAN environments.

FIPS 203 validation: Quantum Xchange's Phio TX received FIPS 203 validation (NIST CAVP certificate #6060) for ML-KEM implementation, becoming among the first NIST-validated PQC key delivery solutions for VPN environments. The latest Phio TX version 4.5 (released September 2025) features multiple key generation methods for crypto-agility.

Cisco – 8000 Series Secure Routers (2026)

Cisco positioned its 8000 Series Secure Routers as purpose-built quantum-safe WAN solutions. Announced in January 2026, these routers feature dedicated cryptographic engines designed to handle PQC workloads without compromising performance.

Technical approach:

• Hardware acceleration: Quantum-Flow Processor (QFP) ASIC in high-end models, secure networking processor ASIC in branch/campus routers
• Immediate protection: Support for RFC 8784 with Post-Quantum Pre-Shared Keys (PPKs) for quantum-safe IKEv2 IPsec
• Native PQC support: Hybrid encryption based on RFC 9370, combining legacy and NIST-approved quantum-safe methods
• Firmware and software integrity: LMS (NIST SP 800-208) for quantum-safe boot and image signing

Protocol coverage: Cisco is rolling out native PQC across its public key cryptography solutions, with core IKEv2 IPsec support available now and remaining capabilities phasing in through the second half of 2026 (IOS-XE 26.2). Coverage includes:

• IKEv2 IPsec
• SD-WAN
• FlexVPN
• DMVPN (Dynamic Multipoint VPN)
• IKEv2 Cluster Load-balancing
• MACsec with EAP-TLS
• SSH

WAN-first strategy: Cisco advocates the same WAN-first approach and pioneered RFC 8784 to integrate PPKs into existing key exchange mechanisms.

Palo Alto Networks – PAN-OS 12.1 Orion (August 2025)

Palo Alto Networks introduced enterprise-wide quantum readiness capabilities with its PAN-OS 12.1 Orion release in August 2025.

Key features:

• Quantum Readiness Dashboard: Provides NGFW and SASE customers with detailed insights into encryption posture and cryptographic risk assessment
• Cipher translation capability: Industry-first feature that can instantly upgrade non-quantum-safe applications to quantum-safe encryption
• Hardware optimization: 14 new fifth-generation NGFW models with hardware acceleration for post-quantum cryptography
• Crypto-agility: Emphasis on the ability to switch between PQCs easily if one algorithm is compromised

Platform support: Available for PAN-OS 11.1 or later across NGFW and SASE deployments. The solution provides automated cloud and AI workload discovery with native deployment and scaling of protections.

Migration framework: Palo Alto Networks adapted the Quantum Economic Development Consortium (QED-C) five-step model for planning and preparing the transition to post-quantum security:

1. Assign Resources and Build Awareness
2. Define Responsibilities
3. Develop a Crypto Inventory and Priority List
4. Evaluate Solutions, Experiment, and Test
5. Continue to Monitor Progress

Vendor comparison table

*Quantum Xchange is included for completeness, but it is a key delivery and management partner rather than an SD-WAN platform vendor. Phio TX integrates with Fortinet (and other) infrastructure to provide PQC key services; it is not a standalone SD-WAN solution.

Performance analysis: PQC vs classical cryptography in SD-WAN

PQC adoption carries two distinct costs, and they behave very differently on a WAN. Computational overhead is microsecond-scale and confined to tunnel establishment, while the higher cost is on-wire size, which lands in the handshake and scales with network conditions.

Once a tunnel is up, the AES-256 data plane performs identically to a classical deployment, so steady-state throughput is unaffected.

Computational overhead: Minimal and bounded to setup

Bottom line: The processing cost is tiny and happens only while a connection is being set up, so live traffic and existing hardware are unaffected.

Key exchange adds about 0.022 to 0.047 ms per ML-KEM operation with AVX2 optimization, competitive with ECDH at equivalent security.

ML-DSA signing runs 0.077 to 0.144 ms and verification runs 0.028 to 0.071 ms; this cost occurs during tunnel establishment and certificate validation rather than in steady state.

Working memory for ML-DSA-65 is tens of KB per signing operation, well within the RAM capacity of any modern SD-WAN edge device or NGFW, so RAM is not a meaningful constraint at any tier.

On-wire size: The dominant WAN factor

Bottom line: PQC makes the connection setup messages bigger, and on a WAN, that extra data is the one thing worth planning around.

At equivalent security, ML-KEM-768 public key is 1,184 bytes versus 64 bytes for ECDH P-256, about 18 times larger, and its ciphertext is 1,088 bytes versus roughly 64 bytes, about 17 times larger. 

ML-DSA-65 public key is 1,952 bytes versus 64 bytes for ECDSA P-256, about 30 times larger, and its signature is 3,309 bytes versus 64 to 72 bytes, about 46 times larger. 

A hybrid ML-KEM exchange, therefore, adds roughly 2 to 4 KB to the initial handshake, calculated from these sizes rather than measured, with certificate-heavy handshakes adding more.

Per-operation speed is competitive, so size is what drives WAN overhead.

Component impact: VPN gateways and SD-WAN edge

Bottom line: The load lands on the central hub that terminates many tunnels at once, so size the head-end for it, and the branch devices will keep up.

On VPN and IPsec gateways, CPU rises by a single-digit percentage during tunnel establishment and returns to baseline afterward, bandwidth increases because IKEv2 exchange messages are larger, and the load concentrates on the head-end terminating many tunnels at once. 

On SD-WAN edge devices, cryptographic operations are viable with AVX2 optimization. The main concern is the added packet overhead for control-plane communications, and hybrid mode is recommended for backward compatibility.

What drives real-world impact: Network conditions

Bottom line: Users on healthy links will not notice — the impact shows up on weak or lossy links, and a small change to the connection window recovers much of it.

Network conditions matter more than the PQC operations themselves. 

On healthy links, the increase in connection establishment time is under 5%, while on constrained or high-loss links, it commonly runs 10 to 30% and can climb higher under heavy packet loss. 

Operating at the highest security levels, for example, ML-KEM-1024 or ML-DSA-87, adds delay under suboptimal conditions. 

Hybrid schemes add little beyond pure PQC, so defense-in-depth does not incur a meaningful performance penalty. 

TCP congestion window behavior is pivotal: a small increase to the initial congestion window can cut the observed slowdown by up to 50%.

Hybrid PQC implementation: Best practice approach
 

Why a hybrid approach is recommended

Industry best practices advocate hybrid key establishment that combines classical and PQC algorithms. Hybrid keys provide an extra layer of security by creating encryption keys with multiple key exchange mechanism (KEM) technologies. Best practice combines a strong classical KEM (such as Diffie-Hellman Group 21) with one or more PQCs.

Rationale:

1. Transition security: If one PQC KEM succumbs to a vulnerability, the other KEMs still protect the key.
   1. Real-world validation: In WWT's opinion, PQCs require 5-10 years of real-world migration experience before the industry can have confidence in the various integrations and best practices.
2. Backward compatibility: Ensures interoperability with systems that haven't yet adopted PQC.
3. Regulatory compliance: Meets requirements while providing defense-in-depth.

RFC standards supporting hybrid implementation

Key standards enabling PQC in SD-WAN/VPN deployments

• RFC 8784: Post-Quantum Pre-Shared Key (PPK) integration for IKEv2—pioneered by Cisco
• RFC 9867: 8784+9370 (Mixing Preshared Keys in the IKE_INTERMEDIATE)
• RFC 9370: Multiple Key Exchange (hybrid KEM) for IKEv2
• RFC 9242: Additional IKEv2 extensions for PQC integration

NSA CNSA 2.0: Commercial National Security Algorithm Suite 2.0 (NSA Cybersecurity Advisory, September 2022, with timelines updated through 2024). Defines the U.S. government's authoritative roadmap for PQC adoption in National Security Systems and supersedes the retired Suite B.

Implementation challenges and considerations

WWT is seeing this play out in the field. In a live PQC proof of concept we ran for a global financial services firm, with key and certificate lifecycle handled through Keyfactor, the pattern matches the analysis above: The cryptographic operations are the easy part, and the real work is crypto asset inventory, certificate automation and flagging older edge gear that will need a refresh. That same hands-on experience informs our direct collaboration with Cisco and Palo Alto Networks on how quantum-safe cipher suites land in production WAN products.

Crypto-agility: The ability to switch easily and quickly between PQCs if one algorithm is compromised. This requires using multiple PQC algorithms simultaneously and maintaining infrastructure flexibility.

Network optimization strategies:

• Increase TCP Congestion Window to mitigate the impact of larger handshake data.
• Optimize certificate chain composition.
• Configure MTU (Maximum Transmission Unit) appropriately for PQC packet sizes.
• Implement intelligent failover between PQC and classical algorithms based on network conditions.

Strategic recommendations
 

Immediate priorities (2026 H2)

1. Begin with WAN infrastructure: Prioritize SD-WAN, VPN and edge router upgrades, the assets most vulnerable to HNDL attacks.
2. Implement RFC 8784/9370/9867 PPKs: Deploy post-quantum pre-shared keys for immediate protection while native PQC solutions mature.
3. Harden existing encryption: Align with CNSA 2.0 cipher suites: AES-256-GCM, RSA-3072 (or larger), and SHA-384/512. Avoid AES-128 and deprecated Suite B references.
4. Conduct a cryptographic inventory: Focus on comprehensive discovery of all cryptographic dependencies across the network.

Medium-term strategy (2026-2028)

1. Deploy hybrid PQC solutions: Implement ML-KEM + classical DH, combining quantum-safe and proven algorithms.
2. Hardware refresh cycles: Align network equipment upgrades with PQC-capable hardware (e.g., crypto-accelerated routers and firewalls).
3. Pilot programs: Test PQC implementations in non-production environments before enterprise-wide rollout.
4. Training and awareness: Build organizational understanding of PQC requirements and migration processes.

Long-term vision (2029-2035)

1. Full PQC migration: Complete transition to native PQC algorithms across all network infrastructure.
2. Regulatory compliance: Meet CNSA 2.0 milestones, with quantum-safe networking equipment by 2030 and full transition across national security systems by 2035.
3. Continuous monitoring: Maintain crypto-agility to respond to new algorithm vulnerabilities or advances.
4. Post-quantum secure boot: Extend quantum protection to firmware, authentication, and system integrity.

Conclusion

Post-quantum cryptography implementation in SD-WAN technology has progressed from theoretical planning to commercial availability in 2025-2026. Major vendors — Fortinet, Cisco and Palo Alto Networks — have released production-ready solutions incorporating NIST-standardized ML-KEM and ML-DSA algorithms.

Performance benchmarks demonstrate that PQC is computationally viable for SD-WAN deployments. With hardware acceleration, ML-KEM adds only 0.022-0.047 milliseconds per key exchange operation — negligible overhead for connection establishment. The primary performance consideration is increased bandwidth consumption during handshake phases (2-4 KB additional data) rather than computational burden. Once VPN tunnels are established, data-plane performance with AES-256 encryption remains identical to that of classical implementations.

The industry consensus strongly recommends hybrid PQC approaches that combine classical and post-quantum algorithms during the 5-10-year transition period. This provides defense-in-depth security while PQC algorithms undergo real-world validation. The WAN-first sequence follows directly from the HNDL exposure of long-lived WAN traffic.

Organizations should begin PQC migration immediately, starting with cryptographic inventory, infrastructure planning and phased deployments beginning with WAN edge equipment. With U.S. government timelines calling for quantum-safe networking equipment by 2030 and a full transition by 2035 and quantum threats potentially emerging within the next decade, proactive action is essential to protect against both current HNDL attacks and future quantum decryption capabilities.

References
 

NIST standards

NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024.

NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, August 2024.

NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, August 2024.

NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process, July 2022.

NIST announcement of HQC selection as additional KEM, March 2025 (formal FIPS publication expected 2026–2027).

IETF RFCs

RFC 8784, Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security, June 2020.

RFC 9242, Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2), May 2022.

RFC 9370, Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), May 2023.

RFC 9867, Mixing Preshared Keys in the IKE_INTERMEDIATE Exchange of IKEv2, 2025.

U.S. government guidance

NSA Cybersecurity Advisory, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), September 2022 (with updates through 2024).

National Security Memorandum 10 (NSM-10), Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems, May 2022.

OMB Memorandum M-23-02, Migrating to Post-Quantum Cryptography, November 2022.

Vendor documentation

Fortinet, FortiOS 7.6 / 8.0 Release Notes and PQC capability documentation.

Cisco, 8000 Series Secure Routers product documentation and Quantum-Safe Networking white papers, 2025–2026.

Palo Alto Networks, PAN-OS 12.1 Orion release notes and Quantum Readiness documentation, August 2025.

Quantum Xchange, Phio TX 4.5 documentation and FIPS 203 validation certificate, September 2025.

Industry reports and research

Cisco, Cybersecurity Readiness Index, 2025.

Quantum Economic Development Consortium (QED-C), Five-Step Quantum Migration Framework.

Note: This references list provides primary-source pointers for the standards, RFCs, vendor documentation and research cited in this paper. Benchmark figures for ML-KEM and ML-DSA operation times and AVX2 speedups are cited inline to Demir et al. (2025). Algorithm key, ciphertext and signature sizes are per NIST FIPS 203 and 204. Network-level estimates for CPU, bandwidth and constrained-network overhead are directional and vary with hardware and link conditions.