SBOM vs HBOM vs CBOM: Which Bill of Materials Each Rule Demands

Teams are now asked for three different bills of materials, software, hardware and cryptographic, and most cannot say which one a given regulator, customer or asset actually requires. The result is over-collection or the wrong artefact handed to the wrong reviewer. This guide is a decision guide: it maps each major driver (the EU Cyber Resilience Act, US federal procurement and post-quantum memoranda, FDA cyber device rules, PCI DSS and UK NCSC migration timelines) and each asset class to the bill of materials it really demands. It is written for supply chain, product security, procurement and post-quantum programme leads. Format depth lives in the linked guides: the SBOM Guide, the Hardware and Firmware SBOM Guide and the Cryptographic Inventory and CBOM Guide.

Key takeaways

• Only the SBOM is written into binding law today. The EU Cyber Resilience Act (Annex I Part II) and US FD&C Act section 524B both name a software bill of materials; neither names an HBOM or a CBOM.
• The CBOM is driven by post-quantum policy, not product law. US OMB M-26-15 (24 June 2026) tells federal agencies to populate a central Cryptographic Bill of Materials, and NCSC sets 2028 as the date for discovery.
• The HBOM is a procurement and sanctions tool. It answers "which parts, from which supplier, made where", which is what NDAA Section 889 screening and counterfeit checks need; US federal policy points to the CISA HBOM framework as a reference, not a mandate.
• Asset class decides more than sector. Pure software needs an SBOM, connected devices need SBOM plus hardware data, and anything holding long-lived secrets or signatures needs cryptographic inventory.
• One CycloneDX pipeline can carry all three. Build them from the same component graph so the CBOM inherits the SBOM's component identities instead of becoming a separate spreadsheet.

The short answer

If you make or sell software or a product with digital elements into the EU, you need an SBOM, kept current and available to market surveillance authorities on request. If you sell connected medical devices into the US, you need an SBOM in the premarket submission. If you are a US federal agency or sell to one, you need a cryptographic inventory feeding a CBOM, and you should expect contracts to ask for SBOMs case by case. If you buy or sell physical equipment where origin matters (telecoms, video surveillance, defence, critical infrastructure), you need HBOM-style hardware data, even though no law names it. Most product companies end up needing an SBOM everywhere, a CBOM for anything that handles keys or signatures with a long life, and an HBOM only for hardware lines.

What each one answers

The three artefacts look alike because they share a structure (components, identifiers, relationships), but each answers a different risk question. Picking the wrong one usually means the reviewer's question goes unanswered even though a document was supplied.

For the field-level difference between SBOM formats see SPDX vs CycloneDX; for the AI extension of the same idea see SBOM vs AIBOM.

Which regulator demands which bill of materials

This table reflects the primary texts as checked in November 2026. Status lines change, so confirm against the source before relying on a date.

Two readings matter. First, "SBOM required" in the CRA means a maintained internal record that an authority can request, not a document you must publish. Second, no driver above demands a CBOM from a private product maker, yet three of them (CRA encryption duties, federal vendor requirements under M-26-15 and PCI DSS cipher reviews) are much easier to meet with one. For the CRA in full see the EU Cyber Resilience Act Guide; for dated PQC obligations across countries see the Post-Quantum Cryptography Deadlines Tracker.

Which asset class needs which

Sector rules tell you the minimum; the asset tells you what is useful. Use this matrix to decide per product line or per system.

SBOM: threat model, failure modes and controls

Threat model: a known-vulnerable or malicious component ships inside your product and you cannot tell customers or regulators quickly whether they are affected. The SBOM shortens that question from weeks to minutes.

Architecture in words: generate at build from the dependency graph, sign and store per release, correlate against vulnerability feeds, and publish exploitability decisions as VEX so consumers can filter noise. Operational detail is in SBOM operations and the VEX Guide.

• Failure mode, top-level only: the CRA wording requires at least top-level dependencies, and many teams stop there. Transitive components are where most vulnerable code sits.
• Failure mode, stale on request: an SBOM generated once for certification no longer matches the shipped build when the authority asks.
• Failure mode, firmware gap: device makers produce an SBOM for the companion app and not for the firmware image.
• Controls: per-build generation, signing, retention for the support period, and a request process that can produce the SBOM for any supported version.

HBOM: threat model, failure modes and controls

Threat model: a product contains parts from a prohibited or untrusted supplier, counterfeit components, or a single-source part exposed to disruption. These are sourcing questions that no software inventory can answer.

