A cryptographic bill of materials lists the cryptographic capabilities built into software components, such as supported algorithms and libraries. It is useful for component visibility, but it does not show live configuration, deployment context or actual runtime usage. That makes it a partial input, not the full governance record.
Expanded Definition
A cryptographic bill of materials, often shortened to CBOM, is an inventory of the cryptographic functions present in software components: algorithms, libraries, protocols, key sizes, and related dependencies. It helps teams answer what cryptography is available, but not how it is configured, where it runs, or whether it is actively used.
Definitions vary across vendors because CBOM is still an emerging practice rather than a single, universally enforced standard. In security governance, it is best treated as a visibility artifact that complements a software bill of materials, not a replacement for runtime discovery or policy enforcement. That distinction matters in NHI-heavy environments, where machine identities may depend on libraries, certificates, or embedded crypto defaults that change by deployment context. For identity assurance and lifecycle thinking, compare this with the baseline expectations in NIST SP 800-63 Digital Identity Guidelines, which focuses on assurance and authentication outcomes rather than component inventory alone.
The most common misapplication is treating CBOM data as proof of secure cryptographic posture, which occurs when teams assume a declared library list reflects approved algorithms, current key rotation, or live certificate usage.
Examples and Use Cases
Implementing CBOM rigorously often introduces maintenance overhead, requiring organisations to weigh cryptographic transparency against the cost of keeping component inventories accurate as dependencies change.
- A platform team uses a CBOM to detect that a service still includes deprecated ciphers, then validates whether those ciphers are actually enabled in production before approving release.
- An NHI governance team correlates CBOM entries with secret management and certificate issuance records to understand which workloads depend on specific crypto libraries.
- A compliance reviewer uses a CBOM as supporting evidence during control testing, but still checks configuration baselines and runtime telemetry because inventory alone cannot confirm enforcement.
- A software supplier shares a CBOM to help customers assess cryptographic exposure in a third-party component, aligning with the supply chain visibility concerns discussed in the Ultimate Guide to NHIs.
- A security architect maps cryptographic dependencies to federation and token validation flows, using the NIST SP 800-63 Digital Identity Guidelines to distinguish identity assurance from code-level capability disclosure.
In practice, CBOM is most useful when paired with release pipelines, asset inventories, and policy checks that show where cryptography is actually consumed.
Why It Matters in NHI Security
Cryptography underpins how NHIs authenticate, exchange tokens, protect secrets, and validate trust in automated systems. If a CBOM says a component supports modern algorithms, that does not mean the deployed agent, service account, or API integration is using them correctly. This gap is important because NHI programs commonly fail when visibility stops at static inventories and never reaches runtime posture. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes cryptographic assurance even harder to prove in practice. The broader NHI lifecycle issues covered in the Ultimate Guide to NHIs are exactly why a CBOM should be read as one input, not the governance answer.
For modern identity programs, CBOM also intersects with Zero Trust expectations because trust decisions depend on verified context, not merely declared capability. That is why practitioners often cross-check CBOM output against control guidance in NIST SP 800-63 Digital Identity Guidelines and operational reviews already described in the Ultimate Guide to NHIs.
Organisations typically encounter CBOM limitations only after a token compromise, certificate failure, or audit finding, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Guidelines stress assurance outcomes, not just declared crypto capabilities. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires verified context, so static crypto inventories are insufficient. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | NHI controls emphasize secret and identity visibility that CBOM can only partially inform. |
Use CBOM as input, then confirm secret handling, runtime use, and deployment context.
