What Is an HBOM? The Hardware Bill of Materials, Explained
What a Hardware Bill of Materials inventories, and why Spectre and Meltdown-class flaws live below what software scanners see.
- An HBOM inventories the physical layer: CPUs, chipsets, storage and network controllers, BMCs, and their firmware versions, not the software running on top of them.
- CISA published a formal HBOM Framework in September 2023, with three parts: use-case categories, a format, and a data field taxonomy for hardware attributes.
- CycloneDX 1.6+ has native hardware support, a 'device' component type for physical parts and a 'firmware' type for what runs on them.
- Firmware CVEs like Spectre, Meltdown, and BMC authentication bypasses sit below the operating system, where software-only SCA and SBOM tools don't look.
- HBOM matters most where hardware has a long service life and is hard to patch: IoT, embedded systems, and industrial control systems.
Your SBOM says you're running a clean, patched Linux image. Your dependency scanner has nothing to flag. And yet the CPU under all of it has a microcode revision from before the Spectre v2 patch, and the baseboard management controller sitting next to it has a known authentication bypass. None of that shows up in a software inventory, because none of it is software. A Hardware Bill of Materials is how you see it.
An HBOM (Hardware Bill of Materials) is an inventory of the physical components your systems run on: processors, chipsets, storage and network controllers, embedded controllers like BMCs, and the firmware that runs on each of them. Where an SBOM answers "what code am I running," an HBOM answers "what silicon am I running it on, and what firmware is on that silicon right now."
HBOM is more standardized than you'd expect
Of the newer BOM types, HBOM is actually one of the better-defined. In September 2023, a CISA task force published a formal HBOM Framework. It's not just guidance. It has three parts: use-case categories that explain why a buyer wants an HBOM, a format for consistency across vendors, and a data field taxonomy, a categorized list of the component attributes an HBOM can capture.
The format side is covered too. CycloneDX 1.6 added native hardware support: a `device` type for physical parts and a `firmware` type for what runs on them. So unlike some of its siblings in the BOM family, HBOM has real footing on both sides. A government framework for the "why." A machine-readable schema for the "how."
That doesn't mean adoption is universal. Most vendors still don't ship an HBOM by default. The standard exists; the practice of publishing one is still catching up, which is exactly why buyers in regulated or high-assurance environments are starting to ask for it.
HBOM vs SBOM: different layer, different blind spots
An SBOM lists the packages and libraries your application depends on. It's built by reading manifests, lockfiles, and container layers. An HBOM lists the physical components underneath all of that: the CPU model and stepping, the storage controller firmware, the network card driver version, the BMC firmware build. It's built by querying hardware, not parsing source.
| SBOM | HBOM | |
|---|---|---|
| Question it answers | What code and packages am I running? | What physical hardware and firmware am I running it on? |
| Scope | Application code, dependencies, licenses | CPUs, chipsets, storage/network controllers, BMCs, firmware |
| Standard | CycloneDX / SPDX | CISA HBOM Framework (2023) + CycloneDX 1.6+ device/firmware types |
| Primary use | Vulnerability and license management | Firmware CVE correlation, supply-chain provenance |
“An SBOM tells you what your software depends on. An HBOM tells you what your software is standing on, and whether that ground is safe.”
The class of bugs an HBOM catches that nothing else does
Spectre, Meltdown, and Rowhammer aren't application vulnerabilities. They're microarchitectural side channels. A CPU speculatively executes instructions and leaks what it saw. DRAM cells leak state to their neighbors. A perfectly patched OS on a CPU with outdated microcode is still exposed. BMCs have the same problem. A BMC is a small independent computer inside a server that handles remote management. A BMC authentication bypass hands an attacker the whole server, underneath the OS entirely. No scanner that only looks at the OS will ever see it.
- CPU and chipset model, stepping, and current microcode version, matched against known Spectre/Meltdown/L1TF variant advisories.
- Storage and network controller firmware versions, tracked for the CVEs specific to that manufacturer and model.
- BMC firmware version and known IPMI/authentication vulnerabilities, since BMCs run with privileges above the host OS.
- TPM and other embedded security controller firmware, verified against the versions the vendor has actually patched.
This is why firmware CVE correlation needs the hardware inventory first. You can't match a CPU against a Spectre variant advisory if you don't know which stepping and microcode revision is actually running.
Where HBOM matters most
Every organization runs on hardware. But the risk concentrates in a few places. IoT devices and embedded systems often run for years without a firmware update. Some have no mechanism to apply one at all. Industrial control systems mix decades-old hardware with modern network connectivity. A compromised controller can cause physical damage, not just a data breach. Cloud and data center hardware sits underneath every workload you run. A BMC or NVMe firmware flaw on shared infrastructure can hit every tenant on that box.
- IoT and embedded devices: long service life, infrequent patching, hard to inventory at scale.
- Industrial control systems: hardware failures and compromises carry physical, not just digital, consequences.
- Cloud and data center infrastructure: shared hardware means one firmware CVE can affect many tenants.
- Regulated and critical-infrastructure sectors: increasingly asked to prove hardware provenance, not just software provenance.
Where HBOM fits in the BOM family
The Bill of Materials family covers a different layer of the stack with each member, and HBOM is the one that goes lowest.
- SBOM: the software components your application is built from.
- CBOM: the cryptography inside those components, algorithms, keys, certificates.
- AIBOM: the models, datasets, and ML dependencies your software calls.
- QBOM: the CBOM graded for quantum risk.
- HBOM: the physical hardware and firmware everything above it runs on.
India's CERT-In treats all five as one framework in its 2025 BOM guidelines, one of the first regulators to name HBOM alongside SBOM, CBOM, QBOM, and AIBOM in a single document.
How to build one
An HBOM isn't compiled from a manifest the way an SBOM is. It comes from querying the hardware itself, across every environment you run in.
- Inventory the physical layer. Identify every CPU, chipset, storage and network controller across cloud instances, bare metal, and embedded devices, capturing manufacturer, model, and stepping.
- Capture firmware versions. Record the current firmware build for each component, since the same hardware model can be safe or vulnerable depending on what's flashed to it.
- Correlate against known hardware CVEs. Match each CPU stepping and firmware version against Spectre/Meltdown variant advisories, BMC CVEs, and manufacturer security bulletins.
- Re-inventory continuously. Hardware changes when instances are replaced, firmware is updated, or new devices are provisioned, so a one-time HBOM goes stale the same way a one-time SBOM does.
“You can't patch a CPU stepping you don't know you're running. The HBOM is how you find out.”
The bottom line
An HBOM is the one BOM type with real footing on both sides: a CISA framework that defines why and what to capture, and a CycloneDX schema that defines how. What's still catching up is adoption. Most organizations have never inventoried the hardware layer at all, which means firmware-level flaws like Spectre, Meltdown, and BMC authentication bypasses sit unpatched simply because nobody's tracking the microcode and firmware versions those advisories apply to. Build the inventory, correlate it against known hardware CVEs, and keep it current as hardware changes. It's the layer every other BOM assumes is safe.