What is a Cryptographic Bill of Materials (CBOM)?

What is a CBOM?

A Cryptographic Bill of Materials (CBOM) is a structured record of an organization’s cryptographic components and their context. In practical terms, it answers questions such as: Which algorithm is being used? Where is it used? Which protocol, application, library, hardware, firmware, or infrastructure invokes it? Which key or certificate is associated with it? Who owns or sponsors it? What data or service does it protect? What is its current status, and does it require replacement or migration? This definition follows the broader scope of cryptographic management guidance, which encompasses algorithms, infrastructures, protocols, implementations, applications, and their management. C11

The value of a CBOM is the relationship among those records. An algorithm name without a location, use, owner, protocol, key, certificate, or protected asset is difficult to act on. A contextual record can support investigation, renewal, replacement, exception handling, and prioritization. It can also expose where the same cryptographic dependency appears across applications, servers, endpoints, network protocols, development pipelines, operational technology, or supplier products. C24

What information should a CBOM contain?

The exact schema may vary by organization and implementation, but a useful CBOM should capture enough information to identify a cryptographic use, locate it, assign accountability, assess it, and follow it through its lifecycle. The following categories are evidence-supported design objectives rather than a claim that every implementation must use identical field names. C1[C7]3

• Cryptographic mechanism: algorithm, primitive, mode, key type, key length or size, and relevant implementation or provider.
• Use and location: protocol, application, service, device, server, endpoint, hardware, firmware, infrastructure, repository, or deployment location.
• Key and certificate context: key identifier or reference, certificate identity, owner or sponsor, validity period, expiration, status, and contact information. The inventory should not expose private key material merely because it records a key or certificate.
• Relationships and dependencies: the application, library, package, service, protocol, component, or supplier relationship in which the cryptography is used.
• Governance and accountability: owner, responsible team, source of the record, discovery method, evidence date, confidence or validation state, and the action or status assigned to the record.
• Risk and migration relevance: protected dataset or service, data criticality, secrecy or protection lifetime where known, quantum-vulnerability or other replacement concern, planned disposition, and migration priority.

Key and certificate records deserve particular care. NIST defines a key inventory as information about each key that does not include the key itself, such as the owner, key type, algorithm, application, and expiration date. Its guidance says that key and certificate inventory management includes establishing and maintaining records, assigning and tracking owners or sponsors, monitoring status, and reporting status for remedial action. Certificate inventories should include the latest certificates for each entity and information about certificate owners and contacts; associated private keys should not be included unless the inventory is also authorized for backup or archiving. C41

A CBOM should also preserve uncertainty. Discovery is not proof of complete coverage, and an absent record may mean that a mechanism was not found rather than that it is not present. Recording source, timestamp, method, validation state, and known unknowns allows users to distinguish observed facts from assumptions and target follow-up work. This is consistent with the cited SBOM guidance, which treats data quality, generation context, coverage, known unknowns, and accommodation of updates as important parts of transparency. C8143

How is a CBOM related to an SBOM?

An SBOM is a nested inventory of the components that make up software applications and systems. Its structure is roughly hierarchical: components can contain subcomponents, and the inventory captures dependency relationships among them. CISA’s minimum-element guidance includes fields such as component name, version, software identifiers, hash, license, dependency relationship, tool name, and timestamp. An SBOM therefore answers primarily: What software components are present, and how are they related? C834

A CBOM answers a different but complementary question: What cryptography is being used, where and how is it used, who is accountable for it, what does it protect, and how can it be maintained or replaced? A cryptographic library may appear as one component in an SBOM while exposing several algorithms, protocols, providers, certificates, or implementation paths that matter to a CBOM. Conversely, a CBOM record may point back to the software, firmware, device, or dependency that implements the cryptographic function. The two inventories can therefore be correlated without being treated as interchangeable. C1[C8]32

The distinction is important for risk decisions. Knowing that a library is installed does not necessarily reveal which algorithm or protocol path is active, which datasets are protected, whether a certificate is nearing expiration, or whether an embedded implementation is quantum-vulnerable. Likewise, a cryptographic record without software dependency context may not identify the build, component, or supplier responsible for remediation. Use an SBOM for software composition and dependency transparency, and use a CBOM for cryptographic visibility and management; correlate them where the evidence supports the relationship. C2[C8]321

How discovery evidence populates a CBOM

A CBOM is populated from multiple sources rather than from a single scan. The joint CISA, NSA, and NIST fact sheet recommends cryptographic discovery activities and identifies network protocols, end-user and server assets, applications and associated libraries, firmware and software updates, and cryptographic code or dependencies in CI/CD pipelines as discovery targets. These observations can create or update CBOM records, which should then be correlated with asset, identity, credential and access-management, endpoint, and continuous-diagnostics inventories. C24

