Google’s PQC roadmap puts traditional digital certificates under pressure

In March, Google moved its own post-quantum cryptography (PQC) migration deadline forward to 2029, a full six years ahead of NIST's guidance, and two ahead of the NSA's requirement for national security systems.

<![CDATA[ <article> <p>In March, Google moved its own post-quantum cryptography (PQC) <a href="https://www.techradar.com/best/best-data-migration-tools">migration</a> deadline forward to 2029, a full six years ahead of NIST's guidance, and two ahead of the NSA's requirement for national security systems. It was a terrific bit of security signaling, but now it is backed up by a new product-by-product roadmap organized around three risk domains, with milestones attached to named services.</p><p>For anyone whose job touches digital trust, the most significant of those three domains is Google’s attempt at enhancing foundational capabilities for cryptographic agility: building flexible systems that can adopt new cryptographic standards with minimal engineering effort as those standards evolve.</p><p>The message is that organizations should prepare for a future in which standards, certificate formats, and operational requirements continue to evolve, and evolve regularly, requiring cryptographic agility.</p><h2 id="why-quantum-risk-is-already-a-digital-trust-problem">Why quantum risk is already a digital trust problem</h2><p>Adversaries are already harvesting and storing encrypted <a href="https://www.techradar.com/best/best-data-recovery-software">data</a> today on the assumption that a future quantum computer will decrypt it (harvest now, decrypt later). Anything with a long confidentiality tail, from health records to national archives to intellectual property, is already exposed to a machine that does not yet exist. </p><p>Quantum-resistant algorithms, like ML-DSA, solve the cryptographic problem, but they introduce much larger keys and signatures. Deployed through today's public key infrastructure (PKI), they would inflate or possibly break the systems behind secure connections. Legacy systems and high-latency networks would feel it most.</p><h2 id="what-is-a-merkle-tree-certificate-mtc">What is a Merkle Tree Certificate (MTC)?</h2><p>At the time this article is being written, the most significant development in Google's roadmap may be the easiest to miss. Under Domain 2, Integrity and non-repudiation, a single line reads:</p><p>“Google Trust Services, Merkle Tree Certificates, 2028”.</p><p>Merkle Tree Certificates (MTCs) are a new kind of <a href="https://www.techradar.com/news/the-best-website-builder">website</a> domain certificate designed to keep secure connections fast in the coming era of quantum computers. Today a website proves its identity by presenting a certificate that carries several digital signatures, and the quantum-resistant versions of those signatures are so bulky they would slow down every secure connection on the internet.</p><p>MTCs solves this by having the certificate authority (CA) record everything it issues in a public, tamper-evident log, organized as a Merkle tree. Rather than carrying heavy signatures, the website presents a short trail of digital fingerprints showing its certificate sits in that log, and the <a href="https://www.techradar.com/best/most-secure-browsers-heres-our-pick">browser</a> checks the trail against a summary of the log it already received through its normal software updates.</p><p>Of note, MTCs do not abandon X.509. They are X.509 certificates, carrying a proof where a signature used to sit, issued alongside conventional directly-signed certificates rather than replacing them.</p><p>The result is a certificate that stays small, stands up to quantum computers, and is publicly verifiable by default. For the regular everyday person: we get to keep using the internet fast and uninterrupted with quantum resistance underneath.</p><h2 id="mtcs-make-transparency-structural">MTCs make transparency structural</h2><p>In today's web PKI, transparency is bolted onto issuance as a separate step. The CA signs a certificate, submits it to independent CT logs, and collects SCTs, each of which is a log's signed promise to publish the certificate within a fixed window. A misbehaving or compromised log can vouch for a certificate that never becomes visible to the monitors watching for misissuance.</p><p>MTCs change that relationship. The CA certifies by logging, and a certificate is literally a proof that its entry appears in the CA's public issuance log, verified by the browser on every connection. If it is not in the log, it is not a certificate. Under MTC, transparency does not merely survive the post-quantum transition. It comes out stronger.</p><h2 id="who-is-developing-merkle-tree-certificates">Who is developing Merkle Tree Certificates</h2><p>When the vendor with the dominant browser share proposes a new certificate format and a new root store to hold it, it is reasonable to ask whether the rest of the ecosystem is being consulted or simply informed.</p><p>However, MTCs are not Google's alone. At the time of writing, the IETF draft's authors span Google, Apple, Cloudflare, and Geomys. Cloudflare has been involved from the outset, CAs including Sectigo have contributed to the underlying research, and Let's Encrypt publicly committed to MTCs in June 2026. The result will be an open standard any CA can implement, controlled by no single vendor.</p><p>The organizations that will shape post-quantum web trust are the ones in the working group now. Root programs, CAs, and large implementers who stay outside it will inherit decisions rather than influence them. That choice is available to everyone, and the window is open today.</p><h2 id="how-organizations-should-prepare-for-mtcs">How organizations should prepare for MTCs</h2><p>Google’s 2028 date for MTCs deserves a roadmap's usual caveats. Google ties it to standardization work still in progress at the IETF, and dates like these move. The direction, however, resembles something that seems settled.</p><p>Chrome's planned Quantum-resistant Root Store will support quantum-resistant certificates only in the MTC format, not as post-quantum signatures bolted into traditional X.509. Compact classical signatures and X.509 served the web extraordinarily well for three decades, but with the dawn of quantum <a href="https://www.techradar.com/news/computing/pc/10-of-the-best-desktop-pcs-of-2015-1304391">computing</a>, we are due for a redesign.</p><p>For everyone else, the practical implication of Google's roadmap is not that you need MTCs. It is that you need to be capable of adopting them (or whatever else emerges) without a multi-year engineering program. Which is precisely the cryptographic agility Google put at the foundation of its own plan.</p><p>In concrete terms, organizations should focus on:</p><ul><li>A complete inventory of certificates and cryptographic assets, because you cannot migrate what you cannot see</li><li>Automated certificate lifecycle management, because shorter certificate lifetimes will make manual processes untenable well before quantum computers arrive</li><li>A written post-quantum roadmap from your CA, which every organization should be asking for</li></ul><p>The full scope of what MTCs can do is still coming into focus, and they may not be the only answer the industry ultimately adopts. What is already clear is that organizations that invest in cryptographic agility, certificate lifecycle <a href="https://www.techradar.com/best/it-management-tools">management</a>, and complete visibility today will be best positioned to adapt as post-quantum standards mature. </p><p>The future of digital trust will belong to organizations that can evolve as quickly as the cryptography they depend on.</p><p><em></em><a href="https://www.techradar.com/news/best-endpoint-security-software"><em>We've featured the best endpoint protection software.</em></a></p><p><em>This article was produced as part of </em><a href="https://www.techradar.com/pro/perspectives" target="_blank"><em>TechRadar Pro Perspectives</em></a><em>, our channel to feature the best and brightest minds in the technology industry today.</em></p><p><em>The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: </em><a href="https://www.techradar.com/news/submit-your-story-to-techradar-pro" target="_blank"><em>https://www.techradar.com/pro/perspectives-how-to-submit</em></a></p> </article> ]]>