The Crypto Agility Maturity Model: 5 Levels, and Where Most Teams Actually Sit

Ask a security team how long it would take to replace every use of RSA in their stack with a post-quantum algorithm, and you'll usually get a long pause before a guess. Not because nobody knows RSA is there. Because nobody's ever actually tried to swap it out at scale, and there's no map for how hard that would be. That gap, between knowing your cryptography and being able to change it fast, is what crypto agility measures.

Crypto agility is the ability to replace or update cryptographic algorithms, keys, and protocols across your systems without a multi-year rebuild. It's not a tool you buy. It's a capability you build, and like any capability, some organizations have more of it than others. This is a maturity model for figuring out where you actually stand, and what the next level looks like.

Crypto agility isn't the same thing as a CBOM, and mixing them up costs you time

These two get confused constantly, and it's an easy mistake to make since they're both about managing your cryptography. But they answer different questions, and one is a prerequisite for the other.

NIST draws this same line in its own July 2025 draft on the subject. Crypto agility, in NIST's words, refers to "the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations." Notice what's missing from that definition. An inventory. It's assumed. Agility is what you do once you already have one.

NIST says the maturity model for this doesn't fully exist yet

Here's the part that surprises people. There's no NIST-published crypto agility maturity model. Not an old one you missed. Not one buried in an appendix. NIST's second public draft of Considerations for Achieving Cryptographic Agility (CSWP 39, published July 2025) is explicit about this. The document says NIST "encourages ongoing dialogue among stakeholders to establish strategies, frameworks, requirements, and metrics tailored to specific sectors and environments. This will help inform a maturity model with key performance indicators."

That doesn't mean you're starting from nothing though. One real framework already exists. It's just not from NIST.

The one real maturity model that exists today: CAMM

CAMM (the Crypto-Agility Maturity Model) comes out of the UCS Research Group at Hochschule Darmstadt, a German university. Version 1.1 was published in September 2022. It defines five levels. Even if you never adopt the model wholesale, they're worth knowing, because they map cleanly onto real organizational states.

1. Level 0, Initial: the default state. At least one system violates the basic conditions for agility, usually meaning algorithms are hardcoded somewhere with no abstraction layer.
2. Level 1, Possible: the foundational conditions are met. Systems are theoretically capable of swapping cryptography, but nothing has been tested end to end.
3. Level 2, Prepared: agility measures exist, but preparatory work remains before you could actually execute a swap under pressure.
4. Level 3, Practiced: migration between cryptographic methods is demonstrably, effectively, and securely feasible. You've done it, not just planned for it.
5. Level 4, Sophisticated: advanced agility capabilities, applied consistently across your broader infrastructure, not just one system.

CAMM is rigorous. It's real academic work, not marketing. What it isn't is operational. There's no self-assessment questionnaire a security team can run through in an afternoon. There's no benchmark against peer organizations. No vendor has built tooling around it. It's a model you'd cite in a paper, not one you'd hand to your engineering team on a Monday.

Where most organizations actually sit

In practice, most teams land at Level 1 or the low end of Level 2 on a model like CAMM's, and it's worth being specific about what that looks like, because "we're pretty agile" is doing a lot of unearned work in most conversations.

• Level 0 signs: cryptographic algorithm names are hardcoded in application code with no configuration layer. Nobody can tell you every place RSA-2048 is used without a manual audit.
• Level 1 signs: you have a partial inventory (maybe a CBOM), you know roughly where your cryptography lives, but no system has ever had its cryptography swapped without a code change and a full regression cycle.
• Level 2 signs: some systems use crypto-agnostic libraries or configurable algorithm selection, but it's inconsistent across the estate, and a full swap would still take a dedicated project, not a deployment.
• Level 3 signs (rare): you've actually executed at least one algorithm migration end to end, on a live system, and documented what broke and what didn't.
• Level 4 signs (very rare): agility is a design requirement enforced at build time, not a retrofit, across your whole environment, not one flagship system.

Why the gap matters now, not in 2030

The algorithms you'll eventually need to migrate to already exist. NIST finalized FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme) on August 13, 2024. The math is done. What isn't done, for most organizations, is the operational muscle to actually deploy a new algorithm without a year-long project.

That's the entire point of measuring agility separately from inventory. You can have a perfect CBOM and still be months away from a real migration if every algorithm change requires touching application code, re-certifying a compliance boundary, and coordinating a dozen teams. Agility is what collapses that timeline.

A practical self-assessment, in the absence of a formal one

Until a vendor or standards body ships a real interactive assessment, here's a rough, honest way to place yourself using the CAMM levels above. Answer these in order and stop at the first one you can't confidently answer yes to.

1. Do you have a current, accurate inventory of every cryptographic algorithm, key, and protocol in use across your systems? (No: you're at Level 0. This is the CBOM step, and it comes first.)
2. Is that cryptography abstracted behind a configuration layer, or is it hardcoded into application logic? (Hardcoded: Level 0 to 1. Configurable in at least some systems: Level 1 to 2.)
3. Have you tested swapping an algorithm on a non-production system and measured what broke? (Never: Level 1 to 2. At least once: Level 2 to 3.)
4. Have you executed a real algorithm migration on a production system, end to end, with a documented rollback plan? (Level 3.)
5. Is agility a build-time requirement for new systems, enforced by policy, not left to individual teams? (Level 4, and genuinely rare.)

Most teams stop at question two or three. That's not a failure. It's an honest starting point, and it tells you exactly what the next investment should be: not another inventory tool, but a rehearsed migration.

The bottom line

Crypto agility and a cryptographic inventory get talked about as if they're the same project. They're not. The inventory tells you what you have. Agility tells you how fast you can act on it, and right now, there's no settled industry framework for measuring that, not from NIST, not from a vendor. CAMM is the closest real thing, and it's academic, not operational. Until that changes, the honest move is to run the five questions above against your own environment, be specific about where you actually land, and treat the gap between "we know our cryptography" and "we can change it in a weekend" as the real project.