Google Trust Services Targets Merkle Tree Certificates for 2028

Google’s 2028 certificate milestone makes its 2029 PQC target actionable​

Google announced its 2029 post-quantum cryptography, or PQC, migration timeline on March 25, 2026. Its stated reasoning included progress in quantum hardware, error correction and estimates of the resources needed to break existing public-key cryptography. Google also explicitly elevated authentication services in its threat model, recognizing that migrating encryption alone would leave digital signatures and identity infrastructure exposed to future quantum attacks.

The August Google Cloud roadmap supplies the operational detail behind that commitment. It organizes migration around three domains: “Store Now Decrypt Later (SNDL) mitigation,” “Integrity and non-repudiation,” and “Foundations and key management.” The first targets confidentiality; the second addresses forgery and authenticity; the third supplies the algorithms, libraries, key-management services and hardware foundations needed to carry out the transition.

That structure is more useful than a single finish date. A company can have quantum-resistant key exchange on an internet-facing connection while still relying on conventional signatures for the server’s certificate, its software deployment pipeline and its identity tokens. Google’s roadmap treats these as related but separate engineering jobs, with different dependencies and completion targets.

The certificate implications were highlighted in a September 22 TechRadar Pro commentary by Jason Soroko, Sectigo’s senior vice president of product. His central argument—that organizations should prepare to change certificate infrastructure without a multiyear redesign—is supported by Google’s published milestones. His piece is an industry participant’s analysis, however, rather than an independent performance test of the proposed certificate system.

The milestones most relevant to that argument are these:

These are Google’s published statuses and targets, not independently measured deployment coverage. Google says individual product schedules may change with engineering requirements and third-party dependencies. It also acknowledges that some physical hardware transitions could extend beyond 2029 because they involve both active replacement and normal equipment-refresh cycles.

That qualification belongs beside the dates. Google’s 2029 commitment is neither a universal certificate-expiration deadline nor a requirement imposed on every enterprise. It is a substantial supplier’s migration target, useful for planning dependencies and procurement, but it does not tell an organization when every browser, operating system, appliance or private application will support the same certificate format.

Post-quantum key exchange and certificate authentication solve different problems​

The most important technical distinction in this transition is between protecting the secrecy of a connection and proving who is at the other end.

Google’s March announcement describes the confidentiality threat as present-day collection for future decryption: an adversary could retain encrypted communications now and attempt to decrypt them once a sufficiently capable quantum computer exists. Information with a long useful life creates the strongest concern. A connection can finish successfully today while the confidentiality of its recorded contents remains a future target.

Authentication has a different timeline. Let’s Encrypt’s June 3 explanation of its post-quantum plans describes the web-authentication threat in terms of a quantum computer capable of forging signatures when an attacker needs to impersonate a server. That differs from collecting encrypted traffic and waiting to decrypt it. Nevertheless, replacing the authentication infrastructure takes enough time that postponing the work until such a computer exists would be impractical.

This distinction explains why Google is pursuing multiple tracks. Its Cloud API endpoints support ML-KEM, a standardized post-quantum key-encapsulation mechanism, in hybrid mode. Its application and proxy load balancers support the TLS 1.3 hybrid key-exchange configuration named X25519MLKEM768. Those capabilities address confidentiality, including the risk from traffic captured today. They do not, by themselves, establish that the certificates authenticating those connections have migrated to quantum-resistant signatures.

ML-DSA belongs to the signature side of the problem. It provides a standardized post-quantum digital-signature algorithm. Describing it as the answer to quantum risk without specifying its role can obscure the work still needed elsewhere: a signature algorithm does not substitute for a key-exchange mechanism, and a key-exchange upgrade does not replace a certificate’s authentication machinery.

For an administrator, the practical consequence is that “PQC enabled” is too imprecise to serve as a complete inventory entry. A useful migration record distinguishes the protection of data in transit from the algorithms used to authenticate endpoints, sign software or validate identity tokens. Google’s own roadmap makes that separation, assigning confidentiality work a different set of service milestones from integrity and authentication work.

