Common CBOM Challenges

What a CBOM must make visible

A CBOM should be treated as a structured description of cryptographic use and its surrounding context. The cited evidence does not provide a single formal CBOM field model; instead, it establishes the practical scope through cryptographic discovery, key-management guidance, and the CycloneDX specification’s explicit support for CBOMs. CycloneDX is described as a full-stack bill-of-materials standard and lists CBOM alongside software, hardware, machine-learning, manufacturing, and operations bills of materials. It provides formats in JSON, XML, and protocol buffers. These facts support using a CBOM as a machine-processable supply-chain artifact, while leaving implementation teams responsible for deciding which cryptographic details and relationships are needed for their use cases.1

The scope is broader than naming an algorithm. The key-management evidence identifies factors that can affect cryptographic protection, including the mode of operation, implementation embodiment, operating environment, personnel turnover, data volume or transaction count, data security life, algorithm-usage limits such as invocation limits intended to avoid nonce reuse, security function, rekeying method, rekeying or key-derivation process, and the number of nodes sharing material. A CBOM that records only an algorithm name can therefore omit operational facts that change risk.2

Why CBOM challenges matter

The central challenge is moving from data to decisions. CISA’s 2025 SBOM minimum-elements evidence describes an SBOM as an ingredients list that provides data about software makeup; organizations then transform that data into insights and actions to mitigate risks. It also states that an effective mechanism for sharing and using software data must be machine-processable and scalable. The same reasoning applies to cryptographic inventories: a record is not a risk decision by itself. It must be analyzed, correlated with context, and connected to an owner and an action.3

Scale makes manual review inadequate. CISA explains that the volume of software used by agencies is too high for manual processes to assess and mitigate risks effectively, and that software which is not tracked creates a problem for transparency and security. Cryptographic use can be embedded in many of those software and infrastructure relationships. Consequently, a CBOM program must be designed for repeated collection, normalization, analysis, sharing, and update rather than a one-time spreadsheet project.3

• Visibility is incomplete when discovery covers applications but not protocols, libraries, firmware, hardware, infrastructure, or cloud dependencies.
• Context is weak when records omit the protected data’s criticality, confidentiality life, security function, implementation, or operating environment.
• Ownership is unclear when no team is accountable for validating an entry, responding to a finding, or maintaining it after a release or configuration change.
• Analysis is disconnected when CBOM data cannot be correlated with vulnerability, advisory, asset, supplier, or business-impact information.
• Change is unmanaged when an organization cannot determine where an algorithm or cryptographic implementation must be replaced, tested, or reconfigured.

Challenge 1: discovering cryptography across the estate

Discovery is difficult because cryptography is not confined to a single application library. The joint CISA, NSA, and NIST quantum-readiness fact sheet recommends cryptographic discovery to identify reliance on quantum-vulnerable cryptography. Its inventory scope includes network protocols; end-user systems and servers; applications and associated libraries; and cryptographic use in application functionality. The evidence also discusses custom-built and commercial off-the-shelf technologies, information-technology and operational-technology systems and devices, and cloud-service reliance.4

