The Post-Quantum Migration Clock: Real Deadlines and How to Plan Against Them

Most discussions of post-quantum cryptography stall at the same place: when do we actually have to do this? The honest answer used to be "nobody knows." That's no longer true — not because anyone can predict when a cryptographically relevant quantum computer arrives, but because regulators stopped waiting for that prediction and published dates anyway.

If you already understand what PQC is and which algorithms replace which, our guide to post-quantum cryptography covers that ground. This post is about the calendar and the project plan.

The standards are settled

NIST finalized three post-quantum standards on August 13, 2024, after an eight-year competition:

Use the FIPS names in procurement documents and internal specs. "Kyber" and "Dilithium" refer to the competition submissions, which differ in small but real ways from the standardized versions — a vendor claiming "Kyber support" may or may not mean FIPS 203 compliance, and that ambiguity has already caused interop problems.

Two more are in flight. NIST selected HQC in March 2025 as a code-based backup KEM with different mathematical foundations from ML-KEM, with a draft standard expected around 2026 and finalization targeted for 2027. FN-DSA (FALCON) remains slated for standardization as a compact-signature option. Neither should hold up your migration; ML-KEM and ML-DSA are the workhorses.

The deadlines that exist on paper

Three separate sets of dates matter, and they don't line up.

NIST IR 8547 — Transition to Post-Quantum Cryptography Standards, initial public draft November 2024 — is the broadest. It proposes that RSA, ECDSA, EdDSA, ECDH, DSA, and finite-field Diffie-Hellman become deprecated after 2030 and disallowed after 2035. Deprecated means continued use requires the data owner to document a risk acceptance. Disallowed means the option to accept that risk goes away.

NSA's CNSA 2.0 applies to National Security Systems and moves faster, with a staged schedule by product category. As published and updated through May 2025, software and firmware signing is the leading edge — exclusive use of CNSA 2.0 algorithms from January 1, 2027 — with networking equipment following around 2030, and operating systems, custom applications, and cloud services around 2033. Full quantum resistance across NSS is expected by 2035.

OMB M-23-02 (November 2022) is the one that already bit. It directed federal agencies to inventory cryptography on prioritized systems, produce funding estimates, and report annually — with full federal migration targeted for 2035.

Two things follow from this. First, if you sell to the US federal government, especially anything involving signed firmware, your effective deadline is 2027, not 2035. Second, even for purely commercial work, NIST's deprecation calendar becomes the de facto compliance baseline the moment auditors and insurers start citing it — which historically happens well before the date itself.

Note that none of these dates are predictions about quantum hardware. They are engineering schedules working backward from the migration itself taking a decade.

Why the threat model has no start date

The reason a 2030 deadline is defensible even though nobody expects a code-breaking quantum computer by 2030 is harvest now, decrypt later. An adversary records encrypted traffic today and decrypts it whenever Shor's algorithm becomes runnable at scale. Any data whose confidentiality must outlive that moment is already exposed.

The practical calculation is Mosca's inequality: if the time your data must stay secret plus the time your migration takes exceeds the time until a capable quantum computer exists, you are already late. For medical records with a 50-year sensitivity horizon and a five-year migration, you needed to start before the standards existed.

What makes this hard to plan against is that the hardware estimate keeps moving. Shor's 1994 paper established the algorithm; the resource question — how many logical qubits and how many gates to break RSA-2048 — has been re-estimated downward repeatedly as compilation techniques improved. Recent work machine-checking those estimates in Lean is valuable precisely because it removes hand-waving from a number that security planning depends on. The estimates remain far beyond current devices, but "far" has been shrinking, and the direction of travel is one-way.

For the record: symmetric cryptography is fine. Grover's algorithm gives only a quadratic speedup, so AES-256 retains 128-bit effective security. The migration is an asymmetric-crypto migration.

Why this takes years

Migration is slow for reasons that have nothing to do with the algorithms:

