up:: Crypto-Agility
Crypto-Agility vs Migration
What is the difference between crypto-agility and migration?
Crypto-agility is a property a system has. Migration is work an organization does. They are not two routes to the same place, and one does not substitute for the other.
The question this page exists to answer is whether building agility lets an organization defer migrating. It does not. Federal guidance places the agility requirement inside the migration phases rather than ahead of them, so agility is something the migration delivers rather than a reason to postpone it.
The short version:
- Crypto-agility is the architectural property that lets a system change algorithms through configuration instead of a rebuild.
- Migration is the project that actually replaces quantum-vulnerable algorithms with post-quantum ones.
- OMB M-26-15 requires both, in the same phases. Phase 3 moves priority systems to post-quantum key establishment and makes all systems cryptographically agile. Phase 4 does signatures and keeps them agile.
- Agility changes the cost of a migration. It changes none of the dates.
- NIST gives agility its own publication, CSWP 39upd1, which is a sign of how load-bearing it is rather than a sign that it replaces anything.
What is crypto-agility?
The architectural property that lets a system change, upgrade or replace its cryptographic algorithms without a redesign or a code rewrite. An agile system treats the algorithm as a configuration decision rather than something welded into the application.
With it, replacing an algorithm is a central change that propagates. Without it, every application touching cryptography has to be found, opened and rewritten one at a time.
NIST defines it in a dedicated publication as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations”.
Source: NIST CSWP 39upd1, Considerations for Achieving Crypto Agility: Strategies and Practices, final 19 December 2025, updated 29 June 2026.
What is migration?
The project that inventories where cryptography lives, prioritizes what moves first, and replaces quantum-vulnerable algorithms with the post-quantum standards, on a schedule with dated milestones.
It starts with a cryptographic inventory, because the scope of the replacement is unknown without one, and it ends when the stated uses have actually changed.
Crypto-agility vs migration at a glance
| Dimension | Crypto-agility | Migration |
|---|---|---|
| What it is | A property of a system’s architecture | A project with scope, sequence and dates |
| You can have it | Before, during or after a migration | Only by doing it |
| What it changes | The cost and speed of every future algorithm change | The algorithms actually in use |
| Does it remove a deadline? | No | It is how the deadlines are met |
| Federal requirement? | Yes. OMB M-26-15 Phase 3 requires making all systems cryptographically agile, Phase 4 requires keeping them so | Yes. The same phases carry the algorithm replacement |
| Where it sits in the schedule | Inside the migration phases, 2028 to 2031 | Phases 1 to 5, running to 2035 |
| Governing document | NIST CSWP 39upd1 | OMB M-26-15, NIST IR 8547 and the FIPS standards |
| What it does for the next transition | Most of the value. The post-quantum migration is not the last one | Solves this transition |
| Failure mode | An agile system that never migrates is still quantum-vulnerable | A migrated system without agility pays full price again next time |
Sources: OMB M-26-15 phase table, Phases 3 and 4; Crypto-Agility and its NIST citation.
How do they actually differ?
Migration answers “are we vulnerable now.” Agility answers “how expensive is it to stop being vulnerable, this time and every time after.”
They fail in opposite directions, which is the clearest way to see that neither substitutes for the other.
A perfectly agile system that never migrates is still running quantum-vulnerable algorithms. Its configuration file can be changed in an afternoon, and until someone changes it, nothing about its exposure is different. Agility is potential energy.
A fully migrated system with no agility is safe today and expensive forever. It replaced its algorithms by opening and rewriting every application, and it will do that again for the next change, because nothing about how it fails to absorb change was fixed.
The regulatory placement settles the argument. M-26-15 does not list agility as a prerequisite phase before migration begins. It requires agility in Phase 3 (2028 to 2030) alongside moving priority systems to post-quantum key establishment, and again in Phase 4 (2031) alongside signature migration. Agility is something the migration is expected to produce as it goes.
Where do they agree?
Both depend on the same first step. Neither can be scoped without a cryptographic inventory, because you cannot make agile, or replace, what you have not found.
Both are federal requirements carried in the same directive and the same phases.
Both are architecture problems rather than cryptography problems. Neither requires a cryptographer to decide; both require someone who can see how systems are built.
And both stall on the same thing. The vendor-controlled portion of an estate resists agility and migration equally, because neither is the customer’s decision to make.
When does agility matter most?
Where the estate is large, distributed, and expected to outlive this transition. The post-quantum migration is not the last cryptographic change any organization will make, and agility is the part of this work that pays again.
It also matters most where the migration has not started, because agility assessed early is what makes the cost of everything downstream predictable.
When is migration the only answer?
Always, for the algorithms themselves. No amount of architectural flexibility replaces RSA with ML-KEM. Someone has to make the change, and the deadlines apply to whether it was made rather than to whether it could have been made easily.
Why do people confuse them?
Because agility is genuinely valuable, and that makes it an unusually comfortable thing to be working on.
An organization that has started an agility program can accurately report progress, real architectural improvement, and alignment with a named federal requirement. All of that is true and none of it moves the deadline.
The confusion becomes expensive when agility is offered as a reason to defer. “We are becoming crypto-agile, so we can migrate quickly when we need to” describes a system that is still quantum-vulnerable, on the same clock as everyone else, with the added risk that harvested traffic is already gone.
Agility is a lever on the migration rather than a gate in front of it.
Is one replacing the other?
Neither, and the direction of travel is toward requiring both explicitly. M-26-15 naming agility inside two separate phases is the clearest published statement of that, and NIST giving it a dedicated publication is the second.
Common misconceptions
“If we are agile we can wait.” Agility changes the cost of changing. Until the change is made, exposure is unchanged, and recorded traffic is already collected.
“Agility is a prerequisite phase.” Federal guidance places it inside the migration phases rather than ahead of them.
“Migrating makes us agile.” Only if the migration was done in a way that leaves the algorithm as a configuration decision. A migration executed by rewriting applications one at a time produces neither agility nor a repeatable process.
“Agility is a product.” It is an architectural property. Products can support it and none of them confer it on an estate.
“It only matters for post-quantum.” Its value is largest for every cryptographic change after this one.
Questions people ask
Should we do agility first or migrate first? Both are required in the same phases. Assessing agility early is what makes the migration’s cost predictable, and it is not a reason to delay the replacement work.
Does agility count toward compliance? It is a named requirement in M-26-15 Phases 3 and 4, and it does not satisfy the algorithm-replacement requirements in those same phases.
Can we buy crypto-agility? Products can support it. Whether an estate has it is a property of how that estate is built.
What does agility actually look like? Algorithms selected through configuration or a provider interface rather than hardcoded, with a central place to change them and a way to verify the change propagated.
Does agility help with harvested data? No. Data already recorded under classical cryptography is already collected. See Harvest Now Decrypt Later.
Is there a standard for it? NIST’s CSWP 39upd1 is the dedicated publication, final December 2025 and updated June 2026.
Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs. Work with Addie at lamarrlabs.com.