Two migrations, not one
TLS uses public-key cryptography for two jobs: agreeing the session key (key exchange) and proving the server's identity (certificate signatures). Post-quantum key exchange is deployed and mainstream — that story is covered in ML-KEM explained. Post-quantum certificates are not: as of mid-2026, no publicly trusted certificate authority issues ML-DSA certificates that chain to the browser trust stores, and no browser negotiates them.
That asymmetry is deliberate, and it comes down to what an attacker can do retroactively. Recorded traffic can be decrypted years later, so key exchange had to move first (harvest now, decrypt later). A signature, though, only authenticates the moment it is verified — a quantum computer in 2035 cannot travel back and impersonate your server in 2026. Certificate signatures only need to be post-quantum before large quantum computers actually exist, not before they might be imagined.
What's actually holding it up
- Standards plumbing. The algorithms are done — ML-DSA is FIPS 204, SLH-DSA is FIPS 205 — but the certificate profiles and the TLS negotiation points for them are still working their way through the IETF.
- Root programme and CA/Browser Forum policy. Public CAs can only issue what the Baseline Requirements and the browser root programmes permit; post-quantum issuance policies are still being agreed, with the first publicly trusted issuance expected to follow the policy work rather than lead it.
- Size. An ML-DSA-65 public key is about 1.9 KB and a signature about 3.3 KB — versus 32 and 64 bytes for Ed25519. A full chain with post-quantum keys, signatures, SCTs and OCSP staples adds tens of kilobytes to every handshake, which is why alternatives (trust anchor negotiation, Merkle tree certificates, abridged chains) are being explored in parallel.
Hybrid certificates and other transition ideas
Several transition mechanisms are in play. Composite certificates bind a classical and a post-quantum key in one certificate, so validation requires both signatures to verify. Dual-certificate deployments serve a classical or post-quantum chain depending on what the client negotiates. Private PKIs — where you control both ends — can and do issue ML-DSA certificates today; nothing stops an internal CA. The public web will converge on whatever the root programmes bless, so there is little value in guessing the winner now.
What to do today
- Nothing, on certificates — deliberately. Keep issuing and renewing classical ECDSA/RSA certificates as normal. A classical certificate is not a post-quantum failure; it is the current correct state of the web PKI.
- Watch certificate agility instead. The migration, when it comes, will be won by whoever can rotate certificates across their estate quickly. Shorter certificate lifetimes are already pushing automation — that same automation is your post-quantum readiness. See certificate lifecycle.
- Spend the effort on key exchange, the half you can fix today: enable X25519MLKEM768.
Further reading
- FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
- FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)
- draft-ietf-lamps-dilithium-certificates: ML-DSA in X.509
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards
The post-quantum TLS test reads your certificate's signature algorithm as part of its scan — and will tell you, correctly, that a classical one is normal. Decode any certificate in full with the certificate decoder.