Short answer. Post-quantum TLS moves key exchange to algorithms resistant to quantum computers. The key standard is ML-KEM (formerly Kyber, FIPS 203). In 2024–2025 Chrome and Firefox enabled the hybrid scheme X25519MLKEM768, which combines classic X25519 with post-quantum ML-KEM. The main threat PQC defends against is the "harvest now, decrypt later" attack: an adversary stockpiles encrypted traffic today to decrypt it once a powerful quantum computer exists.
Why quantum computers threaten TLS
Modern TLS key exchange (ECDHE over X25519 or P-256) relies on the hardness of the discrete logarithm. Shor's algorithm on a sufficiently powerful quantum computer solves that problem in polynomial time, nullifying the strength of classic key-exchange cryptography. Symmetric encryption (AES) remains relatively safe — you just double the key length.
"Harvest now, decrypt later" means data with long confidentiality lifespans — medical records, state secrets, intellectual property — must be protected post-quantum today, not on the day a quantum computer appears.
What is ML-KEM
ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) is a lattice-based key encapsulation mechanism standardized by NIST as FIPS 203 in 2024. It comes in three strength levels:
- ML-KEM-512 — security level 1.
- ML-KEM-768 — level 3, used in the X25519MLKEM768 hybrid.
- ML-KEM-1024 — level 5, maximum strength.
The hybrid approach: best of both worlds
Browsers don't trust PQC blindly — the algorithms are new. So a hybrid is used: the shared secret is computed via both classic X25519 and ML-KEM-768, and the final key is a combination of both. If a flaw is found in ML-KEM, X25519 keeps you safe, and vice versa.
| Scheme | Type | Status in 2026 |
|---|---|---|
| X25519 | Classic (ECDHE) | Vulnerable to future quantum attacks |
| ML-KEM-768 | Post-quantum | FIPS 203, the new standard |
| X25519MLKEM768 | Hybrid | Enabled by default in Chrome/Firefox |
What changes for administrators in 2026
If your server doesn't support hybrid groups, browsers fall back to classic X25519 — the connection won't break, but there's no post-quantum protection. Update OpenSSL/BoringSSL and your TLS stack, and enable X25519MLKEM768 in the key-exchange groups. Note: post-quantum keys are larger, so the ClientHello may exceed a typical packet size — verify that intermediate network gear doesn't drop large handshakes.
How to check TLS parameters
You can inspect the negotiated key-exchange group with openssl s_client:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep -i "Negotiated\|Server Temp Key"For a quick check of available protocols and ciphers:
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"PQC migration plan
- Inventory where TLS is used and which data needs long-term confidentiality.
- Update crypto libraries to versions supporting ML-KEM.
- Enable hybrid key-exchange groups on your servers.
- Verify compatibility with load balancer and WAF.
- Monitor certificate expiry and configuration.
FAQ
Do I need to switch TLS certificates to post-quantum?
For now the priority is post-quantum key exchange, not certificate signatures. PQC signatures in certificates are standardizing more slowly; start with hybrid key exchange.
Will the connection break if the server doesn't support ML-KEM?
No. The browser falls back to classic X25519. The connection establishes, just without post-quantum key-exchange protection.
What is "harvest now, decrypt later"?
A strategy where an attacker intercepts and stores encrypted traffic now to decrypt it later with a quantum computer.
Is AES safe against quantum computers?
Relatively, yes. Grover's algorithm only speeds up brute force quadratically, so AES-256 stays strong. The threat is primarily to asymmetric key exchange.
Check your site's TLS configuration with the SSL checker on enterno.io — it shows protocols, ciphers and certificate expiry. The security scanner and the HTTP header checker with HTTP/2 and HTTP/3 support are also handy.