Post-Quantum HTTPS Certificates in Google Chrome: How Merkle Tree Certificates Are Changing Web Security

Google Chrome is preparing for one of the most significant changes to HTTPS security in years. In February 2026, Google announced plans to introduce quantum-resistant website authentication using Merkle Tree Certificates (MTCs), a new approach designed to protect web connections against future quantum computing threats. Unlike conventional HTTPS certificates, which rely on chains of digital signatures, MTCs combine certificate issuance with public verification records and compact mathematical proofs. The aim is to introduce stronger cryptographic protection without making websites noticeably slower. Google has already begun testing the technology with Cloudflare, while industry specialists are developing common standards for wider adoption. Understanding this change is important because it affects how browsers establish trust, how websites prove their identities and how internet security may evolve over the coming years.

Why Google Chrome Is Preparing HTTPS for Quantum Computing

HTTPS protects information exchanged between a browser and a website. When someone opens an online banking service, shops online or signs into an account, the browser establishes an encrypted connection using Transport Layer Security (TLS). An HTTPS certificate helps confirm that the server belongs to the intended website rather than an attacker attempting to impersonate it. These certificates are issued by trusted Certificate Authorities (CAs), which verify control of domain names before issuing the relevant credentials. Chrome checks this information when establishing a secure connection, helping prevent unauthorised servers from presenting themselves as legitimate websites.

The difficulty is that much of today’s certificate infrastructure depends on public-key cryptography that sufficiently powerful quantum computers could eventually undermine. RSA and elliptic-curve cryptography are particularly relevant because a cryptographically capable quantum computer could use Shor’s algorithm to attack the mathematical problems underlying their security. Such a machine is not currently known to be capable of breaking internet-scale cryptographic keys in practical attacks. Nevertheless, changing the security systems used by billions of devices takes years, so waiting for a successful quantum attack would leave little time for a safe transition. Google has therefore made post-quantum cryptography an important part of its long-term security planning.

In March 2026, Google published a broader target of 2029 for advancing its post-quantum cryptography migration. Its Chrome certificate programme forms part of that effort, although individual implementation stages have their own schedules and technical requirements. The challenge involves more than replacing one algorithm with another. Browsers must continue recognising legitimate websites, certificate issuers must adapt their infrastructure, and existing services must remain accessible throughout the transition. The proposed solution must also work efficiently on mobile networks and less powerful devices, where larger security messages can increase connection times and data usage.

Why Traditional HTTPS Certificates Need a New Approach

Conventional HTTPS certificates use the X.509 format, which has supported website authentication for decades. A website typically presents its certificate alongside information linking it to a trusted Certificate Authority. The browser verifies the signatures in this chain before accepting the server’s identity. Chrome also requires publicly trusted certificates to satisfy Certificate Transparency requirements, which help expose certificates issued incorrectly or without authorisation. Although this arrangement is well established, it introduces additional signatures and supporting information into the authentication process.

Post-quantum digital signatures are considerably larger than many of their classical counterparts. For example, the NIST-standardised ML-DSA-44 algorithm uses a signature of 2,420 bytes, while ML-DSA-65 signatures contain 3,309 bytes. A traditional Ed25519 signature occupies only 64 bytes. These figures do not represent the complete size of an HTTPS certificate, but they illustrate why directly replacing existing signatures could substantially increase the amount of authentication data transmitted. When several signatures are required for certificate chains and transparency records, the additional traffic becomes particularly relevant for websites serving millions of connections.

Google’s proposed response is to change how certificate authenticity is demonstrated rather than simply accommodate larger files. In its February 2026 announcement, the Chrome Secure Web Networking Team explained that it had no immediate intention of adding traditional X.509 certificates containing post-quantum cryptography to the public Chrome Root Store. Instead, it is developing Merkle Tree Certificates with industry partners. The technology is intended to support stronger algorithms while reducing repeated cryptographic information during connections. Existing HTTPS certificates will continue to matter during the transition, and the new approach is not an indication that conventional HTTPS has suddenly become unsafe.

How Merkle Tree Certificates Change HTTPS Authentication

Merkle Tree Certificates use a different method of proving that a trusted authority issued a certificate. Rather than signing every certificate separately and requiring the browser to verify a lengthy chain of individual signatures, an authority can organise many issued certificates into a cryptographically connected tree. It then signs a compact representation of that tree, known as its root or tree head. The website can provide mathematical evidence that its certificate belongs to the signed collection. This makes it possible to authenticate individual certificates without repeatedly transmitting all the large signatures associated with the wider group.

A Merkle tree works by calculating cryptographic hashes of individual records and combining those hashes through successive levels until a single root value represents the entire collection. A hash is a short digital fingerprint calculated from data. Changing a certificate record would change the resulting hashes and prevent its inclusion proof from matching the trusted tree head. The browser does not need to download the complete tree to check a certificate. Instead, it can verify a relatively small set of neighbouring hashes, which establishes that the certificate belongs to the authenticated collection.