The same distinction prevents a misleading conclusion about existing deployments. An organization using a conventional certificate might already be gaining post-quantum confidentiality protection through compatible hybrid key exchange. Conversely, adopting a post-quantum signing service would not demonstrate that all network paths carrying sensitive information are protected against future decryption.

There is therefore useful work to do before Merkle Tree Certificates arrive. Google explicitly recommends validating applications against its quantum-safe APIs and load balancers, updating client software that negotiates the connections, and identifying cryptographic resources. Those are supported preparation steps for Google Cloud customers; they are not evidence of a universal setting that can be applied to every Windows server, browser or network appliance.

Larger signatures turn certificate migration into a networking problem​

Choosing a standardized post-quantum signature algorithm resolves only part of the deployment problem. The authentication data still has to travel across real networks and pass through existing software.

Let’s Encrypt illustrates the size difference using ML-DSA-44, one of the smaller standardized post-quantum signature schemes. It gives an approximate signature size of 2,420 bytes, compared with 256 bytes for RSA-2048 and 64 bytes for ECDSA-P256. Its comparison also shows substantially larger post-quantum public keys.

Those figures become operationally significant because a web connection carries more than one signature. Let’s Encrypt describes a typical existing Web PKI handshake as carrying five signatures and two public keys. Replacing those components with ML-DSA equivalents would, in its analysis, push a single handshake well beyond 10 kilobytes.

Let’s Encrypt cites Cloudflare research indicating that a meaningful share of real-world TLS connections fail at that scale, while others become slower. The June announcement does not supply enough experimental detail to turn that statement into a universal failure rate, and it should not be treated as a benchmark for a particular enterprise network. It does establish why certificate designers are considering architectural changes rather than simply substituting a new algorithm everywhere.

The concern extends beyond bandwidth consumption. If a security upgrade makes connections less reliable, deployment becomes harder to enable by default. MTCs are intended to reduce that conflict by changing how certification evidence is represented and distributed.

Merkle Tree Certificates move repeated trust data out of the handshake​

A Merkle Tree Certificate, or MTC, is a proposed way to authenticate a website without repeatedly transmitting the full weight of conventional post-quantum certificate-chain signatures.

Let’s Encrypt describes the basic change as batch issuance. Instead of signing every certificate individually, a certificate authority signs a batch containing many certificates. A website then supplies a compact inclusion proof: evidence that its certificate belongs to the batch covered by the authority’s signature.

The batch is organized using a Merkle tree. For the purpose of understanding this proposal, its useful property is that a compact proof can connect one entry to a summary representing many entries. The browser can validate that relationship without receiving every certificate in the batch.

The design does not make the certificate authority’s signature unnecessary. It changes how often the resulting trust evidence needs to be carried through individual connections. Let’s Encrypt calls the batch-signature information maintained by browsers “landmarks” and says browsers keep up with it separately from the TLS handshake.

This is the source of the anticipated efficiency gain. When the browser already has the necessary landmark information, the server can use the compact path rather than repeatedly delivering the larger certification structure. According to Let’s Encrypt, the common MTC authentication path contains one signature, one public key and one inclusion proof, making it smaller than today’s Web PKI handshake despite its use of post-quantum algorithms.

That statement is a design claim from an organization implementing the technology, not a WindowsForum measurement. It also describes the common case, not every possible connection. Let’s Encrypt identifies a larger “standalone” form for situations in which a client’s landmark is out of date.

The fallback is an important operational detail. A design that benefits from pre-distributed information must also account for clients that have not received the latest information. The standalone form means the proposal is not based solely on the assumption that every browser always has perfectly current local state.

It also changes what a useful future evaluation should measure. A test limited to an up-to-date client could demonstrate the compact path while overlooking the behavior of stale clients. A realistic assessment will need to distinguish the optimized handshake from fallback behavior, rather than publishing one certificate-size figure as though it covers every deployment condition.

MTC transparency becomes part of issuance​

