The answer, up front
Crypto agility is no longer optional because the algorithms mandated right now are not the destination, they are the current waypoint. Organizations that treat post-quantum migration as a single, bounded project, swap RSA for ML-KEM, swap ECDSA for ML-DSA, close the ticket, are building the exact same brittleness they are trying to migrate away from. The infrastructure question that actually matters is not "which algorithm do we move to." It is "how expensive is the next move."
Why "migrate once" thinking fails
The post-quantum standards published by NIST in 2024, FIPS 203, 204, and 205, are the result of a multi-year public competition, and they are good. They are also not guaranteed to be final. Lattice-based cryptography, the mathematical foundation under ML-KEM and ML-DSA, is younger and less battle-tested than RSA and elliptic curves ever were before they shipped. Research into lattice cryptanalysis is active and well-funded precisely because these algorithms are now load-bearing for the entire internet. A parameter revision, a new attack that forces a larger key size, or an entirely new algorithm family entering the standard, all of these are plausible within the working life of the systems under migration today.
That means the actual requirement is not "support ML-KEM." It is "support whatever the standard says next, without another multi-year program."
What crypto agile infrastructure actually requires
Crypto agility is not a feature you buy. It is a property of how your systems wire in cryptography. Four things make the difference between infrastructure that can absorb the next algorithm change and infrastructure that needs another emergency program:
- Abstracted cryptographic interfaces. Applications call a key-exchange or signing interface, not a specific algorithm. The algorithm is a configuration value, not a line of application code.
- Centralized key and certificate management. If every service manages its own keys and pins its own certificate authority behavior, no central policy change can propagate. Rotation and algorithm swaps have to happen one service at a time, by hand.
- Continuous inventory, not a one-time scan. A cryptographic inventory taken once during a migration project goes stale the day new code ships. Crypto agility depends on knowing, at any point, what algorithm is running where, which means discovery has to be continuous.
- A tested rollback and rollout path. Hybrid classical and post-quantum deployment, staged rollout, and a validated rollback plan are what let an organization move an algorithm on a schedule it controls, rather than reacting to a deprecation deadline under pressure.
Miss any one of these and the organization has completed a migration, not built agility. The next mandated change becomes exactly as disruptive as this one.
The cost of bolting it on later
The pattern is familiar from every other infrastructure discipline: retrofitting a capability is always more expensive than building it in from the start. A system with hardcoded algorithm choices scattered across dozens of services does not become agile by finishing the current RSA-to-ML-KEM swap faster. It becomes agile when the interfaces, inventory, and rollout tooling exist as standing infrastructure, so the next change is a configuration update instead of a program.
Regulatory timelines make the cost of deferring this concrete. NIST's draft IR 8547 proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit strength after 2030 and disallowing all quantum-vulnerable algorithms after 2035. Federal Executive Order 14412 extends that pressure down federal supply chains. Both dates assume organizations will use this window to build lasting infrastructure, not just to clear a single compliance line item.
What this means in practice
Treat the current post-quantum migration as the first exercise of a capability you are going to use again, not a one-time deliverable. That reframing changes what "done" looks like: done is not "we deployed ML-KEM." Done is "we can deploy the next algorithm the standard requires without opening a new program."
QuTrust is built around that reframing: a living roadmap and continuous crypto agility loop, not a one-time migration checklist, so the infrastructure you build for this deadline is still working the next time the standard moves.