HBOM validation: levels of assurance for hardware BOMs
A valid HBOM file is not necessarily a true one. Validation has several levels, from checking the schema to checking the silicon, and each answers a different question.
- Schema validity and field completeness are necessary but prove nothing about the hardware itself.
- Consistency checks compare supplier HBOMs with in-band and out-of-band observations.
- Firmware integrity checks draw on NIST SP 800-193’s protect, detect and recover model.
- Physical and provenance checks address counterfeits, which in-band tools cannot detect.
Why validation is harder for hardware
An SBOM can be checked against source code or a build. An HBOM describes physical objects and the firmware inside them, and most of that is visible only through what the device chooses to report. dmidecode’s maintainers put it plainly: the tool “does not scan your hardware, it only reports what the BIOS told it to” [1]. HBOM validation is therefore a matter of layered assurance, where each level raises confidence without reaching certainty.
Five levels of assurance
| Level | Question | Method | What it cannot tell you |
|---|---|---|---|
| 1. Structural | Is the document well formed? | Schema validation against CycloneDX or SPDX [2] | Whether any content is correct |
| 2. Completeness | Are the required fields present? | Field policy, e.g. CERT-In Table 11 [3] | Whether values are accurate |
| 3. Consistency | Does it match what the device reports? | Reconcile with Redfish, fwupd, lshw, dmidecode [4] | Whether the device is reporting truthfully |
| 4. Integrity | Is the firmware genuine and unmodified? | Hash and signature checks; platform assessment [5][6] | Hardware-level substitution |
| 5. Provenance | Is the hardware what and from where it claims? | Authorised-source records, inspection, testing [7] | Nothing is absolute; this is risk-based |
Levels 1 and 2: the document
Structural validation confirms the HBOM parses and conforms to its schema; the CycloneDX CLI’s validate command can return a non-zero exit code on errors, which suits automated gates [2]. Completeness validation applies a field policy. For CERT-In alignment that means checking each component for name, version, supplier, licence, dependencies, vulnerabilities, patch status, release and EOL dates, criticality, hashes and a unique identifier [3]. Report gaps per component, not just per file.
Level 3: consistency with the estate
Compare the supplier HBOM, or the last approved operational HBOM, with fresh observations. Redfish’s firmware inventory gives firmware versions and manufacturers from the BMC [4]; in-band tools add serials and modules. Differences fall into three groups: expected (a documented update), benign (a naming variation) and unexplained. Only the last needs escalation, but all should be recorded.
Level 4: firmware integrity
NIST SP 800-193 organises firmware resiliency around protection, detection and recovery [6]. For validation, detection is the relevant part: compare firmware hashes with vendor-published values, confirm signatures, and in higher-assurance settings use a platform assessment framework such as CHIPSEC, which analyses hardware, BIOS/UEFI and platform component security [5]. Firmware BOMs make this easier by declaring what each image should contain; see Firmware BOMs.
Level 5: provenance
Counterfeit or substituted parts cannot be caught by software. Defence procurement shows what provenance assurance involves: DFARS 252.246-7007 requires risk-based processes to track electronic parts from the original manufacturer to acceptance, use of authorised suppliers, and reporting of suspect counterfeits [7]. Outside defence, the same logic applies proportionately: sample inspection, authorised-channel purchasing and supplier attestations for critical assets. See hardware supply-chain risks.
Recording outcomes
Record the result of every validation run with the HBOM version it applied to, the level reached and any exceptions accepted, with a reason and an owner. That record is what an auditor will ask for, and it lets you show that a gap found in one delivery was closed in the next.
Choosing the right level
Not every device needs all five levels. Levels 1–3 should be automated across the estate. Level 4 suits critical servers, network cores and HSMs. Level 5 is reserved for the highest-risk assets and supply routes. For the step-by-step procedure, see How to validate an HBOM.
How IntelliXBOM helps
IntelliXBOM validates HBOMs against required-field policies such as CERT-In’s, reports gaps per component, and keeps version history so supplier and observed HBOMs can be diffed. Validation results are recorded as timestamped evidence mapped to framework controls.
Frequently asked questions
Is schema validation enough for an HBOM?
No. Schema validation confirms the file is well formed. Completeness, consistency with deployed devices and firmware integrity checks are needed before the HBOM can support security or compliance decisions.
Can software detect counterfeit hardware?
Generally not reliably. In-band tools report what firmware tells them, and a counterfeit can report plausible values. Provenance controls such as authorised-source purchasing, traceability and physical inspection address counterfeits.
How does NIST SP 800-193 relate to HBOM validation?
SP 800-193 sets out protection, detection and recovery mechanisms for platform firmware. Detection, confirming that firmware has not been changed without authorisation, is the part that supports validating the firmware entries in an HBOM.
Sources
- Dmidecodedmidecode project (Savannah)www.nongnu.org/dmidecode/
- CycloneDX CLIOWASP CycloneDX (GitHub)github.com/CycloneDX/cyclonedx-cli
- 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
- DSP2062, Redfish Firmware Update White PaperDMTFwww.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.0.pdf
- CHIPSEC: Platform Security Assessment FrameworkCHIPSEC project (GitHub)github.com/chipsec/chipsec
- SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)NISTcsrc.nist.gov/pubs/sp/800/193/final
- DFARS 252.246-7007, Contractor Counterfeit Electronic Part Detection and Avoidance SystemAcquisition.govwww.acquisition.gov/dfars/252.246-7007-contractor-counterfeit-electronic-part-detection-and-avoidance-system.
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.