The important distinction is that Merkle trees are not themselves a replacement for post-quantum cryptography. They provide an efficient way to organise and verify information that has been authenticated using digital signatures. The Certificate Authority can sign a shared tree head using a quantum-resistant algorithm, distributing the authentication cost across many certificates. Independent organisations known as cosigners can also verify and sign views of the tree, adding oversight. The resulting design combines post-quantum authentication, compact inclusion proofs and publicly verifiable issuance records within one certificate system.

Certificate Transparency and Faster HTTPS Connections

Certificate Transparency is an established security mechanism that makes publicly trusted certificate issuance visible for inspection. Under the conventional arrangement, certificates are recorded in public logs so that website owners, security researchers and monitoring services can identify suspicious issuance. Merkle Tree Certificates incorporate this requirement directly into their design. A certificate becomes part of the authority’s public issuance tree, meaning that creating a valid certificate is linked to recording it in a verifiable structure. This reduces the separation between issuing a certificate and documenting its existence.

The proposed system also relies on independent cosigners and organisations that maintain copies of issuance records. Their involvement helps detect inconsistent information or attempts to present different versions of a certificate log to different observers. This is important because a Certificate Authority must not be treated as trustworthy merely because it can produce a valid digital signature. Public verification and independent monitoring provide additional safeguards against mistakes, compromised infrastructure and improper certificate issuance. These mechanisms do not eliminate every possibility of abuse, but they strengthen accountability and make suspicious activity easier to investigate.

For website performance, the main benefit comes from reducing repeated authentication data. Google describes two MTC deployment approaches: standalone certificates and landmark-relative certificates. Standalone MTCs retain the relevant post-quantum signatures during authentication and provide a more straightforward transitional approach. Landmark-relative MTCs can avoid transmitting those signatures when a browser already possesses trustworthy information about the signed tree. The website then supplies a compact inclusion proof. Actual speed improvements depend on browser support, network conditions, certificate configuration and implementation choices, so MTCs should not be interpreted as a guarantee that every website will load faster.

Google Chrome’s Post-Quantum Certificate Rollout and What Comes Next

Google began testing Merkle Tree Certificates with Cloudflare during 2026, including experiments involving real internet traffic. The initial feasibility work evaluates whether the proposed authentication method can operate reliably without weakening existing protections. During these experiments, connections using MTCs are also backed by conventional trusted X.509 certificates. This provides a fallback while engineers examine compatibility, performance and security behaviour. It is an important distinction: successful experimentation demonstrates technical progress, but it does not mean every Chrome user is already receiving fully quantum-resistant website authentication.

Google’s published deployment plan identifies the first quarter of 2027 as the intended period for bringing qualified Certificate Transparency log operators into the initial public MTC programme. A further stage, planned for the third quarter of 2027, involves expanding the Chrome Quantum-resistant Root Store and supporting additional certificate issuers. These dates represent Google’s announced intentions rather than unconditional release commitments. In October 2026, Google also published version 0.4.0 of its draft Quantum-resistant Root Program policy, describing requirements for certificate authorities, independent mirrors, operational reliability and public oversight. The standards themselves remain under active development within the Internet Engineering Task Force.

Chrome’s broader roadmap separates post-quantum authentication into four stages. Initially, the browser gains new cryptographic options while retaining existing methods. Later stages introduce stronger protection against downgrades, gradually require quantum-resistant certificate authorities and eventually move towards quantum-resistant server keys. This distinction matters because introducing MTC support alone does not automatically make every HTTPS connection secure against future quantum computers. Until weaker authentication options are removed or appropriately restricted, an attacker with sufficiently advanced capabilities could potentially target those alternatives. The transition must therefore address both cryptographic strength and browser trust decisions.

What Website Owners and Chrome Users Should Expect

For ordinary Chrome users, the transition should require little direct involvement. Certificate validation normally happens automatically during an HTTPS connection, and Google intends to preserve that familiar experience. Users should continue keeping Chrome updated, checking carefully for browser security warnings and avoiding websites that present certificate errors. They should not assume that a padlock or HTTPS connection proves a website is honest, however. HTTPS protects the connection and authenticates the server identity under the browser’s trust rules; it does not guarantee that a website is free from scams, malicious downloads or misleading content.

Website owners should follow developments from their hosting providers, content delivery networks and Certificate Authorities rather than attempting to replace existing certificates prematurely. As MTC services become available, adoption is expected to involve updates to certificate issuance and renewal processes, including greater use of automation. Organisations with custom TLS configurations, internal security gateways or older software may need additional compatibility testing. Businesses handling sensitive information should also review where cryptography is used across their services, because certificate authentication is only one part of preparing for quantum threats. Post-quantum key exchange, software signing, internal systems and long-term data protection require separate consideration.

Merkle Tree Certificates represent a substantial change in the foundations of browser security, but their success will depend on careful deployment and widespread industry cooperation. The involvement of Google, Cloudflare, Apple and other contributors in the emerging IETF specification demonstrates that the work extends beyond a single browser feature. As of November 2026, the central achievements are an actively developed technical standard, real-world experiments and a clearer route towards quantum-resistant certificate infrastructure. If the transition proceeds successfully, Chrome will be able to verify website identities using stronger cryptography without imposing unnecessary authentication overhead on everyday browsing. The immediate priority remains maintaining reliable HTTPS connections while preparing the underlying trust system for future risks.