The Quantum Threat to Encryption Is Real. The Migration Is the Hard Part.

For most of the past decade, post-quantum cryptography was a research programme. It had competitions, workshops and slide decks, and it sat in the same mental drawer as fusion power: important, real, and safely far away. That framing is no longer accurate. The first standards were finalised in 2024. The United States converted them into dated obligations in June 2026. National security agencies have begun naming phase-out years for systems that cannot comply. The question facing nearly every organisation is no longer whether the migration matters, but why so little of it has happened yet.

This piece is a working guide to that gap. It covers what quantum computers actually threaten, what the new standards are, what the deadlines now require, and where migrations reliably stall. The cryptography itself is the easy part. The inventory, the protocols and the procurement are where the work lives.

What a quantum computer actually threatens

The threat model comes from two algorithms published in the 1990s, long before any hardware could run them. Shor's algorithm, published in 1994, factors large integers and solves discrete logarithms efficiently on a sufficiently large quantum computer. Those are the two mathematical problems underneath RSA and elliptic-curve cryptography, the algorithms that protect key exchange and digital signatures across virtually all of the internet. Grover's algorithm, published in 1996, gives a quadratic speed-up against unstructured search, which effectively halves the security strength of symmetric ciphers like AES. Doubling key lengths addresses that. There is no comparable patch for what Shor's algorithm does to RSA.

