Let’s Encrypt plans to pursue a post-quantum-safe Web PKI through Merkle Tree Certificates (MTCs), a new approach that adds post-quantum authentication to the web without sacrificing the speed and reliability that have made TLS universal. The project is targeting late 2026 for a staging environment that issues MTCs, with a production-ready environment planned for 2027.
“For much of the last several years, the conversation about post-quantum cryptography has been a conversation about encryption. The reasoning was straightforward: an attacker who records encrypted traffic today might be able to decrypt it years from now once quantum computers can break the underlying math,” Andrew Gabbitas, Software Engineer at Let’s Encrypt, explained.
Preparing the Web PKI for post-quantum authentication
Supporting MTCs requires changes throughout Let’s Encrypt’s infrastructure, including certificate issuance, ACME, revocation systems, operational tooling, and the transparency infrastructure that MTCs incorporate. Let’s Encrypt is participating in the IETF PLANTS and ACME working groups as the standards develop.
It is tracking standards work around ML-DSA signatures in X.509 and TLS, along with ecosystem changes such as ML-DSA support in the Go standard library. The Web PKI’s transition to post-quantum security depends on adoption in browsers, libraries, and ACME clients, whether the end result is MTCs or ML-DSA-signed X.509 certificates.
Transition timeline
The NSA’s CNSA 2.0 suite has directed national security systems toward post-quantum algorithms on a 2030-to-2035 schedule since 2022. NIST’s draft guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035. The European Union targets high-risk systems by 2030 and broad migration by 2035. These initiatives set the timeline that vendors, libraries, and standards bodies in the Web PKI ecosystem are already working toward.
In 2026, Google announced plans to migrate its services by 2029, and Cloudflare made a similar commitment. Go 1.27 adds the NIST-standardized ML-DSA signature scheme to the standard library. Post-quantum signatures are moving into mainstream infrastructure.
Why post-quantum authentication matters
Authentication is the part of TLS that verifies a server’s identity. To break it, a quantum computer would need to forge a signature in real time. This threat depends on the existence of a cryptographically relevant quantum computer (CRQC).
The Web PKI ecosystem should not postpone post-quantum authentication. Long-lived keys, including root certificate authorities, code-signing keys, and identity systems, remain valuable targets. Because new technology takes years to reach broad adoption, deployment work needs to begin well before cryptographically relevant quantum computers become available.
Why Web PKI needs a different approach
The scale of the Web PKI makes post-quantum signatures difficult to deploy. A typical TLS handshake carries five signatures and two public keys. Replacing them with ML-DSA would increase a single handshake to more than 10 kilobytes.
Larger handshakes would increase bandwidth usage and connection overhead for every TLS session. Any solution must work at web scale and be practical to enable by default.
How MCTs work
An MTC certificate authority issues certificates in batches, with a single signature covering an entire batch rather than signing certificates individually. Browsers keep landmarks up to date outside the TLS handshake. The authentication path in an MTC handshake consists of one signature, one public key, and one inclusion proof. Even with post-quantum algorithms, it is smaller than a conventional TLS handshake.
A standalone mode is available for clients with outdated landmarks and uses slightly larger handshakes when necessary.
MTCs integrate Certificate Transparency into the issuance process. Today, certificates are issued by certificate authorities and logged separately, with additional TLS handshake data proving that logging occurred. Under MTCs, certificates exist only within the Merkle tree.
Next steps
Since 2019, Let’s Encrypt has operated Certificate Transparency logs, which are append-only Merkle trees based on the same underlying data structure as MTCs. Cloudflare and Chrome are testing MTCs on live internet traffic, the IETF’s PLANTS working group is developing the standard, and Chrome has identified MTCs as its preferred approach for post-quantum certificates on the public web.
The transition will take time. Standards are still being finalized, root programs are defining their requirements, and support still needs to be added to browsers, libraries, and ACME clients. Let’s Encrypt will provide updates as development continues and deployment timelines become more defined.
ACME client developers and operators of ACME-based certificate pipelines should follow the work in the IETF PLANTS working group and the discussions on the mailing list. Some of the upcoming changes will require client-side support, and early preparation will help smooth adoption.
Post-quantum encryption remains the more immediate concern for the broader internet community. TLS traffic that does not use post-quantum key exchange can be recorded today and decrypted in the future once a cryptographically relevant quantum computer becomes available.
“If you operate servers, please ensure they support hybrid post-quantum key exchange (X25519MLKEM768). Major browsers and operating systems already do, and turning it on at the server is one of the highest-leverage things you can do this year,” Gabbitas concluded.
