The most common objection to post-quantum migration is also the most misguided: "there is no quantum computer that can break RSA yet, so why rush?" The answer is harvest-now-decrypt-later. An adversary who captures your encrypted traffic today can store it indefinitely and decrypt it the moment a cryptographically relevant quantum computer exists — and intelligence-grade actors are widely assessed to be doing exactly that. For any data with a confidentiality lifetime measured in years — health records, financial data, government communications, long-lived secrets — the relevant deadline is not when quantum computers arrive; it is today minus the years that data must stay secret. With NIST having finalized the core standards and hybrid key exchange already live in major browsers, the migration has moved from research problem to engineering project. This guide covers what was standardized, what to do first, and how to sequence the work without breaking production.
Harvest Now, Decrypt Later — The Threat That Is Already Active
The threat model that makes post-quantum migration urgent does not require a quantum computer to exist today. It requires only that one will exist within the confidentiality lifetime of data being intercepted now. An adversary records encrypted traffic — a VPN session, a TLS connection, a backup transfer — and stores the ciphertext. Years later, with a sufficiently capable quantum computer running Shor's algorithm, the asymmetric key exchange that protected that session is broken and the stored ciphertext is decrypted retroactively. The data you encrypt with classical algorithms today is therefore only as safe as the assumption that no quantum computer will exist before that data stops mattering. For long-lived secrets, that assumption is already a bad bet.
- The attack is passive and silent today — capture and store ciphertext now, decrypt later
- Your real deadline is: required-secrecy-duration before the arrival of a capable quantum computer
- Data with multi-year or multi-decade confidentiality (health, finance, legal, state) is exposed right now
- Symmetric crypto (AES-256) is largely fine — Grover's algorithm only halves effective key strength
- The break is in asymmetric key exchange and signatures (RSA, ECDH, ECDSA) — that is what must migrate
What NIST Actually Standardized
After a multi-year competition, NIST finalized its first post-quantum standards, and these are the algorithms to build around — not experimental schemes. The headline standard is ML-KEM (FIPS 203), a key-encapsulation mechanism derived from CRYSTALS-Kyber, used to establish shared secrets resistant to quantum attack. For signatures there are ML-DSA (FIPS 204, from CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, a stateless hash-based scheme from SPHINCS+) as a conservative, different-math backup. The practical takeaway: these are finalized federal standards with maturing library support, not bleeding-edge research. ML-KEM-768 for key exchange and ML-DSA for signatures are the sensible defaults for most teams.
- ML-KEM (FIPS 203) — key encapsulation from Kyber; the workhorse for quantum-resistant key exchange
- ML-DSA (FIPS 204) — lattice-based signatures from Dilithium; the default signature choice
- SLH-DSA (FIPS 205) — stateless hash-based signatures from SPHINCS+; slower and larger, valued as a conservative hedge on different math
- ML-KEM-768 is the common security-level default; step up to 1024 for the most sensitive workloads
- These are finalized standards with growing support across TLS libraries, HSMs, and language ecosystems
Hybrid Is the Pragmatic Default
You do not flip from classical to post-quantum overnight, and you should not try. The deployed-and-proven approach is hybrid: combine a classical algorithm with a post-quantum one so the connection is secure if either holds. This is exactly what shipped at scale in TLS — the X25519MLKEM768 hybrid key exchange has been enabled by default in major browsers and on large CDN networks since 2024, and messaging platforms deployed post-quantum handshakes in their protocols around the same time. Hybrid hedges the genuine risk that a relatively new lattice scheme has an undiscovered classical weakness, while still defeating harvest-now-decrypt-later. For nearly every team, hybrid is the right migration target, not pure post-quantum.
- Hybrid combines classical + post-quantum so a break in either one alone does not compromise the session
- X25519MLKEM768 hybrid TLS key exchange is already default in major browsers and large CDNs
- Major messaging protocols deployed post-quantum handshakes (e.g. PQXDH-style designs) at scale
- Hybrid protects against both quantum attack and any latent classical flaw in the newer PQC schemes
- Target hybrid as your migration end-state; pure post-quantum is for specialized, forward-looking cases
Step One Is an Inventory, Not an Algorithm
The instinct to start by swapping in a new algorithm is the wrong first move. You cannot migrate cryptography you cannot find. The first deliverable of any serious post-quantum program is a cryptographic inventory: every place your systems use asymmetric cryptography, what algorithm, what key sizes, what data it protects, and what its confidentiality lifetime is. This is unglamorous discovery work — combing TLS termination, VPNs, code-signing, document signing, JWT and token signing, database and disk encryption key wrapping, and every third-party dependency that does crypto on your behalf. The inventory is what lets you prioritize: long-lived-secret systems first, ephemeral-session systems later. Skip it and you will migrate the easy, visible things while the genuinely exposed long-lived data sits untouched.
- Enumerate every use of asymmetric crypto: TLS, VPN, SSH, code signing, document signing, token/JWT signing, key wrapping
- For each, record algorithm, key size, the data it protects, and that data's required confidentiality lifetime
- Include third-party and dependency crypto — libraries, HSMs, cloud KMS, SaaS vendors
- Prioritize by confidentiality lifetime: long-lived-secret systems migrate first, ephemeral sessions later
- The inventory is the program's foundation — without it you will migrate the visible, not the vulnerable
Crypto-Agility: The Real Long-Term Goal
The deeper lesson of this migration is that it will not be the last one. Hard-coded algorithm choices scattered through a codebase are why crypto migrations take years; the systems that migrate fastest are the ones built so the algorithm is a configuration value behind an abstraction, not an assumption baked into a thousand call sites. Crypto-agility — the ability to swap algorithms without re-architecting — is the durable win here, worth more than any single algorithm choice. Even if ML-KEM and ML-DSA hold for decades, building agility now means the next transition is a config change rather than a multi-year program. Treat post-quantum migration as the forcing function to finally centralize and abstract your cryptographic choices.
- Centralize crypto behind an abstraction so the algorithm is configuration, not a hard-coded assumption
- Avoid scattering algorithm choices across the codebase — that is what makes migrations take years
- Design for negotiation and versioning so endpoints can agree on algorithms and upgrade independently
- Crypto-agility makes the next transition a config change, not a re-architecture
- Use this migration as the reason to finally build the agility you will need repeatedly
A Phased Migration Plan
A migration of this scope needs sequencing, not a big-bang cutover. The phased plan below is the shape we recommend for most organizations. It front-loads the cheap, high-leverage work — inventory and turning on hybrid TLS where your stack already supports it — and defers the harder, application-level cryptography changes until you have the visibility to prioritize them. Align the timeline with external mandates where they apply: government and regulated-industry timelines (such as NSA's CNSA 2.0 guidance) set hard dates for some sectors, and major vendors are moving their defaults regardless. The goal is steady, prioritized progress, not a single risky cutover.
- Phase 1 — Build the cryptographic inventory and classify data by confidentiality lifetime
- Phase 2 — Enable hybrid post-quantum TLS everywhere your libraries and CDN already support it (often a config change)
- Phase 3 — Migrate long-lived-secret systems: key wrapping, backups, code/document signing, long-validity certificates
- Phase 4 — Refactor toward crypto-agility so application-level crypto is swappable
- Phase 5 — Track standards and vendor defaults, align with mandates (e.g. CNSA 2.0), and re-prioritize as support matures
- Throughout — test interoperability carefully; PQC keys and signatures are larger and can break size assumptions in protocols and hardware
Conclusion
Post-quantum migration is the rare security project where the deadline is already behind you for some of your data — anything captured today with a multi-year secrecy requirement is already at risk under the harvest-now-decrypt-later model. The good news is that the work is no longer speculative: NIST has finalized the standards, hybrid key exchange is shipping by default in the browsers and CDNs most teams already depend on, and the library support is real. The teams that come through this well will not be the ones who waited for a quantum computer to appear in the news; they will be the ones who built a cryptographic inventory this year, turned on hybrid TLS where it was a config change, and used the project as the excuse to finally make their cryptography agile. Start with the inventory. Everything else depends on knowing what you are actually protecting and for how long.
About Sensussoft Security
Sensussoft Security is a technology expert at Sensussoft with extensive experience in cybersecurity. They specialize in helping organizations leverage cutting-edge technologies to solve complex business challenges.
