CBOM Best Practices

What a CBOM is and what it should cover

A cryptographic bill of materials (CBOM) is an inventory of an organization’s cryptographic use and the technical and business context needed to interpret that use. In practice, it should answer questions such as: where is cryptography implemented; which algorithms, protocols, libraries, modules, and services are involved; what security function does each use perform; which data or system depends on it; who owns the dependency; and how can the use be changed or replaced? The cited evidence identifies CBOM as one of the bill-of-materials types supported by CycloneDX, alongside software, hardware, machine-learning, manufacturing, and operations bills of materials. CycloneDX is described as a full-stack BOM standard and as ECMA-424, with JSON, XML, and protocol-buffer representations.1

The scope should follow the organization’s actual cryptographic exposure rather than a narrow application boundary. CISA, NSA, and NIST recommend cryptographic discovery across IT and OT systems and devices, including custom-built and commercial off-the-shelf technology and reliance on cloud services. Their fact sheet specifically identifies network protocols, end-user assets and servers, applications, and associated libraries as discovery targets. NIST’s crypto-agility material describes cryptographic use across protocols, applications, software, hardware, firmware, and infrastructures. Together, these sources support treating a CBOM as an enterprise inventory of cryptographic dependencies, not simply a software-package manifest.23

Why CBOM practices matter

The primary value of a CBOM is decision-quality visibility. CISA describes an SBOM as an ingredients list that exposes software makeup and enables organizations to transform component data into insights and actions. It also states that an SBOM alone is data about components; analysis is what produces insight about associated risks. The same operating principle applies to CBOM a list of cryptographic mechanisms has limited value until it is connected to ownership, exposure, data sensitivity, system criticality, lifecycle, and available remediation paths.4

A CBOM can support several related decisions. Security teams can identify deprecated or quantum-vulnerable mechanisms, locate affected systems, and estimate the scope of a change. Architecture teams can assess whether applications and infrastructure can replace algorithms without disrupting operations. Procurement and third-party risk teams can ask suppliers for evidence about cryptographic use and post-quantum plans. Incident and vulnerability teams can narrow investigations to affected cryptographic dependencies. These uses are consistent with the evidence’s emphasis on machine-processable data, analysis, risk-informed decisions, and vendor engagement; the evidence does not claim that a CBOM by itself resolves any of those risks.42

Quantum readiness is a particularly strong use case. The joint CISA, NSA, and NIST fact sheet recommends proactive cryptographic discovery, an inventory of quantum-vulnerable systems and assets, and prioritization based on the criticality of data. It also calls attention to data that may be targeted now and decrypted when a cryptographically relevant quantum computer becomes available. A CBOM can provide an organizing layer for that inventory, provided it records enough context to distinguish an algorithm’s presence from the actual data, function, and exposure at risk.2

A practical CBOM operating workflow

The most reliable implementation is a lifecycle rather than a one-time scan. Begin by defining ownership, scope, and decision objectives. Establish which business units, applications, services, networks, devices, firmware, cloud dependencies, and suppliers are in scope. Assign accountable owners for the inventory, discovery methods, validation, risk decisions, and remediation. Define how the organization will represent uncertainty and how it will handle systems that cannot be inspected directly. This governance step is important because the cited SBOM evidence emphasizes baseline practices, shared expectations, scalable exchange, and accommodation of changes to BOM data.4

1. Discover cryptographic use through code, configuration, binaries, protocols, endpoints, infrastructure records, key-management records, supplier documentation, and interviews where automated evidence is incomplete.
2. Normalize findings into a consistent record, preserving the original observation, source, timestamp, confidence, and relationship to the affected component or system.
3. Enrich each finding with purpose, algorithm or mechanism, implementation, protocol, key or certificate context where available, owner, supplier, environment, data or function, criticality, and lifecycle information.
4. Validate high-impact findings with system owners and suppliers. Resolve duplicates, stale observations, false positives, and conflicting versions before assigning remediation priority.
5. Analyze the inventory against organizational policy, approved cryptographic guidance, exposure, security lifetime, and migration requirements.
6. Create and track actions: configuration changes, library or product upgrades, compensating controls, supplier commitments, architecture changes, or planned replacement.
7. Republish and reconcile the CBOM after material changes, including releases, upgrades, infrastructure changes, certificate or key changes, supplier updates, and migration milestones.

