A Cryptography Bill of Materials is an inventory of the cryptographic components used in a system. It records algorithms, libraries, keys, certificates, protocols, and where they are deployed. Security teams use it to assess exposure, track weak or deprecated cryptography, and support governance, incident response, and compliance.
What a Cryptography Bill of Materials captures
A Cryptography Bill of Materials is more than a list of names. It tells you which cryptographic primitives, libraries, protocols, certificates, and keys are present, where they operate, and which parts of the estate depend on them.
That inventory view matters because cryptography is often embedded across application code, infrastructure, device firmware, APIs, and third-party dependencies. Without a clear record, teams can miss outdated algorithms, duplicate trust anchors, or hidden dependencies that only surface during an incident or audit.
Why cryptographic inventory matters
The value of a cryptographic inventory is that it turns opaque trust dependencies into something teams can review. A system may appear healthy while still relying on weak ciphers, expired certificates, or libraries that embed outdated defaults, and those issues can persist across multiple services.
This is also where governance becomes practical. A cryptographic inventory helps security, platform, and compliance teams answer what is in use, where it is deployed, and which business systems would be affected if a component had to be removed or replaced.
For teams building broader supply-chain visibility, NHIMG’s SBOM Guide is a useful companion because it shows how inventory thinking is applied to software dependencies and vulnerability correlation.
What should be recorded in a CBOM
A useful cryptography inventory records the algorithm, implementation, certificate or key material, protocol or mode of use, and the system or service boundary where each item is deployed. It should be specific enough to distinguish what is actually trusted from what is merely available in the environment.
That level of detail lets defenders see patterns such as the same library reused across multiple applications, a certificate chain shared by too many services, or a protocol decision that is still present in legacy paths. It also supports crypto-agility, because teams can plan changes only when they know where cryptography is actually consumed.
For organisations thinking about future algorithm transitions, NHIMG’s Post-Quantum Readiness for Identity and PKI explains why inventory and crypto-agility are inseparable when certificates, signing and authentication material need to evolve.
How teams use a cryptographic inventory in practice
In practice, the inventory becomes a decision support tool. Teams use it to prioritise remediation, validate that weak or deprecated cryptography is not still exposed, and identify the blast radius when a library, certificate, or protocol family must be changed.
It is also useful during incident response. If an organisation suspects cryptographic compromise, the inventory helps narrow where keys, certificates, sessions, or signing paths may have been in scope and which services may need review. A strong inventory also reduces guesswork when auditors or responders ask which cryptographic controls are actually in production.
For cloud and platform teams, NHIMG’s AI Security Posture Management (AI-SPM) Guide is a useful parallel because it shows how asset discovery and exposure tracking are applied to security posture at runtime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Defines key lifecycle, cryptoperiods and algorithm selection for cryptographic inventory decisions. |
| Recommendation — Track key lifecycle, cryptoperiods and algorithm choices so inventory data supports rotation and retirement decisions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Annex A cryptography control directly governs how cryptographic use is identified and controlled. |
| A.5.15 — Access control | Inventorying cryptographic assets helps govern which systems and services can rely on protected trust material. | |
| Recommendation — Document cryptographic use and align implementations with approved cryptography policy and control requirements. Map cryptographic dependencies to controlled access paths so only approved systems can use them. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Directly addresses key establishment and lifecycle management, central to a cryptographic bill of materials. |
| IA-5 — Authenticator Management | Keys, certificates and related authenticators in a CBOM need lifecycle governance and renewal oversight. | |
| Recommendation — Inventory cryptographic key dependencies and tie them to lifecycle and establishment controls. Record authenticators and rotate or revoke them based on the inventory’s lifecycle data. | ||
Related resources from NHI Mgmt Group
- How should teams build a cryptography bill of materials for enterprise systems?
- What do organisations get wrong about cryptographic bill of materials data?
- Why do software bill of materials controls not fully solve application risk?
- How should security teams build a crypto bill of materials for post-quantum migration?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org