Crypto-Agility Maturity Model
Score organizational capability to swap cryptographic algorithms (e.g., RSA → post-quantum) at scale.
Crypto-Agility Maturity Model
Score your organisation's capability to audit and migrate cryptographic algorithms.
Security Strategy: Crypto-agility is a requirement for post-quantum readiness (NIST SP 800-227). Mature organizations use service meshes (e.g. Istio) and HSMs to decouple cryptographic implementation from application logic.
Complete the self-assessment to generate your cryptographic roadmap.
Crypto-Agility Is Not the Same as Post-Quantum Migration
Post-quantum migration is a specific remediation effort — replacing RSA and ECDH with NIST FIPS 203 and 204 algorithms before the 2030 deprecation window. Crypto-agility is the organisational capability that makes that migration, and every future algorithm transition, possible without rebuilding systems from scratch. An organisation with high crypto-agility has a complete cryptographic inventory, has abstracted algorithm selection behind configurable interfaces rather than hardcoding primitives, maintains key management infrastructure that can rotate algorithms without application changes, tests algorithm swap operations as part of regular security assurance, and has governance processes that keep cryptographic policy current with emerging threats. An organisation with low crypto-agility may complete this specific PQC migration — but only by touching hundreds of individual codebases, negotiating with dozens of system owners, and rebuilding integrations that had cipher suites hardcoded into them. The cycle time and cost difference between high and low crypto-agility organisations becomes apparent every time NIST revises its algorithm recommendations. SHA-1 deprecation, MD5 retirement, and RC4 removal each required years of remediation effort in low-agility environments that took weeks in high-agility ones. The post-quantum transition is an order of magnitude larger than any of those. NIST SP 800-227 (initial public draft, 2024), titled Recommendations for Key Management, introduces crypto-agility as an explicit property that key management systems and cryptographic implementations should support, and frames it as distinct from but complementary to the PQC migration effort.
How the Five Dimensions Map to NIST SP 800-227 and CISA Guidance
The five dimensions this tool assesses correspond directly to the capability areas described in NIST SP 800-227 and CISA's Post-Quantum Cryptography Initiative guidance. Cryptographic Inventory — weighted at 20 percent — measures whether your organisation maintains a current, complete CBOM documenting all algorithms, keys, and certificates across your systems. Without inventory, no other capability has a stable foundation to operate against. Algorithm Abstraction — weighted at 20 percent — measures whether cryptographic algorithm selection is configurable rather than hardcoded. High abstraction means an application can switch from RSA to ML-KEM by changing a configuration file or policy parameter; low abstraction means every consuming application must be individually modified. Key Management System maturity — weighted at 25 percent, the highest single weighting — measures whether your KMS supports algorithm-agnostic key lifecycle management. A crypto-agile KMS can issue, rotate, and retire keys of different algorithm types under a unified policy framework. KMS receives the highest weight because it is the most common bottleneck: organisations that have completed algorithm abstraction in their applications still face multi-year delays when their HSM or KMS vendor does not support the target algorithm. Crypto-Agility Testing — weighted at 15 percent — measures whether algorithm swap operations are tested as part of security assurance, not just functional testing. Governance and Policy — weighted at 20 percent — measures whether cryptographic standards, deprecation timelines, and exception processes are documented, communicated, and enforced rather than ad hoc.
What Each Maturity Level Means and Where Most Organisations Start
Level 1 corresponds to ad hoc cryptographic management — no inventory, hardcoded algorithms, no KMS, no testing of algorithm transitions, and no documented policy. Cryptographic decisions are made by individual developers based on personal familiarity with libraries rather than organisational standards. Most organisations that have not initiated a formal cryptographic programme are at Level 1 or the lower boundary of Level 2. Level 2 indicates initial awareness — a partial CBOM exists, some systems use configurable cipher suites, KMS is present but not algorithm-agnostic, and there is a cryptographic policy document that may be out of date. Level 3 is defined — inventory is reasonably complete, abstraction is applied to new systems, KMS supports multi-algorithm operation, algorithm swap tests exist for critical paths, and policy is current and enforced. Level 3 represents the threshold at which an organisation can execute a structured PQC migration within a predictable timeframe rather than an open-ended engineering effort. Level 4 is managed — all five dimensions are systematically measured and improved, algorithm transitions are rehearsed through tabletop exercises, and KMS capabilities are verified against algorithm agility requirements as part of procurement. Level 5 is optimising — crypto-agility is embedded in the software development lifecycle, new systems are evaluated for algorithm agility as part of architecture review, and the organisation can execute algorithm migrations for internet-facing systems within weeks rather than months. Published CISA and NSA assessments suggest that most critical infrastructure operators are currently at Level 1 to 2, and that reaching Level 3 is the priority objective before the 2030 PQC deadline.
Frequently Asked Questions
Commonly Asked Questions
- What is NIST SP 800-227 and does it create compliance obligations?
- NIST SP 800-227, Recommendations for Key Management, is a NIST Special Publication that introduces crypto-agility as an explicit design property for key management systems and cryptographic implementations. As of mid-2026 it remains in draft form following its initial public draft release in 2024. NIST Special Publications are not legally binding for commercial organisations but are incorporated by reference into US federal security requirements through FISMA and FedRAMP, meaning federal contractors and cloud service providers seeking FedRAMP authorisation should treat SP 800-227 recommendations as effectively mandatory. For non-federal commercial organisations, SP 800-227 represents the authoritative technical benchmark against which insurance underwriters and enterprise procurement security questionnaires are beginning to assess cryptographic risk management maturity.
- What is algorithm abstraction and why does it have a 20 percent weighting?
- Algorithm abstraction is the practice of separating cryptographic algorithm selection from the code that uses cryptography. In a high-abstraction implementation, an application calls a cryptographic service interface that accepts a policy parameter specifying which algorithm to use — the application code itself does not contain algorithm names, key sizes, or cipher suite strings. In a low-abstraction implementation, algorithm choices are embedded as string literals or hardcoded constants throughout the codebase. Abstraction receives 20 percent weighting because it is the enabling condition for rapid migration: without abstraction, migrating from RSA-2048 to ML-KEM-768 requires finding and modifying every location in every application where RSA is referenced, which in a large codebase can number in the thousands. With abstraction, the same migration requires changing one configuration parameter.
- What does a crypto-agile KMS look like in practice?
- A crypto-agile KMS supports key lifecycle management — generation, storage, rotation, and retirement — for multiple algorithm types under a unified policy framework, without requiring separate infrastructure for each algorithm. Practically this means: the KMS can generate and store ML-KEM keys alongside RSA keys and issue them to applications via the same API; key policies reference algorithm families rather than specific algorithm names so that policy updates propagate automatically when the algorithm is changed; and the KMS exposes a negotiation capability so that clients can request the strongest algorithm both parties support rather than requiring both sides to be updated simultaneously. AWS KMS, Azure Key Vault, and HashiCorp Vault are in various stages of adding FIPS 203 key type support. Hardware Security Modules from Thales and Utimaco have announced roadmaps for post-quantum algorithm support. HSM vendor readiness is often the critical path item for KMS maturity improvement.
- What does crypto-agility testing look like in a security assurance programme?
- Crypto-agility testing verifies that an algorithm swap operation actually works end-to-end without application failures, performance regressions, or interoperability breaks. A basic test suite covers: changing the configured key exchange algorithm for a TLS service and verifying all clients successfully negotiate the new algorithm; rotating to a new signing algorithm for an internal CA and verifying that certificate chains validate correctly across all consuming services; and simulating an emergency algorithm deprecation by disabling a cipher suite and verifying that the system fails safely rather than silently downgrading to a weaker algorithm. Organisations at maturity Level 4 include these tests in their regular security regression suite and run them at least annually. Organisations at Level 5 run them as part of every infrastructure change pipeline that touches cryptographic configuration.
- How does the remediation roadmap from this tool relate to a formal PQC migration plan?
- The remediation roadmap this tool generates identifies which of the five dimensions are below the threshold for your current maturity level and recommends capability improvements in priority order. It is a capability gap analysis rather than a migration plan. A formal PQC migration plan — as described in NIST IR 8547 guidance — covers the specific systems, algorithms, timelines, and resource requirements for replacing quantum-vulnerable cryptography. The two documents are complementary: improving crypto-agility maturity is a precondition for executing the PQC migration efficiently, and the maturity model output tells you which capability gaps will create the most friction in executing the migration plan.
- What is the most common bottleneck that prevents organisations from reaching Level 3?
- The most consistently reported bottleneck across CISA sector assessments and NIST workshop feedback is KMS and HSM vendor readiness. Organisations that have invested in algorithm abstraction at the application layer and completed a CBOM inventory still cannot execute algorithm migrations when their hardware security modules do not support the target algorithm. HSM firmware updates for post-quantum algorithm support require vendor certification, regulatory approval for certain industries, and planned maintenance windows for production systems. The NIST PQC migration guidance explicitly identifies HSM readiness as a critical path dependency and recommends engaging HSM vendors for post-quantum roadmap commitments as an early programme action, before application-layer remediation begins.