Post-quantum cryptography
for people who run networks
Post-quantum cryptography started showing up in vendor roadmaps and compliance conversations, and I realised I was nodding along without really understanding it. So I decided to learn it properly. Not just the theory, but how it applies to the kind of infrastructure most enterprise networks actually run.
This site documents what I found. Everything here has been tested and verified against a
standard enterprise stack: Cloudflare as the CDN edge, F5 BIG-IP as the origin load balancer,
and a real domain to run openssl s_client against. This is a common architecture:
CDN in front, load balancer at origin. Not specific to any one organisation.
Where Does PII Get Exposed, and Where Should We Focus?
PII travels across two separate internet-exposed TLS legs before it reaches your application: browser to CDN, then CDN to origin. A third path exists for trusted external systems (partner APIs, SaaS) that bypass the CDN entirely. The diagram below maps where each harvest opportunity sits. Full breakdown in The Problem.
The Problem
What actually happens in a TLS handshake, which part of it quantum computers break, and why the attack doesn't need a quantum computer to start. The harvest now, decrypt later threat is the reason this is worth paying attention to now.
TLS 1.2 vs TLS 1.3
Why the TLS version actually matters here. TLS 1.3 made the key exchange pluggable. That's the architectural reason ML-KEM can exist at all. TLS 1.2 simply has no slot for it. And TLS 1.3 alone, without ML-KEM, still leaves you exposed.
Post-Quantum Cryptography
NIST finalised three algorithms in 2024. ML-KEM is the one that matters for TLS key exchange and it's already shipping in Cloudflare and modern browsers. This section covers what it is, which parameter set is in active use, and how it fits into TLS 1.3.
Network Architecture & Verification
Knowing which algorithms are quantum-safe is the easy part. The harder question is where you can actually deploy them, and where you can't. What the org controls vs what depends on vendor roadmaps, plus how to verify what is actually being negotiated.
✓ Verified against a Cloudflare-fronted domain (April 2026)
ML-KEM is negotiated in practice, not just on paper. The key line to confirm:
Negotiated TLS1.3 group: X25519MLKEM768. Requires OpenSSL 3.5+.
See the full verification guide
for the command and setup.