Enterprise CBOM Report

Scope, date, and evidence method

This article is a dated primary-source desk review prepared from the cited source set. It synthesizes current or final materials attributed to NIST, CISA, NSA, the UK National Cyber Security Centre, and the OWASP Foundation. The review does not report original interviews, surveys, tests, or measurements, and it does not estimate how many enterprises have deployed CBOMs. Statements below are limited to what the cited passages support; where the evidence describes recommended practice, the article presents it as guidance rather than as proof of implementation or effectiveness.13

The evidence set covers eight source records. It includes NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, dated February 26, 2024; the NIST PQC overview, published August 13, 2024; the CISA, NSA, and NIST joint fact sheet dated August 17, 2023; the NCSC migration guidance dated March 20, 2025; and OWASP CycloneDX ECMA-424 material. It also includes a NIST crypto-agility paper marked final, NIST CSWP 39 Update 1, with cited publication and update dates of December 19, 2025 and June 29, 2026. Those dates and statuses are retained here rather than treated as interchangeable evidence.362

What an enterprise CBOM report represents

OWASP CycloneDX describes itself as a full-stack bill-of-materials standard for supply-chain capabilities and explicitly lists a cryptography bill of materials, or CBOM, among its supported formats. The cited passage also says the project provides standards in JSON, XML, and protocol buffers. This supports using CBOM as a recognized category of bill-of-materials representation, but it does not by itself establish that every enterprise report must use CycloneDX or that a CBOM alone proves an organization is quantum-ready.1

For enterprise purposes, the useful interpretation is broader than an algorithm register. A report should connect cryptographic observations to the assets and services that depend on them, the data or functions they protect, the responsible business or technical owner, and the path to replacement or mitigation. This interpretation follows the cited guidance that inventories should provide visibility into cryptography in IT and OT systems, identify associated criticality, and support risk assessment and migration prioritization.23

The NIST CSF 2.0 evidence is relevant to governance because it calls for inventories of hardware, software, services, and systems, inventories of supplier services, maintained representations of network communication and data flows, and asset prioritization based on classification and criticality. It also describes profiles as scoped collections of organizational information that can be used to analyze gaps and create action plans. A CBOM report can therefore function as a scoped governance artifact within a wider risk-management process, rather than as an isolated technical export.3

Minimum content for an enterprise CBOM report

The evidence supports a staged record rather than a one-time inventory. Begin by defining the boundary: organization-wide, a business service, a public-key infrastructure, a cloud estate, a plant, or another explicit scope. Record the assumptions behind that boundary. NIST CSF 2.0 says profiles may have different scopes and should document high-level facts and assumptions; it also identifies policies, risk priorities, resources, enterprise risk profiles, business-impact information, requirements, tools, safeguards, and work roles as potentially relevant inputs.3

• Asset or service identity, owner, environment, and business function.
• Cryptographic use, including algorithms, protocols, certificates, keys, libraries, modules, and relevant implementation locations where known.
• Technology context: application, operating system, server, workstation, network device, mobile device, IoT or ICS device, firmware, cloud service, or supplier product.
• Version, patch level, lifecycle state, and upgrade or replacement constraints where available.
• Dependencies and communication paths, including external access and supplier relationships.
• Protected data or function, confidentiality and integrity requirements, retention or secrecy lifetime, and business or safety impact.
• Discovery method, evidence confidence, date observed, unresolved gaps, and the person or team responsible for validation.
• Migration status, target approach, vendor roadmap, testing needs, interim controls, and decision criteria for retiring traditional public-key cryptography.

The NCSC evidence specifically recommends understanding system nature before building a detailed formal asset register, quantifying scale where possible, capturing version information and patch levels, and identifying dependencies between components and services. It names applications, communications hardware, mobile devices, servers and workstations, IoT and ICS devices, end-user tokens, and field devices or sensors as relevant categories. The report should therefore make missing coverage visible instead of implying that an unobserved system is cryptographically clean.5

From discovery to risk-based prioritization

CISA, NSA, and NIST state that organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography in deployed products, applications, and services. Their cited guidance recommends an inventory led by IT and OT procurement experts, with engagement from supply-chain vendors and cybersecurity and privacy risk managers. The same passage connects an inventory of quantum-vulnerable technology and data criticality with the beginning of risk assessment and migration planning.2

Prioritization should not be reduced to algorithm names. The reviewed guidance says priority should be given to high-impact systems, ICSs, and systems with long-term confidentiality or secrecy needs. NIST’s “harvest now, decrypt later” explanation adds an important temporal consideration: encrypted information may be collected today for possible decryption in the future, particularly where secrets retain value for many years. Inference: a CBOM report should rank both the technical exposure and the time during which protected information or functions remain valuable.26

