Web Gateway PQC
PQC deployment at the infrastructure edge — TLS termination patterns, certificate lifecycle at scale, and vendor migration paths.
Web Gateway Architecture & TLS Termination Patterns
Web gateways — , load balancers, WAFs, and CDN edge nodes — are the primary points in modern web infrastructure. They handle millions of TLS handshakes per day, making them the most impactful place to deploy .
Unlike application-level PQC (covered in TLS Basics), gateway-level deployment affects every client connection simultaneously. Upgrading a single reverse proxy to PQC hybrid can protect thousands of backend services without modifying application code.
Gateway terminates TLS, inspects plaintext, forwards to backend (usually plaintext or separate TLS).
Gateway forwards encrypted traffic to backend without decryption. No inspection possible.
Gateway terminates client TLS, then establishes a new TLS session to backend.
Different CAs/algorithms for client-facing (public CA) and backend-facing (internal CA) TLS.
Try the to construct your gateway architecture and the to compare these patterns side by side.
Certificate Lifecycle at Edge Scale
CDN and load balancer operators manage certificates at enormous scale. Cloudflare manages over 50 million certificates across 300+ edge PoPs. AWS ALB handles per-listener certificate binding. Migrating these certificates from classical algorithms (RSA-2048, ECDSA P-256) to requires careful operational planning.
Automated Certificate Management Environment (RFC 8555) is essential at scale. CAs must support PQC issuance for automated rotation to work. Let's Encrypt and Google Trust Services are evaluating PQC certificate support.
CT logs (RFC 9162) must store PQC certificates that are 5–10× larger than classical ones. This increases CT log bandwidth and storage requirements significantly.
Subject Alternative Name certificates covering multiple domains reduce the total cert count but increase blast radius if compromised. With PQC, the size trade-off shifts — fewer, larger certs may be preferable.
Applications that pin specific certificate public keys (HPKP, mobile apps) will break during PQC migration unless pin sets are updated first. Plan pin deprecation before algorithm rotation.
Use the to model your edge migration timeline.
PQC Handshake Performance & Session Optimization
PQC algorithms produce larger keys and signatures, directly increasing TLS handshake size. At gateway scale (thousands of handshakes per second), this bandwidth cost is the primary operational concern — not CPU, which remains manageable with modern hardware.
Reuse prior session keys; eliminates certificate exchange on reconnect.
Returning clients only (60–80% of traffic at typical gateways)
Zlib/Brotli compress certificate chain during handshake.
All TLS 1.3 connections; requires both sides to support
Replace per-cert signatures with compact Merkle inclusion proofs.
Experimental (Cloudflare/Chrome); IETF PLANTS WG draft
Reduce round trips via 0-RTT and integrated transport+TLS.
QUIC-capable clients and gateways
Reuse a single TLS connection for multiple domains (HTTP/2+).
Wildcard/SAN certificates; same IP address
Try the to model your specific gateway scenario.
WAF/IDS Inspection Challenges with PQC
Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) rely on to inspect traffic for threats, data loss, and compliance violations. PQC migration creates a critical decision point: if the gateway cannot terminate PQC TLS, it loses all visibility into traffic content.
If an upstream CDN negotiates PQC with the client and passes through to a WAF that only supports classical TLS, the WAF cannot decrypt or inspect the traffic. This creates a security blind spot.
Dedicated TLS inspection appliances (Zscaler, Bluecoat, McAfee Web Gateway) must support PQC on both the client-facing and server-facing TLS sessions. If they cannot negotiate PQC, they become a quantum-vulnerable chokepoint.
During migration, use classical TLS at the inspection point (WAF/IDS) and PQC hybrid on the client-facing edge. This preserves inspection capability while protecting the internet-facing segment. Upgrade inspection infrastructure in phase two.
CDN Edge Deployment & Origin Shielding
Content Delivery Networks deploy PQC at distributed globally. Cloudflare reports that over 20% of TLS connections to their network already use hybrid key exchange (X25519MLKEM768), making CDN edges the largest real-world PQC deployment.
A designated edge node aggregates requests from other PoPs before forwarding to the origin server. This creates a natural PQC deployment boundary — the shield-to-origin connection can be upgraded to PQC independently of client-facing connections.
CDNs must distribute TLS private keys or certificate issuance authority across 300+ PoPs. With PQC, larger key material increases distribution bandwidth. Some CDNs use keyless SSL architectures where private keys never leave a central HSM.
CDN edge PQC only protects the client-to-edge segment if the client browser also supports PQC. Chrome, Firefox, and Edge already support X25519MLKEM768 — but Safari and older browsers do not, requiring hybrid fallback.
Vendor-Specific PQC Migration Paths
Gateway vendor PQC readiness varies significantly. Some products (Cloudflare Edge, F5 BIG-IP 17.5+, Envoy) already support hybrid PQC TLS in production, while others (Imperva WAF, Broadcom Avi, Zscaler) are still on the roadmap. Understanding each vendor's status and upgrade path is critical for planning.
| Product | Version | Algorithms | FIPS |
|---|---|---|---|
| F5 BIG-IP | 17.5+ | X25519MLKEM768 | FIPS 140-2 |
| NGINX Plus | R32+ | X25519MLKEM768 | FIPS 140-3 (OpenSSL) |
| NGINX (Open Source) | 1.28+ | X25519MLKEM768 | No |
| HAProxy | 3.1+ | X25519MLKEM768 | No |
| Envoy Proxy | 1.37+ | X25519MLKEM768 | BoringCrypto |
| Cloudflare Edge | Current | X25519MLKEM768 | Edge platform |
| AWS ALB/NLB | Current | X25519MLKEM768 | FIPS 140-3 (AWS-LC) |
| Cloudflare Zero Trust | Current | X25519MLKEM768 | No |
| Palo Alto PAN-OS | 12.1 Orion | ML-KEM, ML-DSA | Yes |
| Apache HTTP Server | 2.4.60+ | X25519MLKEM768 | No |
Use the to assess your specific gateway infrastructure against PQC readiness.
The workshop has 5 interactive steps: Topology Builder, TLS Termination Patterns, Handshake Budget Calculator, Certificate Rotation Planner, and Vendor Readiness Matrix.
Check off all sections and mark this reading done.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.