Key Insights from NIST’s Latest Report on Crypto-Agility 

NIST’s crypto-agility guidance, finalized as CSWP 39upd1, “Considerations for Achieving Crypto Agility: Strategies and Practices,” defines the capabilities organizations need to replace cryptographic algorithms without rebuilding entire systems. It matters because post-quantum migration and shrinking certificate lifetimes both demand exactly that capability, and most organizations still don’t have it. Recommended action: use NIST’s Crypto Agility Maturity Model to assess your current systems honestly before committing to a migration timeline you can’t actually meet.

Published: April 2025. Updated: August 2026. Reviewed by Encryption Consulting’s PQC Advisory Team.

For the cryptographic inventory that crypto-agility assessments depend on, see How CBOM Differs from SBOM and Why It’s Crucial for Industry. For how crypto-agility fits into a broader federal control catalog, see Elevate Your Security with NIST 800-53. For the certificate-specific consequences of slow cryptographic transitions, see AWS Certificate Manager (ACM) – Best Practices.

What Is Crypto-Agility, According to NIST?

NIST defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures without interrupting a running system, in order to achieve resiliency. In simpler terms, it’s the ability to switch to a stronger algorithm when the current one becomes vulnerable, quickly and without rebuilding the surrounding system. NIST finalized its guidance on this topic as CSWP 39upd1, “Considerations for Achieving Crypto Agility: Strategies and Practices,” on December 19, 2025, with a further update published June 29, 2026, superseding the draft version many organizations have been planning against.

Why Do Cryptographic Transitions Take So Long?

Triple DES was meant to be a temporary patch for aging DES. Even after AES was standardized in 2001, Triple DES continued in use and wasn’t officially phased out until 2024, a 23-year transition for something intended as temporary. The reasons repeat across every slow transition: algorithms hardcoded directly into application source code instead of abstracted behind a crypto API, backward-compatibility requirements that keep weak algorithms like SHA-1 alive years past their recommended retirement, and resource or performance trade-offs that get worse, not better, as post-quantum algorithms with far larger keys and signatures enter the picture.

How Does Crypto-Agility Map to Controls, Owners, and Evidence?

Requirement	Layer	Control	Owner	Evidence artifact
Abstract cryptographic operations from application logic	Application	Crypto APIs (not hardcoded algorithm calls) for encryption, signing, and hashing	Application security / engineering	Code review confirming crypto API usage, not embedded algorithm calls
Support algorithm negotiation	Protocol	Clear, versioned algorithm identifiers (as TLS 1.3 cipher suites use) rather than reused or ambiguous names	Protocol / network engineering	Protocol configuration documentation, cipher suite inventory
Enforce crypto policy at runtime	Enterprise policy	A Cryptographic Service Provider (CSP) that enforces CISO-defined algorithm restrictions	CISO / security governance	Crypto policy document, CSP configuration and enforcement logs
Assess system-level maturity	Organization-wide	Formal assessment against NIST’s Crypto Agility Maturity Model (CAMM)	Security architecture / PQC advisory	CAMM assessment report per system, scored 0 through 4

What Is the Crypto Agility Maturity Model (CAMM)?

NIST’s CAMM defines five levels for assessing how ready a system actually is to change cryptographic algorithms: Level 0 (Not Possible), Level 1 (Possible), Level 2 (Prepared), Level 3 (Practiced), and Level 4 (Sophisticated). A system at Level 2 can replace individual cryptographic components without disrupting the rest of the system; most legacy systems assessed honestly land at Level 0 or 1. CAMM is primarily descriptive today rather than a certification, but it gives organizations a common vocabulary for describing crypto-agility gaps instead of treating the concept as binary.

What Are the Implementation Steps for Building Crypto-Agility?

