Post-Quantum Cryptography: Why Migration Starts Now

Somewhere right now, encrypted traffic is being captured and stored — not because anyone can read it today, but because someone is betting they will be able to read it later. This is the "harvest now, decrypt later" problem, and it's the reason post-quantum cryptography migration has moved from an academic curiosity to a line item on security roadmaps. The math that protects almost every HTTPS connection, VPN tunnel, and signed software update in use today has a known expiration date. Nobody can say the exact day it arrives, but the systems being built or re-keyed this year will likely still be running when it does.

That mismatch — long-lived data and infrastructure versus a cryptographic foundation with a shelf life — is what makes this migration different from a routine security update. It can't be patched in a weekend once the threat materializes, because the threat is retroactive: data encrypted today with vulnerable algorithms can be decrypted years from now, after the fact. Understanding why that is, what's replacing the vulnerable algorithms, and how a realistic migration actually unfolds is the point of this piece.

Why Current Encryption Is Vulnerable

Almost all public-key cryptography in use today — RSA, Diffie-Hellman key exchange, and elliptic-curve cryptography (ECC) — relies on math problems that are extremely hard for classical computers to solve. RSA's security rests on the difficulty of factoring very large numbers into their prime components. ECC and Diffie-Hellman rest on the difficulty of the discrete logarithm problem. Classical computers, even very fast ones, would need more time than the age of the universe to break well-implemented instances of these problems at current key sizes.

Quantum computers change that calculus for one specific reason: a quantum algorithm called Shor's algorithm, first described in 1994, can solve both the factoring problem and the discrete logarithm problem in polynomial time on a sufficiently large, sufficiently error-corrected quantum computer. This isn't a matter of degree — it's not that quantum computers make the attack somewhat faster. It's that the entire class of problem these algorithms rely on stops being hard.

A second quantum algorithm, Grover's algorithm, affects symmetric cryptography (AES and similar) differently. It provides a quadratic speedup for brute-force key search, which is meaningful but manageable — doubling the key size (moving from AES-128 to AES-256, for instance) restores the original security margin. Symmetric cryptography is inconvenienced by quantum computing. Public-key cryptography is broken by it.

Why "No Quantum Computer Can Do This Yet" Isn't Reassuring

The machines capable of running Shor's algorithm against real-world key sizes don't exist yet, and credible estimates for when they will vary widely — some experts point to the early-to-mid 2030s, others further out, and some argue it may never happen on the timeline vendors imply. None of that matters for data that needs to stay confidential for a long time, because of the harvest-now-decrypt-later pattern:

• An adversary with the resources to store bulk encrypted traffic — a nation-state intelligence service is the usual example — captures encrypted data today.
• They keep it in storage, unreadable for now.
• Once a cryptographically relevant quantum computer exists, they decrypt everything they saved, all at once, using keys and algorithms that were considered secure at the time of capture.

For data with a short shelf life — a one-time payment authorization, a session token that expires in an hour — this threat model doesn't matter much. For data that needs to remain confidential for a decade or more — medical records, state secrets, trade secrets, source code, long-term contracts, genomic data — the exposure window is already open. The encryption applied to that data today is what will (or won't) protect it a decade from now.

The New Standards

In August 2024, the U.S. National Institute of Standards and Technology (NIST) finalized its first set of post-quantum cryptography standards after an eight-year public evaluation process that started with 82 candidate algorithms. Three algorithms were standardized first, each solving a different piece of the puzzle:

A fourth signature standard, based on the FALCON algorithm, was expected to follow. The reasoning behind picking multiple algorithms rather than one "winner" is deliberate: lattice-based cryptography (Kyber, Dilithium) is efficient and well-suited to general use, but relying on a single mathematical assumption is risky if a future weakness is found in it. SPHINCS+ is based on entirely different math — the security of hash functions — so it serves as an independent fallback with a different risk profile, even though it produces larger signatures and is slower.

How These Differ From Classical Algorithms in Practice

For engineers who have to actually implement this, the differences aren't just theoretical:

• Key and signature sizes are larger. An ML-KEM public key is roughly 800–1,500 bytes depending on parameter set, versus a few hundred bytes for an equivalent ECC key. SLH-DSA signatures can run into the tens of kilobytes, versus roughly 64–100 bytes for an ECDSA signature.
• Performance characteristics differ by operation. Some post-quantum algorithms are faster than their classical counterparts for certain operations and slower for others — there's no single "PQC is slower" rule.
• Protocol assumptions about message size break. Systems that assume a TLS handshake, a certificate, or a signed token fits within a fixed packet size or byte budget may need rework, not just a drop-in library swap.
• Hybrid modes are the near-term default. Rather than replacing classical algorithms outright, most current deployments combine a classical algorithm (e.g., ECDH) with a post-quantum one (e.g., ML-KEM) in the same handshake, so the connection stays secure even if a flaw is later found in the new algorithm.

Why It Matters Now, Not Later

