CBOM

Expanded Definition

A CBOM, or cryptographic bill of materials, is an inventory of the cryptographic building blocks used by a product, service, or environment. That includes algorithms, key lengths, certificates, protocols, libraries, and any dependency that performs cryptographic functions. The point is not just documentation. It is to make crypto usage visible enough for security teams to detect obsolete primitives, identify policy violations, and plan controlled migration to stronger or post-quantum approaches.

In practice, CBOMs sit alongside software and supply chain visibility efforts, but they are narrower and more specialised than a general SBOM. A software inventory may tell you what components exist, while a CBOM asks what cryptography those components rely on and whether that cryptography still meets policy. That distinction matters because weak crypto can remain hidden inside frameworks, appliances, APIs, signing workflows, and machine-to-machine trust paths long after application owners think the system is secure. The NIST Cybersecurity Framework 2.0 reinforces the need for ongoing asset and risk visibility, which is the same operational logic behind CBOM adoption.

Definitions vary across vendors on how much detail a CBOM should contain, especially around derived keys, runtime-generated certificates, and ephemeral service identities. NHI Management Group treats CBOM as a governance artifact that supports crypto hygiene, migration planning, and enforcement, not merely a reporting format. The most common misapplication is treating a CBOM as a one-time inventory, which occurs when teams generate it during procurement but never update it after library upgrades, certificate rotation, or protocol changes.

Examples and Use Cases

Implementing CBOM rigorously often introduces discovery and maintenance overhead, requiring organisations to balance cryptographic transparency against the cost of continuous inventory updates.

• A financial services platform uses a CBOM to find TLS 1.0 and SHA-1 dependencies embedded in older middleware before they trigger compliance findings.
• A SaaS provider maps certificates, signing algorithms, and crypto libraries in its release pipeline so it can remove deprecated primitives without breaking trust chains.
• An enterprise cloud team inventories service-to-service authentication paths to identify where non-expiring keys or outdated certificate authorities still exist.
• A product security team uses a CBOM to prepare for post-quantum migration by identifying where RSA and ECC are hardcoded into code, devices, or partner integrations.
• A regulated organisation compares CBOM output against internal policy and external guidance from NIST AI 600-1 and adjacent NIST crypto guidance when cryptography is embedded in automated or AI-enabled systems.

CBOMs are also useful when cryptography is hidden inside third-party components. That is especially important in build systems, mobile apps, identity flows, and secure messaging platforms where teams may assume encryption is “handled” without knowing which primitives are actually in use. In NHI-heavy environments, CBOMs can expose certificates and trust relationships tied to machine identities, helping teams separate valid cryptographic dependency from unnecessary credential sprawl.

Why It Matters for Security Teams

Security teams need CBOMs because cryptographic risk is often invisible until a migration, audit, or incident forces the issue. When a weak algorithm is discovered late, the result is usually rushed replacement work, broken interoperability, and emergency exceptions that outlive the original risk. A CBOM turns crypto from an assumption into something that can be governed, reviewed, and remediated.

For identity and access teams, the relevance is direct. Certificates, signing keys, and protocol choices shape how users, workloads, devices, and non-human identities prove trust. If a CBOM is missing or stale, privilege boundaries can be anchored to deprecated crypto without anyone noticing. That creates exposure across authentication, token validation, code signing, and service-to-service trust. Guidance from NIST cryptographic key management guidance is commonly used to inform lifecycle decisions, while a broader security program can anchor oversight in the NIST Cybersecurity Framework 2.0.

Organisations typically encounter the operational cost of poor crypto visibility only after a certificate outage, protocol deprecation, or post-quantum readiness review, at which point CBOM becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who should own CBOM readiness in an enterprise?