An SBOM inventories the software components in a product. An HBOM, or hardware bill of materials, inventories the physical parts such as processors, modules and boards, and ties them to the firmware they run. Embedded and IoT teams often need both, linked together.
Definitions
A software bill of materials lists the code in a product: libraries, frameworks, operating systems and their versions.
A hardware bill of materials describes physical components. CycloneDX, the OWASP standard, describes its HBOM capability as a way to "inventory hardware components for IoT, ICS, and other types of embedded and connected devices". Its page says this covers processors, embedded systems, IoT devices and industrial control systems, and that documenting hardware attributes alongside associated firmware gives a holistic view that bridges software and hardware security practices.
Side by side
| Question | SBOM | HBOM |
|---|---|---|
| What does it list? | Software components | Physical parts and their firmware |
| Typical entries | Libraries, OS, frameworks | Chips, modules, boards, devices |
| Who maintains it? | Software and build teams | Hardware, sourcing and firmware teams |
| Main security use | Match components to vulnerabilities | Track which part and firmware version is in which unit |
| Link to the other | Software that runs on a device | The device that runs the software |
Why a firmware team needs both
A vulnerability advisory often names a software component. Your SBOM tells you whether you ship it. Then the next question is where. If the same library sits in firmware for two different radio modules, and only one module ships in the model your customer owns, you need the hardware side to answer.
The CycloneDX specification expresses the bridge in its component types. A hardware device containing firmware should have a component for the hardware and a second component, type firmware or operating-system, for the software. That is the link between the two documents, or between two sections of one document.
Steps to start
- Begin with the software. Generate the SBOM per firmware release first, because that is where advisories land.
- List each distinct hardware part by supplier, model and revision. A spreadsheet export from your sourcing system is a fine starting point.
- Record which firmware version each part runs, per product model.
- Link them in one CycloneDX file, or keep two files that share stable identifiers.
- Update the hardware list when a supplier changes a part, not only when the software changes.
Limits and honesty
Many teams will not have a complete HBOM for a long time, and that is fine. A partial one that is accurate beats a complete one that is guessed. Do not publish hardware details you have not verified, and check what you are allowed to disclose to customers.
Try a related step
Software inventory is the part Safeguard automates. Safeguard generates SBOMs and scans dependencies from your repositories. Hardware records stay with your sourcing and firmware teams. You can start with a free scan.
Quick check
Does an HBOM replace an SBOM?
No. They answer different questions. The HBOM says what parts are in a unit. The SBOM says what software is in them.
Which standard supports hardware?
CycloneDX documents an HBOM capability and has device and firmware component types.
Sources
Last reviewed: 19 October 2026.