Architecture in words: the supplier maintains component records with manufacturer, part number and location fields following the CISA HBOM framework, and shares them under NDA or through a portal, scoped to the use case the purchaser states (compliance, security or availability). The purchaser joins HBOM data to sanctions and covered lists. See the NDAA Section 889 and FCC Covered List Guide for the screening side.

• Failure mode, model number is not a build: approved alternate parts mean two units with the same model number can differ. An HBOM per model, not per lot, gives false comfort.
• Failure mode, asking for everything: purchasers request full bills down to passive components; suppliers refuse or delay. The CISA framework's discipline is to state the use case first.
• Failure mode, firmware orphaned: the HBOM lists a chip but not the firmware on it, so a firmware flaw cannot be traced to products. Pair it with a firmware SBOM; see the Firmware and Boot Security Guide.
• Controls: use-case-scoped requests, lot-level variation clauses in contracts, and hardware data held under access control because it is commercially sensitive.

CBOM: threat model, failure modes and controls

Threat model: data with a long confidentiality life is captured now and decrypted later by a quantum-capable adversary, or a deprecated algorithm, weak key or expired certificate causes a compromise or an outage. You cannot migrate what you have not found.

Architecture in words: M-26-15 describes the pattern: discover through software composition analysis of SBOMs, static and dynamic code analysis for cryptographic calls, and network scanning for protocols and cipher suites, then feed one central CBOM that gives a near real-time view. The SBOM supplies the component identities; the CBOM adds algorithms, keys, certificates and protocols and the dependencies between them.

• Failure mode, library present treated as algorithm in use: a crypto library that provides many algorithms inflates exposure if every algorithm is counted.
• Failure mode, one-off spreadsheet: the inventory is built once for a deadline and decays. M-26-15 expects it to be continuously updated.
• Failure mode, ignoring supplier crypto: SaaS, appliances and cloud services hold much of the cryptography; without contract clauses the inventory has holes exactly where control is weakest.
• Failure mode, keys without owners: keys and certificates appear in the CBOM with no accountable owner, so migration stalls. Treat them as machine identities with owners; see Post-Quantum Migration for NHIs Guide.
• Controls: automated discovery, per-release CBOM generation, supplier disclosure clauses, and prioritisation by data lifetime as NCSC describes.

Where identity fits

A CBOM is, in practice, an inventory of non-human identity material: TLS certificates, code signing keys, JWT signing keys, SSH host keys and the service accounts that use them. The CycloneDX related-crypto-material type records keys, tokens and credentials with their state and expiry, which overlaps directly with secrets and certificate inventories. Link the two by owner and system so that a quantum-vulnerable key is also a known identity with a rotation path. The Machine Identity, PKI and Certificate Lifecycle Guide covers that lifecycle.

Decision criteria and trade-offs

• Start with the SBOM when: you ship software or firmware into the EU or US medical market, or you need faster vulnerability response. It is also the input both other artefacts reuse.
• Add the CBOM when: you sell to US agencies, hold data that must stay confidential beyond about ten years, sign firmware or code with long-lived keys, or face PCI DSS cipher reviews.
• Add the HBOM when: you make or buy physical equipment where supplier origin, counterfeit risk or part availability is a real business risk.
• Trade-off, depth against cooperation: deeper bills reveal more, but suppliers share less when requests are unscoped. Ask for what the use case needs.
• Trade-off, publish against protect: SBOMs are increasingly shared, while HBOMs and CBOMs reveal sourcing and cryptographic weaknesses. Share them under access control.
• Small against large organisations: a small software vendor needs an SBOM pipeline and a short list of its own keys and protocols; a large manufacturer needs all three, joined in one platform with supplier intake. See the SBOM management platform buyer's guide.

Worked scenarios

Scenario 1, EU industrial router maker. The CRA requires an SBOM for each supported firmware release, available on request from 11 December 2027, with vulnerability reporting duties under Article 14 from 11 September 2026. The maker also sells to US utilities that screen for covered telecoms equipment, so it maintains HBOM records for the main board and radio modules using CISA framework fields, shared per customer under NDA. Because routers terminate VPNs and hold device certificates for many years, the maker generates a CBOM per firmware release from the same CycloneDX pipeline, flagging RSA and elliptic curve key exchange for its post-quantum roadmap.

