On June 3, Let's Encrypt published its plan for post-quantum certificates on the public web. Two parts of it matter for migration planning. First, Let's Encrypt will use Merkle Tree Certificates (MTCs) for post-quantum authentication, with a staging environment in late 2026 and production issuance in 2027. Second, the same plan names one action as the most useful thing a server operator can do this year: turn on hybrid post-quantum key exchange, the X25519MLKEM768 group.
This is the certificate authority's answer to a move Chrome made earlier, which we covered in March: Chrome named MTCs as its preferred route for post-quantum certificates on the public web. Now a CA that issues a large share of those certificates has committed to dates. Chrome sets the rules for which roots browsers trust, Let's Encrypt issues the certificates, and both now point at the same design.
Encryption first, authentication later
The plan splits post-quantum work into two jobs and gives each a different deadline.
Encryption protects secrecy. The threat is harvest-now-decrypt-later: someone records your encrypted traffic today and keeps it until a quantum computer can recover the session key. The clock starts the moment the traffic is captured, not when the quantum computer arrives. Any session that has to stay private into the late 2030s is already at risk.
Authentication protects identity. The threat is a forged signature, and forging one needs a quantum computer running during the live handshake. That depends on the machine existing, so it lands later.
This is the same split a handshake scan records, and we set it out around Sectigo's private-CA work. ML-KEM covers key exchange and stops harvest-now-decrypt-later. ML-DSA covers signatures and stops forgery. They are separate standards for separate layers, and a migration plan reads more clearly when each is its own line.
Let's Encrypt's advice is about the first job. Turn on hybrid key exchange now, since the major browsers and operating systems already support it. A server that negotiates no post-quantum key exchange is still open to harvest-now-decrypt-later, which is why [PQ]probe caps its grade at C, and why origin numbers, which sit near zero behind the edge as we recorded before, tell you more than headline adoption figures. A CA of this size saying the same thing is a useful outside reference.
Why authentication is harder
Authentication trails encryption because post-quantum signatures are big. ML-DSA-44 is one of the smaller standardized schemes, and its signature runs about 2,420 bytes, against 256 for RSA-2048 and 64 for ECDSA-P256. Public keys follow the same pattern: 1,312 bytes for ML-DSA-44, against 256 and 64. A typical web handshake carries five signatures and two public keys, so swapping in ML-DSA everywhere pushes one handshake past 10 KB. Cloudflare measured that at that size a measurable share of TLS connections fail on live networks, and the rest run slower. We worked through the byte counts earlier.
Merkle Tree Certificates cut the size by changing how certificate trust is built, not the algorithm underneath. Rather than sign each certificate on its own, an MTC authority signs a whole batch at once, under one signature. Clients keep up with those batch signatures, called landmarks, outside the TLS handshake. In the normal case a server presents one signature, one public key, and a short proof that the certificate sits in the published tree, which together come to less than today's certificate chain even though they use post-quantum algorithms. A larger standalone form is the fallback when a client's landmark is out of date. Because every certificate is part of a published Merkle tree by design, certificate transparency comes built in instead of bolted on afterward, and a certificate cannot exist outside the tree.
Let's Encrypt notes that issuing MTCs at its scale means changes across its issuance systems, the ACME protocol its subscribers use to get certificates, its revocation and operational tooling, and the transparency logs, which become part of issuance under MTCs. It has run certificate-transparency logs, which are append-only Merkle trees, since 2019, so the core data structure is one it already operates. It is also tracking the conventional path, ML-DSA inside X.509 under RFC 9881 and inside TLS under draft-ietf-tls-mldsa, since the result could be an MTC or an ML-DSA-signed X.509 certificate, depending on how the standards and root programs settle. The MTC design is being standardized in the IETF PLANTS working group, and Cloudflare and Chrome are testing it against live traffic.
Where the dates sit
Let's Encrypt's timeline lands inside a run of deadlines the plan itself points to. CNSA 2.0 moves US national-security systems to post-quantum algorithms on a schedule running through 2030 and 2035. NIST's draft guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035. The EU roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. Google has said it will move its services by 2029, and Cloudflare has made a similar commitment. Go 1.27 adds ML-DSA to its standard library, which lowers the cost of building it in.
None of these bind the public web directly. Together they set the end-of-decade window the libraries, browsers, and certificate authorities behind the web are now working toward. Staging in late 2026 and production in 2027 puts Let's Encrypt ahead of the regulatory dates and in step with the browser and CDN commitments. We track these alongside the rest on the compliance timeline.
What you can measure
If you are checking your own position, the two jobs are at different stages.
Key exchange you can measure today, and it is the immediate priority. A scan of a live handshake shows the group that was actually negotiated, which for most origin servers is still a classical elliptic-curve exchange. That is the value to bring down now, and it is the one Let's Encrypt is telling the ecosystem to fix.
Certificate authentication becomes a second thing to watch once MTC issuance reaches production. The distinction there is the one that already applies to key exchange. Whether a CA can issue post-quantum certificates is separate from whether a given server presents and negotiates one in a live session. That is the same edge-versus-origin gap we saw when edge adoption ran well ahead of near-zero origin deployment. A vendor saying it supports post-quantum certificates does not prove that any given endpoint negotiates one. You confirm that by looking at the handshake.
The destination for authentication is not fixed yet either. The choice between Merkle Tree Certificates and ML-DSA-signed X.509, and the root-program rules around it, are still being worked out. A single snapshot of preparedness means less while the target is still moving. The more reliable reading is the direction of change across repeated scans, measured against a reference that is itself moving.
Long-lived keys are the exception
One caveat sits on top of the idea that authentication can wait. It holds for the leaf certificate a server presents during a handshake, where forging it needs a quantum computer live at the moment of the connection. It holds much less for long-lived signing keys. Root CA keys and code-signing keys sign things that have to stay trustworthy for years, and the plan flags long-lived keys as especially valuable targets. Reading "authentication is less urgent" as a flat rule would defer exactly the keys with the longest life. The right order separates a short-lived leaf certificate from a root that has to last for decades.
What to do now
For most operators the plan comes down to one thing to do now and one to watch. The thing to do is about secrecy: turn on hybrid post-quantum key exchange, and check the negotiated group in the handshake. That matches Let's Encrypt's own advice. The thing to watch is authentication: post-quantum certificates are still a few years out, will arrive through ACME the way today's certificates do, and will bring both a new certificate format to negotiate and a new property to check. If you run ACME clients or certificate pipelines, it is worth following the PLANTS working group now, since client support has to be in place before issuance helps at scale.