Crypto agility explained: NIST's definition, a ready-to-adapt crypto agility policy, what a crypto agility platform must do, KPIs and a 5-level maturity model.
Crypto agility (cryptographic agility) is an organization's ability to replace and adapt the cryptographic algorithms, keys and parameters in its protocols, applications, hardware and infrastructure without breaking security or interrupting operations. In practice it means you know where every algorithm is used, applications ask for cryptography by policy rather than hard-coding it, and changing an algorithm across the estate is a planned, measured change, not a multi-year rewrite.
The business problem: every organization has to replace RSA and elliptic-curve cryptography with post-quantum algorithms, and NIST's draft transition plan puts a 2035 end date on the quantum-vulnerable ones. Touching thousands of applications, certificates and devices by hand won't get there in time. Switching algorithms by changing a policy will.
This guide gives the NIST definition, the five building blocks, and three working tools: a crypto agility policy outline with example rules, a platform capability checklist, and KPIs with a five-level maturity model.
The reference definition comes from NIST. Its Cybersecurity White Paper 39, Considerations for Achieving Crypto Agility: Strategies and Practices, was first published as final on 19 December 2025. The current version, CSWP 39 upd1, includes updates as of 29 June 2026 and supersedes the December 2025 release. (The March 2025 draft was titled Considerations for Achieving Cryptographic Agility, which is why both spellings circulate.) Its abstract opens:
"Cryptographic (crypto) agility 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."
Note the plural "capabilities": crypto agility spans inventory, architecture, process and tooling, not one product. "Replace and adapt" covers both swapping RSA for ML-DSA and changing parameters or hybrid combinations. And a change that needs an outage, or leaves a downgrade path open, doesn't meet "preserving security and ongoing operations".
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, was published as an initial public draft on 12 November 2024 and is still marked as a draft on csrc.nist.gov. Its proposed timeline for quantum-vulnerable digital signatures (RSA, ECDSA, EdDSA) and key establishment (finite-field and elliptic-curve Diffie-Hellman and MQV, RSA):
| Security strength | Proposed status |
|---|---|
| 112 bits (e.g. RSA-2048) | Deprecated after 2030, disallowed after 2035 |
| 128 bits and above (e.g. ECDSA P-256, RSA-3072) | Disallowed after 2035 |
The draft aligns with National Security Memorandum 10, which sets 2035 as the primary target year. Treat the dates as a planning baseline, not as final. Either way, nine years is short when algorithms are compiled into applications and burned into device firmware.
Data encrypted today with RSA or ECDH key exchange can also be recorded now and decrypted later: see store now, decrypt later.
PQC implementations will get patches, parameters may move, and hybrid combinations will eventually give way to PQC-only. Crypto agility is what turns the next change into a routine instead of a crisis.
Regulators ask for governed, reviewable cryptography rather than a specific algorithm:
The common thread: an auditor will ask how you know what cryptography you run, who decides what's allowed, and how fast you can change it. Those three questions are crypto agility.
You can't replace what you can't find. The inventory records each certificate, key, algorithm, library and endpoint, its owner and the data it protects; in machine-readable form it's a cryptography bill of materials (see our CBOM guide). It has to be refreshed continuously, not built once.
The architectural core. If an application calls RSA_sign() directly, every algorithm change means a code change, rebuild and redeploy. If it asks a service to "sign this customer record" and the algorithm comes from central policy, the change happens in one place. The abstraction can be a crypto service API, a KMS or HSM interface (PKCS#11, KMIP), a TLS gateway, or a CA that issues the new algorithm on renewal.
A written, versioned policy states which algorithms are approved for which data classes and purposes, what the hybrid posture is, what triggers a deprecation and how fast keys must rotate. The policy is what an auditor reads. In an agile estate, it's also what the abstraction layer executes.
Certificate issuance and renewal (ACME, EST, SCEP, CMP), key rotation, deployment and remediation tickets must run without manual steps. Manual work doesn't scale to a migration.
Larger post-quantum keys, clients that don't understand ML-DSA and middleboxes that drop large handshakes all break things. Simulation, staged rollout and rollback are part of agility, not an extra.
A crypto agility policy is the governance document that defines which cryptography is allowed, who owns it, and how and how fast it changes. Use the outline below as a starting point. The example rules are illustrative; set the values to match your risk appetite, your regulators and your vendors' support.
| Section | Example rule (adapt values to your context) |
|---|---|
| Approved algorithms | New signatures use ML-DSA-65 or a hybrid ML-DSA-65 + ECDSA P-256 composite; new key establishment uses ML-KEM in a hybrid with a classical group where the protocol supports it; symmetric encryption uses AES-256. |
| Hybrid posture | Data with confidentiality needs beyond 2035 (customer PII, long-term contracts) defaults to hybrid; internal systems where you control both ends may move to pqc_only; legacy interfaces stay classical only under a recorded exception. |
| Prohibited | No new RSA or ECC keys below 112-bit security strength; no SHA-1 signatures; no 3DES or RC4. |
| Deprecation triggers | Deprecation starts when NIST, BSI or a national authority deprecates an algorithm, a practical attack is published, or vendor support ends; a sunset date follows within 30 days and new use stops immediately. |
| Rotation SLAs | TLS certificates renewed automatically before expiry; data-encryption keys rotated at least yearly; a key suspected of compromise is revoked and replaced within 24 hours. |
| Ownership | Every key and certificate has a named owner and an associated application in the inventory; assets without an owner are flagged within 7 days. |
| Abstraction | New applications must request cryptography through the approved crypto service or KMS interface; direct use of an algorithm in code requires an exception. |
| Exceptions and review | Exceptions last at most 12 months, are approved by the crypto review board and recorded in the inventory; the policy is reviewed yearly and on every deprecation trigger. |
A crypto agility platform turns the policy into running controls: it finds cryptography, decides what's allowed, enforces it through an abstraction layer and proves it to auditors. Evaluate capabilities, not labels.
| Capability | What to check | Why it matters |
|---|---|---|
| Discovery | Certificates, keys and keystores on hosts; cloud KMS inventories; TLS endpoints; algorithm and key size detection | An inventory you don't have to build by hand |
| Risk scoring | Per-asset quantum and classical risk; an aggregate readiness score | Lets you prioritize instead of migrating everything at once |
| Central policy | Algorithms resolved from a policy by data class and purpose, with versioning | One place to change; one document to audit |
| PQC and hybrid support | ML-KEM, ML-DSA, SLH-DSA, hybrid composites; classical, hybrid and PQC-only postures | The algorithm change you are actually preparing for |
| Abstraction for applications | API or SDK where code declares intent rather than an algorithm | Algorithm changes without code changes |
| Backend independence | PKCS#11 and KMIP; HSMs, cloud KMS, open-source vaults | Avoids replacing one lock-in with another |
| Certificate automation | ACME, EST, SCEP, CMP; PQC and hybrid CAs; deployment connectors | Most algorithm changes reach servers through certificates |
| Simulation | "What breaks if we change this policy?" before rollout | Preserves ongoing operations, as NIST's definition requires |
| Remediation workflow | Tickets or pull requests to owners; ITSM integration; human approval | Turns findings into changes |
| Audit trail | Tamper-evident log of policy changes and key operations | Shows what changed, when and who approved it |
A demo that only covers discovery shows an inventory tool; one that only covers key storage shows a KMS. A crypto agility platform closes the loop from discovery to an enforced change.
The KPIs below are recommended metrics for your own programme, not benchmarks. Take a baseline now and track the trend quarterly.
| KPI | Definition | How to measure | Direction |
|---|---|---|---|
| Time to replace an algorithm across the estate | Elapsed time from a deprecation decision to the last production use removed | Run a drill on one algorithm or one data class and record start and end dates | Lower is better; this is the headline metric |
| % of assets inventoried | Discovered cryptographic assets with full inventory records / estimated total | Compare discovery coverage (hosts, cloud accounts, endpoints) with the CMDB | Higher; aim for full coverage of production |
| % of keys and certificates with an owner | Assets with a named owner and application / all inventoried assets | Inventory query | Higher; orphaned keys block migration |
| % of services behind an abstraction layer | Services that get algorithms from policy (crypto API, KMS, gateway) / all services using cryptography | Architecture review and code scanning | Higher; the leading indicator of future speed |
| Mean time to rotate | Average time to rotate a key or reissue a certificate once a rotation is required | Ticket or automation timestamps | Lower |
The first KPI answers the board's question: "if we had to replace this algorithm tomorrow, how long would it take?" The others are levers on that number.
Use it to set a current and target level per business unit; most organizations are uneven, such as level 3 for TLS certificates and level 1 for application signing.
| Level | Name | Inventory | Architecture | Policy and governance | Change capability |
|---|---|---|---|---|---|
| 1 | Ad hoc | None, or partial spreadsheets | Algorithms hard-coded in applications and devices | No cryptography policy, or one that's out of date | Algorithm changes are bespoke projects measured in years |
| 2 | Aware | One-off discovery scan; known gaps | Some certificates automated; most code still hard-coded | Written policy listing approved algorithms | Changes are planned per system; owners often unknown |
| 3 | Defined | Continuous discovery; CBOM for critical systems | New applications use a crypto service or KMS; ACME/EST for certificates | Policy with deprecation triggers, rotation SLAs and an exception process | Migration roadmap with dates; KPIs baselined |
| 4 | Managed | CBOM for the whole estate, with owners and data classes | Most services behind abstraction; PQC and hybrid available in production | Policy enforced by tooling; regulatory mapping; regular reviews | Policy changes simulated and rolled out in stages; time to replace measured |
| 5 | Agile | Real-time inventory with drift alerts | Algorithms resolved at runtime from policy; backend independent | Policy as code, versioned and audited | An algorithm switch is a reviewed policy change with no code change; remediation is automated with human approval |
Moving from level 2 to 3 is mostly about process and inventory. Moving from 3 to 5 is mostly about architecture: getting algorithms out of application code.
DuoKey's approach maps onto the building blocks above. The facts below come from DuoKey's product documentation.
DuoKey's cryptographic posture management runs a continuous loop: discover → score → simulate → remediate. Discovery covers certificate and key files, keystores (including the Windows certificate store and TPM), AWS, Azure and Google Cloud KMS inventories, TLS domains and Cockpit-managed vaults. Findings get a P1-P4 risk score, each scan a Quantum Readiness Score (0-100), and the output is a living CBOM with drift alerts. Simulation reports show the effect of a change before it's made; remediation pull requests are drafted by an agent and approved by a human, with ServiceNow sync and mapping to DORA, NIS2, FINMA 05/2026, NIST IR 8547 and CNSA 2.0. The free Quantum Readiness Score is a starting point that needs no access to internal systems.
The Crypto Agility Plane (CAP) is DuoKey's abstraction layer. Developers declare what they protect and why, for example a PII data class with a sign purpose, not which algorithm to use. A central tenant policy resolves the algorithm, the post-quantum posture, the key reference and the backend at runtime:
| Developer declares | Policy posture | Resolved algorithm (example) |
|---|---|---|
| PII + sign | hybrid | hybrid-ml-dsa65-ecdsa-p256 |
| PII + sign | pqc_only | ml-dsa65 |
| PII + sign | classical | classical algorithm set by the policy |
The three postures are classical, hybrid and pqc_only, with hybrid post-quantum (ML-KEM, ML-DSA) available out of the box. Moving to PQC-only is a policy edit: application code doesn't change, and deprecating a cipher needs no recompile. That's the architecture column of level 5 in the maturity model, for the services that use CAP.
CAP is available today on DuoKey Cockpit through a REST API and reference clients for Java/Spring Boot and .NET/EF Core, plus an AI/MCP control plane. Packaged SDKs and annotations such as @Protect are on the roadmap. CAP holds no key material.
DuoKey Cockpit is one console and API over software, MPC, HSM and cloud KMS backends. Through PKCS#11 and KMIP, CAP works with Securosys HSMs, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault and OpenBao. With MPC, keys are split so no single host holds a complete key. Cockpit keeps a cryptographically chained audit log, with RBAC, ABAC and tenant isolation.
DuoKey certificate management issues RSA, EC, ML-DSA (FIPS 204), SLH-DSA (FIPS 205) and hybrid composite ML-DSA-65 + ECDSA-P256 certificates from vault-signed CAs over ACME, EST, SCEP and CMP. DuoKey's documentation recommends PQC where you control both ends and the hybrid composite where you must interoperate with classical relying parties, since not every client understands ML-DSA or SLH-DSA yet.
For AI agents that request keys and sign on their own, see agentic crypto agility.
Q: What is crypto agility?
Crypto agility is the ability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. That's NIST's definition in CSWP 39. In practice it rests on an inventory, an abstraction layer, a policy, automation and testing.
Q: What is a crypto agility policy?
It's the governance document that states which algorithms are approved for which data classes and purposes, the post-quantum and hybrid posture, what triggers a deprecation, rotation SLAs, ownership of keys and certificates, and how exceptions are approved and expire. In an agile estate, the same policy is also executed by tooling, not just read by auditors.
Q: What is a crypto agility platform?
It's the tooling that discovers cryptographic assets, scores their risk, resolves algorithms from a central policy through an abstraction layer, automates certificate and key changes, simulates changes before rollout, and keeps an audit trail. If a product only covers discovery or only key storage, it covers part of the problem, not the whole loop.
Q: How do you measure crypto agility?
The headline metric is the time to replace an algorithm across the estate, from decision to last production use removed. Supporting KPIs are the percentage of assets inventoried, the percentage of keys and certificates with an owner, the percentage of services behind an abstraction layer and mean time to rotate.
Q: Does NIS2 require crypto agility?
Not under that name for every entity. The NIS2 Directive requires policies and procedures on the use of cryptography. For the specific entity types covered by Implementing Regulation (EU) 2024/2690, the Annex adds a dedicated cryptography section with a documented policy and periodic review, which in practice requires the ability to change algorithms. Other entities should check their national transposition. Details are in our NIS2 crypto agility article.
Q: When do RSA and ECC have to be replaced?
NIST's draft transition plan (IR 8547, initial public draft, November 2024) proposes deprecating 112-bit-strength quantum-vulnerable algorithms such as RSA-2048 after 2030 and disallowing all quantum-vulnerable signature and key establishment algorithms after 2035. Sector regulators may set earlier milestones; see our PQC migration roadmap guide.
Q: Is hybrid cryptography part of crypto agility?
Yes. A hybrid posture combines a classical and a post-quantum algorithm, adding quantum resistance while staying interoperable with systems that don't support PQC yet. An agile estate moves a data class from classical to hybrid to PQC-only by changing its policy.
Crypto agility is a capability you can measure: how fast you can change cryptography without breaking anything. The post-quantum deadline gives it a date, and regulators are making it an audit question. Start by moving algorithms out of code and into policy.
To see where you stand today, start with the free Quantum Readiness Score, or talk to DuoKey about cryptographic posture management.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
