PlatformPlatform architectureProduct tourProduct graphRisk intelligenceContinuous governanceEvidence & auditDeploymentIntegrationsExecutive view
BOM SuiteSBOMCBOMQBOMAIBOMHBOMBOM Governance
SolutionsSecurityComplianceSupply chain riskQuantum readinessAI governanceDigital trust
ComplianceCERT-InRBISEBI / CSCRFMeitYNISTEU CRAEU AI ActCERT-In SBOM guide
IndustriesBanking & Financial ServicesGovernment & Public SectorDefence & Critical InfrastructureHealthcareIndian enterprises
ResourcesResource centreSBOM resourcesCBOM resourcesQBOM resourcesAIBOM resourcesHBOM resourcesProgramme & regulationBlog
CompanyAboutSecurity & trustContact
Request a DemoTalk to an expert
Explainer4 min readReviewed September 20266 sources

The CISA HBOM Framework explained

Published in September 2023 by CISA’s ICT Supply Chain Risk Management Task Force, the HBOM Framework gives vendors and purchasers a common vocabulary for hardware supply-chain data.

Key takeaways
  • The framework has three elements: use-case categories, an HBOM format and a data field taxonomy.
  • Use cases are grouped into compliance, security and availability.
  • The format is hierarchical: products break down into assemblies and components, linked by part identifiers.
  • It is voluntary, and SBOM information and detailed firmware provenance are out of scope.

Background

The framework, A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management, was produced by the Hardware Bill of Materials Working Group of CISA’s ICT Supply Chain Risk Management Task Force and published in September 2023 [1]. CISA describes it as offering “a consistent and repeatable way for vendors and purchasers to communicate about hardware components”, built by a working group of “subject matter experts from a diverse set of private and public sector organizations” [2]. It is voluntary: purchasers and vendors “can use the HBOM Framework on a voluntary basis” and tailor it [1].

Element 1: use-case categories

CategoryFramework descriptionExamples in the framework
ComplianceAssessing the product’s compliance with rules and regulationsUyghur Forced Labor Prevention Act, NDAA Section 889, internal quality and authorised-vendor policies
SecurityEvaluating security risk based on exposure to known vulnerabilitiesUntrusted or compromised suppliers and geographies; counterfeit components
AvailabilityAssessing impacts from world events and supply chain diversificationFactory shutdowns, single points of failure, supply clustering

The use case determines which fields a purchaser should request, which is why the taxonomy is a menu rather than a mandatory list [2]. NDAA Section 889 is implemented in federal procurement by FAR 52.204-25, which names specific telecommunications and video surveillance equipment producers [3]; this is the kind of rule the compliance category is designed to support.

Element 2: the format

The framework uses parent-child nesting: a finished product breaks down into assemblies or kits, which break down into components, and each level can have its own HBOM document linked by part identifiers [1]. It is oriented to structured tables rather than a single machine-readable schema, and the authors acknowledge that further work is needed for full interoperability. The framework discusses mapping to CycloneDX and SPDX, noting that not all fields map directly [1]. Today, CycloneDX’s device and firmware types provide a practical target [4].

Element 3: the data field taxonomy

CategoryExample fields
HBOM header informationStandard version, creation and modification dates, author, supplier, finished-good part number and description
Finished good product detailsProduct type, version (which may include firmware version)
Entity nameMain and alternate manufacturers, component supplier and manufacturer, assembly and test supplier
Entity locationSupplier, manufacturing, and assembly and test locations, as text, coordinates or location codes
Component part informationSupplier and manufacturer part numbers, description, component type, part type and code, hash
Component part detailsComponent version, datasheet
Production detailsSourcing percentage, lead times, quantity, technology node, part size, date code

The component type field allows values such as hardware, software and service [1]. Location fields at several levels are what make the compliance and availability use cases possible.

What is out of scope

The framework excludes SBOM information, detailed firmware provenance, part and entity resolution, and operational concepts for using HBOMs [1]. Organisations therefore need to add their own firmware and software linkage (see Firmware BOMs) and their own processes for matching supplier names and part numbers.

How it relates to other guidance

NIST SP 800-161 Rev. 1 provides the broader supply-chain risk management process within which an HBOM is one input [5]. India’s CERT-In takes a different approach, listing a fixed set of minimum HBOM elements focused on vulnerabilities, patch status and lifecycle [6]. An organisation working to both can use CISA’s taxonomy for provenance and sourcing and CERT-In’s list for operational completeness; see CERT-In HBOM requirements.

Applying it

  1. Decide which use cases matter for each product category.
  2. Select the taxonomy fields those use cases need, and put them in procurement templates.
  3. Agree a format (typically CycloneDX or SPDX) and a nesting depth with suppliers.
  4. Add firmware and SBOM linkage that the framework leaves out.

How IntelliXBOM helps

IntelliXBOM ingests supplier HBOMs in CycloneDX and SPDX, including fields drawn from the CISA taxonomy, and validates them against the field policy you set for each use case. It correlates hardware with vulnerabilities, EOL data and business services, and maps the inventory to framework controls as evidence.

This article summarises public guidance and is not legal advice.

Frequently asked questions

Is the CISA HBOM Framework mandatory?

No. The framework states that purchasers and vendors can use it on a voluntary basis and tailor it to their circumstances. It may be referenced in contracts, which can make its fields contractual requirements.

Does the CISA HBOM Framework define a file format?

It defines a hierarchical structure and a taxonomy of fields rather than a single schema, and discusses mapping to CycloneDX and SPDX. The authors note that more work is needed for full interoperability.

Does the CISA framework cover firmware?

Only at a basic level, such as the firmware provider and version associated with a product. Detailed firmware provenance and SBOM information are explicitly out of scope.

Sources

  1. A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management (September 2023)CISA ICT SCRM Task Forcewww.cisa.gov/sites/default/files/2023-09/A%20Hardware%20Bill%20of%20Materials%20Framework%20for%20Supply%20Chain%20Risk%20Management%20(508).pdf
  2. CISA Releases Hardware Bill of Materials Framework (HBOM) for Supply Chain Risk ManagementCISAwww.cisa.gov/news-events/news/cisa-releases-hardware-bill-materials-framework-hbom-supply-chain-risk-management-scrm
  3. FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or EquipmentAcquisition.govwww.acquisition.gov/far/52.204-25
  4. CycloneDX v1.6 JSON ReferenceOWASP CycloneDXcyclonedx.org/docs/1.6/json/
  5. SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and OrganizationsNISTcsrc.nist.gov/pubs/sp/800/161/r1/upd1/final
  6. Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf

Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.

Related HBOM guides

Across the BOM Suite

Put your HBOM under governance.Hardware & firmware trust with continuous correlation and timestamped evidence.