Future-Proofing Enterprise Traffic: How to Govern and Inspect Post-Quantum Traffic Without Hardware Refreshes

This is Part 1 of our three-part architectural series, Future-Proofing Enterprise Traffic, exploring how Zscaler Internet Access (ZIA) and the Zero Trust Exchange solve the three structural shifts breaking legacy network security: Post-Quantum Cryptography (PQC), Inline Cyber Threat Protection for Agentic AI, and SOC Provenance with Endpoint Context.

Every inline security architecture relies on a simple contract: if an attack has to cross the network, your security stack should be able to terminate the connection, inspect the bytes, understand the context, and render a verdict before any damage is done.

For fifteen years, legacy network security vendors tried to honor that contract by bolting features onto castle-and-moat firewalls or by lifting those same virtual firewall instances into the cloud and calling them SASE. As long as enterprise traffic mostly consisted of classical TLS 1.2/1.3 over TCP and compiled .exe binaries, that approach limped along.

Over the last nine months, the wire moved faster than legacy appliances could follow. Looking across the 500+ trillion daily signals and 9+ billion daily blocked threats traversing the Zscaler Zero Trust Exchange, three structural shifts have broken the assumptions behind traditional network and endpoint security:

• Post-Quantum Cryptography (PQC) changed the physical geometry of TLS handshakes: With modern browsers, operating systems, and major content providers enabling hybrid post-quantum key exchange by default and the IETF finalizing RFC 10024 in August 2026, TLS 1.3 ClientHello messages now routinely span multiple TCP segments—overwhelming fixed-hardware firewalls and legacy proxies.
• Inline Cyber Threat Protection now has to parse AI agents and persistent streaming protocols: Sanctioned AI tools hold open bidirectional WebSockets, browsers default to HTTP/3 over QUIC, attackers tunnel command-and-control (C2) inside gRPC, and autonomous AI agents execute instructions out of plain-text Markdown skill files (.md) and Model Context Protocol (MCP) servers.
• The SOC is starving for provenance, not just more alerts: When an attacker uses a living-off-the-land binary (LOLBin), a ClickFix PowerShell stager, or an offline USB drop, a network proxy that only sees packets can’t tell which process opened the connection — and an EDR that only sees the host can’t surgically enforce inline network policy across the global enterprise.

To stop a modern breach, an inline architecture has to win at three consecutive choke points: terminating post-quantum TLS handshakes without failing open, decoding agentic AI and persistent streaming protocols inline, and correlating every network socket to the exact process and DLL executing on the endpoint. We recently shared a high-level summary of our Zenith Live 2026 innovations; across this three-part series, we are going under the hood of Zscaler Internet Access (ZIA) to walk through the architecture across each pillar. In Part 1, we examine the first choke point: Post-Quantum Cryptography (PQC).

From Lattice Math to Production Plumbing: Why PQC Is Today’s Network Crisis

If you have followed the recent standardization work across the IETF, specifically within the TLS, LAMPS (Limited Additional Mechanisms for PKIX and SMIME), and PLANTS (PKI, Logs, And Tree Signatures) working groups, you have noticed an unmistakable shift in tone among cryptographers and systems engineers. Two years ago, PQC discussions were theoretical primers on lattice math. Today, the focus is squarely on production plumbing: standardizing hybrid post-quantum key exchange for TLS 1.3, updating X.509 certificates and PKI hierarchies for ML-DSA (FIPS 204) in LAMPS, advancing Merkle Tree Certificates in PLANTS to keep post-quantum certificate chains from bloating, and solving how larger post-quantum handshakes behave across real-world enterprise networks.

Why does IETF protocol plumbing matter to a CISO or security architect? Because major web browsers (Chrome, Edge, Firefox), modern operating systems, and leading cloud and content providers have already enabled hybrid post-quantum key establishment (such as X25519MLKEM768) by default in TLS 1.3. That means client endpoints, cloud workloads, and major web origins are already negotiating TLS handshakes with post-quantum key exchange on your network today — without enterprise application teams changing a single line of code.

Combine the IETF’s publication of RFC 10024 (Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3) with compressed federal compliance timelines, and PQC is no longer a 2030 roadmap item. 

The Byte Math That Breaks Legacy Firewalls and Virtual SASE

Look at the byte math of a TLS 1.3 handshake to see why this creates an immediate crisis for legacy firewall appliances and virtual-machine SASE gateways:

• Classical Elliptic-Curve Exchange: In a classical X25519 exchange, both the client and server key shares are just 32 bytes each.
• Hybrid Post-Quantum Exchange: In a hybrid X25519MLKEM768 exchange, the key shares are much larger and asymmetric: the client sends a 1,216-byte key share in the ClientHello, while the server responds with a 1,120-byte key share in the ServerHello—a 38 increase in client key share size.
• Ethernet MTU Fragmentation: Once you include cipher suites, extensions, and SNI, the TLS ClientHello routinely exceeds the 1,500-byte Ethernet MTU, forcing the message to split across multiple TCP segments before the handshake even completes.

When a hardware firewall or virtualized appliance with fixed inspection buffers encounters a multi-packet ClientHello proposing hybrid post-quantum key exchange, it hits an architectural wall. If the appliance cannot reassemble and parse the multi-segment ClientHello, it must either fail closed (dropping the connection and breaking access to modern cloud apps) or fail open (passing the session through completely uninspected). Even if a legacy proxy manages to terminate the TLS session without supporting PQC key exchange groups, it forces the connection to negotiate a classical key exchange group (often incurring an extra HelloRetryRequest round-trip) — depriving the inspected session of post-quantum protection.

