Why Your Messages Went Post-Quantum Before Your Certificates Did
Your messages got quantum-safe encryption years ago, your certificates did not. Why key exchange came first, and how signatures are catching up.
If you use an up-to-date browser, a recent iPhone or Signal, much of what you send is already protected against future quantum computers. The connection that delivered this page almost certainly was. Yet the certificate that proved this page really came from us is still signed with classical cryptography that a large quantum computer could forge.
That is not an oversight. Public-key cryptography does two jobs, and the industry deliberately fixed one of them years before the other. This fourth post in our Quantum, Plainly series explains why, and what is changing now that the second job is finally getting its turn.
Two jobs: keeping secrets and proving identity
Every secure connection on the internet leans on public-key cryptography for two different things.
- Key exchange (confidentiality). You and a server agree on a shared secret key over an open network, so nobody listening can read what follows.
- Signatures (authentication). The server proves it is who it claims to be, through a certificate signed by an authority your device trusts. Software updates, app releases and many logins rely on signatures too.
A quantum computer running Shor's algorithm breaks the classical versions of both. But the two breaks do not hurt at the same time, and that difference decided the order of the whole migration.
Why key exchange could not wait
Key exchange has a problem signatures do not: the attack works backwards. As we explained in harvest now, decrypt later, someone can record encrypted traffic today and decrypt it once a quantum computer exists. Every day of delay adds more traffic to that archive, and nothing can be done afterwards to protect it.
Signatures are different. A forged signature only helps an attacker at the moment someone is checking it. To impersonate a website, an attacker needs a working quantum computer on the day of the attack. A recording made today gives them nothing. So for most signatures, the deadline is Q-Day itself, not today.
The two jobs also differ in how hard they are to fix, and here too key exchange was the easy one.
The easy fix: add a key to the handshake
The new key exchange standard, ML-KEM (FIPS 203), fits into an existing connection with little fuss. Browsers and servers combine it with the classical X25519 exchange in a hybrid called X25519MLKEM768, so an attacker has to break both. It adds about 2.3 KB to the handshake, once, and requires no change to certificates, authorities or anything else in the system.
Because only the two ends of the connection have to agree, it could roll out as a software update, and it did:
- Chrome turned hybrid post-quantum key exchange on by default on desktop in 2024, followed by Chrome on Android and Firefox. Apple's operating systems joined with version 26 in 2025, which turned it on by default for apps using the system networking stack.
- Messaging apps moved on a similar schedule. Apple's iMessage PQ3 and Signal's post-quantum protocols, most recently its post-quantum ratchet, mix a post-quantum key into conversations and keep refreshing it.
- By Cloudflare's own figures, more than two-thirds of the human traffic reaching its network is now protected by post-quantum key exchange.
This blog is part of that picture: its connections negotiate X25519MLKEM768 with any browser that offers it.
The hard part: signatures are big
Signatures are a harder engineering problem, and the reason is size.
According to Let's Encrypt, a typical TLS handshake carries five signatures and two public keys: the server's own signature, the certificate chain, and proofs that the certificate was publicly logged. With today's elliptic curve cryptography that is a few hundred bytes. With ML-DSA-44, the smallest variant of the new signature standard (FIPS 204), each signature is 2,420 bytes and each public key 1,312.
Swap them in one for one and the handshake grows past 10 KB, just for authentication. That costs more than bandwidth. Larger handshakes take extra round trips on slow networks, and some older network equipment mishandles them outright. Unlike key exchange, a signature change also cannot be done by two parties alone: certificate authorities, browsers, logging systems and servers all have to move together.
So the industry made a reasonable bet: fix the retroactive, cheap problem first, and take the time to design the expensive one properly.
The redesign: Merkle Tree Certificates
That design is now taking shape. On June 3, 2026, Let's Encrypt, the largest certificate authority on the web, announced its post-quantum plan and chose Merkle Tree Certificates as its path.
The idea is to stop signing every certificate individually. Instead, the authority collects a batch of certificates into a Merkle tree, a structure of hashes that lets anyone prove a given item is inside it, and signs only the root of the tree. Browsers learn those batch signatures ahead of time, outside the handshake. A typical connection then needs just one signature, one public key and one short proof that the certificate is in the batch. Even with post-quantum algorithms, that is smaller than a handshake today.
A bonus: because a certificate cannot exist outside a published tree, public logging of every certificate is built in rather than bolted on.
Chrome has named Merkle Tree Certificates its preferred path for post-quantum certificates on the public web, Cloudflare and Chrome are testing the approach, and the IETF's PLANTS working group is standardizing it. Let's Encrypt aims to run a staging environment by late 2026 and a production-ready one in 2027.
Where signatures cannot wait
"Signatures can wait" has important exceptions: anything that must stay trustworthy for many years after it is signed.
- Root certificates and device firmware. A root key or a boot chain baked into hardware may be trusted for a decade or more. If it cannot be updated after Q-Day, it has to be quantum-safe before. That is why Android 17 is moving its verified boot and device attestation to ML-DSA.
- Enterprise PKI. Company certificate authorities issue long-lived certificates for devices, VPNs and internal services. Since May 2026, Microsoft's built-in certificate authority on Windows Server 2025 can issue ML-DSA certificates.
- Long-term signed records. Contracts, archives and software releases that need to be verifiable years from now.
What this means for your systems
The practical order of work follows the same logic the industry used.
- Confirm key exchange is already done. Keep TLS libraries, operating systems, CDNs and load balancers current, and check that connections between your own services negotiate a hybrid post-quantum group, not only the ones facing browsers.
- List your long-lived signatures. Firmware signing, code signing, root and intermediate certificates, anything with a lifetime of years. These are the signatures to migrate first.
- Leave web certificates to the ecosystem. For ordinary websites, the switch will arrive through your certificate authority and browsers. The job is to keep certificate renewal automated so you can adopt new certificate types without drama.
- Build for change. Systems that can swap algorithms through configuration will handle this transition, and the next one, far better than systems where the choice is hard-coded.
Next week the series takes on the hardest version of this problem: a system where signatures are the whole point, keys can be decades old, and there is no central authority to issue new ones. That system is Bitcoin.
If you like plain-language explanations of security engineering, subscribe below. We publish them alongside updates on what we are building at FirstPoint.
