The Quantum Threat

The Problem

The right starting point isn't cryptography. It's the network. Where does PII actually travel? Which segments of that path cross the internet and can be intercepted? Those are the segments where the quantum threat is real and where the organisation needs to act.

Where PII Flows

For most enterprise web applications, user PII travels through a common pattern: browser to CDN edge, then CDN to origin. TLS terminates at each of those two points. They're separate encrypted tunnels, not one end-to-end pipe. The organisation controls the configuration at both termination points. That matters for what comes next.

Network diagram showing PII flow through CDN and origin with harvest points
TLS Leg 1 - Browser → CDN
  • Crosses the public internet. Harvestable by nation-state or ISP tap.
  • Organisation controls CDN TLS config → PQC is achievable here
  • Cloudflare: ML-KEM on by default for all TLS 1.3 zones
TLS Leg 2 - CDN → Origin
  • May cross the internet (CDN PoP to origin datacenter)
  • Organisation controls origin TLS config → PQC is achievable here
  • F5 BIG-IP: ML-KEM available from TMOS 17.5.1+
✓ Organisation controls TLS config at both termination points. Both are candidates for PQC readiness.
The part that is outside your control: This framing covers inbound traffic to your published applications (the legs you configure). It does not cover outbound traffic from inside your network to third-party SaaS, partner APIs, or cloud services. On those sessions, the TLS configuration belongs to the destination. Whether they support ML-KEM is their decision, not yours. That gap is covered in the Network Architecture section.

Why the Key Exchange Step Is the Vulnerability

TLS does two separate things: it establishes a shared secret between client and server (key exchange), and it uses that secret to encrypt the actual data (AES-256). A quantum computer only threatens the first step. AES-256 isn't meaningfully affected.

Key Exchange

RSA and ECDH rely on mathematical problems that a sufficiently large quantum computer can solve efficiently. This is the step where client and server agree on a shared secret at the start of every TLS session.

Broken by quantum

Data Encryption

Once the shared secret is established, all application data (form submissions, API responses, session tokens) is encrypted with AES-256. Quantum computers don't provide a meaningful attack against AES-256 at current key lengths.

Not a quantum problem

Post-quantum cryptography replaces the key exchange algorithm only. The rest of TLS, the certificate, the cipher, the MAC. None of that changes. It's a targeted replacement, not a rebuild.

Harvest Now, Decrypt Later

Every post-quantum readiness conversation eventually lands on this phrase. It sounds like something from a sci-fi script, but the mechanics are straightforward and the first half is already happening. You do not need a quantum computer to start this attack. You only need one to finish it.

The reason this matters for your network today is that the capture step requires nothing special. Bulk interception of TLS traffic at internet scale is well within the capability of nation-state actors right now. The encrypted data sitting in cold storage somewhere is just waiting on the hardware.

1
Harvest
Encrypted TLS sessions are captured in bulk today via ISP taps, undersea cable interception, BGP route hijacking, or passive collection at internet exchange points. The full ciphertext is stored, including the handshake that locked it.
2
Store
Storage is cheap. A decade of harvested TLS traffic from a targeted organisation fits on hardware that costs a few thousand dollars. The RSA or ECDH key exchange material is preserved inside that ciphertext, intact and unmodified.
3
Wait
The attacker waits for a cryptographically relevant quantum computer. NIST's own timeline puts this somewhere in the 10-15 year window, though estimates vary. The stored data does not expire.
4
Decrypt
Shor's algorithm breaks the key exchange in polynomial time. Session keys are recovered. Everything captured years earlier, login sessions, health records, financial transactions, M&A discussions, is readable. Retroactively.
The clock started when the capture started, not when the quantum computer arrives. The right question is not "does a quantum computer exist today?" It is: what are you transmitting right now that still needs to be confidential in 10 years? Health records, authentication tokens, financial data, internal strategy. If any of that applies, the window to act is before the harvest, not after. That window is open right now.
← Previous TLS 1.2 vs TLS 1.3