Skip to content
Encryptorium

PQC

Google Is Switching to ECDSA Certificates. That Is Not the Post-Quantum Migration.

Andreas Renz · · 10 min read
PQC TLS WebPKI ECDSA Google

What Google actually announced

The notice is easy to miss. It sits on a Google Trust Services change-notification page, below an update about intermediate CAs, and it says this:

"During Q2 2026, a number of Google services that have historically provided an RSA leaf certificate will shift to an ECDSA leaf certificate by default." [1]

Google Trust Services is Google's own certificate authority, and it posted the notice on behalf of other Google services, including Google Cloud. Read the scope carefully, because every word limits it: a number of Google services, leaf certificates, by default. This is not a deprecation of RSA across the WebPKI, not a Chrome root-store policy, and not a browser-side change. It is Google adjusting what its own endpoints serve.

The stated reason is one sentence:

"ECDSA certificates are typically more efficient than RSA certificates both in terms of size to transmit and in terms of processing power required." [1]

That is the entire rationale. The page does not mention post-quantum cryptography once.

The silence matters, because the reflex reading of "Google is replacing RSA" is "Google is finally going post-quantum". That reading is wrong, and it is wrong in an instructive direction.

ECDSA is the more quantum-fragile primitive

Shor's algorithm breaks RSA and elliptic curves alike, but not equally.

Resource estimates have consistently put 256-bit curves below RSA-2048 on the difficulty scale for a quantum attacker. Roetteler, Naehrig, Svore, and Lauter estimated in 2017 that computing an elliptic-curve discrete logarithm on a 256-bit curve needs roughly 2,330 logical qubits, against roughly 4,100 for factoring RSA-2048, with lower gate counts as well [9]. The ordering is not an artifact of mismatched key sizes: at comparable classical security levels, the curve side stays the smaller quantum target [9]. Meanwhile the RSA qubit estimates keep falling: Gidney and Ekerå's 2019 figure of 20 million noisy qubits running for eight hours was cut in 2025 to under one million noisy qubits running for less than a week [10]. The machines do not exist. The trend line does.

So when a Google frontend hands you an ECDSA P-256 certificate where an RSA one used to be, it will be relying on the primitive those resource estimates rank as the easier quantum target. If certificates had to survive a quantum adversary, this move would be backwards.

For live TLS server authentication, they do not have to. That is the point.

TLS migrates in layers

A TLS connection is not one algorithm. Unbundle it:

  • Key exchange establishes the session secret (X25519, and now hybrids with ML-KEM, formerly Kyber).
  • Server authentication proves you are talking to the right host (the certificate and its signatures).
  • The trust hierarchy anchors that proof (CA chain, root stores).
  • Symmetric encryption protects the actual data (AES-GCM, ChaCha20-Poly1305).

These layers face different threats on different clocks.

Key exchange is on the fast clock because of harvest-now-decrypt-later: an adversary recording encrypted traffic today can decrypt it the day a cryptographically relevant quantum computer exists. The confidentiality you promise today depends on the attackers of the future, so key exchange had to move first, years before any such machine is built.

And it has moved. The hybrid X25519MLKEM768 key agreement is on by default in Chrome 131+, Edge 131+, Firefox 132+ on desktop, and Safari 26+ [8]. OpenSSL enabled it by default in April 2025, and Apple shipped post-quantum key agreement across iOS, iPadOS, and macOS 26 in October 2025 [4]. By late October 2025, the majority of human-initiated traffic with Cloudflare was using post-quantum encryption [4], and Cloudflare's Radar measurements show client-side support growing from under 3% at the start of 2024 to over 60% in February 2026 [5]. F5's June 2025 scan found 8.6% of the top million websites already completing hybrid post-quantum handshakes, rising to 50% among the top ten [6].

Server-side adoption lags: roughly 10% of Cloudflare customer origins could already benefit from a post-quantum-preferred key agreement, up from under 1% at the start of 2025 [5]. The migration is not finished. But the defaults are set, and defaults finish migrations.

