Most conversations about post-quantum migration are framed as a single decision: which algorithm do we move to. That framing is already out of date by the time the migration finishes.
NIST's first post-quantum standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) — became effective in August 2024. Seven months later, NIST added a fifth algorithm, HQC, specifically because it doesn’t want the entire post-quantum standard resting on one mathematical assumption.
A fourth signature scheme, FN-DSA, is still in draft. The standards this transition is built on are still being finalized while organizations are being told to start migrating to them.
That isn’t a flaw in the process. It’s the normal, permanent condition of cryptography: the algorithms in use today are never the last algorithms you’ll need. The organizations that handle this transition well won’t be the ones that pick the “right” algorithm, since there may not be a single right answer yet.
They’ll be the ones whose infrastructure can absorb the next change, and the one after that, without a multi-year re-architecture each time. That capability has a name: crypto-agility. It’s the actual deliverable of a quantum-safe migration, not a side effect of it.'
NIST defines cryptographic agility as follows:
|
NIST DEFINITION “The capabilities needed to replace and adapt cryptographic algorithms — in protocols, applications, software, hardware, firmware, and infrastructure — while preserving security and ongoing operations.” |
It doesn’t say “adopt post-quantum cryptography.” Crypto-agility is a property of how a system is built, independent of which specific algorithm it happens to be running this year.
In practice, most network security infrastructure was never built with this property in mind. Cryptographic algorithms are frequently hardcoded into firmware, burned into fixed-function ASICs, or wired so deeply into a protocol implementation that changing them means replacing the device, not updating it.
That was a reasonable engineering trade-off when algorithm transitions happened once a decade and everyone assumed the current one would last. It’s a liability now that the industry knows, with certainty, that at least one more transition is already scheduled and a second is philosophically guaranteed. Cryptography has never had a “final” algorithm, and post-quantum cryptography won’t be the first one that holds that title indefinitely.
Crypto-agility would matter even if quantum computers never materialized, because every major algorithm transition in the industry’s history has followed the same shape: a weakness is identified, standards bodies recommend migration, and organizations take years to actually complete it.
SHA-1 is the clearest recent example. Cryptanalytic weaknesses were identified in 2005. A full, enforced phase-out didn’t land across major platforms until roughly 2030 — a 25-year gap between “we know this is a problem” and “this is actually gone.”
Along the way, systems that couldn’t gracefully add SHA-2 support, including older Windows deployments without the right service pack, produced years of compatibility failures and emergency patching, not because SHA-2 was hard to implement, but because the infrastructure running SHA-1 had no clean path to run anything else alongside it.
DES gave way to 3DES and then AES on a similarly slow, disruptive timeline. RSA and Diffie-Hellman key lengths have been quietly stepped up every few years as computing power grew, each step requiring coordinated updates across certificate authorities, endpoints, and network infrastructure that didn’t all move at once.
None of these transitions were caused by quantum computing but by the ordinary progress of cryptanalysis and computing power. These are the same forces that will keep producing new transitions after post-quantum cryptography is old news.
The only thing quantum computing changes is the deadline, since it compresses a transition that would normally unfold over a comfortable decade into a much tighter, harvest-now-decrypt-later-driven window, which makes the cost of not having crypto-agility considerably higher this time than it was for SHA-1.
NIST’s own standardization process is, in effect, a live demonstration of why crypto-agility matters. ML-KEM is the primary recommendation today, but it’s a lattice-based scheme.
As a structurally independent backup, NIST then added HQC built on error-correcting codes to protect against the possibility that a future cryptanalytic advance weakens lattice-based mathematics generally.
If that happens, organizations that treated ML-KEM as a permanent, hardcoded choice will be doing an emergency migration in the middle of a migration they thought they’d already finished. Organizations with crypto-agile infrastructure will switch a configuration.
| Standard | Status as of September 2026 |
| FIPS 203 – ML-KEM | Finalized, effective August 2024 |
| FIPS 204 – ML-DSA | Finalized, effective August 2024 |
| FIPS 205 – SLH-DSA | Finalized, effective August 2024 |
| HQC (code-based backup KEM) | Selected March 2025; standardization in progress |
| FN-DSA / FALCON | Still draft; publication expected late 2026 or early 2027 |
The compliance timeline reflects the same uncertainty. NIST’s draft guidance (IR 8547 and the forthcoming SP 800-131A revision) points toward deprecating today’s classical public-key algorithms after 2030 and disallowing them after 2035.
These algorithms include RSA, ECDSA, ECDH, finite-field Diffie-Hellman, and NIST explicitly permits hybrid modes (classical plus post-quantum, run together) through and beyond that migration window.
This is a multi-year band in which the acceptable set of algorithms keeps narrowing. Regulators have started writing the capability to keep up with it directly into law rather than just naming a target algorithm.
DORA’s technical standards require EU financial entities to maintain a plan for updating cryptographic technology as cryptanalysis evolves, instead of one-time PQC deployment. CNSA 2.0 and the EU’s NIS2 framework carry the same underlying expectation of a managed, ongoing transition.
Applications and libraries have made real progress toward agility. TLS stacks increasingly support algorithm negotiation, and major cloud providers rolled out hybrid key exchange well ahead of most enterprise networks. The place agility most often breaks down is exactly where the harvest-now-decrypt-later risk concentrates: the network infrastructure carrying data between sites, data centers, and clouds.
Purpose-built encryption appliances have historically leaned on fixed-function hardware to hit wire-speed throughput. This is an entirely reasonable design choice when the algorithm running on that hardware was expected to stay fixed for its service life.
Now that design choice is a bottleneck. A hardware-bound crypto engine that needs a physical refresh to add a new algorithm turns every future standards update (e.g. HQC’s eventual finalization, FN-DSA’s, whatever comes after them) into a procurement cycle instead of a software update.
At the throughput data center interconnects and backbone links actually run (10, 40, 100 Gbps), that’s not a minor inconvenience. It’s the difference between adopting a new standard in weeks and adopting it years after it’s needed, on whatever schedule a hardware refresh happens to land on.
A network encryption layer that’s genuinely crypto-agile, rather than agile in name only, tends to have a specific, checkable set of properties:
That list is intentionally missing a specific algorithm name. An organization can even create their own algorithms if they so wish in a crypt-agile set up. It’s important to be able to handle the next algorithm change with a configuration update rather than with a new product cycle.
SSH’s NQX runs on a software-defined crypto engine specifically so that algorithm changes are a configuration update, instead of a hardware refresh. With the solution, classical, hybrid, and post-quantum key exchange can run concurrently across the network, link by link, at up to 100 Gbps.