Post-Quantum Migration Clock Already Running

In boardrooms, quantum computing is often dismissed as a problem for the next decade. The conversation follows a predictable arc: someone raises it, someone else says it's ten years out, and the topic gets tabled until the next budget cycle. But the clock that matters isn't waiting for a quantum computer to arrive—it started ticking the moment an organization first sent sensitive data over a channel an adversary could capture and store.

A nation-state or well-resourced criminal group doesn't need a working quantum computer today to pose a threat. It needs storage capacity and ciphertext, both of which it likely already has. It can sit on that data for years and decrypt it retroactively the day a cryptographically relevant quantum computer exists. This is the harvest-now-decrypt-later model, and for many organizations, it is already unfolding.

Why the deadlines keep moving closer

NIST's transition plan, published as NIST IR 8547, provides concrete dates to plan around: RSA-2048 and ECC P-256 get deprecated by 2030, and they're gone from NIST standards entirely by 2035. That timeline isn't theoretical anymore. NIST spent eight years getting here, and in August 2024 it finally landed three finalized FIPS standards. ML-KEM handles key encapsulation. ML-DSA and SLH-DSA cover digital signatures, using two different mathematical approaches so you're not betting everything on one scheme holding up. A fourth standard, FN-DSA (built on the FALCON algorithm and designated FIPS 206), is due out later this year.

Organizations in national security or defense-adjacent environments are working against a tighter window. The NSA requires national security systems to adopt quantum-resistant cryptography for new acquisitions starting in 2027. The UK has set its own pace on a similar structure — the NCSC's guidance splits the transition into three phases: identifying cryptographic services and building a migration plan through 2028, executing high-priority upgrades from 2028 to 2031, then completing migration across all systems, services and products between 2031 and 2035.

None of this belongs in the “future planning” bucket anymore. A 2030 deprecation deadline sounds distant until you map it against how long your organization takes to touch every system running cryptography. Cryptographic discovery projects have stretched past a year just to produce an accurate inventory, for clients who thought they had a clear picture of their own environment going in.

Let the math set your timeline

Mosca's theorem is worth learning even if you never see the formula written out. It weighs three numbers against each other: how long migration will take you (X), how long your data needs to stay confidential (Y) and how soon a cryptographically relevant quantum computer is likely to exist (Z). When X plus Y outpaces Z, you're already exposed, whether the exposure has been noticed yet.

Run that comparison against your own data instead of against an industry average. A retail transaction log with a two-year retention window carries a different risk profile than genomic data, merger documentation or infrastructure design specs that need to stay confidential for thirty years. For a good number of organizations, that confidentiality window runs well into the 2030s and beyond — healthcare records, financial data and classified information can need protection for fifty years or more. If any of your data fits that description, “quantum computers are a decade away” stops being a reason to wait and starts being the reason you're already behind.

What migration actually requires

Treating this like a patch cycle is a common mistake — swap an algorithm, ship an update, move on. That framing misses the scale of what's involved. Migrating to post-quantum cryptography means locating every algorithm in every protocol, on every device, across every product in your supply chain and replacing each one without breaking interoperability with everyone else going through the same transition on their own timeline.

Start with discovery, because it's the piece every client underestimates going in. You need a real inventory of where RSA, ECC and other quantum-vulnerable algorithms are running — in TLS configurations, code signing processes, VPN tunnels, embedded firmware and third-party libraries you didn't write and may not fully control. Almost every discovery project turns up cryptography the client had forgotten existed.

From there, the architectural goal is crypto-agility rather than a one-time fix. Migrating once and hoping the next transition goes smoother isn't a strategy, since there will be a next transition. Building systems where swapping an algorithm doesn't require rebuilding the surrounding infrastructure means abstracting cryptographic operations behind interfaces that don't hard-code a specific algorithm and standing up key management that can run classical and post-quantum algorithms side by side during the overlap period.

Prioritization should track data sensitivity and exposure time, not convenience or ease of implementation. Systems holding data with long confidentiality windows need to move first. Public-facing TLS endpoints carrying traffic vulnerable to harvest-now-decrypt-later deserve early attention too, since that's the traffic most likely already sitting in someone else's storage.

Vendor coordination is where migrations lose months. Your own readiness only goes as far as the readiness of every vendor whose cryptography your systems depend on. Asking vendors for their PQC roadmaps now costs you nothing, and waiting until your migration hits a dependency you don't control costs you a quarter you didn't budget for.

Where to start this quarter

You don't need a board mandate to justify the first step. CISA, NSA and NIST have jointly published a six-step migration playbook, and cryptographic discovery — the first step in it — is something you can start on your own budget and your own schedule, without waiting on a vendor or a committee decision.

In my experience, the organizations struggling in 2030 won't be the ones running the most complicated environments. They'll be the ones who spent 2026 waiting for someone else to move first, even though the standards were already finalized and the guidance was already public.