1. Build a cryptographic inventory (a CBOM) so you know exactly where each algorithm, key, and certificate is used before assessing agility.
2. Assess each in-scope system against NIST’s Crypto Agility Maturity Model to establish an honest current-state baseline rather than an assumed one.
3. Replace hardcoded algorithm calls with crypto APIs at the application layer, prioritizing systems that scored Level 0 or 1.
4. Adopt clear, versioned algorithm identifiers in protocols so future negotiation and rollback don’t depend on ambiguous naming.
5. Enforce algorithm policy centrally through a Cryptographic Service Provider governed by CISO-defined rules, rather than leaving enforcement to individual application teams.
6. Treat crypto agility as a continuous governance function, re-assessing CAMM levels as new algorithms, standards, and threats emerge, not a one-time project.

What Changed When NIST Finalized This Guidance?

The guidance this content is based on moved from a draft (ipd) white paper open for public workshop feedback to a finalized publication, CSWP 39upd1, on December 19, 2025, with a further update on June 29, 2026. Organizations that read only the earlier draft should revisit the finalized text directly, since NIST white papers commonly incorporate workshop and public-comment feedback between draft and final release. The core concepts, the definition of crypto agility, the CAMM levels, and the emphasis on crypto APIs, carried through to the final version.

What Are the Limitations of Crypto-Agility Efforts?

• Crypto agility is more limited at the kernel and hardware layer than at the application layer, since supported algorithms are often fixed at build or manufacturing time.
• Supporting multiple algorithm options increases configuration complexity and the attack surface for downgrade attacks if negotiation isn’t itself protected.
• Cloud environments can constrain crypto agility through vendor lock-in on provider-specific cryptographic APIs and key management services.
• CAMM is currently descriptive, not a certification standard; a Level 2 or 3 self-assessment carries no independent verification unless an organization commissions one.

Audit-Ready Checklist for Crypto-Agility Readiness

1. A current cryptographic inventory (CBOM) covering algorithms, keys, and certificates in every in-scope system.
2. A documented CAMM assessment score for each in-scope system, not an assumed maturity level.
3. Crypto API abstraction confirmed through code review for systems scoring Level 0 or 1.
4. A centrally enforced cryptographic policy through a CSP, with CISO-approved algorithm restrictions documented.
5. A re-assessment cadence built into governance, not a one-time crypto-agility project marked complete.

How Can Encryption Consulting’s PQC Advisory Services Help?

Most organizations we assess have never formally scored their systems against NIST’s CAMM levels, which means their PQC migration plan is built on an assumed maturity that doesn’t match reality. Our PQC Advisory Services run that CAMM assessment against your actual environment, our CBOM Secure platform builds the cryptographic inventory the assessment depends on, and we provide project management estimates, internal training, and post-deployment validation once the migration is underway.

Frequently Asked Questions

Has NIST’s crypto-agility white paper been finalized?

Yes. It was finalized as CSWP 39upd1, “Considerations for Achieving Crypto Agility: Strategies and Practices,” on December 19, 2025, with a further update on June 29, 2026, superseding the earlier draft (ipd) version.

What is the Crypto Agility Maturity Model?

A five-level framework (0 through 4, Not Possible through Sophisticated) NIST defines for assessing how ready a specific system is to replace its cryptographic algorithms without disrupting operations.

Why did Triple DES take so long to retire?

It was hardcoded directly into many applications rather than accessed through a crypto API, so replacing it required rewriting and retesting the applications themselves, a 23-year process even after AES was standardized in 2001.

How much bigger are post-quantum signatures than classical ones?

An ML-DSA signature (FIPS 204) runs roughly 2,420 bytes, versus about 384 bytes for an RSA signature at the same 128-bit security level using a 3072-bit key, more than six times larger, which strains storage, processing, and network bandwidth.

Is crypto agility only relevant to post-quantum migration?

No. It’s a general capability that also matters for retiring weak algorithms like SHA-1, responding to new cryptanalysis, and meeting shrinking certificate validity requirements, independent of the post-quantum transition specifically.

Need a CAMM-based assessment of how crypto-agile your actual environment is before committing to a PQC migration timeline? Talk to Encryption Consulting’s PQC Advisory team.

References

NIST CSWP 39upd1, Considerations for Achieving Crypto Agility – csrc.nist.gov

Considerations for Achieving Crypto Agility: Strategies and Practices – nist.gov