Post-Quantum Cryptography Is Now a Deadline
For thirty years, "quantum computers will break RSA" was a slide at the end of a talk. It has now moved into the migration column of real roadmaps — not because a cryptographically relevant quantum computer exists yet, but because the standards are final, the browsers already shipped it, and the data you encrypt today can be stolen today and decrypted later. Post-quantum cryptography stopped being a research topic and became a program-management problem.
Why the clock is already running
A sufficiently large quantum computer can factor integers and solve discrete logarithms efficiently — which breaks RSA, Diffie-Hellman, and elliptic-curve cryptography, the asymmetric backbone of nearly everything. The threat isn't only future traffic. Under harvest-now, decrypt-later, an adversary records your encrypted data now and waits for the hardware. Anything that must stay confidential past the arrival of quantum computers is already at risk. Symmetric crypto (AES) and hashes (SHA-2/3) are far less affected — Grover's algorithm only halves their effective strength, answered by using AES-256.
The standards are done
After a multi-year competition, NIST finalized its first post-quantum standards in 2024. The names you'll actually type:
| Standard | Algorithm | Role |
|---|---|---|
| FIPS 203 | ML-KEM (formerly CRYSTALS-Kyber) | Key encapsulation — replaces ECDH key exchange |
| FIPS 204 | ML-DSA (formerly CRYSTALS-Dilithium) | Digital signatures — general-purpose |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash-based signatures — conservative backup |
ML-KEM and ML-DSA are lattice-based, resting on problems like Learning With Errors that resist both classical and quantum attack. SLH-DSA trades size and speed for security resting only on hash functions — the hedge in case a lattice weakness is ever found. A further signature standard (FN-DSA/Falcon) is finalizing for size-constrained uses.
The migration principle: hybrid, not replacement
Nobody sane rips out battle-tested ECDH on faith in a new algorithm. The deployed answer — already the default in major browsers and TLS libraries — is hybrid key exchange: run a classical curve (X25519) and ML-KEM together and combine both shared secrets, so the connection is safe unless both are broken. The most widely deployed instance is X25519MLKEM768. You are very likely already negotiating it without noticing.
Doing it in code today
Hybrid TLS is largely a matter of enabling the group. With OpenSSL 3.5+ (which ships ML-KEM natively):
# Server or client: prefer the hybrid group, fall back to classical
openssl s_client -connect example.com:443 \
-groups X25519MLKEM768:X25519:P-256
# Inspect what was negotiated
openssl s_client -connect example.com:443 -groups X25519MLKEM768 \
2>/dev/null | grep -i "Negotiated TLS.*group"
Directly exercising the KEM — encapsulate to a public key, decapsulate with the private key, both sides derive the same secret:
from cryptography.hazmat.primitives.asymmetric import mlkem # OpenSSL 3.5-backed
# Recipient generates a keypair; publishes the public key
private_key = mlkem.MLKEM768.generate()
public_key = private_key.public_key()
# Sender encapsulates: gets a shared secret + a ciphertext to send
ciphertext, sender_secret = public_key.encapsulate()
# Recipient decapsulates the ciphertext back to the same secret
recipient_secret = private_key.decapsulate(ciphertext)
assert sender_secret == recipient_secret # now key AES-256-GCM with it
For signatures, ML-DSA drops into the same libraries; the practical cost is larger keys and signatures (kilobytes, not bytes), which matters for certificate chains and constrained links but not for most application traffic.
A migration you can actually run
- Inventory your cryptography. You cannot migrate what you can't find. Catalogue where RSA/ECC live — TLS endpoints, VPNs, code signing, secrets management, embedded devices. This is the hard part.
- Prioritize by data lifetime. Long-lived secrets and anything subject to harvest-now-decrypt-later go first.
- Turn on hybrid TLS where your stack supports it — often just a library upgrade and a config line.
- Demand crypto-agility from vendors. The device that can't have its algorithms updated is the one you'll be fighting in 2030.
- Keep AES-256 and SHA-384/512 on the symmetric side and you're already quantum-resistant there.
The quantum computer that breaks RSA may be a decade away, but the data you must protect for a decade is being encrypted today. Standards are final, hybrid is shipping — the only wrong move left is waiting.