For 10 years, the security industry treated post-quantum cryptography as a problem for later. Then, in late March, Google set a hard date: 2029. Not the comfortable mid-2030s, where most roadmaps had quietly filed it. 2029. Cloudflare matched the deadline within two weeks. When two companies that essentially run the plumbing of the internet land in the same year, you can stop treating it as someone else's roadmap. It's a planning assumption you've inherited, whether you asked for it or not.

The date moved for a reason, and the reason matters. For years, the consensus has been that a quantum computer useful for cryptography will be available within the next decade. Newer research has pulled that horizon in, work suggesting the elliptic-curve cryptography that underpins most modern authentication could fall to far fewer qubits than anyone had modeled. Google and Cloudflare pointed to the same drivers: faster hardware, better error correction, sharper factoring estimates. Read that carefully. The people building these machines looked at the latest numbers and decided the runway was shorter than they'd assumed. When the builders move the deadline forward, that isn't a news cycle to wave off. It's a tell.

The Algorithm Is Not the Hard Part, Discovery Is

So far, the noise has mostly been about algorithms: ML-KEM, ML-DSA, which lattice scheme lands where, NIST's deprecation calendar. Important work. Not the work that's going to sink most enterprises. What will sink them is simpler and far less glamorous: almost no organization can tell you where cryptography actually lives inside its own walls. And you can't migrate what you can't see.

Even the Best-Prepared Enterprises Are Finding Blind Spots

I got a fresh reminder of how wide that gap runs at the RSA Conference this year. I was on stage with a cryptography program manager from a Fortune 100 company, working through quantum-ready identity defense. This is exactly the org you'd expect to be ahead: a dedicated program, executive air cover, real budget. Their own numbers told a different story. Visibility into maybe half their cryptographic inventory. Almost no ability to rotate keys or certificates on demand. Effectively zero ability to swap algorithms across systems. Most of the estate is still running cryptography a quantum computer will eventually render vulnerable. If a mature program is still at the starting line, the average enterprise hasn't laced up.

The Real Post-Quantum Challenge Is Knowing What You Own

That's why I keep saying the post-quantum transition isn't really an algorithm problem. The algorithms are mostly settled. The hard part is everything underneath them: finding the cryptography you have, knowing what it protects, who owns it, and what shatters when you change it.

Look at where Google and Cloudflare actually shifted their attention. Both pushed their near-term priority from encryption toward authentication. That's no accident. Encryption has had the spotlight for years, thanks to "harvest now, decrypt later." Authentication- the identities, certificates, tokens, and keys that decide who and what gets trusted- is the harder problem, and it's the one most inventories barely scratch.

The Hidden Risk: The Identities Machines Use to Connect and Trust

The real exposure hides in the credentials nobody keeps a list of. Human accounts are the easy part. The danger lies in the rest: service accounts, machine and workload identities, device credentials, API keys, and above all, code-signing keys. A stolen code-signing key is about as bad as it gets. It lets an attacker push malicious software that every downstream system trusts on sight, which is precisely how several of the worst supply-chain breaches of the last few years played out. These non-human identities already outnumber human ones many times over in most companies. They rarely have a clear owner. And they're usually missing from the very asset databases that security teams lean on. You can't prioritize a key you don't know exists.

Post-Quantum Resistant Does Not Mean Post-Quantum Safe

This is also where "post-quantum resistant" and "post-quantum safe" quietly part ways, and treating them as the same thing will burn you. Drop a PQC algorithm into one place, say your customer-facing TLS, and that path is resistant. The organization is not safe. Anything sensitive you encrypt with classical cryptography today should already be considered captured; a future quantum computer can decrypt it after the fact, and migrating later won't claw any of it back. Even once you've deployed PQC, a downgrade attack can push a connection back to classical crypto whenever you're still running legacy clients. And you're caught in a bind: you can't switch off the old algorithms until everyone you talk to supports the new ones, but you stay exposed to downgrades until you do. Safety is a property of the whole estate and everything it leans on, not of the one system you happened to fix first.

The Five Questions Every Security Leader Must Ask Now

So, when you can't do everything at once, what comes first? Rank your cryptographic assets along five lines. Lifespan: How long does this need to stay confidential or trusted? Anything that has to survive into the 2030s is already at risk. Exposure: Is it internet-facing, and does it touch anything sensitive? Dependencies: How many breaks would there be if you changed it? Ownership: Can you even name who's accountable? Blast radius: What goes down if it's compromised? A codesigning or root key with a long life, wide dependencies, and no clear owner is a five-alarm fire, no matter where it sits on the org chart.

Here's what I'd do in the next 90 days. Run a real cryptographic discovery effort, across identities, certificates, keys, and especially the non-human accounts everyone skips. Not a one-time scan. A living inventory that keeps up as things change. Then score and rank it against those five questions, so risk drives the work instead of whatever happens to be easiest to find. And make post-quantum support a procurement requirement starting now, so you stop dragging in new quantum-vulnerable dependencies while you're clearing out the old ones. None of this waits on you choosing final algorithms, and all of it pays off no matter when Q-Day actually lands.

2029 Is Not the Deadline; It's the Warning

2029 isn't the year you finish. It's the year the companies you depend on plan to be done. The organizations that spend the next three years treating this as a visibility problem first and an algorithm problem second are the ones still standing when it arrives.