Quantum-Safe Networking: ML-KEM in Corporate VPNs and TLS

TL;DR

Post-quantum key exchange is already in production TLS at Cloudflare, Google, Apple and AWS, and OpenSSH ships hybrid PQC by default. For a corporate stack the practical move today is the X25519+ML-KEM-768 hybrid on TLS 1.3 termination and on VPN tunnels that support it — not a rip-and-replace, not QKD hardware, and not new certificates yet.

Why now — the harvest-now-decrypt-later problem

Any classical key exchange recorded today can be decrypted retroactively once a cryptographically relevant quantum computer exists. For traffic protecting secrets with a long shelf life — legal, medical, IP, source code, long-lived credentials — the deadline is the data's lifetime, not Q-Day. Hybrid ML-KEM closes that window without waiting.

ML-KEM in one page

ML-KEM (Module-Lattice Key Encapsulation Mechanism), standardised as FIPS 203, is a lattice-based KEM derived from CRYSTALS-Kyber. Three parameter sets ship: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. ML-KEM-768 is the mainstream target for TLS and VPNs — roughly AES-192 equivalent post-quantum security, about 1.1 KB of extra handshake traffic, and negligible CPU cost on modern hardware.

It replaces the key-agreement step only. Symmetric encryption (AES-GCM, ChaCha20-Poly1305) is already considered quantum-safe at 256-bit key sizes and does not need to change.

TLS 1.3 — what's shipping

• Cloudflare, Google Chrome, Apple iCloud Private Relay: hybrid X25519+ML-KEM-768 in production TLS 1.3 handshakes.
• AWS: hybrid ML-KEM available on ALB / CloudFront and AWS KMS TLS termination.
• Microsoft: PQC support in SymCrypt and preview endpoints in Azure.
• OpenSSL 3.2+ and BoringSSL support hybrid ML-KEM code points; enable at the listener.

Practical action for a corporate origin: enable the hybrid group on the load-balancer or reverse proxy (Cloudflare / nginx-with-BoringSSL / ALB), leave classical groups active for compatibility, and verify with a browser build that supports the code point.

Corporate VPNs

Support today, by protocol:

• IPsec / IKEv2 — strongSwan and Libreswan support hybrid PQC key exchange via RFC 8784 pre-shared-key mixing and, more recently, native ML-KEM proposals in IKEv2.
• WireGuard — mainline WireGuard is classical only; hybrid forks (Rosenpass, WireGuard-PQ) add ML-KEM alongside the existing Curve25519 handshake.
• OpenVPN — with an OpenSSL 3.2+ build exposing ML-KEM code points, hybrid TLS is available on the control channel.
• SSL VPNs (Cloudflare Access, Zscaler, Netskope) — inherit the TLS termination story above; verify the vendor advertises hybrid ML-KEM.

Rollout plan

1. Inventory: list every VPN concentrator and TLS terminator, the library each one uses, and its version.
2. Pick canaries: one low-risk site-to-site tunnel and one internal web service.
3. Enable hybrid ML-KEM on the canaries; keep the classical group active so fallback works.
4. Measure handshake latency and PMTU. Hybrid handshakes add ~1 KB — usually invisible, but can matter on constrained WAN links.
5. Expand site by site. Track OpenSSL / BoringSSL / strongSwan minor versions in your inventory.
6. Feed the inventory into Business Readiness for a rules-based score and PDF roadmap.

Common pitfalls

• Chasing QKD. Quantum key distribution is not what "quantum-safe networking" means in practice; ignore it for a corporate stack.
• Non-hybrid ML-KEM. Pure ML-KEM removes fallback security if a new lattice attack lands. Deploy hybrid.
• Old cipher suites. ML-KEM only helps if TLS 1.3 is enforced. Retire TLS 1.0/1.1/1.2-only endpoints first.
• Middleboxes. Some legacy IDS/IPS drops handshakes with unfamiliar key-share groups. Test through the full path.
• Forgotten certificates. ML-KEM covers key exchange, not signatures. Certificate PQC (ML-DSA) is a separate later migration.

Nothing on this page is legal or security advice. See methodology and editorial policy.

Frequently asked questions