Section 1 of 4

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

The attack doesn't need a quantum computer to start. An adversary can capture and store the encrypted TLS sessions on Leg 1 and Leg 2 today. The decryption happens later, once a capable quantum computer exists. The window to protect against this is before the capture happens, not after.

1
Capture
Encrypted TLS sessions on internet-facing segments are archived via ISP taps, transit interception, or BGP hijacking. The handshake data is what matters: it contains the key exchange.
2
Store
The ciphertext is kept. It contains the RSA or ECDH key exchange material, enough to derive the session key once the underlying math can be broken.
3
Wait
The adversary waits for a cryptographically capable quantum computer. Timeline is uncertain. Most estimates put this 15-20+ years out, but the range is wide.
4
Decrypt
The quantum computer breaks the key exchange. Session keys are recovered. Traffic captured years earlier (login sessions, documents, API calls, health data) is decrypted retroactively.
The relevant question is not whether a quantum computer exists today. It is: what PII are you transmitting right now that still needs to be secret in 15 years? If the answer is anything: health records, financial data, authentication tokens, M&A conversations. The migration clock is already running, because the capture is already possible. PQC readiness for the legs you control is where to start.
← Back Home