Most quantum-migration conversations frame the work as a destination: get off RSA, get onto ML-KEM and ML-DSA, declare victory. The DST report quietly rejects that framing. It lists crypto-agility as a guiding principle to be adopted in Milestone 1 — before migration — and as a capability to be institutionalised by the end. The destination is not an algorithm. The destination is the ability to change algorithms.
Why a one-time migration is the wrong goal
Consider what happens after a bank finishes migrating to today's post-quantum standards. The standards are new. Lattice-based schemes like ML-KEM and ML-DSA are well-studied but young in deployment terms. Cryptanalysis advances; the report itself notes AI may accelerate it. Parameters get revised; standards get superseded; a scheme can be weakened by a discovery no one anticipated. The history of cryptography is a history of algorithms that were once considered safe.
An institution that hardwired RSA into thousands of systems is now learning, expensively, what hardwiring costs. An institution that then hardwires ML-DSA has learned nothing — it has simply reset the clock to repeat the same crisis in fifteen years. The report's insistence on agility is the lesson that the migration is supposed to teach.
If replacing an algorithm requires rewriting the application, you don't have a cryptographic system. You have a cryptographic liability with a delay timer.
What crypto-agility actually is
Crypto-agility is an architectural property: cryptographic operations are accessed through an abstraction layer rather than called directly, so the specific algorithm is a configuration choice, not a structural assumption. In an agile system you can move a service from RSA to ML-KEM, or to a hybrid of both, without touching application logic. Concretely it means:
- No hardcoded algorithms. Cipher choices live in policy and configuration, not scattered through code.
- Negotiated, not assumed. Protocols carry the algorithm as a parameter, enabling hybrid modes and clean transitions.
- An authoritative inventory. You can answer "where do we use RSA?" instantly — which is just the CBOM from N° 03, kept alive.
- Tested swap paths. Sandbox environments where new primitives are trialled and re-deployed under control — the report calls for exactly this in its later milestones.
The hybrid era makes agility non-optional
The migration itself demands agility before it delivers it. The report's transitional model is hybrid — running classical and post-quantum algorithms together during the changeover. Hybrid is, by definition, the ability to operate more than one algorithm at once and shift the balance between them. A system that can't be configured to do that can't migrate the way the report prescribes. Agility isn't the reward at the end of the journey; it's the vehicle.
Building it in during migration, not after
Here is the practical opportunity. A bank is about to touch a vast number of cryptographic call-sites anyway, to move off quantum-vulnerable algorithms. That is the cheapest moment it will ever have to introduce abstraction — to replace "call RSA here" with "call the crypto layer here." Migrating to PQC without building agility means paying the full disruption cost for a one-time benefit. Migrating with agility means paying roughly the same cost for a permanent capability. The institutions that treat the quantum migration as an agility programme get vastly more for the same spend.
The governance dimension
Agility is not only technical. The report frames it alongside continuous cryptographic-lifecycle management: periodic review of algorithms, parameters and key lengths; a conformance register of vendor algorithm usage; incident-response playbooks for algorithm and parameter changes. In other words, agility is a standing function with an owner — a Quantum Lead or equivalent — not a project that closes. The organisations that institutionalise this will absorb the next cryptographic transition as routine maintenance rather than as another multi-year fire drill.
Phased migration is the category KavachQ's MIGRATE module addresses — sequencing and tracking the hybrid (classical + PQC) roll-out across an institution's specific systems. Because safe migration is deeply tied to each bank's architecture, this is built around a first reference deployment rather than offered generically; the agility principle here is methodological, applied jointly with the institution. The CBOM and plan from earlier modules are what keep the resulting inventory authoritative and the next swap cheap.
→ Migration is developed with the institution; the agility principle is the constant.