This creates a coverage problem. A scanner may identify an algorithm in source code but miss a device firmware implementation, a protocol negotiated at runtime, a hardware security function, a managed cloud service, or a supplier-controlled component. NIST key-management guidance further indicates that the implementation embodiment and operating environment matter. Discovery should therefore record where the cryptographic function occurs and how it is used, not just the apparent algorithm label. [claim-0224

Practical discovery should begin with a defined scope and confidence model. Separate observed facts from inferred facts, record the source and time of discovery, and identify unknown or unavailable information rather than silently treating it as absent. The cited CISA evidence specifically discusses known, redacted information and reducing ambiguity about known unknowns by explaining why information may not be provided. That principle is directly relevant when suppliers or managed services cannot expose implementation details.3

Challenge 2: representing cryptographic context consistently

Even complete discovery does not guarantee useful records. The same cryptographic function may appear under different names across source code, configuration, certificates, protocol profiles, vendor documentation, and operational tools. Teams must decide how to represent algorithms, modes, key types, protocols, implementations, libraries, providers, certificates, keys, data uses, and dependencies without confusing a product with the cryptography it invokes. The cited CycloneDX evidence establishes support for CBOMs and multiple exchange formats, but it does not establish that all tools interpret every cryptographic concept identically.1

Context also changes the meaning of a finding. NIST states that key-management metadata may include the identity of a person or system associated with a key and the information that person is authorized to access. It describes metadata as crucial to applications and protocols even though it does not appear in cryptographic algorithms. This means a CBOM should be connected to identity, authorization, system, data, and lifecycle information where appropriate, while protecting sensitive details through governed distribution.2

Challenge 3: ownership, sharing, and change control

A CBOM crosses organizational boundaries. Application teams know implementation details; infrastructure and platform teams know deployment context; security teams assess risk; procurement teams manage suppliers; and business owners understand data criticality. Without assigned responsibilities, records become stale or disputed. CISA’s SBOM evidence emphasizes authorship, software producers, operators, sharing, and the need for information that supports decisions. Although that guidance concerns SBOMs, its governance lesson applies to a cryptographic inventory: every record needs a producer, consumer, and maintenance path.3

Distribution is another challenge. A CBOM can contain sensitive information about security architecture, key roles, cryptographic dependencies, and technology weaknesses. The cited CISA update says access control was removed as a standalone minimum element and incorporated into distribution and delivery, while also describing known or redacted information. This supports treating dissemination, audience, redaction, and explanation of unavailable data as part of the delivery design rather than as an afterthought.3

Change control must accommodate updates. CISA’s 2025 evidence describes replacing an accommodation-of-mistakes element with accommodation of updates to SBOM data, reflecting improved data quality and the expectation that changes to data should be managed. For CBOMs, updates may follow releases, configuration changes, certificate rotation, key rollover, provider changes, protocol changes, supplier updates, or discovery of previously unknown cryptography.3

Challenge 4: converting inventory into prioritized action

The useful output of a CBOM is not the count of algorithms; it is a defensible sequence of decisions. CISA states that SBOM analysis can map data to other sources so organizations can leverage data, intelligence, and actions. For CBOM operations, relevant correlations may include asset criticality, protected-data lifetime, exposure, supplier status, implementation location, key-management state, vulnerability or advisory information, and migration dependencies. The evidence supports the analytical direction, but it does not prescribe a particular scoring formula.3

Prioritization should account for long-term confidentiality and high-impact environments. The joint quantum-readiness fact sheet gives priority to high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. It also says that an inventory of quantum-vulnerable technology and associated data criticality enables risk assessment and migration prioritization. These criteria can help distinguish an exposed, high-consequence dependency from a lower-priority technical occurrence.4

Challenge 5: crypto agility and post-quantum migration

A CBOM becomes especially valuable when algorithms or implementations must change. NIST CSWP 39 Update 1 defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. The paper discusses approaches, challenges, tradeoffs, and operational mechanisms. This means an inventory should support dependency tracing and transition planning, not merely identify current cryptographic use.5

Migration is technically and operationally risky. NIST key-management guidance says that changing algorithms requires analyzing consequences, including potentially significant modifications for new key sizes or block sizes, reviewing retained security measures, evaluating the change before implementation, testing before deployment, training personnel, and taking care during implementation and transition. These considerations make compatibility, performance, interoperability, operational procedure, and rollback material CBOM-adjacent information.2

The joint quantum-readiness guidance recommends creating a project-management team, establishing a roadmap, and identifying current reliance on quantum-vulnerable cryptography. It advises engaging vendors about their quantum-readiness roadmaps, including when and how commercial products will provide updates or upgrades and the expected migration cost. Cloud customers are likewise advised to engage cloud providers about their roadmaps and later focus on configuration changes or application updates when standards are available.4

Supplier dependence can be a decisive constraint. The guidance says custom-built older products are likely to require the most effort to make quantum-resistant, while vendor engagement is critical for commercial off-the-shelf products. It recommends viewing migration as an IT/OT modernization effort. A CBOM process should therefore capture supplier, product, version, deployment, roadmap, and upgrade dependencies where those facts are available, while clearly distinguishing supplier assertions from independently verified observations.4

Challenge 6: key lifecycle and operational drift

Cryptographic records age as keys and systems move through lifecycle states. NIST describes four key-management phases: preoperational, operational, post-operational, and destroyed. It also explains that key-management metadata is necessary for applications to select appropriate keys. A CBOM that is disconnected from key states, rotation, retirement, and destruction can present an incomplete picture of current exposure or historical obligations.2

NIST gives suggested cryptoperiods for particular key types while noting that longer or shorter periods may be warranted depending on the application and environment. For private and public authorization keys, the cited evidence recommends no more than two years, while explicitly preserving the possibility that circumstances justify a different period. This is an example of why a CBOM should record applicable policy and rationale rather than turning one recommendation into an inflexible universal rule.2

A practical CBOM operating workflow

An enterprise can organize CBOM work as a controlled cycle. First, define scope: systems, environments, suppliers, cryptographic functions, and the business or regulatory decisions the inventory must support. Second, discover cryptography using code, configuration, protocol, asset, hardware, firmware, and supplier evidence. Third, normalize records and preserve provenance, confidence, timestamps, and known unknowns. Fourth, enrich records with owners, data criticality, security life, exposure, implementation, key-management context, and lifecycle state. [claim-05432

Fifth, analyze and prioritize. Correlate the CBOM with asset, vulnerability, advisory, supplier, and business-impact information; then identify actions such as configuration correction, key rotation, compensating control, upgrade, replacement, or additional investigation. Sixth, plan changes with vendors and internal teams, especially for custom-built, COTS, cloud, OT, and long-lived systems. Seventh, evaluate, test, train, deploy, and monitor the transition. Eighth, update the CBOM when software, configuration, keys, certificates, protocols, suppliers, or lifecycle states change. [claim-11324

Implementation considerations and useful measures

Implementation should be measurable without reducing the program to a single completeness percentage. Useful measures include the proportion of in-scope systems and suppliers assessed; the proportion of records with an identified owner and source; the proportion with implementation and security-function context; the age of records; the number of unresolved known unknowns; the time from discovery to triage; and the time from a migration decision to tested deployment. These are operational measures proposed from the workflow; the cited sources do not mandate them.3

• Coverage: which IT, OT, cloud, product, protocol, hardware, firmware, and supplier populations have been assessed?
• Quality: which records have provenance, timestamps, confidence, lifecycle status, and enough context for analysis?
• Actionability: how many findings have an accountable owner, priority, decision, due date, and documented rationale?
• Agility: can teams identify affected dependencies, test a replacement, train operators, and preserve ongoing operations?
• Freshness: how quickly do releases, configuration changes, key events, and supplier updates reach the inventory?
• Readiness: which high-impact or long-confidentiality systems depend on quantum-vulnerable cryptography, and what roadmap exists for them?

Interoperability should be tested rather than assumed. CycloneDX supports CBOMs and provides JSON, XML, and protocol-buffer standards, but the evidence does not say that a format alone solves semantic differences, missing fields, provenance, authorization, or analysis integration. Teams should conduct representative import, export, validation, and round-trip tests using their actual tools and records.1

Conclusion

The common CBOM challenge is not producing an inventory file; it is making cryptographic use sufficiently visible, contextualized, governed, current, and actionable to support security and migration decisions. Discovery must span the estate, records must preserve uncertainty and operational context, and ownership must extend across internal teams and suppliers. Analysis should prioritize high-impact and long-confidentiality systems, while crypto-agility and post-quantum planning should connect inventory to tested, staged change. Standards can provide structure, but durable value comes from the operating workflow around the CBOM.345