How Google Is Making HTTPS Quantum-Proof Without Slowing Down the Internet.
TL;DR — Key Takeaways:
- HTTPS certificates are currently protected by cryptography that quantum computers will eventually break
- Replacing that cryptography directly would make certificates 40 times larger, crippling web performance
- Google's Merkle Tree Certificate (MTC) system compresses authentication back to today's size while using quantum-resistant algorithms underneath
- Google is already running live experiments with Cloudflare, with a full rollout planned by Q3 2027
- For Indian businesses under the DPDP Act 2023, this transition will affect how digital certificates, data transmission security, and website compliance are evaluated
The padlock in your browser address bar sits on a ticking clock.
Not because of a software bug. Not because of a breach. Because a category of computer, one that does not yet fully exist at scale, will eventually make the mathematics protecting that padlock trivially solvable.
Every encryption protocol powering HTTPS today, including the certificates that verify who a website actually is, relies on problems that classical computers find impossibly hard: factoring enormous prime numbers, solving discrete logarithms. Quantum computers running Shor's algorithm can solve these in a fraction of the time.
The security research community has known this for years. NIST finalized post-quantum cryptographic standards in 2024 to address it. The problem is what happens when you actually try to use them inside the existing HTTPS infrastructure.
That is where Google's announcement on February 27, 2026 becomes interesting.
Why the "Simple Fix" Would Break the Web
The intuitive solution to quantum-vulnerable certificates is to swap in quantum-resistant algorithms and move on. The math changes. The structure stays the same. Done.
Except the post-quantum algorithms approved by NIST produce cryptographic material that is orders of magnitude larger than what we use today. A current X.509 certificate carries roughly 64 bytes of key and signature data per link in the chain. The post-quantum equivalent swells to approximately 2.5 kilobytes per certificate — roughly 40 times the current size.
That number sits on the critical path of every single HTTPS connection made anywhere on the web. Before any page content loads, the certificate must be transmitted and verified. Chrome processes billions of TLS handshakes per day.
The size bloat does not just slow page loads. It creates compounding failures: higher connection error rates on mobile networks, crushed throughput on bandwidth-constrained infrastructure, and serious stress on intermediary servers that process those handshakes at scale. Google stated plainly that Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Doing so would create a performance crisis at internet scale.
The architecture itself needed to be rethought. Merkle Tree Certificates are Google's answer to that problem.
What Merkle Tree Certificates Actually Do
A Merkle tree is a data structure with one critical property: you can prove that one item belongs to a large dataset using only a small chain of hash values, not the entire dataset.
Here is how that maps onto HTTPS certificates.
Under the traditional X.509 model, a Certificate Authority signs each certificate individually. Under the Merkle Tree Certificate (MTC) model, the CA signs a single "Tree Head" that represents potentially millions of certificates simultaneously. When your browser connects to a website, the server does not hand over a bulky certificate chain. It hands over a lightweight proof of inclusion in that tree, a compact set of hashes demonstrating that its certificate is one of the millions the Tree Head represents.
The browser verifies the proof against the Tree Head. The handshake completes. Total authentication data transmitted: approximately 64 bytes, identical to today's footprint.
Security strength and transmission size are now independent of each other. You can use quantum-resistant cryptography underneath without paying a bandwidth penalty on top.
Transparency Gets Built In, Not Bolted On
There is a second benefit to the MTC model that receives less attention than the size story.
Today's Certificate Transparency system, the public audit log designed to catch fraudulent or misissued certificates, is a separate layer attached to the TLS handshake. It adds overhead. It creates edge cases where proofs are missing or incomplete. And it is possible to issue a certificate without it appearing in a CT log immediately, which creates windows where rogue issuance can go undetected.
Under the MTC model, it is structurally impossible to issue a certificate without including it in a public, auditable tree. Transparency is not an add-on requirement. It is how the issuance mechanism functions.
The 2011 DigiNotar breach, in which a compromised Certificate Authority issued hundreds of fraudulent certificates for major domains including Google's own properties, became known only after the damage was done. Under the MTC architecture, that class of attack cannot be hidden from the moment it happens. Every certificate issued is public record by definition.
The Three-Phase Rollout Timeline
Google is not flipping a switch. The transition is structured in three phases.
Phase 1 (Underway now): In collaboration with Cloudflare, Google is conducting a live feasibility study to evaluate the performance and security of TLS connections using MTCs. Every MTC-based connection in this experiment is backed by a traditional, trusted X.509 certificate as a fallback. No user's security is degraded while the technology is validated against real-world traffic conditions.
Phase 2 (Q1 2027): Google will invite established Certificate Transparency log operators with at least one usable log in Chrome before February 1, 2026 to participate in bootstrapping the public MTC infrastructure. These operators already run high-availability global security services, and the MTC architecture shares deep structural similarities with CT infrastructure, making them the most qualified group to get this running reliably from day one.
Phase 3 (Q3 2027): Google will finalize the requirements for onboarding Certificate Authorities into the new Chrome Quantum-resistant Root Store (CQRS), a dedicated trust framework built specifically for MTCs. The CQRS will operate alongside the existing Chrome Root Program to ensure a managed transition. Websites will also gain the ability to opt into downgrade protections, ensuring that sites committed to quantum-resistant certificates can enforce that standard for their users.
Why This Matters Now, Not in a Decade
Post-quantum threats still feel abstract to most people because the quantum computers capable of running Shor's algorithm at meaningful scale do not yet exist. So why is Google building this infrastructure in 2026?
Two reasons matter here.
First, "harvest now, decrypt later" attacks are not theoretical. Nation-state actors are actively capturing encrypted internet traffic today and archiving it. The plan is to decrypt it once quantum hardware becomes capable. Sensitive data transmitted over HTTPS this year, this month, this week, is potentially at risk in a post-quantum future. The delay is not safety; it is exposure.
Second, migrating certificate infrastructure across the entire web is not a fast process. It requires browser vendors, Certificate Authorities, server operators, enterprises, and standards bodies to coordinate transitions across millions of systems. The IETF's PLANTS working group is developing MTCs as an open, interoperable standard, not a Google-only solution. That kind of ecosystem change takes years to propagate. Starting in 2026 to reach a production-ready quantum-resistant root store by Q3 2027 is already an aggressive timeline.
What This Means for Indian Businesses and DPDP Compliance
For organizations operating under India's Digital Personal Data Protection Act 2023, this transition carries practical implications worth understanding now rather than later.
The DPDP Act places obligations on Data Fiduciaries to implement reasonable security safeguards when processing personal data. Certificate security is part of that infrastructure. As quantum-resistant certificate standards emerge and browsers begin preferring or requiring MTC-based connections, websites that delay transitioning may find themselves running on deprecated security models that regulators could eventually treat as inadequate safeguards.
Beyond compliance, businesses that handle sensitive user data over HTTPS, including e-commerce platforms, fintech applications, healthcare portals, and SaaS products operating in India, should begin conversations with their hosting providers and SSL certificate vendors about post-quantum readiness. The questions to ask now: What is your timeline for supporting MTC-based issuance? Which CA partners are involved in Google's PLANTS working group? Will your CDN provider support quantum-resistant handshakes by 2027?
The answers to those questions determine whether your site's security baseline remains aligned with where the web is heading.
Frequently Asked Questions
Q: What is a Merkle Tree Certificate and how is it different from a standard SSL certificate?
A: A Merkle Tree Certificate is a new type of HTTPS certificate where a Certificate Authority signs one "Tree Head" representing millions of certificates simultaneously. Your browser verifies a small proof of inclusion rather than a full certificate chain. This produces the same security outcome as traditional SSL certificates but uses quantum-resistant cryptography underneath and transmits far less data.
Q: Will my website need to do anything before the 2027 deadline?
A: Not immediately. Google is rolling out this change gradually, and the CQRS will operate alongside the existing Chrome Root Program during the transition. However, website operators should monitor guidance from their Certificate Authority and hosting provider, and IT teams should factor MTC compatibility into infrastructure planning for 2026-2027.
Q: Does this affect websites in India differently than elsewhere?
A: The technical change is global. The legal dimension differs. Indian websites processing personal data under the DPDP Act 2023 have an obligation to maintain reasonable security practices. As post-quantum certificates become the industry standard, continuing to use deprecated cryptographic models could potentially create compliance exposure, particularly for Data Fiduciaries in high-risk categories like fintech, healthcare, and e-commerce.
Q: What is "harvest now, decrypt later" and does it affect Indian businesses?
A: "Harvest now, decrypt later" refers to the practice of intercepting and storing encrypted data today with the intent of decrypting it once quantum hardware becomes capable. It is not a future hypothetical. Indian organizations in sectors handling sensitive financial, health, or identity data should treat currently transmitted data as potentially at risk in a post-quantum timeline, and assess whether their security posture reflects that reality.
Q: What is the IETF PLANTS working group?
A: PLANTS stands for PKI, Logs, and Tree Signatures. It is the Internet Engineering Task Force working group developing Merkle Tree Certificates as an open, interoperable standard. Google, Cloudflare, and other major infrastructure operators are active participants. The group's drafts are published publicly at datatracker.ietf.org.
Q: Should I consult a cyber law advocate about post-quantum compliance?
A: If your organization processes personal data of Indian citizens and operates internet-facing services, yes. Post-quantum readiness intersects with DPDP Act compliance, data security obligations, and contractual representations made to users about the security of their data. A qualified cyber law advocate can help you assess your current posture and identify gaps before regulators begin treating quantum-vulnerable infrastructure as a compliance risk.
If your organization needs guidance on DPDP Act compliance, digital security obligations, or cyber law advisory services, the team at LLM Advocates advises clients across Punjab, Haryana, Delhi, and across India on data protection and AI governance law. Reach out at contact@llmadvocates.com or call +91-8572022292.