The instinct to defer this work is understandable — the quantum threat is uncertain in timing, the standards are still young, and there are more immediate fires to fight. But three separate pressures are converging that make "later" a worse bet than it sounds.

First, the harvest-now-decrypt-later problem described above means the migration clock started the moment the standards were finalized, not the moment quantum computers become practical. Every year of delay is another year of data encrypted with algorithms already known to have an expiration date.

Second, cryptographic migrations are slow by nature, independent of anything quantum-related. Replacing SSL with TLS, or migrating from SHA-1 to SHA-256, each took the better part of a decade across the industry once you count discovery, vendor support, protocol updates, certificate reissuance, and the long tail of legacy systems that can't be touched without breaking something else. Post-quantum migration touches more surface area than either of those — it affects key exchange, signatures, and certificate chains simultaneously, across every system that does TLS, code signing, VPN, or PKI.

Third, regulatory and procurement pressure is starting to move ahead of the technology risk itself. Government agencies and their supply chains, in particular, are being asked to inventory cryptographic assets and produce migration timelines well before any quantum computer is expected to exist. Contract requirements travel down supply chains — a prime contractor's PQC requirement becomes every subcontractor's problem — so the practical deadline for many organizations is procurement-driven, not threat-driven.

What Migration Actually Involves

A realistic post-quantum migration is closer to a multi-year infrastructure program than a library upgrade. It breaks down into stages that most guidance — NIST's, and that of national cybersecurity agencies that have published PQC roadmaps — converges on.

1. Cryptographic inventory. Before anything can be replaced, an organization needs to know where cryptography is actually used: which systems perform TLS termination, which use hardcoded certificates, which sign firmware or software updates, which embed cryptographic libraries in ways that are hard to update (IoT devices, industrial control systems, long-lived hardware). Most organizations discover this inventory is far larger and messier than expected — cryptography is embedded in places nobody remembers, from decade-old appliances to vendor SDKs.
2. Risk prioritization. Not everything needs to move at the same speed. Data with long confidentiality requirements, and systems that are hard to update after deployment (embedded devices, signed firmware that can't easily be re-signed), should be prioritized over short-lived, easily-patched systems.
3. Crypto agility as the real deliverable. The most valuable outcome of a well-run migration usually isn't "we adopted ML-KEM" — it's building systems where the cryptographic algorithm is a configuration choice, not something hardcoded and brittle. Organizations that abstract cryptographic operations behind clean interfaces can swap algorithms as standards evolve; organizations that hardcoded a specific algorithm deep into application logic will do this migration again, painfully, the next time something changes.
4. Vendor and dependency dialogue. Most organizations don't write their own TLS stacks — they depend on operating systems, cloud providers, browsers, and libraries to implement PQC support. Tracking which vendors have announced PQC support timelines, and pressuring the ones that haven't, is as much a part of migration as internal engineering work.
5. Hybrid deployment and testing. Rolling out hybrid classical/post-quantum handshakes in non-critical paths first, monitoring for compatibility issues (older clients, middleboxes that choke on larger packets), before widening the rollout.
6. Full cutover and certificate lifecycle updates. Eventually, certificate authorities, PKI infrastructure, and code-signing pipelines need to support post-quantum signature algorithms end to end — not just support them, but make them the default for anything being newly deployed.

A Rough Sequencing Guide

Practical Implications for Businesses and Builders

For most organizations, this isn't primarily a cryptography research problem — it's a systems inventory and change-management problem wearing a cryptography costume. A few practical implications follow from that framing:

• Start with visibility, not algorithms. An organization that doesn't know where its certificates, keys, and cryptographic dependencies live can't sequence a migration, no matter how good its understanding of lattice-based math is. Automated discovery tools that scan for TLS configurations, certificate expiry, and embedded key material are a better first investment than early PQC library adoption.
• Treat this as a budget line, not a side project. Migrations of this scope compete for engineering time against feature work indefinitely unless they're explicitly funded and staffed. Organizations that treated Y2K, SHA-1 deprecation, or TLS 1.0 sunsetting as side projects generally finished late and expensively.
• Favor systems and vendors that already support hybrid modes. When evaluating new infrastructure, cloud services, or libraries, whether they have a stated PQC roadmap is now a legitimate procurement question, in the same category as asking about SOC 2 compliance a decade ago.
• Don't wait for "the standard to settle." The core algorithms are finalized. Waiting for the standards to feel more mature is a reasonable-sounding excuse that mostly just consumes the lead time an organization needs to actually execute a multi-year migration.
• Long-lived hardware needs the earliest attention. Anything that ships once and can't easily be updated in the field — medical devices, industrial controllers, satellites, some IoT products — needs post-quantum consideration baked into design now, because it will still be in service when the migration deadline that matters (quantum arrival, not a regulatory date) becomes real.

Real Limitations and Open Questions

Post-quantum cryptography migration is not a solved problem dressed up as an open one. Several genuine uncertainties remain:

• The algorithms are newer and less battle-tested. RSA and ECC have been attacked by cryptographers for decades without a practical break emerging. Lattice-based cryptography has a shorter public scrutiny history, and some candidate algorithms from earlier rounds of the NIST process were broken during evaluation — a reminder that "finalized standard" means "best current understanding," not "mathematically guaranteed forever."
• Performance and size overhead is real, not hypothetical. Larger keys and signatures mean more bandwidth, more storage, and in some cases meaningfully different latency characteristics. Systems designed around tight assumptions — constrained embedded devices, high-frequency handshake scenarios — may need real engineering work, not just a library swap.
• Nobody knows exactly when the threat becomes real. Estimates for a cryptographically relevant quantum computer range from the early 2030s to "not within any confident forecast horizon." This uncertainty is often used to justify inaction, but it cuts both ways — nobody can prove it won't happen on a given data-sensitive organization's watch either.
• The long tail of legacy and embedded systems may never fully migrate. Some systems currently in the field — old medical devices, industrial equipment, certain IoT hardware — cannot be updated at all without physical replacement. For these, migration planning has to account for eventual decommissioning rather than in-place upgrade.
• Interoperability during the transition is genuinely messy. Hybrid handshakes, mixed fleets of updated and non-updated clients, and inconsistent vendor timelines mean the transition period itself introduces complexity and potential compatibility bugs that a fully-migrated or fully-classical world wouldn't have.

What to Watch Next

A few developments are worth tracking as this migration unfolds over the coming years:

1. Broader algorithm standardization. Additional signature schemes and parameter sets are still being evaluated and standardized, partly to diversify the mathematical assumptions the industry depends on.
2. Browser and OS default rollout. As major browsers, operating systems, and cloud providers move from optional to default hybrid post-quantum support in TLS, the practical floor of "what's protected without anyone doing anything" rises.
3. Regulatory deadlines with teeth. Government mandates for federal systems and critical infrastructure, and how aggressively those requirements propagate to contractors and vendors, will likely set the real-world pace more than any purely voluntary industry timeline.
4. Cryptographic agility tooling maturing. Expect more mainstream tooling for cryptographic inventory, automated certificate rotation, and algorithm-agnostic key management, since this migration will not be the last one — crypto agility as a design principle will keep paying off.
5. Quantum computing progress itself. Milestones in error correction and qubit count are the leading indicators for how much runway actually remains, and they're worth monitoring independent of the cryptography side of the story.

FAQ

What is post-quantum cryptography?

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks from both classical and quantum computers. Unlike current public-key algorithms such as RSA and ECC, which quantum computers running Shor's algorithm could theoretically break, PQC algorithms are built on mathematical problems — like structured lattices or hash functions — that don't have a known efficient quantum attack.

Why does post-quantum migration need to start before quantum computers exist?

Because of the "harvest now, decrypt later" threat: encrypted data captured today can be stored and decrypted retroactively once a capable quantum computer exists. Data that needs to stay confidential for years — health records, trade secrets, government data — is already exposed to this risk under current encryption, regardless of when the decrypting technology actually arrives.

What are the main NIST post-quantum cryptography standards?

NIST finalized three standards in August 2024: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber) for key exchange, FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium) for digital signatures, and FIPS 205 (SLH-DSA, based on SPHINCS+) as a hash-based signature alternative with different underlying assumptions than the lattice-based options.