Discovery should be deliberately broad. The joint quantum-readiness guidance says that organizations should create an inventory offering visibility into how cryptography is leveraged in IT and OT systems. It identifies network protocols and assets on end-user systems and servers, including applications and associated libraries, among the places to look. NIST’s crypto-agility description extends the relevant technology surface to protocols, applications, software, hardware, firmware, and infrastructure. A mature program should combine automated discovery with owner review because neither source claims that one discovery technique can observe every implementation.23

Treat updates as a first-class requirement. CISA’s 2025 SBOM minimum-elements evidence describes replacing a standalone mistake-accommodation concept with accommodation of updates to SBOM data, reflecting an expectation that recipients can rely on improving data quality while still handling changes. Applied to CBOM operations, this means retaining version history, distinguishing a corrected observation from a changed deployment, recording when a finding was last confirmed, and making downstream consumers aware of material changes.4

What information makes a CBOM actionable

Algorithm names alone are insufficient for risk analysis. NIST SP 800-57 identifies factors relevant to key-management decisions, including the operating environment, personnel turnover, data-flow or transaction volume, the security life of the data, limitations on algorithm usage, the security function, rekeying method and process, and the number of nodes sharing keying material. These factors illustrate why a useful CBOM should capture context around cryptographic use rather than treating every occurrence as equivalent.5

At minimum, define records that can express relationships. A cryptographic finding may relate an application to a library, a library to an algorithm, an algorithm to a protocol, a protocol to a data flow, and that data flow to a business service. Other useful relationships connect a device or firmware version to a supplier, a certificate or key-management service to its consuming systems, and a finding to an owner and remediation action. The evidence supports a machine-processable and scalable model and identifies multiple technology surfaces, but it does not establish a mandatory universal field list; field selection should therefore be documented as an organizational design choice.413

Prioritize findings by impact and changeability

A practical prioritization model should combine technical exposure with business consequence and migration difficulty. Start with high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs, because the joint quantum-readiness guidance explicitly recommends giving these areas priority. Then consider whether the cryptography protects signatures, updates, confidentiality, authentication, key establishment, or another function; how long the protected data must remain secret; whether the dependency is custom-built, commercial, cloud-hosted, or embedded in older technology; and whether an upgrade or replacement path exists.2

Do not convert guidance into an automatic universal deadline. NIST SP 800-57 says that longer or shorter cryptoperiods may be warranted depending on the application and environment, even while providing suggested periods for particular key types. The evidence also says that NIST SP 800-57 addresses key-management guidance and supplements more focused standards, while implementation details for cryptographic modules are addressed in FIPS 140 and associated guidance. Consequently, a CBOM may identify key and module dependencies, but key-lifetime decisions and module assurance require the applicable policy, application context, and dedicated guidance.5

Use confidence and evidence quality in prioritization. A confirmed vulnerable algorithm in a high-impact service should not be treated the same as an unverified string found in an inactive test artifact. Record why a finding is believed to be present, what was inspected, when it was observed, and which owner confirmed it. Where information is unavailable, distinguish unknown from not applicable and preserve the reason. CISA’s SBOM evidence discusses reducing ambiguity around known unknowns and explaining why information may not be provided; that principle is directly useful for CBOM data governance.4

Standards, evidence, and supplier engagement

CycloneDX is a relevant interoperability option because the cited OWASP evidence identifies it as ECMA-424, describes support for CBOM, and lists JSON, XML, and protocol-buffer standards. Its role should be understood accurately: a format or standard can help represent and exchange information, but it does not automatically make an inventory complete, correct, current, or risk-prioritized. Organizations should publish their profile, required fields, allowed values, relationship model, update expectations, and validation rules alongside the chosen representation.14

Use NIST SP 800-57 to inform key-management context and decisions, not as a substitute for a CBOM schema. It is a final document, NIST SP 800-57 Part 1 Revision 5, published May 4, 2020, and its cited passages state that it provides general key-management guidance, including appropriate key length, cryptographic policy, and cryptographic-module selection, while implementation details for modules are addressed elsewhere. Preserve the document version and the boundary between inventory evidence and control requirements when mapping CBOM findings to policy.5

