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, and it's a textbook case of cyber resilience thinking: designing for a future failure rather than hoping to avoid it entirely. 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, which is exactly the kind of long-horizon confidentiality problem that broader privacy-enhancing technologies also try to solve. 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, following hybrid key-exchange schemes standardized through bodies like the IETF, 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 — including the public-key cryptography underpinning modern passkey-based authentication.

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.

Benefits of Starting Post-Quantum Cryptography Migration Now

Long-lived data stops accumulating risk

Every record encrypted with a vulnerable algorithm and captured in transit adds to the pool an adversary may decrypt later. Moving key exchange for sensitive traffic to hybrid post-quantum modes closes that window for new data. The earlier it happens, the smaller the archive of exposed material, which matters most for health, legal, financial, and government information with long confidentiality requirements.

Crypto agility pays off beyond quantum

Organisations that use this migration to put cryptography behind clean interfaces, with algorithms chosen by configuration, gain a capability they will use again. Algorithms get deprecated, libraries get vulnerabilities, and standards change. A crypto-agile system handles each of those as a planned change rather than an emergency rewrite, whether or not a quantum computer ever arrives. The investment is useful in every scenario.

A complete inventory improves security today

The first step of any migration, finding every certificate, key, library, and protocol in use, routinely uncovers expired certificates, weak configurations, forgotten services, and undocumented dependencies. Fixing those reduces present-day risk. The inventory also makes ordinary operations easier, from certificate renewals to incident response, because the team finally knows where cryptography lives. Many organisations find the inventory justifies its cost on these operational gains alone.

Time to handle the hard cases properly

Embedded devices, signed firmware, and long-lived hardware may need redesign or replacement. Starting early lets those changes ride normal refresh cycles and product roadmaps rather than forcing expensive emergency replacements. It also gives teams time to test larger keys and signatures against real network and storage constraints before they become mandatory. Rushed retrofits are where implementation mistakes creep in, and cryptographic mistakes are expensive to find and fix later.

Readiness for customer and regulatory demands

Government agencies, critical infrastructure operators, and large enterprises are already asking suppliers about cryptographic inventories and post-quantum roadmaps. Organisations with a credible plan can answer those questions in procurement rather than scrambling to produce one. Early movers can also influence vendor priorities while vendors are still deciding what to ship first. Being ready also avoids losing contracts to competitors who are.

Post-Quantum Cryptography Use Cases

Hybrid key exchange on the web

Major browsers, CDNs, and TLS libraries have begun supporting hybrid key exchange that pairs a classical algorithm with ML-KEM. The problem it addresses is harvest-now-decrypt-later capture of web traffic. Deployment happens largely in software the organisation already uses, so public-facing endpoints can often gain post-quantum key exchange by updating libraries and configuration. The outcome is protection for new sessions without changing certificates yet. Certificate and signature changes follow later, once PKI support matures.

Secure messaging

Some widely used messaging apps have added post-quantum key agreement to their encryption protocols, typically in hybrid form. Messages can contain sensitive personal and business information that people expect to stay private for years. Adding quantum-resistant key exchange to the protocol protects future conversations against later decryption, and it shows that PQC can run at consumer scale on ordinary phones.

VPNs and site-to-site links

VPN tunnels carry bulk traffic between offices, data centres, and cloud environments, making them attractive targets for capture. Vendors and open-source projects are adding hybrid post-quantum key exchange to VPN protocols. Organisations prioritise links that carry long-lived sensitive data, testing for compatibility with older endpoints and network equipment that may struggle with larger handshakes. Results feed back into the wider plan.

Code signing and firmware updates

Software and firmware signatures need to stay trustworthy for the whole life of a device. If a signing algorithm can be broken, an attacker could forge updates. Manufacturers of long-lived products are planning post-quantum or hybrid signature schemes for update pipelines and secure boot, often alongside hardware changes to handle larger signatures. The outcome is devices that can still verify genuine updates years after they ship.

Long-term archives and records