Discovery output should be normalized into records with a stable identity and a clear relationship to the observed asset or software. For example, an observation might identify an algorithm in a protocol on a server; a second source might identify the certificate and owner; a third might identify the application and library; and a data inventory might establish the criticality and protection lifetime of the information involved. These are separate evidence contributions that can be linked rather than collapsed into an unsupported single conclusion. C441

Manual validation and supplier engagement are necessary complements to automated discovery. The cited guidance warns that tools may not identify embedded cryptography used internally within products and recommends asking vendors for lists of embedded cryptography. Vendor engagement is also important for understanding product and cloud-provider post-quantum roadmaps, including when updates, upgrades, configuration changes, or application changes may enable post-quantum cryptography. C64

CBOM lifecycle: create, validate, use, and update

A CBOM is not a one-time report. It should be created from discovery and existing records, validated with system and service owners, used for risk and operational decisions, and updated as systems, software, certificates, keys, protocols, and suppliers change. NIST’s key-management guidance emphasizes lifecycle management, including secure generation, storage, distribution, use, and destruction of keys. Its inventory guidance likewise calls for maintaining records, tracking owners, monitoring status, and reporting when remedial action is required. C41

Operational update triggers include a new application or service, a software or firmware release, a changed dependency, a certificate issuance or renewal, key rotation or retirement, a protocol configuration change, a supplier update, a newly discovered embedded implementation, or a decision to migrate an algorithm. The cited SBOM guidance provides a useful analogous principle: each software version or update should have associated updated inventory data. Applied to a CBOM, the principle is to refresh records when the cryptographic reality changes and to retain the evidence and date of the update. C81

Maintenance should include reconciliation. Duplicate records should be linked or resolved; stale certificates and retired keys should receive an explicit status; unverified findings should remain marked as uncertain; and owners should be contacted when action is needed. A central repository or mutually trusted repositories are specifically recommended for certificate inventories, operated in accordance with a certificate policy. The appropriate repository and access controls for a broader CBOM depend on organizational requirements and are not prescribed by the cited evidence. [C5]1

Why CBOMs matter for risk and migration

Cryptographic strength depends on more than an algorithm label. NIST notes that effective protection depends on the strength of keys, the effectiveness of associated mechanisms and protocols, and protection of the keys; weak implementations, inappropriate algorithm pairing, poor physical security, or weak protocols can render cryptography ineffective. A CBOM makes these surrounding dependencies visible enough to support a more complete assessment. [C1]4

For post-quantum planning, the joint fact sheet recommends an inventory of quantum-vulnerable technology and the criticality of the data it protects. Such an inventory supports risk assessment and migration prioritization, including consideration of where vulnerable cryptography protects sensitive datasets and how long those datasets require protection. The agencies also describe a “harvest now, decrypt later” concern for information with a long secrecy lifetime and urge organizations to begin roadmaps, inventories, risk assessments, and vendor engagement. C24

A CBOM can support crypto agility when it identifies the mechanisms and dependencies that must be changed, the systems affected, the accountable owners, and the operational constraints. NIST describes crypto agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. A CBOM does not itself make an environment agile; it supplies visibility and relationships that can inform the engineering and governance work required for change. C144

Limitations and responsible use

A CBOM is only as complete and current as its evidence and maintenance process. Automated tools can miss embedded cryptography; vendor documentation can be incomplete; ownership may be unclear; and the same implementation may appear through several software, infrastructure, or protocol paths. The cited evidence therefore supports treating discovery as an ongoing activity and explicitly recording coverage limitations and unknowns. C643

A CBOM also does not by itself establish that a cryptographic mechanism is secure, compliant, correctly configured, or appropriate for a particular dataset. It is an inventory and relationship layer. Assessment still requires context about keys, protocols, implementations, data criticality, protection lifetime, operational constraints, and the applicable policy or standard. In addition, private key material should not be placed in an ordinary inventory merely to make the record appear complete. C1[C5]1

Finally, the cited evidence does not define one universal CBOM field set, mandatory interchange format, or required scanning method. CycloneDX identifies CBOM as a supported bill-of-materials type and provides standards in JSON, XML, and protocol buffers, but organizations still need to select an implementation, governance model, evidence policy, and update process appropriate to their environment. [C7]2

Conclusion

A CBOM is a maintained, structured view of cryptographic use and its operational context. It complements an SBOM by connecting algorithms, keys, certificates, protocols, implementations, libraries, assets, owners, dependencies, data, and lifecycle status. Its practical value comes from evidence-backed relationships: discovery finds use, validation improves confidence, ownership enables action, and updates preserve accuracy. Used with risk assessment and vendor engagement, a CBOM can help prioritize certificate and key work, identify cryptographic weaknesses, and plan controlled crypto-agility or post-quantum migration. C2[C14]23