Scenario 2, SaaS provider bidding for a US federal contract. M-26-05 means the agency may write an SBOM-on-request clause, covering the runtime production environment. M-26-15 means the agency must include the provider's cryptography in its own CBOM and PQC plan, so expect a questionnaire on TLS versions, key exchange, signing algorithms and the timeline to TLS 1.3 and hybrid post-quantum key exchange. No HBOM is relevant. The provider's best move is an internal CBOM built from its SBOMs plus a scan of its endpoints, so answers are evidence-based rather than survey-based. See the Hybrid Post-Quantum TLS Key Exchange Guide.

Scenario 3, hospital buying infusion pumps. The manufacturer supplies the 524B SBOM through its disclosure package; the hospital ingests it for vulnerability matching. The hospital asks for hardware data only for parts obsolescence planning, and for cryptographic disclosure on the pump's wireless and update-signing mechanisms because the devices will outlive many algorithm transitions. See the MDS2 and Medical Device SBOM Guide for Hospitals.

How to implement

1. Map drivers per product line: list each product, its markets and its buyers against the regulator table above. Record which artefact is legally required and which is contractually expected.
2. Build one component graph: standardise on a format that can carry software, hardware and cryptographic components; CycloneDX does all three in one schema. Give every component a stable identifier.
3. Automate the SBOM first: generate per build, sign, store per release. Pilot on one product, measure completeness, then extend.
4. Layer the CBOM: run cryptographic discovery against the same releases and live endpoints, merge results by component identifier, and assign owners to keys and certificates.
5. Add hardware data for hardware lines: agree use cases with procurement, collect CISA framework fields from suppliers, and handle lot variation in contracts.
6. Set sharing rules: define who receives each artefact, under what terms, and how requests from authorities are answered within the time you commit to.
7. Roll back safely: if a new generator or discovery tool drops completeness, keep the previous pipeline producing release artefacts in parallel until quality metrics recover.

Detection and measurement

• SBOM coverage: percentage of supported releases with a signed, current SBOM including transitive dependencies.
• Request turnaround: time to produce the correct SBOM for any supported version on request.
• CBOM coverage: percentage of high-value systems with automated cryptographic discovery and owners assigned to every key and certificate.
• Quantum-vulnerable share: proportion of key establishment and signature uses still on quantum-vulnerable algorithms, tracked quarterly.
• Supplier disclosure rate: percentage of in-scope suppliers that have provided SBOM, cryptographic or hardware data as contracted.
• Hardware screening hits: number of covered-supplier or counterfeit findings resolved before deployment.

Common failure patterns

• Treating "BOM" as one deliverable: a team sends an SBOM to a procurement reviewer who needed supplier origin data, and the review stalls.
• Collecting all three everywhere: HBOM requests for pure software vendors and CBOMs for low-risk internal tools waste effort that should go to high-value systems.
• Separate tools, separate identities: SBOM, HBOM and crypto inventories in different systems with different component names cannot be joined when an incident crosses them.
• Relying on rescinded policy: contracts still cite M-22-18 attestation duties after M-26-05 rescinded it, creating confusion about what suppliers owe.
• Waiting for a law to name the CBOM: programmes defer cryptographic inventory because no product law requires it, then face the NCSC 2028 discovery milestone and federal vendor questionnaires unprepared.

Framework mapping

For the wider supply chain risk programme see the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.

Practitioner checklist

• Map every product line to its markets and record which bill of materials each driver legally requires.
• Generate a signed SBOM per build, including transitive dependencies and firmware images.
• Confirm you can produce the SBOM for any supported version on an authority's request.
• Run automated cryptographic discovery on high-value systems and merge results into a CBOM keyed to SBOM component identifiers.
• Assign an owner to every key and certificate in the CBOM.
• Collect HBOM data only for hardware lines, scoped to a stated use case, with lot variation handled in contracts.
• Add SBOM, cryptographic disclosure and, where relevant, hardware data clauses to supplier contracts.
• Remove references to rescinded federal memoranda from contract templates.
• Share HBOMs and CBOMs only under access control.
• Report coverage and quantum-vulnerable share quarterly.

Standards and references

• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• Cornell LII: 21 U.S.C. 360n-2, Ensuring cybersecurity of devices
• OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
• OMB: M-26-15 Execution of the Migration to Post-Quantum Cryptography
• OMB: M-23-02 Migrating to Post-Quantum Cryptography
• NCSC: Timelines for migration to post-quantum cryptography
• CISA: Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management
• OWASP CycloneDX: Cryptography Bill of Materials

Related NHI Mgmt Group resources: SBOM Guide · Hardware and Firmware SBOM Guide · Cryptographic Inventory and CBOM Guide · Post-Quantum Cryptography Migration Guide · Supplier SBOM Request Template