Healthcare providers, legal firms, and government bodies hold records that must stay confidential for decades. Re-encrypting stored data with strong symmetric keys and protecting key exchange and key management with post-quantum algorithms reduces long-term exposure. These organisations typically appear in the highest priority tier of migration plans. Their migration work often starts with an inventory of where archived data is stored and how its keys are protected.

What Post-Quantum Cryptography 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, in keeping with broader secure-by-design engineering principles. 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

Common Post-Quantum Cryptography Migration Mistakes

Waiting for a quantum timeline

Organisations often defer action until there is a confident date for a cryptographically relevant quantum computer. That date may never be clear in advance, and harvest-now-decrypt-later means exposure is already accumulating for long-lived data. Planning around the confidentiality lifetime of your data, rather than a forecast of quantum progress, gives a sounder starting point.

Starting with algorithms instead of inventory

Teams eager to try ML-KEM sometimes begin with a library experiment. Without knowing where cryptography is used across systems, vendors, and devices, those experiments don't add up to a migration plan. The inventory is slower and less exciting, but it determines everything that follows. It also reveals the vendor dependencies that will set the real pace of the programme.

Treating it as a library swap

Larger keys and signatures can break assumptions about packet sizes, certificate storage, handshake timing, and hardware limits. Assuming a drop-in replacement leads to failures in middleboxes, embedded devices, and protocols with tight byte budgets. Test in realistic environments before rolling out widely. Include older clients and network equipment in those tests, since they are where compatibility problems usually surface.

Dropping classical algorithms too early

The new algorithms have a shorter history of public scrutiny. Replacing classical cryptography entirely, rather than running hybrid modes, removes the safety net if a weakness in a post-quantum scheme is discovered. Hybrid deployment is the near-term default for good reason. It costs some extra bandwidth and computation, which is a modest price for keeping two independent layers of protection.

Hardcoding the new algorithm

Organisations that replace one hardcoded algorithm with another hardcoded algorithm will repeat the whole exercise next time standards shift. If the migration doesn't leave cryptography configurable and centrally managed, it has missed its most valuable outcome. Build the abstraction first, then switch algorithms through it.

Post-Quantum Cryptography Migration Best Practices

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 — the same discovery discipline that underpins broader cloud security posture management.
• 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, or increasingly, whether a workload needs confidential computing guarantees alongside encryption in transit.
• 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.
• Name an owner and track progress. Assign a single accountable owner for the programme, report inventory coverage and migration milestones to leadership regularly, and include post-quantum readiness questions in vendor reviews so progress doesn't stall between budget cycles.

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.

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

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. ML-KEM is the one most teams will meet first, because it protects key exchange in TLS and VPNs against harvest-now-decrypt-later attacks. The signature standards matter more for certificates, code signing, and firmware updates, where migration usually takes longer.

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. Public-facing TLS endpoints are often a quick early win, because major browsers, CDNs, and TLS libraries already support hybrid key exchange. Prioritization only works if you know where cryptography is used, so a cryptographic inventory comes first.

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.

Conclusion

Post-quantum cryptography migration is urgent for a reason that is easy to miss: the threat works backward in time. Data encrypted today with RSA, Diffie-Hellman, or elliptic-curve cryptography can be captured now and decrypted later, once a capable quantum computer exists. Anything that needs to stay confidential for years is already exposed.

The replacement standards are ready. NIST's ML-KEM, ML-DSA, and SLH-DSA give organizations approved algorithms to plan around, and hybrid key exchange lets them add quantum resistance without dropping classical protection. The real work is organizational: finding every place cryptography is used, prioritizing long-lived data and hard-to-update systems, working with vendors, and building crypto agility so algorithms can be changed again without a rewrite.

Be realistic about the limits. Nobody knows when a cryptographically relevant quantum computer will arrive, the new algorithms have larger keys and signatures that can affect performance, and past cryptographic transitions took about a decade. Starting late is the main risk, not starting with an imperfect plan.

The best first step is a cryptographic inventory of your systems, libraries, certificates, and vendors. If you need help mapping that footprint and planning the migration in your applications and infrastructure, talk to our backend infrastructure team.