MTCs also change the relationship between certificate issuance and public visibility.

In Let’s Encrypt’s description of today’s Certificate Transparency system, a certificate authority issues a certificate and then has it logged separately. Additional signatures travel with the TLS handshake to attest to that logging. Transparency is therefore a separate mechanism attached to the issuance process.

With MTCs, the certificate is part of a published Merkle tree from the outset. The inclusion proof is evidence of that membership. Let’s Encrypt describes transparency as a property of issuance itself: a certificate cannot exist outside the tree that certifies it.

This is a meaningful structural change, but it should be understood precisely. Inclusion establishes that an entry belongs to the relevant published certificate structure. It does not, by itself, establish that every certificate was correctly authorized or that all operational mistakes become impossible.

Public visibility and correct issuance are related security goals, not interchangeable ones. The value of the MTC arrangement is that transparency evidence is integral to the proposed certification mechanism, rather than an additional set of promises accompanying a separately issued certificate.

Let’s Encrypt brings relevant operational experience to that work. It says it has operated Certificate Transparency logs since 2019, using append-only Merkle trees. That provides a concrete precedent for operating the underlying data structure at scale, although an existing transparency-log service is not proof that the complete new certificate system has finished its engineering work.

The distinction is worth retaining. MTCs reuse ideas with production history while changing how browsers, certificate authorities and issuance clients interact. Familiar components reduce the amount of wholly new machinery involved; they do not eliminate the need for interoperability testing and standards work.

X.509 continuity does not guarantee drop-in compatibility​

Soroko’s TechRadar Pro commentary describes MTCs as X.509 certificates that carry a proof in place of conventional signature treatment. That narrower point is useful: the proposal should not be understood as a wholesale abandonment of every aspect of the existing certificate model.

But retaining X.509 does not establish that existing certificate software will accept the new authentication method unchanged. Let’s Encrypt’s implementation plan explicitly calls for changes to issuance infrastructure, the ACME protocol used to obtain certificates, revocation and operational tooling, and transparency infrastructure.

That is the compatibility boundary administrators should keep in mind. A familiar certificate container does not remove the need for the issuing service, client software, validation code and deployment pipeline to agree on how the new proof is created, conveyed and verified.

For now, the strongest supported conclusion is that MTCs aim to preserve useful certificate infrastructure while changing a costly part of its authentication model. They are still a migration, with software dependencies on both sides of the connection.

Public-web MTCs and private post-quantum PKI are separate tracks​

Google’s roadmap does not propose one certificate format for every environment. Under its integrity domain, it describes both Merkle Tree Certificates for the public Web PKI and support for ML-DSA or SLH-DSA certificates in private certificate-authority services.

That separation is essential for enterprise readers. A public website’s browser-facing certificate and a certificate used inside a private application environment may share cryptographic concepts, but they do not necessarily share trust policies, deployment schedules or client populations.

Google targets its Certificate Authority Service work for 2027 and Google Trust Services MTCs for 2028. The roadmap also says these certificate transitions will follow IETF standardization efforts. It is therefore more accurate to describe coordinated but distinct projects than a universal replacement of conventional certificates on a single date.

The public-web path has visible support beyond Google. Let’s Encrypt announced on June 3 that it plans to pursue MTCs for its post-quantum Web PKI, targeting a staging environment in late 2026 and a production-ready environment in 2027. It also reports that Chrome and Cloudflare are running a feasibility experiment using real internet traffic.

Those statements establish participation, plans and experimentation. They do not establish general production availability. In particular, a target for a staging environment is an invitation to prepare for testing, not a reason to assume that production certificate pipelines can already request and deploy the new format.

Let’s Encrypt identifies the IETF PLANTS working group as the home of the standardization effort and says it is participating in both PLANTS and ACME work. Its announcement also describes MTCs as Chrome’s preferred path for bringing post-quantum certificates to the public web.

