What is an HBOM? Hardware Bill of Materials explained

A Hardware Bill of Materials records the physical and firmware components of a device, where they came from and how long they will be supported. This guide covers the definitions, the reference frameworks, the formats and how to begin.

A working definition

A Hardware Bill of Materials (HBOM) is a structured inventory of the physical components that make up a product or system (processors, chipsets, boards, memory, storage and network controllers, security modules) together with the firmware that controls them and the relationships between them. OWASP CycloneDX describes the HBOM capability as capturing “detailed inventories of physical hardware components and associated firmware” ^[1].

The idea mirrors the software bill of materials (see What is an SBOM?), but the questions are different. An SBOM asks which libraries a piece of software contains. An HBOM asks who manufactured each part, where it was made and assembled, which firmware version it runs, whether it is still supported, and whether it is affected by a published hardware or firmware vulnerability.

Why hardware needs its own bill of materials

Most supply-chain tooling stops at the operating system. Beneath it sit BIOS/UEFI firmware, baseboard management controllers (BMCs), storage and network controller firmware, trusted platform modules and hardware security modules. Weaknesses at that layer can undermine every control above it. Microsoft’s analysis of the BlackLotus UEFI bootkit, for example, notes that bootkits run “prior to the operating system loading” and can interfere with protections such as BitLocker and Microsoft Defender Antivirus ^[2].

NIST SP 800-161 Rev. 1 frames the wider concern: organisations have reduced visibility into how the technology they buy is developed, and products may contain “malicious functionality, are counterfeit, or are vulnerable due to poor manufacturing and development practices” ^[3]. An HBOM is the record that makes those risks answerable at the level of individual devices.

What an HBOM contains

The two reference models

CISA HBOM Framework (September 2023)

CISA’s ICT Supply Chain Risk Management Task Force published A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management in September 2023 ^[4]. CISA describes three elements: use-case categories, a consistent HBOM format, and a data field taxonomy of attributes that “depending on the use for which the purchaser intends to use an HBOM, may be appropriate to include” ^[5]. The use-case categories are compliance, security and availability. The framework is voluntary and deliberately flexible, and it places SBOM information out of scope ^[4]. Our explainer on the CISA HBOM Framework covers it in detail.

CERT-In Version 2.0 (July 2025)

India’s CERT-In extended its SBOM guidance in Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025 ^[6]. Its minimum HBOM elements (Table 11) are: component name, version, supplier, licence, dependencies, hardware vulnerabilities, patch status, release date, end-of-life (EOL) date, criticality, checksums or hashes, and a unique identifier ^[6]. Legal commentary notes that the guidance also reaches embedded software and firmware dependencies within hardware devices ^[7]. See CERT-In HBOM requirements for a field-by-field reading.

The two models are complementary. CISA’s taxonomy is rich in provenance and sourcing data suited to procurement risk. CERT-In’s list is shorter and operational, emphasising vulnerabilities, patch status and lifecycle.

Formats

An HBOM does not need a new format. CycloneDX defines component types that include device (“a hardware device such as a processor or chip-set”), firmware and device-driver, and advises that a hardware device containing firmware should include a component for the physical hardware itself ^[8]. SPDX 3.0 offers equivalent software purposes, including device (“a chipset, processor, or electronic board”) and firmware ^[9]. Using the same formats as SBOMs lets hardware, software and cryptographic inventories be linked rather than kept in separate silos. CycloneDX for hardware BOMs shows how.

Supplier HBOM and operational HBOM

Two HBOMs usually exist for the same device. The supplier HBOM is what the manufacturer declares at delivery: design-level components, part numbers and sources. The operational HBOM is what is running in your estate today, after field replacements, firmware updates and configuration changes. Most of the value comes from comparing the two: a supplier HBOM without operational data goes stale, and operational data without a supplier HBOM cannot reveal what sits below the management interface.

What an HBOM lets you answer

The last row links the HBOM to cryptography. Firmware signing keys are hard to change after deployment, which is why NSA’s CNSA 2.0 asks for quantum-resistant software and firmware signing to be supported and preferred by 2025 and used exclusively by 2030 ^[10][11]. The CNSA 2.0 timeline sets out the other categories, and a CBOM records the algorithms and keys involved.

Who produces and who uses an HBOM

The CISA framework is written for two parties: vendors who produce HBOMs and purchasers who use them ^[4]. In practice the chain is longer. Component manufacturers know their own parts; OEMs assemble those parts into products; integrators and resellers combine products into solutions; operators run them for years. Each role holds part of the picture, and each hand-off is a point where detail can be lost. Inside an organisation, procurement uses the HBOM to screen sources, security teams to respond to advisories, infrastructure teams to plan refresh cycles, and compliance teams to evidence controls.

Common misconceptions

• “Our asset register is our HBOM.” An asset register records one line per device. It rarely records firmware versions, sub-components or manufacturing locations.
• “Scanning will find everything.” Tools report what the platform tells them; dmidecode’s own documentation warns that DMI data should not be blindly trusted ^[12]. Sub-component provenance has to come from the supplier.
• “An HBOM is a one-off delivery document.” Vulnerabilities, patch status and EOL dates change after delivery, which is why CERT-In lists them as HBOM elements ^[6].
• “HBOMs only matter for defence.” Lifecycle, firmware and advisory questions arise in every data centre, bank and telecom network.

Where to start

1. Pick a scope that matters: core network, database and virtualisation hosts, HSMs, OT gateways.
2. Collect what you already have: asset registers, purchase records, BMC and Redfish inventories, firmware update tooling.
3. Normalise identifiers (manufacturer, model, part number, firmware version) and store them in CycloneDX or SPDX.
4. Ask suppliers for HBOMs in procurement, referencing the CISA taxonomy and the CERT-In minimum elements.
5. Correlate continuously with vendor advisories, known-exploited vulnerability lists and EOL notices.
6. Reconcile supplier and operational HBOMs, and review differences as change events.

The rest of this cluster goes deeper: generation, management, validation and hardware supply-chain risks.

How IntelliXBOM helps

IntelliXBOM generates and ingests HBOMs in CycloneDX and SPDX, validates them against required-field policies such as the CERT-In HBOM elements, and keeps version history so supplier and operational HBOMs can be diffed. It correlates devices and firmware with vulnerabilities, known-exploited lists, EOL dates and the business services they support, and maps the inventory to framework controls as timestamped evidence, on-premise or air-gapped.