CERT-In HBOM requirements: the Table 11 minimum elements
CERT-In’s Version 2.0 guidelines list the minimum data an HBOM should hold. Several elements were written with software in mind, so interpreting them for hardware takes some care.
- CERT-In’s Version 2.0 guidelines (9 July 2025) list minimum HBOM elements in Table 11, from component name and supplier to patch status, EOL date and criticality.
- Several elements (licence, checksums, dependencies) need hardware-specific interpretation.
- Vulnerabilities, patch status and EOL date change over time, so HBOMs need continuous maintenance.
- CycloneDX and SPDX, the formats CERT-In names for SBOMs, both support hardware and firmware components.
Where the requirements come from
CERT-In’s Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025, extend its earlier SBOM guidance to four further bills of materials, including the HBOM [1]. The guidelines are aimed at government, public sector and essential services organisations and software exporters, and list minimum HBOM elements in Table 11 [1]. Legal commentary summarises the HBOM’s purpose as establishing “greater transparency in the sourcing and maintenance of hardware components” [2].
Key Table 11 elements, interpreted for hardware
| Element | Hardware interpretation | Typical data source |
|---|---|---|
| Hardware component name | Manufacturer’s component or module name | Supplier HBOM, datasheet |
| Version | Hardware revision; firmware version for firmware components | Supplier HBOM, Redfish, fwupd |
| Supplier | Entity that supplied the part; record manufacturer separately where it differs | Supplier HBOM, purchase records |
| Licence | Licence of firmware and embedded software; hardware design licences where relevant | Supplier declaration, firmware SBOM |
| Dependencies | Parent-child relationships (assembly to component, device to firmware) | Supplier HBOM structure |
| Hardware vulnerabilities | Known vulnerabilities affecting the component or its firmware | Vendor advisories, CSAF, KEV |
| Patch status | Whether a fixed firmware or microcode release exists and is applied | Advisories plus observed version |
| Release date | Date the hardware revision or firmware version was released | Vendor lifecycle data |
| End-of-Life (EOL) date | End of support or maintenance for the component | Vendor lifecycle notices |
| Criticality | Importance to system function or security | Internal risk assessment |
| Checksums or hashes | Hashes of firmware images; hardware identity via serial and part number | Vendor-published hashes, collection tools |
| Unique identifier | A stable identifier per component type and, where needed, per instance | Part number, CPE, serial number |
Element names follow CERT-In’s Table 11 [1]; the interpretation column is ours. This is not a substitute for the table itself, check the current CERT-In PDF for the complete, authoritative list of elements.
Elements that need care
Licence
Physical components rarely carry a software-style licence, but their firmware does. Record the firmware licence on the firmware component, and leave the hardware component’s licence as not applicable unless an open hardware licence applies. A firmware SBOM usually supplies this.
Checksums or hashes
You cannot hash a chip. Hash the firmware image, and identify the hardware by manufacturer part number and serial. The CISA HBOM Framework similarly includes hash fields for finished goods and components [3].
Unique identifier
Use a scheme that tools can match. CPE 2.3 names can identify hardware as distinct from operating systems and applications [4]; manufacturer part numbers identify types, and serial numbers identify instances.
Format
CERT-In names SPDX and CycloneDX as SBOM formats [1]. Both can carry an HBOM: CycloneDX defines device and firmware component types [5], and SPDX 3.0 includes device and firmware software purposes [6]. Using the same format for SBOMs and HBOMs simplifies validation. See CycloneDX for hardware BOMs.
Keeping it current
Vulnerabilities, patch status and EOL dates are not static. A compliant HBOM on the day of delivery can be non-compliant a month later if a new advisory appears. Match hardware advisories published in CSAF [7] against firmware versions, record vulnerability decisions using the VEX statuses CERT-In describes (not affected, affected, fixed, under investigation) [1], and re-validate on every change.
Evidencing compliance
- Configure a field policy containing all Table 11 elements.
- Validate supplier HBOMs on receipt and operational HBOMs on change.
- Keep dated versions to show the state at any point.
- Report completeness per component, with exceptions explained.
For the wider picture, see HBOM compliance and HBOM for Indian enterprises.
How IntelliXBOM helps
IntelliXBOM validates HBOMs in CycloneDX and SPDX against the CERT-In HBOM elements, flags missing or stale fields per component and keeps version history. It correlates hardware and firmware with vulnerabilities and EOL dates, records VEX decisions, and packages the result as timestamped evidence. It helps organisations address the guidelines; it does not certify compliance.
This article summarises public guidance and is not legal advice.
Frequently asked questions
How many HBOM elements does CERT-In list?
Table 11 of CERT-In’s Version 2.0 guidelines lists the minimum HBOM elements, including component name, version, supplier, licence, dependencies, hardware vulnerabilities, patch status, release date, EOL date, criticality, checksums or hashes and unique identifier. Check the current CERT-In PDF for the complete table.
What does licence mean for a hardware component?
For most physical parts it applies to the embedded firmware and software rather than the silicon. Record the firmware licence on the firmware component, and note where an open hardware licence applies to a design.
Which format should a CERT-In aligned HBOM use?
CERT-In names SPDX and CycloneDX as bill-of-materials formats. Both support hardware and firmware: CycloneDX through device and firmware component types, and SPDX 3.0 through device and firmware software purposes.
Sources
- 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
- CERT-In’s New BOM Guidelines: What India’s Software, AI, and Hardware Ecosystem Needs to KnowAZB & Partnerswww.azbpartners.com/bank/cert-ins-new-bom-guidelines-what-indias-software-ai-and-hardware-ecosystem-needs-to-know/
- 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
- NIST IR 7695, Common Platform Enumeration: Naming Specification Version 2.3NISTcsrc.nist.gov/pubs/ir/7695/final
- CycloneDX v1.6 JSON ReferenceOWASP CycloneDXcyclonedx.org/docs/1.6/json/
- SPDX 3.0.1, SoftwarePurpose vocabularySPDX / Linux Foundationspdx.github.io/spdx-spec/v3.0.1/model/Software/Vocabularies/SoftwarePurpose/
- Common Security Advisory Framework (CSAF) Version 2.0OASISdocs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html
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.