Google just told the certificate industry that its plan for post-quantum HTTPS isn’t what anyone expected.
On February 27, Chrome’s Secure Web and Networking Team announced that Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, Chrome is building a parallel trust infrastructure based on Merkle Tree Certificates (MTCs), a fundamentally different certificate architecture developed through the IETF’s new PLANTS working group. Cloudflare is already running experimental MTC deployments in collaboration with Chrome.
This matters far beyond browser engineering. If you’re an organization planning your PQC migration, the target just moved.
The Assumption That Just Broke
The working assumption across most of the industry has been straightforward: PQC certificate migration means replacing classical signatures (ECDSA, RSA) with post-quantum signatures (ML-DSA) inside the existing X.509 certificate format. Bigger keys, bigger signatures, same architecture. The migration would be painful — ML-DSA signatures and public keys are orders of magnitude larger than their classical equivalents — but conceptually simple.
Google just rejected that path for the public web.
The reason is performance. Today’s X.509 certificate chain carries roughly 64 bytes of signature material. A post-quantum equivalent using ML-DSA balloons to multiple kilobytes. Every TLS handshake — every page load, every API call, every resource fetch — would carry that overhead. As Cloudflare’s Bas Westerbaan put it: the bigger you make the certificate, the slower the handshake and the more people you leave behind.
MTCs solve this by restructuring how certificate trust works. Instead of each certificate carrying its own chain of signatures, a Certificate Authority signs a single tree head representing potentially millions of certificates. The browser receives a compact proof that a specific certificate is included in that tree. The post-quantum cryptography still exists — it protects the tree head and the transparency infrastructure — but it’s decoupled from the per-handshake data that users actually experience.
What Kim Nguyen Gets Right
Bundesdruckerei SVP Innovations Kim Nguyen flagged this on LinkedIn within hours of the announcement, and his framing is precise: PQC migration in Web PKI is no longer an algorithm question. It’s an architecture question.
Nguyen leads innovation at Bundesdruckerei, the parent company behind Germany’s primary qualified trust service provider D-Trust. His organization issues the certificates, operates the infrastructure, and implements the eIDAS-compliant trust services that European digital identity depends on. When he says this changes the operational role of trust service providers, he’s describing changes to his own business.
His core observation — that the discussion has shifted from “how do we replace algorithms” to “how do we redesign trust infrastructure so post-quantum security is viable at global scale” — is correct, and it has consequences that extend well beyond the TSP community.
The Migration Scope Problem
Here’s what this means for organizations outside the browser and CA ecosystem.
Most PQC migration roadmaps — to the extent they exist at all — assume a relatively contained scope: inventory your cryptographic dependencies, identify quantum-vulnerable algorithms, swap them for NIST-standardized post-quantum equivalents, validate interoperability, deploy. That’s already a 12-year effort by reasonable estimates, and most organizations haven’t started.
The Chrome MTC announcement doesn’t change the algorithm migration work. You still need ML-KEM for key exchange. You still need ML-DSA for signatures. You still need to find every place your systems negotiate classical cryptography and plan the transition.
What it changes is the infrastructure those algorithms plug into. If your organization operates web services, issues or consumes TLS certificates, or depends on certificate-based authentication, your migration plan now has an additional variable: the certificate format and trust model itself may change underneath you. Not someday. Chrome is targeting Phase 2 — inviting CT log operators to bootstrap public MTCs — for Q1 2027. Phase 3, onboarding additional CAs into a new Chrome Quantum-resistant Root Store, targets Q3 2027.
That’s 18 months from now.
What This Means for Tracking Migration
We’ve argued since launching pqprobe that PQC migration requires trajectory tracking over time, not point-in-time assessment. The question that matters isn’t “are you quantum-safe today” — nobody is. The question is: are you getting better or worse?
The MTC development makes that argument sharper. When the migration target itself is evolving — when what “PQC-ready” means for your certificate infrastructure is actively being redefined by the browser that handles two-thirds of global web traffic — static assessment is even less useful. You need to track your position against a moving reference point.
Consider what an organization’s PQC migration dashboard should look like right now. Key exchange readiness: measurable, relatively stable target (ML-KEM, well-defined by NIST). Signature algorithm readiness: measurable, stable target (ML-DSA). Certificate infrastructure readiness: target actively shifting. The first two you can scan for and track progress. The third requires watching not just your own systems but the ecosystem decisions being made by Google, Cloudflare, and the IETF PLANTS working group, and understanding how those decisions affect your timeline.
The Wider Architecture Question
Chrome’s MTC plan also has implications beyond web certificates.
We wrote last month about how Germany’s Bundesdruckerei is PQC-hardening the chip layer for identity documents, while the middleware and verification infrastructure above it remains quantum-vulnerable. The EUDI Wallet ships end of 2026 with whatever cryptography is baked in now. The identity ecosystem — credential signing, key agreement, DID resolution, trust registries — all sits on classical crypto that BSI President Plattner says will be breakable by 2030.
If Web PKI is moving from X.509 to Merkle Tree Certificates, the question for every other PKI-dependent system becomes: does your trust architecture need the same rethink? Enterprise PKI, code signing, email certificates, IoT device identity — all of these use X.509 today. Chrome’s answer to the PQ certificate size problem is architectural innovation. Other ecosystems will face the same size problem and may not have the same engineering resources to solve it.
What Comes Next
Google’s phased rollout — feasibility study now, CT log operator bootstrapping in Q1 2027, new root store in Q3 2027 — is aggressive by standards-body timelines and conservative by threat timelines. The IETF PLANTS working group is actively developing the MTC specification. Cloudflare is enrolling roughly 1,000 TLS certificates in the experimental deployment. Chrome has already integrated preliminary MTC support.
This is no longer theoretical. The question for CISOs and infrastructure teams is whether their migration plans account for it.
Let’s be clear about what happened here. Google has thousands of engineers and an ad-revenue business model that funds projects most organizations could never justify. They didn’t crack some deep technical insight the rest of the industry missed. They had the luxury of deciding the existing path was too slow, and the resources to build a different one. That’s not genius. That’s headcount.
But the result is the same whether you admire it or resent it: the migration target moved, and it moved without asking anyone’s permission. If your PQC roadmap assumed you’d swap ML-DSA into X.509 and call it done, that roadmap now has a hole in it. Not because you were wrong about the cryptography, but because someone with more resources changed the infrastructure underneath it.
This is why agility matters more than architecture. Kim Nguyen is right that the discussion shifted from algorithms to architecture. But for anyone running real services with real customers, the lesson isn’t “redesign your trust infrastructure.” You can’t. You don’t have a browser with two-thirds market share. The lesson is: build migration plans that survive the target moving. Because it just did, and it will again.
The organizations that treat PQC migration as a one-time project with a fixed destination are the ones that will get hurt. The ones that build the capacity to detect changes, reassess, and pivot — those are the ones that will still be standing when the dust settles. The threat isn’t quantum computers. The threat is cryptographic conservatism and rigidity.