What is a hybrid cryptographic approach and why is it used?

A hybrid approach combines a classical algorithm (like ECDH) with a post-quantum algorithm (like ML-KEM) in the same key exchange, so the connection remains secure even if a weakness is later discovered in the newer, less-tested post-quantum algorithm. Most near-term real-world deployments use hybrid modes rather than switching to post-quantum algorithms alone.

How long will post-quantum cryptography migration take?

Comparable past cryptographic transitions, such as the move away from SHA-1 or SSL, took roughly a decade industry-wide once legacy systems, vendor support, and certificate lifecycles are accounted for. Post-quantum migration is expected to take at least as long, and likely longer, because it affects key exchange, signatures, and certificate infrastructure simultaneously.

Which systems should be prioritized in a post-quantum migration?

Systems handling data with long confidentiality requirements (health, legal, government, genomic data) and systems that are difficult to update after deployment (embedded devices, signed firmware, industrial hardware) should generally be prioritized first, since they carry the highest risk from delay or the highest cost of a late, rushed retrofit.

Does upgrading to AES-256 solve the quantum threat?

Only partially, and only for symmetric encryption. Grover's algorithm gives quantum computers a quadratic speedup against symmetric key search, so doubling key length (AES-128 to AES-256) restores that security margin. It does nothing for public-key cryptography like RSA or ECC, which are vulnerable to a different, more severe quantum algorithm (Shor's) that requires migrating to entirely new algorithm families, not just larger keys.

Teams that need help mapping their cryptographic footprint and sequencing a realistic migration plan can find hands-on support at Woyce Technologies.