Google just moved 'Q-Day' to 2029. Here's what that changes for your crypto stack

Google’s security engineering team just bumped Q-Day forward by six years. In a blog post published this month, VP of Security Engineering Heather Adkins and senior staff cryptography engineer Sophie Schmieg said the company now plans to complete its post-quantum cryptography migration by 2029. That’s ahead of the NSA’s 2031 CNSA 2.0 deadline and the US government’s 2035 goal. If you ship TLS, sign software, or run anything that outlives the next product cycle, this matters.

What “Q-Day” actually means

Q-Day is the informal name for the day a quantum computer becomes powerful enough to break the public-key crypto that runs the modern internet. RSA-2048, ECDSA, the key exchanges in every TLS handshake: Shor’s algorithm breaks them all in polynomial time, given enough reliable qubits. Nobody’s built that machine yet. The field’s bet on “when” has been the source of a lot of hand-wavy numbers.

The “harvest now, decrypt later” threat is the reason the date matters before the machine exists. Nation-state actors are already capturing encrypted traffic with the explicit plan of decrypting it once Q-Day lands. If you ship a secret today that has to stay secret for ten years, you’re in an asymmetric race: you have to rotate to post-quantum crypto before a credible adversary builds a working cryptographically-relevant quantum computer.

Until this month, the prevailing timeline among US agencies was 2031 for high-priority systems and 2035 for the rest. Google just said “actually, 2029.”

What Google just changed

The specifics come from Adkins and Schmieg’s post on blog.google, which frames the 2029 date around priorities rather than a single big flip. Google has been shipping PQC for years. This post lays out the completion plan, what already works, and how the threat model has shifted:

• 2029 is the new internal deadline for Google’s own migration, across Chrome, Android, and Google Cloud.
• Android 17 is integrating ML-DSA, the NIST-standardized lattice-based signature algorithm, for digital signature protection. Signatures go in first, deliberately. Encryption follows.
• Chrome already supports PQC for TLS 1.3 key exchange. That rolled out in earlier releases; the 2029 date is about finishing the rest of the stack, not shipping it to users.
• Google Cloud offers PQC migration tooling and guidance for customers. Google’s own PKI, certificate authority infrastructure, and long-lived secret stores are the priorities inside the company.
• The threat-model shift is explicit. Adkins and Schmieg say Google now prioritizes authentication and digital signatures over encryption. Signatures protect future traffic. Encryption has a harvest window that’s already leaking.

They also nudge the industry: “we hope to provide the clarity and urgency needed to accelerate digital transitions…across the industry.” Cloudflare is on the same page, with a 2029 roadmap of its own.

Why 2029, not 2035

Three reasons, per the blog post. None of them are a single quantum-breakthrough headline. All three are the kind of slow, cumulative progress that shifts an entire field’s timeline:

1. Quantum hardware is moving faster than the public timelines assumed. IBM’s roadmap hit a 1000-plus qubit system ahead of plan. The Quantum Insider catalogued three factoring papers in three months that each shortened the qubit count needed to break RSA-2048.
2. Quantum error correction is the bigger deal. The industry used to obsess over raw physical qubits. The current bet is that useful logical qubits arrive through error correction sooner than anyone projected. Google’s position is that the curve is bending.
3. Resource estimates for Shor’s keep shrinking. Newer algorithmic work has cut the theoretical hardware budget required to break a given key size. Not enough to factor RSA tomorrow. Enough that “ten years out” stopped being a safe assumption.

None of this proves a cryptographically-relevant quantum computer arrives in 2029. It’s Google saying the probability distribution has shifted left. If you build infrastructure to a 2035 timeline and the actual date lands in 2030, you’re in trouble.

What to ship first

This is the part that’s actually useful for engineers right now. Three priorities, ordered by the “what breaks first” question:

Ship PQC in your signatures. If you sign firmware updates, code, certificates, or anything your users will still be running in 2030, move to hybrid ML-DSA signatures. Signatures get harvested too: an adversary downloads your signed binary, waits for Q-Day, forges an update. ML-DSA is standardized; most modern crypto libraries now have implementations (openssl, boringssl, Go’s hybrid packages).

Audit your long-lived secret exposure. Anything encrypted with classical public-key crypto and transmitted over a network you don’t control (read: any network) is a harvest candidate. Data that needs to stay secret past 2030 needs to be re-encrypted with a hybrid scheme that includes ML-KEM, the standardized successor to Kyber. This is not a switch-the-cipher-and-go operation. Treat it as a migration with a rollout plan, not a config change.

Pin down your crypto inventory. You can’t migrate what you can’t find. Get a real list of every place your stack terminates TLS, verifies a signature, or holds a long-lived symmetric key. Most orgs don’t have this list. The ones that do are the ones shipping on time.

Chrome already does hybrid X25519 plus ML-KEM for TLS 1.3, so if you sit behind Google, Cloudflare, or Fastly, you get the TLS side for free. The signature and at-rest-encryption problems are yours.

What this means for you

If you’re a frontend dev shipping web apps, Chrome’s hybrid KEM covers you on TLS. The actionable work is on the auth and signing side: package signing, JWT signing keys, long-lived HMAC secrets. Move to ML-DSA hybrid where your language’s crypto library supports it (the NIST FIPS 204 standard is final). Treat 2029 as a hard date for anything new. For legacy systems, assume you have 24 months to finish an inventory and 36 months to start swapping keys.

If you’re at a larger org, the 2029 number shifts your budgeting conversations. You’re now asking for the crypto migration line item a year or two earlier than the NSA-deadline planning assumed. The argument isn’t “someday” anymore. It’s “Google finishes in 2029. Where’s our plan?” The procurement and compliance teams are about to start reading the same Schneier post you’re reading. They’re going to ask.

For small teams and solo shippers, the picture is simpler but not smaller. You probably don’t run your own CA, you probably inherit TLS from your CDN, and your signing keys are wherever your package manager lives. That’s most of the migration. The part you own is usually two things: how you sign releases, and where you stash long-lived secrets. Do those now. Hybrid ML-DSA signing is a small PR in modern codebases. Re-keying a secrets vault is a bigger lift, but it’s exactly the sort of lift that gets put off and then runs out of time.

And if none of this lands in your stack before Q-Day, the outcome isn’t apocalyptic overnight. It’s a slow bleed. Expired trust. Forged signatures on old artifacts. Re-encryption of data an adversary already captured. The first attacks won’t look like attacks. They’ll look like verification failures on software nobody thought to migrate.