Authentication is on the slow clock because a signature has to be secure at the moment it is verified, not forever. A quantum computer built in 2035 cannot retroactively forge the certificate that authenticated your session in 2026; that session already happened, authenticated by a signature that was sound when it mattered. WebPKI certificates also rotate constantly, and maximum lifetimes are scheduled to shrink to 47 days by March 2029 under the CA/Browser Forum's ballot SC-081, approved in April 2025 [11]. Certificates need to go post-quantum before a cryptographically relevant quantum computer exists, not before harvest-now-decrypt-later becomes uncomfortable. Those are very different deadlines.

Symmetric encryption sits on the slowest clock of all: Grover's algorithm halves the effective key length in theory, and AES-256 keeps a comfortable margin even then.

One class of signatures does sit on the fast clock: anything signed today that must still verify years from now. Firmware images, code signing, notarized documents, timestamping. For those, the verification moment is in the future, so the at-time-of-use argument cuts the other way. TLS server authentication is simply not in that class.

Why signatures cannot simply be swapped

If the deadline were the only variable, you might still migrate signatures early just to be done with it. The byte budget is why the public web does not.

An ML-DSA-44 signature, the smallest parameter set of NIST's primary post-quantum signature scheme (formerly Dilithium), is 2,420 bytes; an ECDSA P-256 signature is 64 bytes raw, 70 to 72 bytes once DER-encoded. ML-DSA-44 public keys are 1,312 bytes; ECDSA's are 64 [7]. And a TLS handshake does not carry one signature. It carries the leaf signature, intermediate signatures, certificate transparency SCTs, and the handshake signature itself. Cloudflare's estimate: using ML-DSA-44 as a drop-in replacement for classical signatures "would more than double the number of transmitted bytes over the lifetime of the connection" for most QUIC connections [4]. There is already a measured baseline for what handshake bytes cost, because post-quantum key agreement paid it: an extra 1.1 kB server-to-client and 1.2 kB client-to-server produced a 4% slowdown in TLS handshake time [4].

On top of the bytes sits the ecosystem: root programs, CA issuance pipelines, ACME automation, certificate transparency logs, middleboxes, and a long tail of embedded clients that assume certificates look the way they have looked for fifteen years.

Chrome's position is explicit:

"Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store." [2]

That is a root program stating that the drop-in path is closed. What Google is building instead changes the certificate format itself: Merkle Tree Certificates, developed in the IETF PLANTS working group and currently in a feasibility study with Cloudflare [2][8]. Instead of shipping a chain of large signatures, an MTC handshake carries roughly one signature, one public key, and one Merkle inclusion proof [7]. Chrome states the goal plainly:

"By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today's internet." [2]

The format also has its first major issuer lined up. Let's Encrypt, the web's largest certificate authority, announced in June 2026 that it plans to support Merkle Tree Certificates, targeting a staging environment that issues MTCs in late 2026 and a production-ready environment in 2027 [12]. That is adoption, not design; the specification work stays with Google, Cloudflare, and the PLANTS group. But when a CA of that size puts dates on the format, the path stops being an experiment.

Post-quantum signatures are already live where one party controls both ends: Cloudflare supports ML-DSA for authenticating the connection between its edge and customer origin servers, while post-quantum authentication from visitors to the edge is, in Cloudflare's own words, still under development [8]. Controlled environments first, the open web later.

And there is now a date on the wall. In March 2026, Google's security leadership wrote: "We're setting a timeline for post-quantum cryptography migration to 2029." [3] That is Google's own commitment, framed with the hope that it pulls the industry along. It is not a prediction of when a quantum computer arrives.

Against that roadmap, the RSA-to-ECDSA shift reads exactly as its stated rationale: shave handshake bytes now with a smaller and faster classical primitive the WebPKI already supports, while the actual post-quantum authentication layer is redesigned in parallel rather than forced through an X.509 shape that was never sized for 2,420-byte signatures.

What to do with this

