Post-quantum TLS is often discussed as a future migration. In mid-2026 that framing is half wrong: one half of the problem is largely deployed, and the other half is the interesting open question. This is a snapshot of where TLS actually stands against quantum threats right now, and why certificates - not key exchange - are the remaining hard part.
Key exchange: mostly solved, already shipping
The confidentiality half of TLS - the part exposed to "harvest now, decrypt later" - has moved fast. The industry settled on hybrid key exchange: combine a classical curve with a post-quantum KEM so the session is safe as long as either primitive holds. The codepoint you see in the wild is X25519MLKEM768 - X25519 paired with ML-KEM-768 (the standardised form of Kyber, finalised by NIST as FIPS 203 in August 2024).
This is not theoretical. Chrome has shipped hybrid PQ key exchange on by default, Cloudflare negotiates it at the edge, and major cloud providers support it. If you terminate TLS on modern, updated software, a large share of your connections are already protected against retrospective decryption. The practical action here is small: make sure your TLS stack (OpenSSL 3.5+, BoringSSL, your CDN) is current enough to negotiate it, and stop disabling it for "compatibility."
Authentication: still classical, and that is the problem
The signature half - proving the server is who it claims - is still RSA and ECDSA everywhere. That is fine against harvest-now-decrypt-later (you cannot retroactively forge a past handshake), so it is genuinely less urgent than key exchange. But it has to move eventually, and it is where the difficulty concentrates.
The post-quantum signature schemes NIST standardised - ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) - are large. ML-DSA-65 public keys and signatures are on the order of a couple of kilobytes each; SLH-DSA signatures are larger still. A normal TLS handshake carries multiple signatures and a full certificate chain. Swap in PQ signatures naively and the handshake balloons from a few kilobytes to tens of kilobytes - which, over lossy or high-latency links, means extra round trips and measurable slowdown. The bottleneck for PQ authentication is not security; it is bytes on the wire.
Where Merkle Tree Certificates come in
This size problem is what makes Merkle Tree Certificates (MTC) interesting. The idea, currently an IETF draft, reframes certificates for a world of high-volume, short-lived issuance. Instead of every certificate carrying its own heavyweight PQ signature, certificates are batched and committed into a Merkle tree; a server then presents a compact inclusion proof rather than a full signature chain. For the common case - a relying party that already trusts a recent tree head - the bytes on the wire drop dramatically.
It pairs naturally with the other big trend in the ecosystem: as the CA/Browser Forum drives certificate lifetimes toward 47 days, issuance becomes high-frequency and automated anyway, which is exactly the regime MTC is designed for. It is early - a draft, not a deployed standard - but it is the most credible answer to the PQ-certificate-size question on the table.
What we are building
We have started building support for monitoring Merkle Tree Certificates in TLS Radar. The current work is a probe that detects whether a host negotiates MTC and records what it observes - tracking the draft spec version as it evolves - behind a gated, sampled rollout while the standard is still moving. It is forward-looking on purpose: MTC is not something most teams will deploy this year. But when the ecosystem starts turning it on, "can we see which of our endpoints support it, and what they're presenting" should not require a research project. That visibility is the point of monitoring.
What to actually do in 2026
- Turn on hybrid key exchange where your stack supports it, and stop treating it as optional. This is the part with real harvest-now-decrypt-later upside, and it is available today.
- Do not migrate authentication yet. There is no production reason to move to PQ signatures now, and doing it naively just costs you handshake bytes. Watch the standards (MTC, PQ signature profiles) instead of pre-committing.
- Keep an inventory. When the signature transition does come, it will be gated by which of your endpoints and clients can handle larger certs or support newer formats. Knowing your TLS surface now is what makes that migration measurable later.
If you want the non-technical version to share with the rest of the team, we wrote a plain-English guide to post-quantum cryptography.
Sources: NIST, FIPS 203/204/205, Cloudflare, State of the Post-Quantum Internet, and IETF, Merkle Tree Certificates (draft-davidben-tls-merkle-tree-certs).
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.
Keep reading
The 47-Day Certificate Schedule: SC-081v3, DCV Reuse, and What to Automate
TLS Scan Report, Check by Check: A Technical Walkthrough
What Is SSL/TLS Certificate Monitoring and Why Does It Matter?
Related guides
-
SSL/TLS Vulnerabilities - A Quick Guide for Non-Experts
A non-expert tour of well-known SSL/TLS vulnerabilities and how to check yours.
-
What Is SSL/TLS Certificate Monitoring? A Complete Guide
A plain-English definition of SSL/TLS certificate monitoring, what it catches beyond expiry, and why shorter certificate lifespans are making it essential.