For years, post-quantum cryptography lived in the same category as flying cars: technically real, practically distant, something you'd get to eventually. Then last August, NIST published the actual standards — FIPS 203, 204, and 205 — and "eventually" became "now." The math is done. The algorithms have names. The migration clock is running.
And here's what I want everyone to understand: this is not a math problem anymore. It's a program-management problem.
I say this as someone who's spent a career in key management, so I know exactly how unglamorous this sounds. Nobody's giving keynotes about inventory spreadsheets. But the hard part of post-quantum migration was never the algorithms — NIST and a few hundred cryptographers handled that. The hard part is finding every place cryptography lives in your organization and changing it, in the right order, without breaking anything.
Think about what "every place cryptography lives" actually means. It's the TLS libraries, obviously. But it's also the VPN concentrators, the code-signing infrastructure, the HSMs and whether their firmware supports the new algorithms, the IoT devices with crypto baked into silicon that can't be updated, the third-party SaaS vendor who handles your data and hasn't published a migration plan, the backups encrypted with algorithms you're about to retire, the certificates with ten-year lifetimes issued back when ten years felt safe.
Nobody has a complete list. I'd bet money on it. Most organizations can't fully inventory their current crypto usage, and now they need to migrate all of it. Discovery alone is a multi-quarter program for any company of size.
Then there's the sequencing problem, which is where it gets genuinely tricky. You can't just flip a switch. The new algorithms have different performance characteristics — bigger keys, bigger signatures, more computation. That matters for constrained devices, for high-throughput TLS terminators, for anything where latency is measured in microseconds. Hybrid approaches — running classical and post-quantum together during transition — are the sane path, and they're also twice the operational complexity.
And the vendors. Everyone's waiting on everyone else. Your HSM vendor is waiting on firmware validation. Your cloud provider has a roadmap but the dates are soft. Your auditors haven't decided what "compliant" means yet. Coordinating a migration across a supply chain where every link moves at a different speed is pure program management — dependencies, critical paths, escalation, the works.
The quiet urgency behind all of this has a name: harvest now, decrypt later. Adversaries are collecting encrypted traffic today on the assumption that they'll decrypt it once quantum computers mature. If your data has a secrecy lifetime longer than the migration timeline — and for a lot of regulated data, it does — then the window that matters isn't "when quantum computers arrive." It's already open.
So what should you actually do? Start with inventory. Not a pilot, not a working group to discuss forming a working group — an inventory. Where does crypto live in your environment? What algorithms, what key lengths, what lifetimes? You can't migrate what you can't see, and most organizations are about to discover they're blinder than they thought.
Then prioritize by data lifetime and exposure. The stuff facing the internet, protecting long-lived secrets, goes first. The internal system with a three-year refresh cycle can wait its turn.
And staff it like the program it is. This needs someone running it full-time — tracking vendors, sequencing migrations, managing the hybrid period, reporting to leadership in terms of risk reduced rather than algorithms deployed. The cryptographers did their part. Now it's our turn.
The quantum apocalypse isn't coming. It's a migration project. And migration projects are won by people with spreadsheets, not people with whiteboards.