Soroko goes further, describing a planned Chrome Quantum-resistant Root Store that would support quantum-resistant certificates only in MTC form. That specific restriction is reported in his commentary; Let’s Encrypt’s announcement corroborates Chrome’s preference for MTCs, rather than independently establishing every future root-program rule. Organizations should distinguish the supported direction of travel from final acceptance policies that will govern production deployments.

For Windows administrators, none of these announcements establishes a Microsoft-wide certificate transition. They do not provide an affected-version matrix for Windows, declare Microsoft Edge support, or specify changes to Microsoft’s private-PKI products. A Chrome roadmap should not be converted into an assumed Windows trust-store policy.

The actionable boundary is the application and service actually involved. A Google Cloud load balancer, a Chrome client, an ACME issuance client and an internally managed certificate authority may each reach post-quantum readiness at different times. A migration plan needs to identify those dependencies instead of assigning one readiness label to the entire estate.

Google’s wider roadmap shows why a certificate purchase is insufficient​

The MTC milestone attracts attention because certificates are highly visible trust artifacts. Google’s surrounding roadmap demonstrates how much migration work sits behind them.

For confidentiality, Google targets completion of its first domain by the end of 2027. Beyond public API endpoints and load balancers, it names administrative and developer paths such as Cloud VPN, Cloud Interconnect, GCE OS Login, Cloud SDK, the gCloud CLI, GKE service mesh and client libraries. Data-transfer paths include Cloud Storage SDK, Storage Transfer Service, BigQuery CLI and Data Transfer Service. The listed schedules span 2026 and 2027.

The significance is coverage. Protecting a customer-facing session does not establish that the management connection used to configure the service, or a transfer path moving sensitive data between systems, has received equivalent protection. Google’s service-by-service approach exposes these as separate migration surfaces.

Its integrity roadmap is broader still. Alongside certificates, it includes software attestations and identity systems: Binary Authorization and Access Approval are listed for 2026, Assured OSS for 2027, and Cloud IAM for 2028. It also targets infrastructure-wide quantum-safe authentication and access work across 2027 and 2028. These are roadmap entries, not a declaration that every named capability has already shipped.

The connection to certificate planning is practical. Organizations often encounter digital signatures through HTTPS certificates, but those signatures also support decisions about which software may run and which identity claims a service should accept. Buying or obtaining a new class of web certificate would address only one part of that dependency chain.

The foundations domain supplies another boundary. Cloud KMS already offers the standardized algorithms ML-KEM, ML-DSA and SLH-DSA, while other milestones cover quantum-safe key import, hardware-backed cryptographic services, Confidential Computing and external key-management arrangements. Several of those foundational targets fall in 2028.

Availability of an algorithm in a key-management service is valuable, but consuming applications still need compatible logic and protocols. Google makes that responsibility split explicit: it manages the security of its cloud infrastructure, while customers must manage their applications, update client software, maintain asymmetric-key lifecycles and adopt appropriate service configurations.

This is where cryptographic agility becomes a concrete engineering requirement. In Google’s usage, it means building systems that can adopt changing cryptographic standards with minimal engineering effort. For an enterprise, the implication is to understand which parts of a certificate or signing workflow can be updated through supported components, and which are entangled with application-specific assumptions.

Let’s Encrypt’s ACME plans illustrate the point. Certificate automation remains useful, but the automation clients themselves may need new capabilities. A pipeline can renew conventional certificates reliably today and still require software work before it can handle a new issuance protocol or certificate proof.

What this means for your certificate migration plan​

Keep supported production certificates in service while preparing the dependencies that will let you adopt post-quantum capabilities safely. Google’s already available key-exchange features justify evaluation now; its 2028 MTC milestone justifies planning, rather than an immediate public-certificate replacement campaign.

Let’s Encrypt makes the present-day position particularly clear for its subscribers: its June announcement says existing certificates continue to be issued and renewed as before. Its post-quantum plans do not require customers to abandon their current certificate workflows today.