For anyone running their own migration, the useful output is not "Google did a thing". It is the sorting function.

  1. Sort your cryptography by threat clock, not by algorithm family. Key agreement and anything protecting long-lived secrets face harvest-now-decrypt-later today. TLS server authentication does not. Long-lived signatures (firmware, code signing, documents) are the exception: they need post-quantum planning now because their verification moment is in the future.

  2. Take the free key-exchange win. If your TLS terminators run current OpenSSL, your clients are current browsers, or you sit behind a major CDN, hybrid key exchange may already be on. Verify that X25519MLKEM768 actually negotiates end to end; middleboxes and pinned client stacks are where it silently falls back to classical.

  3. Do not buy "quantum-safe certificates" for the public web today. As of mid-2026, no browser root program accepts post-quantum X.509 certificates, and Chrome has said it has no immediate plan to add them [2]. A vendor selling quantum-safe WebPKI certificates in 2026 is selling something browsers will not trust.

  4. Watch PLANTS alongside NIST. The signature migration will change certificate infrastructure (issuance, transparency, ACME tooling) more than it changes algorithm identifiers. If Merkle Tree Certificates land, the operational work rewards teams that kept their certificate automation agile, and the 47-day lifetime schedule forces that agility anyway.

  5. Ask the three questions. Which layer is migrating? Against which threat? With which ecosystem attached? Most confusion about post-quantum timelines, including "why is Google deploying a quantum-vulnerable algorithm in 2026", dissolves under those three.

One honest caveat on the slow clock. The at-time-of-use argument assumes the trust hierarchy can rotate faster than quantum hardware improves. Roots live for decades. Devices outlive their update channels. The WebPKI needed years to retire SHA-1 after everyone agreed it was broken. And the estimated qubit count for breaking RSA-2048 fell by a factor of twenty between 2019 and 2025 [10]. The certificate layer being deliberately last does not mean it can start late. It means the redesign happening now, at the Merkle-tree level rather than the drop-in level, is the part of the migration most worth watching.

Sources:

  1. Google Trust Services, "August 2025 Intermediate CA Change Notification", https://developers.google.com/public-key-infrastructure/updates/august2025-intermediate-update, updated 2026-05-13.
  2. Chrome Secure Web Networking Team, "Cultivating a robust and efficient quantum-safe HTTPS", Google Security Blog, 2026-02-27, https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/
  3. Heather Adkins and Sophie Schmieg, "Quantum frontiers may be closer than they appear", Google, 2026-03-25, https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
  4. Bas Westerbaan, "State of the post-quantum Internet in 2025", Cloudflare, 2025-10-28, https://blog.cloudflare.com/pq-2025/
  5. David Belson et al., "Bringing more transparency to post-quantum usage, encrypted messaging, and routing security", Cloudflare, 2026-02-27, https://blog.cloudflare.com/radar-origin-pq-key-transparency-aspa/
  6. F5 Labs, "The State of PQC on the Web", 2025-06-26, https://www.f5.com/labs/articles/the-state-of-pqc-on-the-web
  7. Luke Valenta, Christopher Patton, Vânia Gonçalves, Bas Westerbaan, "Keeping the Internet fast and secure: introducing Merkle Tree Certificates", Cloudflare, 2025-10-28, https://blog.cloudflare.com/bootstrap-mtc/
  8. Cloudflare Docs, "Post-quantum cryptography", https://developers.cloudflare.com/ssl/post-quantum-cryptography/
  9. Martin Roetteler, Michael Naehrig, Krysta M. Svore, Kristin Lauter, "Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms", ASIACRYPT 2017, https://eprint.iacr.org/2017/598
  10. Craig Gidney, "How to factor 2048 bit RSA integers with less than a million noisy qubits", arXiv:2505.15917, 2025, https://arxiv.org/abs/2505.15917 (supersedes Craig Gidney and Martin Ekerå, arXiv:1905.09749, 2019)
  11. CA/Browser Forum, "Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods", 2025-04-11, https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
  12. Let's Encrypt, "A Post-Quantum Future for Let's Encrypt", 2026-06-03, https://letsencrypt.org/2026/06/03/pq-certs