What Is It?
Crypto-agility is the ability to update cryptographic algorithms, key sizes, and protocols within a system without requiring a full architectural redesign. A crypto-agile system can replace ECDSA with ML-DSA, or ECDH with ML-KEM, by changing configuration or a small amount of code not by rebuilding the system from the ground up.
NIST IR 8547 (draft) and NSA CNSA 2.0 both cite crypto-agility as a foundational requirement for post-quantum migration programs. The goal is to design systems that can evolve as standards mature and as future deprecation cycles occur.
Crypto-agility is an architectural property, not a product or feature. It must be designed in. Most existing enterprise systems are not crypto-agile: they hard-code algorithm choices in application logic, database configurations, certificate issuance workflows, and library dependencies.
Why Does It Matter?
Cryptographic algorithms have finite lifespans. RSA and ECDH are now being retired by quantum computers. But post-quantum algorithms will eventually be revised, deprecated, or replaced as cryptanalysis advances. Organizations that hard-code algorithm choices into their software, hardware, and protocols pay the full migration cost every time. Organizations with crypto-agile architectures pay a fraction of that cost.
CNSA 2.0 does not treat crypto-agility as optional: it requires it for all National Security Systems as part of the post-quantum migration. The current migration from classical to post-quantum algorithms is not a one-time event; it is the first in a series of necessary transitions that will recur throughout the lifetime of long-running enterprise systems.
Systems with 10-20 year lifetimes infrastructure, embedded devices, hardware security modules that are not designed for crypto-agility today will require costly full replacements in future migration cycles. The return on investing in crypto-agility now compounds across every future algorithm transition.
How It Works
Crypto-agility is achieved through architectural choices that decouple cryptographic algorithm selection from application logic.
Algorithm abstraction layers
Cryptographic operations are invoked through an abstraction layer (API, library interface, or HSM driver) rather than hard-coded directly in application code. The application requests "sign this message" or "establish a key" without specifying the algorithm the algorithm is configured externally.
Negotiable cipher suites
TLS 1.3 is a strong model: cipher suites are negotiated at handshake time and can be updated without application code changes. Crypto-agile systems use similar negotiation patterns throughout the stack.
Centralized key and policy management
Algorithm selection is driven by externally configurable policy rather than compiled constants. Key management systems that support algorithm-agnostic key derivation allow algorithm changes without re-keying everything simultaneously.
Vendor and library requirements
Crypto-agility extends into the supply chain. Purchasing criteria and vendor contracts should require crypto-agile implementations from software providers, hardware manufacturers, and cloud services.
Enterprise Impact
For most enterprises, crypto-agility is not a current property of their systems it is a design goal for the migration. Achieving it requires deliberate investment during the post-quantum transition.
Inventory first
You cannot make systems crypto-agile without knowing where cryptography is used. A CBOM is the prerequisite.
Refactoring priorities
High-value, long-lived systems should be refactored for crypto-agility before receiving new algorithms. Avoid migrating to ML-KEM in a hard-coded way that will require another full migration in 10 years.
CI/CD integration
Automated testing should verify that algorithm configuration changes do not break system behavior. Crypto-agility is only useful if it can be exercised safely.
Procurement criteria
New software, hardware, and cloud services should be evaluated on crypto-agility as a purchasing requirement. Legacy systems that cannot be made agile should have documented end-of-life plans.
NIST Guidance
Multiple NIST documents address crypto-agility requirements.
NIST IR 8547 (draft)
Explicitly covers crypto-agility as a requirement for post-quantum migration planning in federal systems.
NIST SP 800-131A rev. 2
Provides guidance on algorithm and key-size transitions, including deprecation timelines.
NSA CNSA 2.0
Requires all National Security Systems to implement crypto-agile designs as part of their PQC migration by 2033.