A practical priority record can distinguish observation from inference. “Observed” might mean a discovery tool, configuration record, certificate inspection, product statement, or owner interview identified a public-key algorithm in a named system. “Inferred” might mean that the system’s data lifetime, external exposure, or dependency structure creates a higher migration concern requiring validation. The cited evidence supports this separation because it emphasizes visibility, criticality, dependencies, risk assessment, and vendor engagement, but it does not provide a universal scoring method.132

IT, OT, field devices, and supplier coverage

The enterprise boundary must include more than centrally managed servers. NCSC evidence describes OT and IT convergence and says ordinary enterprise IT considerations apply in industrial control contexts. Remote logins to ICS IT zones need secure authentication, while wireless field OT devices and sensors may have especially important integrity requirements even where confidentiality does not require strong cryptographic protection. Faulty sensor readings or commands can lead to ICS failures, according to the cited passage.5

Industrial IoT devices can be resource-constrained, difficult to service, embedded in larger products, non-replaceable, dependent on proprietary or not-yet-compatible protocols, or not upgradeable. Internet-connected devices may provide an entry point into control networks and onward into an enterprise IT zone through a DMZ. These observations support separate CBOM fields for device constraints, serviceability, protocol compatibility, network position, and replacement path. They do not establish that every such device is vulnerable or that a particular migration design will work.5

Supplier and cloud coverage is equally important. NIST CSF 2.0 calls for supplier-service inventories and supply-chain security practices integrated into cybersecurity and enterprise risk management. CISA, NSA, and NIST recommend asking vendors how they address quantum-readiness, while their guidance says cloud customers should understand a provider’s roadmap and how PQC will be enabled through configuration or application updates. A CBOM report should therefore record supplier assertions as evidence to validate, not silently convert them into confirmed product capabilities.2

Post-quantum standards, coexistence, and crypto agility

NIST’s cited project material says that in August 2024 it released three principal post-quantum cryptography standards as FIPS: FIPS 203 for ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 for ML-DSA, a module-lattice-based digital signature standard; and FIPS 205 for SLH-DSA, a stateless hash-based digital signature standard. The same evidence says organizations should begin applying the standards and that NIST is developing additional standards as backups or alternatives.7

The evidence also records continuing work: NIST expects ML-KEM, ML-DSA, and SLH-DSA to provide the foundation for most deployments, while Falcon and HQC were selected for ongoing standardization. This is why an enterprise report should preserve the exact standard, implementation, status, and date observed. It should not imply that a selected or standardised algorithm is automatically deployed, interoperable, suitable for every device, or validated in the organization’s environment.5713

NCSC guidance says most systems will need traditional public-key cryptography and PQC to coexist for a period because PQC can introduce compatibility-breaking changes. It recommends seeking cryptographic agility: the ability to support alternative algorithm suites and determine when traditional algorithms can cease to be supported. NIST CSWP 39 Update 1 defines crypto agility as capabilities to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. Together, these sources support treating agility evidence—configuration flexibility, upgrade mechanisms, testability, and retirement criteria—as a first-class CBOM field.574

Operating model and report refresh

A credible CBOM report needs ownership and a refresh cycle. Procurement teams can obtain supplier and product information; application and infrastructure owners can validate implementations; OT owners can assess physical and operational constraints; privacy and risk managers can evaluate data criticality; and governance leaders can approve prioritization and residual-risk decisions. This division is an inference from the cited recommendations for IT and OT procurement leadership, vendor engagement, risk-manager participation, organizational profiles, roles, responsibilities, and enterprise risk integration.32

Refresh triggers should include new or replaced systems, certificate and key lifecycle events, software or firmware upgrades, supplier changes, newly discovered dependencies, changes to data-retention or secrecy requirements, and changes in PQC implementation readiness. The report should retain historical observations so that migration decisions can be audited. The cited evidence supports continuous planning and staged migration, but it does not prescribe a particular reporting cadence or tool.4513

Conclusion

The evidence supports an enterprise CBOM report as a structured bridge between cryptographic visibility and enterprise action. Its value comes from scope, coverage, context, provenance, criticality, dependencies, supplier evidence, migration status, and explicit uncertainty—not from an algorithm list alone. Organizations should begin with a bounded inventory, include IT, OT, cloud, field devices, and suppliers, prioritize high-impact and long-secrecy systems, and plan for coexistence and crypto agility. The review does not establish market adoption, costs, or a single required CBOM format; those remain evidence gaps requiring organization-specific validation.23157