Post-Quantum Cryptography
Once you understand what's broken, the next question is what replaces it. More practically: is it actually deployed in a standard enterprise stack today? The short answer is: NIST finalized the standards in 2024, the key exchange algorithm (ML-KEM) is already shipping in Cloudflare and modern browsers, and it slots into TLS 1.3 without changing anything else about the protocol.
NIST Post-Quantum Standards (2024)
NIST ran an open competition from 2016 to 2024. Eight years of cryptographers worldwide trying to break each other's submissions. Three algorithms came out standardised. They cover the two things you need to replace in TLS: key exchange and digital signatures. For network infrastructure right now, the key exchange one is the immediate priority. The signature migration is a separate wave, further out.
ML-KEM
Replaces RSA and ECDH in TLS key exchange. Three parameter sets: ML-KEM-512, ML-KEM-768 (the one in active deployment), ML-KEM-1024. This is what protects session traffic.
ML-DSA
Replaces RSA and ECDSA for code signing, certificates, and authentication. TLS certificates still use classical signatures today. That migration is still being worked out across the industry.
SLH-DSA
An alternative signature scheme based on hash functions rather than the same mathematical family as ML-KEM. Slower and larger, but provides algorithm diversity. Useful if you don't want all your eggs in one basket.
How ML-KEM Slots Into TLS 1.3
This is the part that made it feel practical rather than theoretical. ML-KEM occupies exactly
the same slot in the TLS 1.3 handshake where ECDH used to sit. The protocol structure doesn't change. Both sides advertise what they support, agree on an algorithm, exchange the key material
through the key_share extension, and derive the session key. The difference is
what happens mathematically inside that exchange. The result is that the session key is
never transmitted at all. It is derived independently on both sides from the encapsulation
process.
X25519MLKEM768 → ServerX25519MLKEM768 in its supported_groups
and sends a speculative key share upfront so the server can respond immediately
without an extra round-trip if it supports ML-KEM.
key_share response.
HelloRetryRequest asking it
to retry with the correct group. That's an extra round-trip. Cloudflare's default behaviour
("supported" mode) uses this approach. It works but adds latency. Setting Cloudflare to
"preferred" mode via the API makes it send the ML-KEM key share in the first ClientHello,
skipping that round-trip. Worth doing if you're tuning for performance.
Why X25519MLKEM768 Runs Both Algorithms Together
When you see X25519MLKEM768 in a TLS negotiation, that's a hybrid group
identifier. It's ML-KEM-768 and the classical X25519 running simultaneously in the same handshake.
The approach is deliberate. ML-KEM is new. It went through eight years of global scrutiny and
came out clean, but it doesn't have the decades of real-world deployment that X25519 has.
Running both means an attacker has to break both simultaneously to compromise the session.
If ML-KEM has an unexpected weakness, X25519 still holds.
If a quantum computer eventually breaks X25519, ML-KEM still holds.
TLS 1.3 is non-negotiable
ML-KEM uses the key_share extension that only exists in TLS 1.3. If any
part of your stack has TLS 1.2 as a minimum (a Cloudflare zone setting, an F5 profile,
a load balancer), ML-KEM can't negotiate. It doesn't fall back gracefully. It just won't happen. Check your minimum TLS versions before anything else.
Certificates are fine for now
The server certificate still uses RSA or ECDSA and that's not a problem today. Certificates prove identity, not confidentiality, and they're short-lived (90 days typically). They aren't worth harvesting for future decryption. Post-quantum certificates using ML-DSA are coming but they're a separate migration, not urgent yet.