Most organisations can now ask a supplier for a software bill of materials, but very few can say which chips, boards and firmware sit inside the network appliances, servers and OT devices they buy, or where those parts were made. A hardware bill of materials (HBOM) closes that gap, and CISA's HBOM Framework for Supply Chain Risk Management, published in September 2023, gives vendors and purchasers a shared structure for it. This guide explains the framework's use cases and data fields, how to represent hardware and firmware together in CycloneDX, how to request, validate and use HBOMs in procurement and vulnerability response, and where the framework stops. It is for supply chain risk managers, procurement and product security teams, and OT and network engineers. It builds on the SBOM Guide, which covers the software side.
Key takeaways
- The CISA framework is voluntary and purpose-driven: it defines eight HBOM use cases in three categories (compliance, security, availability) and tells you which data fields each needs, so you do not ask for everything.
- Firmware is only partly covered: the framework records basic firmware information such as provider and version, but firmware provenance is out of scope, so pair HBOM with SBOMs for firmware images.
- Structure is hierarchical: each product, kit or assembly that breaks into smaller parts gets its own HBOM, linked to its parent through part-level information.
- Formats already exist: CycloneDX has device and firmware component types, and the CISA field names are designed to map to CycloneDX and SPDX where possible.
- An HBOM is not proof: CISA states that using the framework does not establish regulatory compliance, and HBOM integrity and provenance verification are listed as future work.
What an HBOM is and why it is different from an SBOM
An HBOM is a structured list of the physical components in a product: assemblies, boards, semiconductors, modules, passive parts and sometimes cables and adhesives, together with who supplied and manufactured them and where. An SBOM lists software components and their dependencies. The two answer different questions.
| Question | SBOM | HBOM | Firmware SBOM |
|---|---|---|---|
| Is a vulnerable library inside this product? | Yes | No | Yes, for libraries in firmware images |
| Does this product contain parts from a prohibited supplier? | No | Yes | Partly (firmware provider) |
| Where were the main board and chips made? | No | Yes (location fields) | No |
| Which devices share a chip with a newly disclosed hardware flaw? | No | Yes (manufacturer part numbers) | No |
| Is the firmware version patched? | No | Version field only | Yes |
| Which products are exposed to a single-source part shortage? | No | Yes (production details) | No |
Hardware also changes in ways software does not. Manufacturers substitute approved alternate parts during production, so two units with the same model number may contain different components. The CISA framework handles this with alternate manufacturer and component option fields, but purchasers should still expect variation across production lots.
The CISA HBOM framework at a glance
The framework was produced by the HBOM Working Group of the ICT Supply Chain Risk Management Task Force, a public-private body that CISA organises and co-chairs through its National Risk Management Center. Its stated aim is a consistent, repeatable way for vendors to communicate hardware component information so purchasers can assess and mitigate supply chain risk. It has three parts: a consistent naming methodology for component attributes, a format for identifying and describing component types, and guidance on which information fits each purpose. Vendors and purchasers can use it voluntarily and flexibly, and the document notes that true interoperability needs further industry work such as proof-of-concept testing.
The eight use cases
| Category | Use case | Example question it answers |
|---|---|---|
| Compliance | 1. Government | Does the product contain equipment covered by rules such as FY2019 NDAA Section 889, the Uyghur Forced Labor Prevention Act or Withhold Release Orders? |
| Compliance | 2. Industry or customer | Does it meet sector or customer-specific supply chain requirements? |
| Compliance | 3. Internal and quality | Were parts bought only from OEM-authorised sources, and were product change notifications followed? |
| Security | 4. Geography and entity level | Are untrusted entities, compromised infrastructure or geographic concentration involved? |
| Security | 5. Product and component level | Are untrusted, compromised or counterfeit parts present? |
| Availability | 6. World events | Which products are affected by a pandemic, strike or regional disruption? |
| Availability | 7. Clustering: risks | Which common dependencies are single points of failure? |
| Availability | 8. Clustering: optimise | Where can shared components create efficiencies? |
When a need fits more than one category, the framework classifies it in the order compliance, then security, then availability. Choosing the use case first is the main discipline the framework imposes: it keeps requests proportionate and makes vendors more willing to share.
The data fields
The framework defines field names grouped into categories, and Appendix C maps each field to use cases. The HBOM header must state hbom_std_version as "1.0".
| Field group | Example fields | Needed for |
|---|---|---|
| Header | hbom_std_version, hbom_creation_date, hbom_modify_date, hbom_author, fga_supplier, fga_num, fga_description | All use cases |
| Finished good product details | fga_type (all); fga_version, fga_hash | Version and hash for compliance and security, not availability |
| Entity name | fga_main_manufacturer, fga_alt_manufacturer, comp_supplier, comp_manufacturer | All use cases |
| Entity location | fga_supplier_loc, fga_main_location, fga_alt_location, comp_mfg_location, with matching coordinate and location code fields; assy_and_test_location for semiconductors | Government and industry compliance, geography and entity security, all availability cases |
| Component part information | comp_supplier_pn, comp_manufacturer_pn, comp_description, comp_type, comp_part_type, comp_part_code, comp_hash | All use cases |
| Component part details | comp_opt_name (all); comp_version, comp_datasheet | Version and datasheet for compliance and security |
| Production details | supplier_sourced_pctg, lead_times, quantity, technology_node, comp_part_size_val, comp_part_size_unit, comp_datecode | Availability (per Appendix C) |
Three details matter in practice. First, comp_type takes the values Hardware, Software or Service, while comp_part_type is free text such as semiconductor, antenna or capacitor, so expect inconsistency across vendors. Second, the framework separates the OEM (fga_supplier) from the actual manufacturer (fga_main_manufacturer), which is what reveals contract manufacturing locations. Third, the document itself uses upper-case field names in places and lower-case in its taxonomy table, so normalise names when you ingest. Table 4 and Appendix C also differ on which use cases need production details; Appendix C is the more specific source.
Representing hardware and firmware in CycloneDX
The CISA framework suggests spreadsheets with one tab per assembly level and aims for one-to-one mapping to CycloneDX and SPDX where possible, with user-defined fields where no equivalent exists. For machine processing, CycloneDX already supports hardware.
- Component types: the CycloneDX 1.6 schema includes
device,device-driverandfirmwaretypes. Its definition ofdevicesays a hardware device containing firmware SHOULD include one component for the physical hardware and another of type firmware or operating-system for the software running on it. That is the practical pattern for a combined hardware and firmware BOM. - Device properties: the CycloneDX property taxonomy defines
cdx:device:properties including quantity, function, board location, deviceType (such as SMD or through-hole), serialNumber, sku, lotNumber, prodTimestamp and macAddress, plus pointers to engineering and manufacturing BOMs (cdx:device:bom:ebom,cdx:device:bom:mbom) and certification properties by country and authority. - Use cases named by CycloneDX: inventory of hardware in IoT, ICS and embedded devices, and managing risks such as outdated firmware and hardware dependencies.
- Nesting: model the finished good as the top component, assemblies as nested components, and firmware as a component of the device that runs it, with its own SBOM referenced or embedded.
| CISA field | CycloneDX element (suggested mapping) |
|---|---|
| fga_supplier, fga_num, fga_description | metadata.component supplier, name or part number, description |
| comp_manufacturer, comp_manufacturer_pn | component manufacturer and part identifier |
| comp_type | component type (device, firmware) |
| comp_version, comp_hash | component version, hashes |
| comp_mfg_location, assy_and_test_location | properties (no direct core field) |
| quantity | cdx:device:quantity property |
The mapping table is a starting point, not an official crosswalk: the CISA framework says conversion of fields without a direct equivalent needs a case-by-case decision. Agree the mapping in the contract or data sharing agreement.
Choosing a format and exchange method
| Option | Strengths | Weaknesses | Choose it when |
|---|---|---|---|
| CISA spreadsheet layout, one tab per assembly | Easy for suppliers with ERP or PLM exports; field names match the framework | Manual ingestion, weak validation, no signatures | Early pilots and suppliers with low tooling maturity |
| CycloneDX JSON or XML | Schema validation, nesting, firmware as separate components, tooling shared with SBOM | Location and production fields need properties; mapping must be agreed | You already run SBOM tooling and want one inventory pipeline |
| Supplier portal or questionnaire | No format work for the supplier | Not machine-readable, hard to keep current | Low-risk products or small purchasers |
Whatever the format, treat HBOMs as sensitive commercial data. Location and supplier fields reveal a vendor's supply base, so agree confidentiality terms, restrict access in your inventory, and record who supplied each HBOM and when. The framework lists roles for producing, sharing and protecting HBOMs, and customer rights to them, as future work, so these terms belong in your contracts for now.
Firmware: what the HBOM covers and what it does not
Firmware is where hardware supply chain risk turns into exploitable risk, and it is the weakest part of current HBOM practice. The CISA framework captures basic firmware information, such as the firmware provider and version, but explicitly does not address firmware provenance or other attributes, and puts software component analysis in the SBOM domain. In practice you need three things for each firmware-bearing component:
- Identity and version: recorded in the HBOM so you can find every device running a vulnerable firmware build.
- Contents: a firmware SBOM listing the bootloader, OS, libraries and binary blobs, either from the vendor or from binary analysis of the image.
- Trust chain: who signs the firmware, which keys a device trusts, and how those keys can be revoked. The MSI signing keys leak showed why: leaked firmware image signing keys and Intel Boot Guard keys meant signed but modified firmware could pass hardware checks on affected devices, and the trust chain, not the HBOM, determined the blast radius.
NIST SP 800-193 Platform Firmware Resiliency Guidelines frames the controls you should ask suppliers about: protection against unauthorised firmware changes, detection of changes that occur, and secure recovery. See the Firmware and Boot Security Guide.
Where identity fits
Firmware signing keys and device identity keys are non-human credentials with an unusually long life: they are often burned into hardware or trusted by every unit shipped. An HBOM should record which components hold device identity (TPMs, secure elements, DICE-capable microcontrollers) and which keys sign firmware, so that a key compromise can be mapped to affected products quickly. See the IoT Device Identity with TPM and DICE Guide.
Implementing an HBOM programme
- Pick use cases: start with one compliance use case (prohibited suppliers) and one security use case (component-level vulnerability lookup). Note which CISA fields each needs.
- Pick product scope: begin with network edge devices, servers and OT controllers, where hardware and firmware flaws have the largest impact.
- Write the contract clause: require an HBOM per supplied model and major version, in CycloneDX or the CISA spreadsheet layout, with the agreed fields, a firmware SBOM for each firmware-bearing component, and notice when components or firmware change.
- Pilot with two suppliers: ingest their HBOMs, normalise field names and part numbers, and record gaps. Expect entity resolution problems: CISA lists part and entity naming variation, mergers and subsidiaries as open issues.
- Validate samples: for high-risk products, spot-check delivered units against the HBOM (board markings, firmware version read from the device).
- Connect to operations: load HBOM data into the asset inventory so hardware advisories and firmware CVEs can be matched to installed devices.
- Scale and review: extend to more suppliers, and request a new HBOM when a vendor releases a new product version, since the framework leaves life cycle updates out of scope.
Small organisations rarely have the leverage to demand full HBOMs. Focus on asking suppliers of critical devices for country of manufacture, main manufacturer, firmware version and update support. Large purchasers and regulated operators can require the full field set for compliance and security use cases and test conformance.
Detection and measurement
- HBOM coverage: share of critical device models in the estate with a current HBOM.
- Firmware linkage: share of firmware-bearing components in HBOMs with a matching firmware SBOM and current version.
- Time to exposure answer: hours from a hardware or firmware advisory to a list of affected installed devices.
- Data quality: share of HBOM entries with manufacturer part numbers that resolve to a known manufacturer.
- Sample conformance: share of spot-checked units that match their HBOM.
Framework mapping
| Framework | Reference | HBOM relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 | Inventories of hardware managed by the organisation are maintained |
| NIST CSF 2.0 | GV.SC-05, GV.SC-07 | Supply chain requirements in contracts; supplier risk understood and monitored |
| NIST SP 800-53 Rev. 5 | CM-8, SA-4 | System component inventory; acquisition requirements |
| NIST SP 800-53 Rev. 5 | SR-3, SR-4, SR-5, SR-11 | Supply chain controls; provenance; acquisition strategies; component authenticity |
| NIST SP 800-53 Rev. 5 | SI-7 | Firmware integrity |
| MITRE ATT&CK v20 | T1195.003, T1542.001, T1553.002 | Compromise hardware supply chain; system firmware; code signing abuse |
For the broader supply chain programme these controls sit in, see the NIST SP 800-161 Cyber Supply Chain Risk Management Guide and the Hardware Trojans and Chip Supply Chain Guide.
Common failure patterns
- Asking for everything: requesting every field for every product makes suppliers refuse; tie each request to a use case as the framework intends.
- Treating the HBOM as evidence of compliance: CISA states the framework does not establish regulatory compliance and regulators may not accept it as evidence.
- HBOM without firmware SBOM: knowing a board's chips does not tell you whether its firmware contains a vulnerable library.
- One HBOM per model forever: alternate parts and product revisions change contents; without version-specific HBOMs, exposure answers are wrong.
- Unresolved part identities: free-text part types and inconsistent manufacturer names break matching against advisories.
- Ignoring signing keys: the trust chain for firmware is the part of the hardware supply chain attackers abuse most, yet it is rarely recorded.
Practitioner checklist
- Choose the CISA HBOM use cases you need and list the fields each requires.
- Add HBOM and firmware SBOM requirements to contracts for critical device suppliers.
- Represent hardware as CycloneDX device components with separate firmware components.
- Normalise manufacturer names and part numbers on ingest and track unresolved entries.
- Link HBOM data to the asset inventory so advisories map to installed devices.
- Record firmware signing key owners and device identity components for each product.
- Spot-check high-risk deliveries against their HBOM.
- Request a new HBOM for each new product version and track coverage metrics.
Standards and references
- CISA: A Hardware Bill of Materials Framework for Supply Chain Risk Management
- CISA: HBOM Framework resource page
- CycloneDX: Hardware Bill of Materials (HBOM)
- CycloneDX: BOM 1.6 JSON schema
- CycloneDX: cdx:device property taxonomy
- NIST: SP 800-193 Platform Firmware Resiliency Guidelines
- CISA: Software Bill of Materials (SBOM)
Related NHI Mgmt Group resources: SBOM Guide · Hardware Trojans and Chip Supply Chain Guide · Firmware and Boot Security Guide · CWE Hardware Weaknesses Guide