Crypto-agility: what it is and how a CBOM enables it
The post-quantum transition will not be the last algorithm change. Crypto-agility is the capability that makes such changes routine, and a CBOM is how you know whether you have it.
- NIST defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations.
- Agility depends on design choices, algorithm identifiers, abstraction layers, configuration over code, and on organisational practice.
- IETF's RFC 7696 sets out algorithm-agility guidelines for protocol designers, including the need for protocols to identify the algorithm in use.
- A CBOM shows where cryptography is hard-coded, which systems cannot change algorithms, and how long a change takes.
- Hybrid schemes and crypto gateways are transitional tools for systems that cannot be made agile quickly.
Definition
NIST's Cybersecurity White Paper 39, Considerations for Achieving Crypto Agility (first published 19 December 2025, updated 29 June 2026), 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" [1].
The idea is older than post-quantum cryptography. The IETF's RFC 7696 (BCP 201, 2015) set out guidelines for cryptographic algorithm agility in protocols, including that "the protocol MUST include a mechanism to identify the algorithm or suite that is being used" [2]. The migrations from DES, MD5, SHA-1 and early TLS versions all showed the cost of systems that could not change.
Why it matters now
NIST IR 8547 (draft) proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit level after 2030 and disallowing them after 2035 [6]. Every system that uses RSA or elliptic-curve cryptography will need to change. Organisations whose cryptography is configurable will do that as a sequence of managed changes; those whose cryptography is hard-coded will face rewrites and replacements. India's DST task force report calls for government procurement to require "crypto-agile and PQC-compliant assets" [4].
What makes a system agile
| Property | Agile | Not agile |
|---|---|---|
| Algorithm selection | Configuration or policy | Hard-coded in source |
| Implementation | Behind a crypto API or provider interface | Direct calls to a specific library's primitives scattered through code |
| Protocol | Negotiates algorithms with identifiers, per RFC 7696 [2] | Fixed algorithm, no identifier |
| Data formats | Room for larger keys, signatures and ciphertexts | Fixed-size fields sized for today's algorithms |
| Keys and certificates | Automated issuance and rotation | Manual, long-lived |
| Hardware and firmware | Updatable | Fixed-function or unsupported |
Practices from NIST CSWP 39
The white paper describes several strategies [1]:
- API abstractioncryptographic APIs that separate application logic from the underlying implementation, so algorithms can be replaced without changing applications.
- Policy enforcementcryptographic policy that is communicated and enforced across cryptographers, developers, implementers and policymakers.
- Strategic planninga crypto-agility plan combining governance, asset management, risk assessment and automated tooling.
- Transitional mechanismshybrid schemes that combine traditional and post-quantum algorithms, and crypto gateways for legacy systems that cannot be modified.
- A maturity model for assessing an organisation's crypto-agility readiness.
It also notes that technology producers can help by providing automated mechanisms that give "a comprehensive list of cryptographic components such as algorithms, protocols, libraries, applications, certificates, and related crypto materials" [1]in other words, a CBOM.
How a CBOM enables agility
- Shows where cryptography lives. Code-level CBOMs record the file and line where an algorithm is used, distinguishing central configuration from scattered hard-coding.
- Identifies non-agile systems. Assets with
executionEnvironmentofhardwareor on fixed firmware [5], and products whose suppliers have no migration roadmap, are candidates for gateways or replacement. - Measures change. Comparing CBOM versions shows how long it took to remove an algorithm from a service, the most direct measure of agility.
- Supports procurement. CERT-In recommends that suppliers provide complete CBOMs (8.4.1.2) and that CBOMs be updated as new algorithms are introduced (8.4.1.13) [3], which is the information needed to judge a product's agility.
A practical sequence
- Build the CBOM; see CBOM generation.
- Classify each system as configurable, code change needed, or replace or wrap.
- Make new development agile by default: approved crypto libraries, configuration-driven algorithms, automated certificates.
- Rehearse: change one algorithm across one service end to end and measure it.
- Plan post-quantum migration on that foundation; see preparing for post-quantum cryptography.
How IntelliXBOM helps
IntelliXBOM keeps version history and diffs for every CBOM, which shows how quickly algorithms are replaced across services. It correlates cryptographic assets with end-of-life data, vulnerabilities and business services, helping teams identify systems that cannot change and prioritise them.
Frequently asked questions
What is crypto-agility?
Crypto-agility is the ability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations. NIST sets out this definition in CSWP 39.
How does a CBOM help crypto-agility?
A CBOM shows where each algorithm is used, whether it is configured centrally or hard-coded, and which systems run on hardware or firmware that cannot change. Comparing CBOM versions over time measures how quickly algorithms are actually replaced.
Is crypto-agility only about post-quantum cryptography?
No. It applies to any algorithm change, including earlier transitions away from DES, MD5, SHA-1 and old TLS versions. The post-quantum transition has made it a priority because it affects all public-key cryptography.
Sources
- CSWP 39, Considerations for Achieving Crypto Agility: Strategies and PracticesNISTcsrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final
- RFC 7696 (BCP 201), Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms (November 2015)IETFwww.rfc-editor.org/rfc/rfc7696
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- Implementation of Quantum Safe Ecosystem in India: Report of the Task Force (February 2026)Department of Science and Technology, Government of Indiadst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20(v1).pdf
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (November 2024)NISTnvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.