Crypto-agility is the ability to replace and adapt the cryptographic algorithms an organisation uses without breaking the systems that depend on them. It is easy to claim and hard to evidence. Five practical questions show whether you actually have it: where each algorithm is used, who owns each use, what depends on it, whether the algorithm is chosen in code or in configuration, and how you would confirm a change had worked.
The claim to be crypto-agile tends to appear in policy documents and vendor decks, rarely with anything behind it. The useful test is not whether the phrase is written down, but whether the organisation could change an algorithm under pressure without breaking the services that depend on it.
How NIST defines crypto-agility
NIST’s Cybersecurity White Paper on the subject, CSWP 39, “Considerations for Achieving Crypto Agility: Strategies and Practices”, was published on 19 December 2025. The current version is CSWP 39-upd1, which includes updates as of 29 June 2026 and supersedes the original. Its definition is the one worth working from:
“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.”
That is a demanding definition. It covers hardware and firmware as well as software, and it requires operations to continue while the change happens. It is worth turning into questions you can answer with evidence rather than reassurance.
1. Where is each algorithm used?
You cannot replace what you cannot locate. This is the foundation of everything else: a current inventory of which algorithms, key sizes, protocols and certificates are in use, and on which systems. NIST’s strategic plan for crypto agility makes the same point, telling organisations to “Inventory the use of cryptography for data protection across the organization”, from application code and libraries to hardware, firmware and communication protocols.
Most estates have an answer for the systems the security team manages directly and a gap everywhere else: inherited dependencies, embedded devices, test environments, and cryptography added by delivery teams under deadline pressure. If answering this question takes a project rather than a query, that is the first finding.
2. Who owns each use?
An algorithm change is a change to a system, and systems have owners with their own release calendars. A finding with no named owner is a note, not a task. Agility depends on being able to go from knowing where an algorithm is used to knowing who is responsible for changing it, without a search. NIST asks for the same accountability at programme level: “Identify key stakeholders, including a responsible official to lead the effort and monitor the progress of the activities.”
3. What depends on it?
Replacing a cryptographic mechanism is rarely a self-contained change. Certificates are validated by clients you may not control, keys are consumed by downstream services, and libraries carry algorithm choices on behalf of the applications that use them. Before a change, you need to know what else moves with it. Where dependencies are not mapped, the safe response is to delay, and delay is the opposite of agility.
4. Where is the algorithm chosen: in code or in configuration?
Where the choice of algorithm lives decides how fast it can change. CSWP 39-upd1 describes the range:
- Configuration: “administrators can change a configuration setting to prohibit the use of a particular algorithm as a means of forcing algorithm transition.”
- Embedded systems: in many of them, “available algorithms are typically fixed at compile time”, so a change needs a new build and a release.
- Hardware: functions implemented in an integrated circuit cannot be changed, which means “the chip will need to be replaced if it has design errors or if changes to the algorithms are needed.”
Knowing which is which, estate-wide, tells you where change will be quick and where it will follow a hardware refresh cycle. That distinction should shape the order of any migration plan.
5. How would you know if it had worked?
An algorithm change that cannot be verified is a hope. After a change you need to confirm that the old mechanism is gone from the places it was meant to leave, and that nothing has quietly reintroduced it. That means re-discovery as a routine, not a one-off audit. A snapshot taken before the change says nothing about the estate afterwards. NIST’s plan ends on the same note: “These steps are continuously repeated to mitigate evolving cryptographic risks”.
What the five questions have in common
All five depend on the same thing: an inventory that is accurate, owned and kept current. Agility is not a separate capability sitting alongside discovery. It is what discovery makes possible, and what stops being possible when the inventory ages.
It is also why agility is better measured than declared. An organisation that can answer these five questions for a defined boundary, such as one service, one environment or one regulated function, has evidence. One that cannot has a policy statement.
Turning the questions into a programme
The Enterprise Cryptographic Exposure Management (ECEM) lifecycle runs Discover, Inventory, Assess, Prioritise, Transition, Monitor. The five questions map onto it: the first two are discovery and inventory, the third and fourth are assessment and prioritisation, and the fifth is monitoring. NIST’s own step after inventory is the same idea: “Develop a prioritized list of assets to be mitigated”.
Quantum Sentinel builds a living Enterprise CBOM from discovery across the estate. Each finding is scored with the Cryptographic Exposure Score, so priority reflects business context rather than raw counts, and ownership and criticality can be synced in from ServiceNow and BMC Helix CMDBs. Progress is tracked over time with the Quantum Readiness Score, with continuous re-discovery to catch regressions. The platform produces the prioritised evidence a migration plan is built from, and raises tickets in Jira, ServiceNow ITSM and BMC Helix ITSM where the work happens.
Start with one boundary and see how many of the five questions you can answer today. The gaps are your first work list.
Frequently asked questions
What is crypto-agility?
NIST defines crypto-agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructures while preserving security and ongoing operations. In practice it means being able to change an algorithm without breaking the services that depend on it.
Which NIST document covers crypto-agility?
NIST Cybersecurity White Paper 39, Considerations for Achieving Crypto Agility: Strategies and Practices, published on 19 December 2025. The current version is CSWP 39-upd1, which includes updates as of 29 June 2026 and supersedes the original.
How do you measure crypto-agility?
Test it against evidence for a defined boundary. Can you say where each algorithm is used, who owns each use, what depends on it, whether it is set in code, configuration or hardware, and how you would confirm a change had worked? Each question you cannot answer from a current inventory is a gap in agility.
Why does it matter where an algorithm is configured?
It decides how fast the algorithm can change. NIST notes that administrators can change a configuration setting to prohibit an algorithm, that in many embedded systems algorithms are fixed at compile time, and that algorithms implemented in an integrated circuit need the chip replaced to change.
Sources: NIST, CSWP 39-upd1, Considerations for Achieving Crypto Agility: Strategies and Practices (19 December 2025, includes updates as of 29 June 2026), including the abstract and Sections 3.2, 4.4, 4.5 and 5; NIST, CSWP 39 publication page.
Further reading: crypto-agility: building systems that can adapt, crypto-agility maturity models compared, building an Enterprise CBOM and continuous posture monitoring.