NIST recommends crypto agility — the ability to swap algorithms when one is broken. Most organizations interpret this as "use a library that supports multiple algorithms." That is not crypto agility. That is vendor lock-in with options.
Direct answer: Crypto agility means swapping a compromised algorithm in production without a system-wide outage. This is impossible when cryptography is embedded in databases, API gateways, authentication services, and backup systems independently. Real crypto agility requires a single attestation layer where algorithm selection is a configuration parameter, not a code change in 50 different systems.
The NIST definition: the ability to transition between cryptographic algorithms with minimal disruption to the systems that depend on them. In the post-quantum context, this means: if ML-DSA is broken by a new mathematical attack, you can switch to SLH-DSA without redeploying your infrastructure.
What this requires in practice:
The typical enterprise approach to crypto agility:
| System | Crypto Library | Algorithm Config | Update Mechanism |
|---|---|---|---|
| API Gateway | Vendor A | Config file | Rolling deploy |
| Database encryption | Vendor B | Compiled | Maintenance window |
| Authentication | Vendor C | Environment var | Service restart |
| Backup encryption | Vendor D | Policy setting | Re-encrypt all |
| Certificate authority | Vendor E | Profile selection | Re-issue all certs |
When ML-DSA is compromised on a Friday afternoon, you need to disable it across all five vendors, each with different configuration mechanisms, different update procedures, and different rollback strategies. This is not agility. This is coordinated chaos.
The fundamental problem: Crypto agility requires coordinated algorithm changes across all systems simultaneously. Modular vendors make this harder, not easier, because each vendor manages algorithm state independently. More vendors means more coordination points means slower response to a compromise.
Place cryptographic attestation at a single layer in your architecture. Every system produces data; the attestation layer signs it. Algorithm selection happens in one place. When an algorithm is compromised:
A well-designed attestation primitive includes a field that records which algorithm families are active. When verifying an attestation, the verifier checks which families were active at signing time and validates those signatures. If a family is later compromised, attestations that also include a non-compromised family remain valid.
This is not theoretical architecture. It is a concrete byte in a concrete data structure that determines verification behavior. Flip one bit, disable one family. The remaining families continue protecting everything.
| Property | Crypto Agility | Crypto Resilience |
|---|---|---|
| Definition | Swap algorithms when one breaks | Survive algorithm failure without swapping |
| Assumption | One algorithm active at a time | Multiple algorithms active simultaneously |
| Response time | Hours to days (deploy new algorithm) | Instant (disable broken, keep remaining) |
| Data in flight | Vulnerable between compromise and swap | Protected by remaining families |
Crypto agility is necessary but insufficient. You also need crypto resilience: the ability to survive algorithm failure without ANY configuration change, because the other families are already protecting the data. Multi-family signing provides this by default.
For an enterprise deploying crypto agility in production:
The crypto agility reality: If you need to coordinate algorithm changes across multiple vendors and systems, you don't have crypto agility. You have a plan to achieve crypto agility, and that plan has a response time measured in weeks, not minutes. Real agility requires one layer, one configuration point, and multiple families active simultaneously.
Read the Migration Guide →