Post-Quantum Cryptography: Why the Migration Deadline Is Now, Not When Quantum Computers Arrive

A cryptographically-relevant quantum computer — one actually capable of breaking RSA and elliptic-curve encryption — doesn't exist yet, and credible estimates for when one might range from several years to over a decade out. That's not the part that should drive migration timelines. The part that should is that encrypted data being intercepted and stored today can be decrypted retroactively the moment such a computer exists — a strategy security researchers call "harvest now, decrypt later." For anything with a long confidentiality shelf life — government records, health data, trade secrets, most of what GDPR actually governs — the migration deadline isn't when quantum computers arrive, it's now, for data that needs to stay confidential past whenever that turns out to be.

What actually changed: NIST finalized real standards in 2024

On August 13, 2024, NIST finalized three post-quantum cryptographic standards after an eight-year public evaluation process — this stopped being a theoretical research question and became something with real, implementable specifications:

• ML-KEM (FIPS 203) — a key encapsulation mechanism, replacing RSA and ECDH for establishing shared secrets in encrypted communication (the "key exchange" part of TLS).
• ML-DSA (FIPS 204) — a digital signature algorithm, replacing ECDSA and RSA for signing certificates, tokens, and authentication artifacts.
• SLH-DSA (FIPS 205) — a hash-based signature algorithm with more conservative security assumptions than ML-DSA, intended as a structural fallback if a future weakness is found in lattice-based cryptography specifically.

Having three finalized standards, not one, is deliberate: it avoids the single-point-of-failure risk of standardizing on one mathematical approach that later turns out to have a flaw nobody anticipated.

The deadlines that already exist

The most concrete deadline so far applies to U.S. National Security Systems: the NSA's CNSA 2.0 guidance sets 2030 as the point by which most such systems must support post-quantum algorithms, moving toward exclusive use by 2035. That's a U.S. government-specific mandate, but it's functioning as an industry pacesetter the way earlier NIST cryptographic standards have historically done — vendors building products used across critical infrastructure and defense supply chains are aligning to it regardless of jurisdiction, which means EU and EMEA organizations in those supply chains are likely to see PQC support requirements flow down from customers and partners well before any EU-specific mandate exists.

Why "harvest now, decrypt later" makes this urgent for specific kinds of data

Most organizations don't need to migrate everything immediately — TLS sessions protecting a routine web transaction today have essentially no value to decrypt in ten years. The calculation changes completely for data with a long required confidentiality period: patient health records, long-term government or defense communications, intellectual property with a multi-decade competitive value, and anything else where "confidential until 2040" is a real requirement, not a rounding error. For that category specifically, an attacker doesn't need a working quantum computer today — they need to capture the encrypted traffic today and hold onto it, which is a much lower bar and one there's no way to detect after the fact.

What a realistic migration actually looks like

This isn't a single product swap — it's a multi-year inventory and transition process, and the first real step is knowing where you currently rely on the algorithms being replaced:

• Inventory cryptographic dependencies. Most organizations don't have a clear picture of where RSA, ECDSA, and ECDH are actually used across their systems, vendors, and product dependencies — that visibility gap is usually the actual bottleneck, not the migration itself.
• Prioritize by data sensitivity and confidentiality horizon, not by system criticality alone — a system protecting short-lived data is genuinely lower priority than one protecting long-lived data, even if the system itself is less central to operations.
• Expect hybrid deployments first. Most real-world PQC rollouts run a classical algorithm alongside a post-quantum one during the transition, rather than a hard cutover — this hedges against an undiscovered flaw in the new standards while still closing the harvest-now-decrypt-later window.
• Track vendor and dependency readiness. Your own migration is gated by whether the libraries, hardware, and third-party services you depend on actually support these algorithms yet — which is exactly the kind of dependency visibility our Supply Chain Advisories archive and Secure Code Review service are built to surface.

If you're not sure where to start, the honest first deliverable isn't a migration plan — it's the inventory that makes a migration plan possible. Our Security Engineering and Security Consulting services can help build exactly that picture for your actual environment.