Supplier engagement belongs in the operating workflow. CISA, NSA, and NIST state that engagement with vendors on their post-quantum cryptography roadmap is critical, and recommend recording when and how commercial off-the-shelf vendors plan to provide updates or upgrades, as well as expected migration cost. For cloud-hosted products, the guidance recommends engaging cloud service providers about their quantum-readiness roadmap. Ask suppliers for supported algorithms and protocols, implementation locations, affected versions, upgrade mechanisms, transition dependencies, testing status, and commitments—but label supplier statements as assertions until they are validated against the deployed environment.2

Risks and limitations of CBOM programs

The first limitation is observability. Cryptography may be hidden in proprietary components, firmware, managed services, hardware security modules, dynamically loaded libraries, configuration, or protocols negotiated at runtime. A scan can also produce ambiguous matches or miss cryptography implemented indirectly. The evidence supports broad discovery and supplier engagement, but it does not promise complete detection. State coverage boundaries, confidence, collection methods, and unresolved gaps so that decision-makers do not mistake inventory completeness for security assurance.23

The second limitation is interpretation. Finding an algorithm does not by itself establish that a system is vulnerable, noncompliant, or ready for replacement. Risk depends on the security function, data lifetime, environment, implementation, key-management practices, exposure, and operational constraints. NIST SP 800-57 explicitly frames cryptographic decisions around context and notes that its guidance supplements more focused standards. Use subject-matter review for high-consequence findings and preserve the rationale for risk acceptance, mitigation, or remediation. [claim-115

The third limitation is staleness. Releases, infrastructure changes, supplier updates, and configuration changes can invalidate a previously accurate CBOM. Establish triggers for rescanning and reconciliation, monitor age and confirmation status, and make material changes visible to consumers. CISA’s 2025 SBOM evidence emphasizes accommodating updates to BOM data; the same discipline is necessary for a CBOM that supports operational decisions.4

Finally, a CBOM is not a complete cryptographic control program. It does not replace secure key generation, storage, access control, rotation, module validation, protocol configuration, vulnerability management, architecture review, or incident response. CISA explains that BOM data must be analyzed and mapped to other data sources to drive action, while NIST distinguishes general key-management guidance from cryptographic-module implementation details. Connect the CBOM to those processes instead of presenting it as a standalone compliance artifact. [claim-0445

Useful measures and practical next steps

Measure both inventory quality and operational outcomes. Useful measures include the percentage of in-scope systems with a current CBOM record; coverage across applications, protocols, devices, firmware, infrastructure, OT, and cloud services; the percentage of findings with an owner, purpose, criticality, confidence, and supplier; median age since confirmation; unresolved unknowns; duplicate or conflicting records; time to assess a newly disclosed cryptographic issue; and the number of high-priority quantum-vulnerable dependencies with an approved migration or mitigation plan. These measures operationalize the evidence’s emphasis on transparency, analysis, scalable sharing, discovery, prioritization, and vendor roadmaps. [claim-0542

1. Set a written CBOM scope and accountable operating team, including IT, OT, architecture, procurement, cloud, application, and risk representatives as appropriate.
2. Select or define a machine-processable representation and publish the organization’s profile, required context, confidence model, update rules, and evidence-retention approach.
3. Run a focused discovery pilot on high-impact systems, long-term confidentiality workloads, critical OT, and representative commercial, custom-built, and cloud dependencies.
4. Validate findings with owners and suppliers; separate confirmed use, suspected use, retired use, and unknown status.
5. Create a risk-ranked backlog for quantum-vulnerable cryptography, difficult-to-change dependencies, and systems whose data or functions have high impact.
6. Integrate CBOM changes into release, procurement, architecture, vulnerability, certificate, key-management, and supplier-review workflows.
7. Review measures and coverage regularly, revise the profile as use cases evolve, and preserve document versions and limitations in reporting.

Conclusion

CBOM best practices center on trustworthy, contextual, and continuously maintained visibility. Build the inventory broadly, represent relationships and uncertainty, connect findings to criticality and data lifetime, and make updates and supplier assertions auditable. Use a recognized exchange approach where useful, but do not confuse format adoption with completeness or assurance. The strongest CBOM program turns discovery into prioritized decisions: which cryptography needs attention, which suppliers must provide a path forward, and which systems should be prepared first for crypto-agile or post-quantum migration.124