• Inventory keys, certificates and the applications that depend on them, separating confidentiality requirements from authentication and signing requirements.
• For Google Cloud workloads, evaluate the documented hybrid post-quantum key-exchange capabilities without treating them as proof that certificate authentication has also migrated.
• Maintain certificate-lifecycle automation, and include the ACME client and deployment pipeline in compatibility planning rather than assessing the certificate authority alone.
• Ask certificate authorities and service providers for product-specific PQC roadmaps that distinguish public MTCs, private post-quantum certificates and general algorithm availability.
• Treat staging environments and feasibility experiments as testing opportunities, and retain production deployment gates until the relevant clients, services and trust policies support the intended configuration.

Begin with dependencies rather than a certificate count​

Google recommends inventorying cryptographic resources, including keys and certificates, and names Cloud Asset Inventory as one tool for its environment. The purpose is to map usage well enough to prioritize a migration backlog. A raw count of certificates is less useful than knowing which service consumes each one and which software must change with it.

As a planning implication, associate each identified certificate workflow with its issuing authority, renewal mechanism, deployment owner and consuming clients. That turns an inventory into a dependency map: if a future certificate profile requires a new ACME client or verifier, the organization can identify the systems involved.

Do not assume that one cloud inventory captures every application-level dependency. Google assigns application migration and key-lifecycle responsibilities to customers. Its service readiness milestones therefore need to be connected to the software and configurations an organization actually controls.

Evaluate confidentiality protection before waiting for MTCs​

For Google Cloud application and proxy load balancers, the roadmap identifies TLS 1.3 hybrid key exchange using X25519MLKEM768, initially available on an opt-in basis. Google recommends validating existing applications against its quantum-safe APIs and load balancers to identify architectural bottlenecks.

The supplied announcements do not establish a universal console sequence, a supported command for every load-balancer configuration, or an operating-system-wide verification procedure. Inventing one would obscure the very compatibility boundaries the roadmap exposes.

A useful evaluation should therefore record the specific service configuration and client software involved. Successful application access is necessary, but the intended claim is narrower and more demanding: that the supported configuration negotiates the desired protection while preserving the application’s behavior. An MTC experiment would require a separate assessment of certificate authentication.

Require operational detail from certificate providers​

Soroko recommends requesting a written post-quantum roadmap from a certificate authority. That is a reasonable procurement action because the announcements expose several different meanings of “PQC support.”

A provider might offer post-quantum signing primitives, private certificates, an MTC staging service or production issuance. Those are different deliverables. A useful response identifies the intended certificate model, availability stage, required client changes and supported deployment path.

Let’s Encrypt supplies an example of that specificity: late-2026 staging, a 2027 production-ready target, and explicit acknowledgment that issuance, ACME, revocation tooling and transparency infrastructure need changes. Its announcement is more actionable than an undated assurance that a provider is “quantum ready.”

Operational questions should extend to fallback behavior. Because Let’s Encrypt describes both an optimized MTC path and a standalone form for stale landmarks, eventual testing should distinguish them. That is a design-specific consideration grounded in the proposed mechanism, rather than a generic demand for more benchmarks.

The next MTC milestones are interoperability milestones​

The nearest published milestone in this evidence is Let’s Encrypt’s target for an MTC staging environment in late 2026. Its planned production-ready environment follows in 2027, while Google Trust Services lists MTCs for 2028. These schedules describe different participants’ work and should not be collapsed into one universal launch date.

What matters at each stage is the set of components that can work together. Let’s Encrypt explicitly identifies browsers, libraries and ACME clients as dependencies, alongside standards and root-program requirements. A certificate authority reaching a deployment milestone is necessary progress, but customers also need software capable of requesting, serving and validating the resulting certificates.

Google’s roadmap consequently puts pressure on traditional certificate operations without making existing certificates immediately obsolete. It shows that the post-quantum transition involves handshake size, issuance protocols, client state and public transparency, as well as algorithm selection. Enterprises that map those dependencies and keep their certificate workflows adaptable will be able to evaluate MTCs when interoperable services arrive, instead of discovering then that their trust infrastructure requires a redesign.