Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. That definition is NIST's, from Cybersecurity White Paper 39, published 19 December 2025 and updated 29 June 2026. In practice, crypto agility means an algorithm can be changed by configuration and negotiation rather than by rewriting the systems that call it. It is the property that turns post-quantum migration from a rebuild into a rollout, and its absence is why organizations with hardcoded algorithms face replacing infrastructure to change a cipher.
The four mechanisms that make a system crypto agile
Crypto agility is not a single feature. Four mechanisms carry most of the weight, and a system missing any of them is agile only on paper.
Algorithm negotiation lets two endpoints agree on which algorithm to use at run time rather than at build time. NIST CSWP 39 describes negotiation using either cipher suite identifiers, which name a bundle, or individual algorithm identifiers, which name each primitive. Negotiation works only when both sides implement more than one option, which is why the paper treats mandatory-to-implement algorithms as an agility requirement: without a guaranteed common option, negotiation fails to a downgrade or to no connection.
Key wrapping indirection separates the key that protects data from the algorithm that protects that key. A data encryption key encrypts the payload; a separate key encapsulation mechanism wraps that data key. Changing the encapsulation algorithm means rewrapping keys, not re-encrypting data. This is the mechanism that makes migration tractable at scale, because rewrapping touches key material measured in bytes while re-encryption touches the entire data estate.
Cryptographic inventory is the record of which algorithms, key sizes, certificates, libraries and protocol versions are in use, in which systems, under which owners. Agility without inventory is untestable, because no one can say what would break, and inventory is where a migration is scoped.
Protocol and format versioning provides a place to put the new algorithm identifier. A protocol or file format with a version field and an algorithm identifier can carry a new primitive without ambiguity. A format that assumed a single algorithm forever has nowhere to record the change, and every reader must be updated in lockstep with every writer.
CSWP 39 adds mechanisms that sit alongside these: cryptographic APIs that abstract implementations away from applications, hybrid constructions combining a traditional and a post-quantum algorithm during transition, key expiration and revocation to retire algorithms on a schedule, and cryptographic policy enforced through configuration management.
The post-quantum standards crypto agility now has to accommodate
NIST issued the first three post-quantum standards on 13 August 2024. Their existence is what converted crypto agility from a design principle into a delivery deadline.
| Standard | Algorithm | Function | Parameter sets |
|---|---|---|---|
| FIPS 203 | ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) | Key establishment | ML-KEM-512, ML-KEM-768, ML-KEM-1024 |
| FIPS 204 | ML-DSA (Module-Lattice-Based Digital Signature Algorithm) | Digital signature | ML-DSA-44, ML-DSA-65, ML-DSA-87 |
| FIPS 205 | SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) | Digital signature | Multiple parameter sets across SHA2 and SHAKE variants |
Two properties of these standards matter for agility specifically. The key sizes and signature sizes are substantially larger than the elliptic curve equivalents they replace, so systems with fixed-size fields, fixed record layouts or tight packet budgets fail on size before they fail on algorithm support. And post-quantum key establishment is a key encapsulation mechanism rather than a key agreement, which is a different interface shape from the Diffie-Hellman pattern many protocols were built around.
CNSA 2.0 parameter sets and what agility means under them
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) removes parameter choice for national security systems. It requires the highest parameter set of each algorithm: ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures, at all classification levels. It also specifies LMS and XMSS for software and firmware signing, AES-256 for symmetric encryption, and SHA-384 or SHA-512 for hashing.
CNSA 2.0 excludes options that appear in the NIST standards. SLH-DSA is not part of the suite, and neither are multi-tree hash-based signature variants. Implementations built against draft algorithm versions do not satisfy the requirement; only implementations conforming to the final FIPS standards do.
Agility means something specific under CNSA 2.0: not the freedom to choose a parameter set, but the ability to reach the mandated one without redesign. NSA's published timeline sets 1 January 2027 as the point at which new national security system acquisitions must support CNSA 2.0, with exclusive use required across categories through 2030 and 2033 depending on equipment class. An organization whose products cannot change parameter sets by configuration is redesigning against that date rather than shipping against it. The exclusivity of the mandated parameter sets is examined in CNSA 2.0: ML-KEM-1024 and ML-DSA-87 Exclusive Clarification.
NIST IR 8547 and the migration timeline
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, sets the schedule for retiring quantum-vulnerable algorithms in federal use. It was released as an initial public draft on 12 November 2024, with the public comment period closing 10 January 2025.
| Algorithm class | 112-bit security strength | 128-bit security strength and above |
|---|---|---|
| RSA, ECDSA, EdDSA digital signatures | Deprecated after 2030, disallowed after 2035 | Disallowed after 2035 |
| Finite field and elliptic curve Diffie-Hellman and MQV key establishment | Deprecated after 2030, disallowed after 2035 | Disallowed after 2035 |
| RSA key establishment | Deprecated after 2030, disallowed after 2035 | Disallowed after 2035 |
Deprecated means the algorithm may still be used with recognized risk. Disallowed means it may no longer be used for federal protection of information. The distinction sets up the practical planning question: an organization has to know, per system, whether it lands in the deprecation window or must be finished before it. Current status of that migration is tracked in NIST IR 8547 and the Mid-2026 PQC Migration Status.
The timeline is also why harvest-now-decrypt-later matters more than the dates suggest. Data encrypted today under a quantum-vulnerable key establishment and captured today remains readable at whatever future point the capture is decrypted, regardless of when the standard is disallowed.
Crypto agility at the data layer
Most crypto agility discussion is about protocols in motion: which cipher suite a session negotiates, which certificate a server presents. Data at rest has a different problem, because objects outlive the systems that wrote them and a stored object cannot renegotiate with anything.
Key wrapping indirection is what supplies agility for stored objects. When the payload is encrypted under a data encryption key, and that data key is wrapped by a separate key encapsulation mechanism, the encapsulation algorithm becomes a property of the wrap rather than of the object's content. Migrating from a classical wrap to post-quantum key encapsulation means unwrapping and rewrapping the data key. The ciphertext of the object does not change, the object identifier does not change, and no application that reads the object is modified.
Two consequences follow. Migration cost scales with the number of keys rather than the volume of data. And a mixed estate is a normal state rather than a failure: objects wrapped under different algorithms coexist as long as each object records which algorithm wrapped it, which is what format versioning provides. Key custody choices that determine how rewrapping is executed are covered in Key Management for Data-Centric Security.
What crypto agility is not
Crypto agility is not post-quantum readiness. A system can negotiate algorithms cleanly and still support only classical ones. Agility is the mechanism that makes the change cheap; it does not make the change.
Crypto agility is not protection for data already captured. Rewrapping a key protects future access to the stored object. Ciphertext an adversary already holds, encrypted under a quantum-vulnerable key establishment, is unaffected by any later change to the algorithm the organization uses.
Crypto agility is not free. Negotiation adds attack surface, because a negotiation is a place where an adversary attempts a downgrade. Multiple supported algorithms mean more code, more validation and more configuration to get wrong. CSWP 39 explicitly treats complexity as a tradeoff to be managed rather than an unqualified good.
Crypto agility does not eliminate hardware constraints. Devices with fixed cryptographic accelerators, constrained memory, or signed firmware that assumes a signature size cannot be made agile by software policy. For those systems the migration path is replacement, and the honest planning answer is a replacement schedule. Algorithms embedded in third-party appliances and firmware are similarly outside an organization's own schedule, which converts them into supply chain dependencies.
Frequently asked questions
What is crypto agility and why does it matter for post-quantum migration?
Crypto agility is the capability to replace cryptographic algorithms in running systems without rewriting the applications that depend on them, as defined in NIST CSWP 39. It matters for post-quantum migration because the migration is not a single event: standards, parameter sets and guidance continue to change, and an organization that can change algorithms by configuration absorbs each change as a rollout instead of a redesign.
How do you implement post-quantum cryptography without replacing infrastructure?
Replace the algorithm at the indirection layers rather than in the applications. Use key wrapping so a data key is rewrapped under post-quantum key encapsulation without re-encrypting stored data. Use algorithm negotiation so protocol endpoints agree at run time. Use libraries and cryptographic APIs that abstract the primitive from the caller. Infrastructure that must actually be replaced is generally hardware with fixed accelerators or size assumptions.
What are FIPS 203, 204 and 205?
FIPS 203, 204 and 205 are the post-quantum cryptographic standards NIST issued on 13 August 2024. FIPS 203 specifies ML-KEM for key encapsulation, with parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024. FIPS 204 specifies ML-DSA for digital signatures, with ML-DSA-44, ML-DSA-65 and ML-DSA-87. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme with several parameter sets.
When do RSA and elliptic curve cryptography stop being allowed?
NIST IR 8547, released as an initial public draft on 12 November 2024, states that RSA, ECDSA, EdDSA and classical Diffie-Hellman key establishment at 112-bit security strength are deprecated after 2030 and disallowed after 2035, with 128-bit and higher variants disallowed after 2035. Deprecated means usable with recognized risk. Disallowed means no longer permitted for federal protection of information.
Which parameter sets does CNSA 2.0 require?
CNSA 2.0 requires ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures at all classification levels, with no lower parameter sets permitted. It also specifies LMS and XMSS for software and firmware signing, AES-256 for symmetric encryption, and SHA-384 or SHA-512 for hashing. SLH-DSA and multi-tree hash-based signature variants are not part of the suite.
How Lattix implements crypto agility at the object
Lattix places agility at the data object. Each protected object carries an identifier for the key encapsulation that wraps its data key, so the wrapping algorithm can change without rewriting applications that read the object and without re-encrypting the payload. Post-quantum key encapsulation using ML-KEM-768 and ML-KEM-1024 is supported, which covers both general enterprise use and the CNSA 2.0 parameter set required for national security systems. Because the access policy and the key binding are properties of the object rather than of the storage system, an estate can hold objects wrapped under different algorithms at the same time and migrate on a schedule rather than in a cutover. The Lattix policy enforcement point acts at decrypt time, so the authorization decision and the cryptographic change stay independent: rewrapping an object changes nothing about who may open it, and revoking access changes nothing about how it is wrapped. How that decision is produced is described in What Is a Policy Decision Point.