Post-Quantum TLS: Why PQC Certificates Lag
Hybrid post-quantum TLS now covers 49% of domains, but post-quantum certificates remain at 0%. Here is what the gap means for PQC migration.
A measurement study of roughly 32,000 domains published this month puts a hard number on something a lot of us suspected but hadn’t seen quantified: 49.3% of sites now negotiate hybrid post-quantum key exchange over TLS. Hybrid post-quantum certificates? Zero percent. Not a small number. Zero.
That gap is worth sitting with, because it means the part of the migration that gets talked about most, key exchange, is running way ahead of the part that actually authenticates who you’re talking to.
Two different problems wearing the same acronym
It’s easy to lump “PQC migration” into one bucket, but key exchange and certificates protect against different attacks on different timelines. Hybrid key exchange (things like X25519 + ML-KEM768) defends against harvest-now-decrypt-later: someone recording your encrypted traffic today and sitting on it until a cryptographically relevant quantum computer shows up to decrypt it. That’s a real threat, and it’s why Cloudflare, Google, and AWS all pushed hard on hybrid key exchange over the last year, and why Chrome now defaults to it for a growing share of connections.
Certificates are a live-attack problem, not a recorded one. A certificate’s signature is what tells your browser that the server on the other end of the handshake actually owns the domain it claims to own. Break the signature scheme and you don’t need to have recorded anything in advance. You can just forge a certificate and sit in the middle of a connection right now. A quantum computer that breaks ECDSA doesn’t care whether your session used hybrid ML-KEM, because it never has to touch the key exchange at all. It goes straight for the identity layer.
So when the study finds 49.3% coverage on one side and 0% on the other, it’s not “the migration is halfway done.” It’s “the easier, more incremental half is nearly half done, and the harder half hasn’t started.”
Why certificates are stuck
The honest answer is that certificates are structurally harder to move than a TLS handshake parameter. Enabling hybrid key exchange is, in a lot of cases, a server-side config change you can make without coordinating with anyone outside your own infrastructure team. Certificates require the entire chain of trust to agree: your CA, the intermediate, the root, and every piece of software anywhere in the world that ships a trust store and has to recognize the new signature algorithm.
Public root CAs have issued exactly zero ML-DSA roots into the trust stores that Chrome, Apple, Microsoft, and Mozilla actually ship. Browser vendors haven’t finished sorting out how they want composite or hybrid signature algorithms to show up in their root programs, and CAs are understandably reluctant to issue certificates that half the internet’s software can’t yet validate. Meanwhile ML-DSA and SLH-DSA signatures are considerably larger than ECDSA, which drags handshake size up further on top of whatever hybrid key exchange already added.
Internal PKI is a different story, and this is the part worth knowing about if you run enterprise infrastructure. Windows Server’s AD CS reached general availability for ML-DSA-44/65/87 issuance back in May, and composite ML-DSA + ECDSA certificates are already usable for internal CAs, service-to-service auth, and anywhere you control both ends of the trust chain. You can start there today. The public trust ecosystem is a much slower-moving target, because it has to move as one piece or not at all.
What to actually take from this
If your migration tracker has a single checkbox labeled “PQC” or even “hybrid TLS,” split it. Key exchange readiness and certificate readiness are on different clocks, need different owners, and depend on different vendors. Ask your CA directly what their timeline looks like for hybrid or composite certificate issuance, and don’t accept “we support ML-KEM” as an answer to a question about certificates. Those are unrelated capabilities that happen to share a marketing slide.
For anything under your own control, internal CAs, service mesh certs, code-signing infrastructure, you don’t have to wait on the public trust ecosystem to sort itself out. Start there. For anything that depends on a public root chaining into a browser trust store, you’re waiting on an industry-wide coordination problem that a single vendor announcement isn’t going to solve, no matter how good the press release sounds.
The 49.3% number is genuine progress and worth acknowledging. The 0% number is the one that should be setting your actual timeline.