Passing encrypted traffic uninspected in 2026 is catastrophic for enterprise security. In our latest research, overall phishing volume dropped 20% as attackers shifted from noisy mass spam to targeted precision, yet 95.2% of phishing attempts and 87% of all blocked malicious activity rode over encrypted TLS channels, driven by 413,524 AI-generated site instances.

At the same time, 1 in 3 organizations inspect 0% of their encrypted traffic and 70% have limited or no visibility into AI threats traversing their tunnels according to the ThreatLabz 2026 VPN Risk Report. If your gateway cannot terminate hybrid PQC handshakes at scale, you face an unfortunate choice: either every modern browser and workload upgrade quietly shrinks your inspection coverage, or you are exposing your data to Harvest Now, Decrypt Later (HNDL) risks posed by future quantum computers.

How the Zscaler Zero Trust Exchange Solves It

Because ZIA is a cloud-native, multi-tenant proxy distributed across 160+ points of presence—not a fixed-ASIC box in a wiring closet—we engineered PQC readiness directly into our elastic TLS state machine with zero CAPEX or hardware refreshes required:

• Cryptographic Discovery & Inventory in Web Insights: You cannot manage a cryptographic migration—or pass a compliance audit—blind. ZIA populates six dedicated PQC logging fields in Web Insights on every transaction (streamable in real time to your SIEM via Nanolog Streaming Service) and visualizes them in the Post Quantum Cryptography Visibility interactive report. Security teams get a live, probe-free inventory of Classical vs. PQC transaction volume, client-proposed key exchange algorithms, negotiated client and server key exchange mechanisms, and signature schemes.

  

• Wire-Speed Hybrid ML-KEM TLS Inspection & Per-Leg Negotiation: ZIA natively reassembles multi-packet ClientHello messages in memory and terminates, inspects, and re-encrypts TLS 1.3 sessions using the standardized RFC 10024 hybrid ML-KEM key exchange groups (X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024). Crucially, ZIA negotiates key exchange independently on the client-to-proxy and proxy-to-origin legs—delivering seamless cryptographic translation across every permutation (PQC client to PQC server, classical client to PQC server, and PQC client to classical server) so a legacy destination never strips quantum protection from the client leg, and you retain 100% full-payload inspection across malware, DLP, and IPS engines.
   
• Pioneering Single-Packet PQC Standards: While the Zero Trust Exchange natively handles multi-packet handshakes, many enterprises still have third-party path devices that fail closed whenever a ClientHello spans multiple TCP segments. To solve this across the broader internet ecosystem, Zscaler authored and registered two compact hybrid PQC TLS groups at the IANA registry—SecP256r1MLKEM512 and MLKEM512X25519, targeted for upcoming support in OpenSSL 4.2—that deliver quantum safety while keeping the ClientHello within a single MTU packet.
   
• Custom Crypto Profiles for Compliance & Digital Sovereignty: ZIA’s Custom Crypto Profiles let administrators actively govern and enforce allowed post-quantum and hybrid key exchange mechanisms separately across source and destination traffic. This enables multinational organizations to satisfy strict federal timelines (such as CNSA 2.0 and OMB M-23-02) while simultaneously tuning regional policies for digital sovereignty mandates (such as Germany’s BSI, France’s ANSSI, or South Korea’s KpqC) when national requirements diverge from NIST guidance.
  
   
• Cryptographic Trust Governance (BYO Trust Store & Cloud HSM): Quantum readiness requires governing certificate trust and private keys alongside key exchange. With Bring Your Own (BYO) Trust Store and Zscaler-managed Cloud HSM, administrators can maintain sovereign control over inspection keys, immediately revoke trust in compromised or untrusted root and intermediate Certificate Authorities (such as rapid mitigation against CA compromises like eMudhra), and prepare their PKI posture for post-quantum digital signatures (ML-DSA / FIPS 204) and Merkle Tree Certificates (MTC).
   
• Quantum-Resistant IPsec Traffic Forwarding (IKEv2 PPK): Securing the inner TLS session doesn't help if an adversary harvests the outer branch tunnel. To protect branch-to-cloud traffic forwarding against "Harvest Now, Decrypt Later" collection, ZIA supports IPsec with Post-Quantum Pre-Shared Keys (IKEv2 PPK, RFC 8784)—mixing a high-entropy post-quantum secret directly into the IKEv2 key derivation to quantum-harden the transport layer itself on commodity IPsec appliances without bloating handshake packets.
  
   

What’s Next in the Series

Terminating the post-quantum TLS handshake is only the first choke point. Once the session is decrypted, what happens when the payload inside isn’t a standard HTTP request or a compiled .exe binary — but an autonomous AI agent executing instructions from a plain-text .md file, or an attacker tunneling C2 over QUIC and gRPC?

In Part 2, we dive into Inline Cyber Threat Protection for Agentic AI, persistent streaming protocols, and 200 MB patient-zero loaders. Want to benchmark your PQC inspection posture today? Reach out to your Zscaler account team to run a Cyber Threat Protection Posture Assessment.