The padlock icon in your browser is about to undergo its most radical overhaul in 30 years. Google has cracked a problem that had the security community stuck: quantum-resistant encryption is safe, but it's enormous—and a bloated certificate could slow the web to a crawl. Their solution compresses roughly 15 kilobytes of post-quantum cryptographic material into a 700-byte proof. The first live tests are already running inside Chrome.
The company's Chrome Secure Web and Networking Team published a phased program to replace the X.509 certificate system that underpins every secure web connection today. The pressure forcing the change isn't hypothetical.
Recent research has lowered the estimated number of physical qubits needed to crack RSA-2048 encryption—the backbone of today's HTTPS—to just 100,000. Quantum computing progress is notoriously non-linear, and security researchers note that governments are almost certainly funding classified work on the problem without publishing results. The window to act may be tighter than most assume.
Classical Cert Data
Post-Quantum Alternative
Break RSA-2048
Why the Current System Can't Simply Be Patched
Every time you visit an HTTPS site, your browser performs a "TLS handshake"—exchanging digital certificates to prove the server is legitimate. Today's certificates use elliptic curve cryptography: a typical chain contains six EC signatures and two EC public keys, each just 64 bytes, for a total of around 4 kilobytes.
A quantum computer running Shor's algorithm could forge those signatures, allowing attackers to impersonate any website or silently intercept encrypted traffic.
The fix sounds simple: swap in post-quantum algorithms. The problem is that those algorithms are far bulkier. The cryptographic material needed to publish a quantum-resistant TLS certificate transparently is roughly 40 times larger than its classical equivalent—pushing a routine handshake from 4kB toward 15kB or more. That gap has real consequences.
"The bigger you make the certificate, the slower the handshake and the more people you leave behind. Our problem is we don't want to leave people behind in this transition." — Bas Westerbaan, Principal Research Engineer, Cloudflare
Westerbaan, who is leading Cloudflare's collaboration with Google on the project, told Ars Technica that users will likely just disable new encryption if it visibly slows their browsing. Bulkier certificates also degrade "middle boxes"—the proxies, load balancers, and network appliances that sit between a browser and the destination server—creating systemic fragility far beyond individual user experience.
# Certificate size at TLS handshake Today's X.509 chain (6 EC sigs + 2 EC keys) : ~4 KB Post-quantum X.509 equivalent : ~15 KB ← 40× problem Merkle Tree Certificate (MTC) proof : ~700 B ← Google's fix
How Merkle Tree Certificates Solve the Size Problem
Google's answer is Merkle Tree Certificates (MTCs), being standardised in the IETF's new "PLANTS" working group.
Instead of a browser verifying a chain of individual signatures, a Certificate Authority (CA) signs a single cryptographic summary—called a "Tree Head"—that represents potentially millions of certificates simultaneously. Each site receives only a tiny mathematical proof showing its certificate is included in that tree.
The result: roughly the same 4kB total handshake size as today, despite the quantum-resistant algorithm underneath.
The system also layers in a hybrid defence. Google is adding cryptographic material from ML-DSA, a quantum-resistant signing algorithm, alongside classical signatures. This means an attacker would have to simultaneously break both classical and post-quantum encryption to forge a certificate—a substantially higher bar than either system offers alone.
The architecture also solves a longer-standing problem in web security. Google and other browser makers already require all TLS certificates to be published in public "Certificate Transparency" (CT) logs—append-only distributed ledgers that let site owners catch rogue certificates in real time.
This requirement was introduced after the 2011 hack of Dutch CA DigiNotar, which enabled attackers to issue 500 counterfeit certificates for Google and other services, some of which were used to intercept traffic of Iranian internet users. With MTCs, transparency is structural rather than added-on: it is cryptographically impossible to issue a certificate that doesn't appear in a public tree.
The Rollout Plan
Feasibility Testing with Cloudflare
MTC support is already built into Chrome. Cloudflare is currently enrolling roughly 1,000 real TLS certificates to test performance in live traffic. Every MTC connection is still backed by a traditional X.509 certificate as a safety net, so users see no change. For now, Cloudflare is running the distributed ledger; Certificate Authorities are expected to take over that role as the program matures.
Public MTC Bootstrap
Existing Certificate Transparency (CT) Log operators—organisations already running the high-availability infrastructure Chrome relies on—will be invited to stand up the first public MTC infrastructure. Their architectural overlap with the new system makes them uniquely qualified to get it off the ground quickly.
Chrome Quantum-Resistant Root Store (CQRS) Launches
A dedicated trust store for MTC-only certificates goes live, running alongside the existing Chrome Root Store. Sites will also be able to opt in to “downgrade protections,” blocking non-quantum-resistant connections entirely for security-sensitive deployments.
What This Means for Site Owners and Developers
For most website operators, the near-term answer is: nothing changes yet. Chrome is not withdrawing support for existing certificates, and the transition is deliberately risk-managed—traditional X.509 certificates continue to work through the whole migration period.
Google also plans to support quantum-resistant X.509 certificates for private, internal PKI deployments later this year, giving enterprises a stepping stone before full MTC adoption is required.
Action item for infrastructure teams
If you operate a CT Log or run Certificate Authority infrastructure, Google is explicitly looking to onboard partners who had a "usable" CT log before February 1, 2026. Organisations fitting that profile should monitor the IETF PLANTS working group and Google's forthcoming CQRS policy framework. For everyone else: now is the time to audit whether your TLS certificate pipeline supports algorithm agility—the ability to swap cryptographic algorithms without rebuilding your entire stack.
The Uncomfortable Context: How Close Is "Quantum-Ready"?
The urgency behind Google's announcement is harder to dismiss than it might appear. Security researchers note that new estimates have pushed the number of physical qubits required to break RSA-2048 down to around 100,000—a threshold that would have seemed distant just a few years ago.
Quantum computing progress doesn't follow a straight line; long plateaus of incremental work (error correction, qubit stability, scaling) can be punctuated by sudden capability jumps that catch the industry flat-footed. There's also the quiet dimension: multiple governments are known to be funding classified quantum research, meaning meaningful advances may already exist that simply haven't been published.
The practical takeaway isn't that quantum attacks are imminent—it's that the cryptographic infrastructure we depend on has a known expiry date, and switching systems at internet scale takes a decade. That's exactly the window Google is trying to open now.
Whether the 2027 timeline holds will depend on the pace of standardisation at the IETF and on ecosystem buy-in from CAs and server operators. But with 1,000 live certificates already enrolled, Cloudflare's infrastructure already generating real proofs, and MTC code already shipping in Chrome builds, this is past the proposal stage. The quantum-safe web has a launch schedule.
Sources: Google Security Blog · Ars Technica · Scott Aaronson Blog · IETF PLANTS WG