Key takeaways
- A sourcing note: CISA's primary HBOM Framework PDF and its companion fact sheet PDF could not be rendered as extractable text by this guide's fetch tooling.
- Of the two dominant SBOM formats, CycloneDX is the one built to carry hardware data natively.
- Record entity and location data for key components, not just part numbers — CISA's taxonomy devotes real weight to supplier identity and geography, the fields a buyer doing supply-chain-risk review will ask for first.
An HBOM (Hardware Bill of Materials) is a structured inventory of the physical components — processors, chipsets, modules, boards — that a product is actually built from, plus the firmware bound to each one, published by CISA's Information and Communications Technology (ICT) Supply Chain Risk Management Task Force as a formal framework on 25 September 2023. Where a software SBOM answers "what code is in this firmware image," an HBOM answers "what physical parts, from which suppliers, make up this product" — a question device buyers, regulators and risk teams increasingly ask separately from the software question.
A sourcing note: CISA's primary HBOM Framework PDF and its companion fact sheet PDF could not be rendered as extractable text by this guide's fetch tooling. Facts about the framework's structure, use-case categories and exact field counts below are drawn from CISA's own HTML press release (fetched directly) for the parts it covers, cross-checked against secondary technical analysis for the Appendix-level detail CISA's press release does not itself spell out. Confirm exact field names and category boundaries against CISA's own PDF (linked in sources) before building a data pipeline or compliance process on this guide alone.
Why hardware needs its own bill of materials
A software SBOM, built from a firmware image or a build pipeline, inventories libraries, packages and components at the code level — the question Executive Order 14028 and the NTIA/CISA Minimum Elements process were built to answer for software supply chains. It says nothing about the physical hardware a device ships with: which vendor made the main processor, whether a module was sourced from a single-source supplier in a geography a buyer wants to flag, or whether the same radio or security chip recurs across a dozen otherwise-unrelated product lines. CISA's ICT SCRM Task Force built the HBOM Framework to close that specific gap, with a scope that explicitly extends to the firmware tied to each hardware part — the framework's own stated goal, per CISA's press release, is "a consistent and repeatable way for vendors and purchasers to communicate about hardware components, enabling effective risk assessment and mitigation in the supply chain."
What the framework defines
CISA's HBOM Framework, developed by the Task Force's HBOM Working Group and published 25 September 2023, is structured in three parts:
| Part | What it covers |
|---|---|
| Appendix A — Use-case categories | Groups of purchaser needs an HBOM can serve, reported by secondary analysis as spanning compliance, security and availability risk assessment; to be confirmed against CISA's own document |
| Appendix B — Format | A consistent structure for producing and exchanging HBOMs, so documents from different vendors are comparable |
| Appendix C — Data field taxonomy | Named attributes for hardware components; secondary technical analysis of the PDF reports 47 fields across seven categories (header, finished-good product, entity name, entity location, component part information, component part details, production details) — to be confirmed against CISA's own Appendix C |
The framework is explicit that it is voluntary: CISA states that adopting it does not by itself demonstrate compliance with any specific US regulation, the same posture the original 2021 NTIA Minimum Elements took for software SBOMs before elements of that model found their way into binding procurement and reporting rules. OMB's January 2026 Memorandum M-26-05 on software and hardware risk management cites the HBOM Framework as a resource agencies should draw on alongside CISA's SBOM guidance — see our attestation form guide for the fuller M-26-05 picture — without converting it into a mandatory HBOM filing requirement in its own right.
Where CycloneDX and SPDX stand today
Of the two dominant SBOM formats, CycloneDX is the one built to carry hardware data natively. Its own specification repository lists HBOM as one of the bill-of-materials types the format covers, alongside SBOM, SaaSBOM, CBOM and AI/ML-BOM — one data model extended across component types rather than a separate standard per BOM type, the same pattern this guide's AI-BOM and CBOM guides describe for their respective component types. A device component type ("a hardware device such as a processor or chip-set") has existed since CycloneDX 1.0, and a dedicated firmware component type ("a special type of software that provides low-level control over a device's hardware") was added in CycloneDX 1.2 (May 2020) — together, a device component nesting a firmware component is the standard CycloneDX pattern for describing a hardware part and the software bound to it, matching CISA's own framing of hardware-plus-firmware. SPDX, by contrast, has no dedicated hardware profile as of SPDX 3.0.1, which is a practical reason vendors building an HBOM today more often reach for CycloneDX. Even there, secondary technical analysis reports that only a minority of CISA's 47 named fields map cleanly onto existing CycloneDX or SPDX properties — entity-location fields in particular, which CISA's taxonomy treats in some depth for supply-chain-geography risk, have no close equivalent in either schema and require custom properties. See our CycloneDX vs SPDX guide for how the two formats compare more broadly.
A workable starting point
Start from what you can verify today: the main processor, any security or crypto chip, radio/connectivity modules, and the board(s) they sit on — the component types CISA's framework and CycloneDX's devicetype both treat as the core of a hardware inventory.Pair every hardware component with its firmware, the same device-plus-firmware pairing CISA's framework and CycloneDX's device/firmwarecomponent types both model, rather than tracking hardware and software inventories as unrelated documents.Record entity and location data for key components, not just part numbers — CISA's taxonomy devotes real weight to supplier identity and geography, the fields a buyer doing supply-chain-risk review will ask for first. Pick CycloneDX over SPDXif you need one machine-readable format that already has a named path for hardware, software and (if relevant) cryptographic and AI components in the same document — see CycloneDX vs SPDX. Treat it as voluntary but increasingly expected, not a regulatory filing — buyers and OMB guidance alike are starting to ask for it as a supply-chain-risk artifact even though no rule requires the CISA format by name today.
An HBOM only has value once it's actually populated from real procurement and bill-of-materials data, which is exactly where most device makers' hardware records are weakest — scattered across supplier POs and CAD exports rather than a structured, machine-readable document. SoftWSP builds SBOMs (and the hardware-and-firmware pairing an HBOM needs) directly from a firmware image and the bill-of-materials a device maker already has, without requiring source access: see device firmware security.
This guide draws on CISA's own HTML press release (fetched directly), the CycloneDX specification repository (fetched directly), and secondary technical analysis of CISA's primary HBOM Framework PDF, which this guide's fetch tooling could not render as extractable text. This guide is not a substitute for CISA's own Appendix A–D text, OMB's own M-26-05 memorandum, or a supply-chain counsel's review of a specific procurement requirement.
Sources
- CISA: CISA Releases Hardware Bill of Materials Framework (HBOM) for Supply Chain Risk Management (press release, 25 September 2023)
- CISA: A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management (primary PDF, ICT SCRM Task Force HBOM Working Group)
- CISA: HBOM Framework Fact Sheet (508-compliant PDF)
- CycloneDX: specification repository (GitHub) — BOM types covered, including HBOM
- OMB Memorandum M-26-05, Adopting a Risk-Based Approach to Software and Hardware Security (January 2026)
Frequently asked questions
What is an HBOM, and how is it different from an SBOM?
An HBOM (Hardware Bill of Materials) is a structured inventory of the physical hardware components that make up a product — processors, chipsets, modules, boards and the firmware bound to each of them — as distinct from a [software SBOM](/guides/firmware-sbom/), which inventories code: libraries, packages and the firmware image's software contents. A device typically needs both: the SBOM tells a buyer what software and open-source components ship inside a product's firmware, while the HBOM tells them which physical parts the product is built from, who makes each one, and where. CISA's own framework explicitly scopes HBOMs to also capture the firmware associated with each hardware component, so the two documents overlap at that boundary rather than sitting in fully separate silos.
What does CISA's HBOM Framework actually define?
On 25 September 2023, CISA's Information and Communications Technology (ICT) Supply Chain Risk Management (SCRM) Task Force published "A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management," developed by the Task Force's HBOM Working Group. Per CISA, the framework gives vendors and purchasers "a consistent and repeatable way... to communicate about hardware components, enabling effective risk assessment and mitigation in the supply chain." It is structured in three parts: Appendix A sets out use-case categories (reported by secondary technical analysis as three categories — compliance, security and availability — covering eight total sub-cases; this guide could not independently re-verify that breakdown against CISA's own PDF, which its fetch tooling could not render as extractable text); Appendix B defines a format for consistency across HBOMs; and Appendix C provides a data field taxonomy of component attributes.
How many fields does an HBOM actually have?
Per secondary technical analysis of CISA's framework PDF (not independently re-verified against the primary document for this guide, since the PDF could not be rendered as extractable text by this guide's fetch tooling), the data field taxonomy groups 47 named fields into seven categories: an HBOM header, finished-good product details, entity name, entity location, component part information, component part details, and production details. Treat the exact field count and category breakdown as **to be confirmed** against CISA's own Appendix C before building a data pipeline on it.
Is filing an HBOM legally required?
No federal rule requires an HBOM by CISA's exact name or format, and CISA describes the framework as voluntary — using it does not by itself demonstrate compliance with any specific US regulation. It functions as a reference vendors and purchasers can adopt by agreement, the same voluntary role the original 2021 NTIA Minimum Elements played for software SBOMs before parts of that model were absorbed into binding rules. The framework is cited as a resource (not a mandate) in OMB's January 2026 Memorandum M-26-05 on software and hardware risk management, alongside CISA's separate [SBOM Minimum Elements](/guides/sbom-minimum-elements/) guidance — see our [attestation form guide](/guides/secure-software-development-attestation-form/) for what M-26-05 changed and left in place.
Does CycloneDX or SPDX support HBOMs directly?
CycloneDX is the format most directly aligned: its own specification repository describes CycloneDX as covering "SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX" as a single data model, and the schema has carried a `device` component type ("a hardware device such as a processor or chip-set") since CycloneDX 1.0, with a dedicated `firmware` component type ("a special type of software that provides low-level control over a device's hardware") added in CycloneDX 1.2 (May 2020). An HBOM in CycloneDX is typically modeled as a hardware `device` component with a nested `firmware` component describing the software bound to it — the same device-plus-firmware pairing CISA's framework scopes for. SPDX, by contrast, has no dedicated hardware profile as of SPDX 3.0.1, which is one reason industry commentary on CISA's framework points to CycloneDX as the more complete path to an interoperable HBOM today; per that same secondary analysis, only a minority of CISA's 47 named fields map one-to-one onto either standard's existing properties, with location-related fields in particular requiring custom extensions in both.
In this cluster