• You don't know where your crypto is. It's in TLS terminators, JWT libraries, database TDE, backup encryption, VPN tunnels, code-signing pipelines, HSMs, IoT firmware, and vendor SDKs you don't control.
• Key and signature sizes change. ML-DSA public keys are roughly 1.3 KB versus 32 bytes for Ed25519, and SLH-DSA signatures can run tens of kilobytes. Protocols with fixed-size fields, embedded devices with constrained flash, and certificate chains with MTU assumptions all break.
• Both endpoints must upgrade. You migrate at the speed of your slowest counterparty.
• Hardware has a decade-long tail. HSMs and embedded devices deployed today will still be running in 2035.

Inventory first: a starting point

You cannot migrate an unknown. Start with automated discovery of what's actually negotiated in production, not what your architecture diagram claims.

# What key exchange and signature algorithms is this endpoint actually using?
openssl s_client -connect example.com:443 -brief </dev/null 2>&1 \
  | grep -Ei 'protocol|ciphersuite|group|peer signature'

# Does the endpoint support hybrid post-quantum key exchange?
# Requires OpenSSL 3.5+, which ships ML-KEM natively.
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768 </dev/null 2>&1 | grep -i 'group\|error'

# Inventory certificate signature algorithms across an internal fleet
while read -r host; do
  alg=$(echo | openssl s_client -connect "$host:443" 2>/dev/null \
    | openssl x509 -noout -text 2>/dev/null \
    | awk '/Signature Algorithm/ {print $3; exit}')
  printf '%s\t%s\n' "$host" "${alg:-UNREACHABLE}"
done < hosts.txt

Feed the results into a register that records, per system: the algorithm, key size, protocol, certificate authority, library and version, the owner, and — most importantly — how long the data it protects must stay confidential. That last column is what turns an inventory into a prioritized migration order.

Hybrid deployment is the low-risk path

The consensus deployment pattern is hybrid: run a classical and a post-quantum key exchange together and combine both shared secrets, so the connection is safe unless both are broken. This hedges against implementation bugs and undiscovered cryptanalysis in the newer lattice schemes.

This is no longer experimental. X25519MLKEM768 is the standardized hybrid group, enabled by default in Chrome since version 131 and Firefox since 132, and OpenSSL 3.5 (April 2025) ships ML-KEM natively — its default group list prefers the hybrid, meaning two OpenSSL 3.5 endpoints negotiate post-quantum key exchange with no configuration at all.

# nginx with OpenSSL 3.5+ — explicit hybrid preference, classical fallback
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:P-256;

Signatures are further behind — public CAs are not yet issuing ML-DSA certificates at scale — so key exchange is where you get real HNDL protection today, and it's the cheapest win available.

What to do this quarter

A realistic 90-day slice:

1. Appoint an owner. Migrations without a named accountable person do not happen. This is a multi-year program, not a ticket.
2. Run automated discovery across external endpoints, internal service mesh, and code repositories. Grep your codebases for RSA, ECDSA, secp256, PKCS1, and hardcoded algorithm identifiers.
3. Classify by data lifetime. Sort systems by how long their data must stay secret. Anything over ten years is priority one.
4. Turn on hybrid TLS where it's free. Upgrade to OpenSSL 3.5+ or a TLS terminator that supports X25519MLKEM768. For many organizations this is a load-balancer config change covering the majority of traffic.
5. Send the vendor questionnaire. Ask every crypto-touching vendor for their FIPS 203/204/205 roadmap with dates. Slow answers are your long pole; you need them on record now.
6. Fix crypto-agility in new code. Stop hardcoding algorithms. Route every operation through an abstraction that takes the algorithm from configuration, so the next transition — HQC, FN-DSA, or whatever follows — is a config change rather than a rewrite. This is the single highest-leverage engineering change, because the 2035 deadline is not the last one.
7. Move code signing early. It has the earliest federal deadline, the longest verification tail, and signatures that must remain verifiable for decades.

The bottom line

The deadlines are published, they're closer than the hardware timeline suggests, and they were set by people who assume migration takes ten years. Two dates are worth memorizing: after 2030, classical asymmetric crypto is deprecated; after 2035, it's disallowed — with federal national-security systems running years ahead of that.

The work that pays off regardless of when quantum hardware actually arrives is the boring part: knowing where your cryptography lives and being able to change it without a rewrite. Everything else is a config flag.

Further reading: What PQC actually is · Reading policy documents as technical assessments · Quantum computing glossary · Latest developments