The honest state of hardware is that the machine which runs Shor's algorithm at the scale needed to break RSA-2048 does not exist, and credible estimates place it years away. But the hardware trajectory has changed character. The field has moved from demonstrating physical qubits to demonstrating error-corrected logical qubits, which is the architecture every credible path to a large machine runs through. Google's team has published a roadmap built around logical-qubit milestones, with the first demonstrations showing that error rates fall as the code grows [1](https://quantumai.google/qecmilestone). IBM's published roadmap commits to early examples of quantum advantage in 2026 and continued progress toward fault-tolerant machines by 2029 [2](https://www.ibm.com/roadmaps/quantum/2026/). Quantinuum reported 48 error-corrected logical qubits running on 98 physical trapped-ion qubits in March 2026, with logical error rates below the physical baseline, and Microsoft and Quantinuum together published Nature results showing logical error reductions of up to 800 times over physical circuits [3](https://www.quantinuum.com/blog/skinny-logic-quantum-codes-go-on-a-diet). None of these is a code-breaking machine. All of them are evidence that the engineering problems between here and one are being worked off one by one.

This matters for security planning because of an asymmetry that has nothing to do with hardware. A sufficiently large quantum computer does not need to exist to cause damage. It only needs to be possible, and the data being collected today is the data it will eventually open. That asymmetry has a name that now appears in government documents: harvest now, decrypt later. The National Security Agency states plainly that adversaries are already collecting encrypted traffic in anticipation of future quantum decryption capability [4](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4615285/nsa-announces-post-quantum-cryptography-measures-to-safeguard-national-security/). Any organisation holding data that must stay confidential into the 2030s, which is nearly every organisation, is already exposed to that collection. The confidentiality clock runs from the day a secret is captured, not from the day the computer is switched on.

The standards exist, and they are two years old

NIST ran its post-quantum standardisation project for eight years, from a 2016 call for proposals through 82 submissions from 25 countries, and published the first three final standards in August 2024 [5](https://csrc.nist.gov/projects/post-quantum-cryptography). They are worth keeping separate, because they solve different problems.

FIPS 203 defines ML-KEM, a key encapsulation mechanism derived from CRYSTALS-Kyber. This is the algorithm that replaces RSA and elliptic-curve Diffie-Hellman for establishing shared secrets over an untrusted channel. FIPS 204 defines ML-DSA, a lattice-based digital signature scheme derived from CRYSTALS-Dilithium, intended as the general-purpose replacement for RSA and ECDSA signatures. FIPS 205 defines SLH-DSA, a stateless hash-based signature scheme derived from SPHINCS+, included deliberately because its security rests on different mathematical assumptions than the lattice schemes. If a weakness were ever found in lattice problems, SLH-DSA remains standing, which is the whole point of publishing it alongside them [5](https://csrc.nist.gov/projects/post-quantum-cryptography).

The pipeline continues behind them. In March 2025, NIST selected HQC, a code-based scheme, as a backup key encapsulation mechanism with different mathematics from ML-KEM, and a draft of FIPS 206, built on the Falcon construction, entered public comment the same year [6](https://csrc.nist.gov/csrc/media/Presentations/2025/nist-pqc-the-road-ahead/images-media/rwcpqc-march2025-moody.pdf). NIST has also published migration guidance, most importantly NIST IR 8547, which sets the transition clock for classical algorithms: public-key systems offering 112 bits of classical security, which includes RSA-2048 and elliptic curves at the 256-bit level, are designated deprecated after 2030 and disallowed after 2035. Those two dates, not the arrival of a quantum computer, are now the operative deadlines for anyone building systems with classical public-key cryptography.

The deadlines arrived in June 2026

For years the transition ran on guidance without enforcement. In the last week of June 2026, that changed. Executive Order 14412, signed on 22 June 2026, directs federal agencies to transition high-impact systems and high-value assets to NIST post-quantum key establishment by 31 December 2030 and post-quantum digital signatures by 31 December 2031, and to assist critical-infrastructure operators with their own transitions [7](https://www.federalregister.gov/documents/full_text/html/2026/06/25/2026-12909.html). Around the same dates, the NSA announced measures under CNSS Policy 15 requiring that all new commercial national security systems be capable of supporting quantum-resistant algorithms starting in 2027, with legacy systems that cannot support them phased out by 2030 [4](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4615285/nsa-announces-post-quantum-cryptography-measures-to-safeguard-national-security/).

The dates stack up faster than the headline numbers suggest. The Cryptographic Module Validation Program stops accepting validation submissions for modules that do not meet the updated standards after 21 September 2026, and the CNSA 2.0 timeline for national security systems reaches its first hard requirement in January 2027 [8](https://www.pqcinformation.com/federal-pqc-migration-deadlines-what-agencies-actually-face-in-2026-and-beyond/). The United States is not alone: the European Union, the United Kingdom, Australia, Canada and Japan have all set their own migration dates in the same 2030 to 2035 window, and nearly every jurisdiction gates everything downstream on the same first deliverable, a cryptographic inventory [9](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html). For vendors selling into any regulated market, these dates arrive through procurement requirements years before they appear in statute. A product that cannot support the new algorithms is not non-compliant in 2030. It is unpurchasable in 2027.

Why migration is the hard part

Swapping one key-exchange algorithm for another sounds like a library update. In practice, the post-quantum migration is closer to a decade of Y2K work distributed across every system an organisation owns, and the failure modes are now predictable enough to describe in advance.

Nobody knows what cryptography they run

The first deliverable in nearly every jurisdiction is a cryptographic inventory, and it is first because nothing else can be sequenced without it [9](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html). Most organisations cannot produce one. Cryptographic code hides in places its owners do not think of as cryptography: TLS termination inside load balancers, license checks inside desktop applications, firmware in printers and badge readers, embedded RSA keys generated by a vendor in 2014, hardcoded certificates in mobile apps. Discovery tooling exists and is improving, but the reliable finding across early federal inventories is that discovered cryptography consistently exceeds assumed cryptography by a wide margin. An organisation that believes it has fifty places using RSA usually has several hundred.

The performance problem is real but narrower than feared

Post-quantum algorithms are not drop-in replacements in either direction. Lattice key encapsulation is, encouragingly, quite fast: ML-KEM key generation and encapsulation are competitive with elliptic-curve operations on modern hardware, and its larger key sizes, on the order of a kilobyte rather than 32 bytes, matter mostly for constrained links and handshake-heavy protocols. Signatures are the sharper edge. ML-DSA signatures are several times larger than their elliptic-curve equivalents, which pressures certificate chains, code-signing formats, and any protocol that stamps many signatures into a single message. SLH-DSA trades even larger signatures for the conservative hash-based security assumption. The engineering consequence is that migration plans must treat key establishment and signatures as separate workstreams with separate bottlenecks, not as one swap.

Hybrid deployment is the sensible intermediate state

Because ML-KEM is young relative to algorithms with thirty years of attack literature, the recommended deployment for key exchange is hybrid: combine ML-KEM with a classical algorithm such as X25519, so that a session is secure if either one holds. This is the pattern adopted by major browsers and cloud providers in their own transitions, and it is what federal guidance expects for the coming years. Hybrid mode costs extra bytes and extra latency, and it is still the correct default for anything where the confidentiality lifetime is long. The one caution is that hybrid modes add protocol complexity, and several early implementation vulnerabilities in post-quantum TLS involved the hybrid glue rather than the new algorithms themselves. The migration is itself an attack surface.

Signatures are the harder deadline to meet

Key establishment can be upgraded connection by connection, and TLS absorbs the change invisibly for most users. Digital signatures are stickier because they authenticate things that persist: software update channels, boot firmware, document signing, certificate hierarchies, blockchain-style ledgers. A signed artefact whose signature algorithm is later broken is exposed in a different way than a session key, because the artefact itself lives on. The executive order's separate 2031 deadline for signatures, one year after key establishment, reflects that the signature transition is expected to be slower, not easier [7](https://www.federalregister.gov/documents/full_text/html/2026/06/25/2026-12909.html).

Crypto agility decides who finishes

The organisations that will finish this migration are the ones that can change algorithms without rewriting systems. That property, usually called cryptographic agility, is not a product feature that can be purchased late. It is an architectural stance: algorithms referenced by configuration rather than hardcoded, protocol versions that negotiate cipher suites cleanly, certificate and signature formats that can carry new algorithm identifiers. Most deployed systems were built assuming the algorithms never change, because for thirty years they never did. Post-quantum migration is the forcing function, but the second transition, whatever eventually replaces the lattice schemes, will punish the same rigidity. Agility is the part of this work that pays off more than once.

What to do now, in order

The sequencing that follows from the deadlines is consistent across jurisdictions. First, build the cryptographic inventory, using automated discovery against real systems rather than questionnaires to teams. Second, prioritise by exposure: data with long confidentiality lifetimes, systems reachable by untrusted networks, and anything in scope for government procurement go first. Third, enable hybrid post-quantum key establishment on external TLS endpoints, which is available today in mainstream libraries and clouds and is the single highest-value change most organisations can make this year. Fourth, put contractual language into procurement requiring post-quantum support in products bought now, so that 2027 does not arrive with a fleet of newly purchased systems that cannot comply. Fifth, treat the 2030 and 2031 dates as planning anchors and the 2035 disallowance as the hard wall.

None of this requires believing that a code-breaking quantum computer is five years away. It requires believing something much less speculative: that data collected today will still be valuable decades from now, that the standards and deadlines exist, and that migrations of this size take longer than the remaining time. The mathematics was settled in 2024. The deadlines were settled in 2026. The only open variable is how much of the work is done when they arrive.

Limitations

Predictions about quantum hardware timelines have historically erred in both directions, and estimates for cryptographically relevant machines range from under a decade to never; the responsible planning basis is the asymmetry of harvest now, decrypt later, not any specific forecast. The published benchmarks for logical qubits come from vendor-led teams on their own hardware, and independent replication is still catching up. Migration cost estimates for private organisations are largely extrapolations from federal experience, which is not a representative sample. And the standards themselves are young: ML-KEM and ML-DSA have withstood sustained scrutiny, but a cryptanalytic surprise remains possible, which is precisely why SLH-DSA and HQC exist as fallbacks and why hybrid deployment is recommended in the interim.