Every couple of weeks, someone on our team Slack asks: "Are we really switching to post-quantum crypto, or is this just vendor noise?" Google Cloud's recent roadmap puts a date on it, 2029, and introduces Merkle Tree Certificates as the preferred mechanism for post-quantum authentication on the public web. That timeline feels both urgent and distant, sparking practical questions about what this means for your infrastructure.
Here's what you need to know about MTCs and the current state of development.
Understanding the Source of Questions
Confusion often arises from the gap between cryptographic theory and operational reality. Your team already manages certificate lifecycles, TLS configurations, and PKI dependencies across cloud workloads, APIs, and device fleets. Now you're told the authentication layer needs to change, not because of a compliance mandate, but because quantum computers will eventually break the math your current certificates rely on. The questions come from privacy officers, security architects, and infrastructure leads who need to translate Google's roadmap into actionable prep work.
Do MTCs Solve the Performance Problem?
Yes, but they require rethinking how certificates work. Traditional post-quantum signatures are large, sometimes several kilobytes, which would bloat TLS handshakes and slow down mobile connections and high-latency networks.
MTCs address this by replacing multiple large signatures with a single compact inclusion proof. Instead of signing each certificate individually, the certificate authority builds a Merkle tree of all issued certificates and publishes one signature over the tree root. Your server presents a certificate with a proof showing it exists in that tree. The proof is small, so users don't experience slowdowns.
The tradeoff is operational: you're moving from a model where each certificate is independently verifiable to one where verification depends on the integrity of a published tree. This shift affects how you monitor issuance and detect misissuance, but it doesn't reintroduce the latency problem.
Do MTCs Replace Certificate Transparency Logs?
Not exactly. MTCs integrate the function of CT logs into the certificate structure itself. In today's PKI, Certificate Transparency logging happens after issuance. A certificate authority issues a cert, submits it to independent CT logs, and browsers check those logs to verify the cert was publicly recorded. If the logging step fails, the certificate can exist without visibility, creating a window for misissuance.
With MTCs, the certificate only exists if it's in the tree. Creating the certificate is logging it. There's no separate submission step, no lag time, and no possibility of a certificate being valid but unlogged. Browsers prefer this path as it eliminates the blind spot between issuance and transparency.
For your team, you'll need to adjust how you monitor certificate issuance. Instead of querying external CT logs, you'll verify inclusion proofs against the published Merkle tree. The monitoring tools will change, but the goal remains the same: detecting unauthorized or misissuance.
What Should You Do Now?
Start by mapping your certificate dependencies. Build an inventory of where certificates are deployed, how they're provisioned, and which systems would break if handshake sizes increased or validation logic changed.
Next, audit your crypto agility. Can you rotate algorithms without redeploying applications? Can you update certificate validation logic without touching every client? If not, you're not ready for any post-quantum transition. Organizations that will adapt smoothly have centralized certificate management, automated issuance workflows, and abstraction layers between applications and cryptographic primitives.
Finally, track browser signals and IETF specifications. MTCs are still being refined, and the exact format, validation rules, and compatibility requirements will evolve. You don't need to implement anything today, but you do need to know when the specs stabilize.
Are MTCs Only for Public-Facing Websites?
The current focus is on the public web, specifically TLS certificates for websites that browsers need to validate. Browsers prefer MTCs for post-quantum certificates, which is why Google and Cloudflare prioritize development there.
For internal PKI, certificates used for API authentication, device identity, code signing, or internal service mesh, you have more flexibility. You could use MTCs if the tooling matures and your infrastructure supports it, or deploy traditional post-quantum signatures in X.509 certificates if performance isn't a bottleneck.
Separate your public-facing certificate strategy from your internal one. They don't have to follow the same path, and forcing uniformity before standards settle will create unnecessary constraints.
How to Test Compatibility?
Feasibility experiments are running, but most organizations can't participate directly. Google, Cloudflare, and others are testing MTCs against live internet traffic to measure performance and compatibility. These experiments will inform the final specifications.
For your team, testing comes later, once the IETF specs are published and vendors start shipping MTC support. Set up a staging environment that mirrors your production PKI and test MTC issuance, handshake performance, and client compatibility before rolling anything out.
Don't build your own MTC implementation from scratch. Wait for vendor support, then test integration points: your certificate management platform, load balancers, API gateways, and any custom clients that validate certificates outside of standard browser or OS trust stores.
Where to Watch for Updates
Monitor the IETF working groups developing MTC specifications. Watch for announcements from your certificate authority vendor about post-quantum roadmaps and MTC support timelines. Pay attention to browser vendor communications, Chrome, Firefox, and Safari will determine adoption timelines for the public web.
Internally, ensure your Chief Privacy Officer and security leadership understand this isn't just a cryptography upgrade. It's a change to how authentication works at the protocol level, requiring coordination across infrastructure, application, and compliance teams. Start that coordination now to prepare over the next four years. Waiting until 2028 will leave you with only four months.
