HBOM management: lifecycle, end-of-life and advisories
An HBOM starts to decay the day it is created. Management is the discipline of keeping it current and acting on the events it reveals: advisories, end-of-life dates and expiring approvals.
- Treat each HBOM change (firmware update, part swap, RMA) as a versioned event.
- Track release, end-of-sale and end-of-support dates; RBI expects regulated entities to monitor EOS and AMC dates.
- Correlate firmware and hardware with CSAF advisories and CISA’s KEV catalogue, and record VEX decisions.
- Certificates and validations expire too: FIPS 140-2 certificates can be accepted only through 21 September 2026.
Three kinds of change
HBOM management deals with three types of event. Estate changes: firmware updates, component replacements, RMAs, new deployments and disposals. Knowledge changes: a new advisory, a newly exploited vulnerability, a supplier added to a restricted list. Time changes: support ending, maintenance contracts lapsing, certifications expiring. A good process captures all three.
Change control
Each estate change should produce a new HBOM version, with the previous version retained. Comparing versions shows exactly what changed, when and on which device. The CycloneDX CLI diff command can report components added, removed or modified between two BOMs [1]; a platform does the same at scale. Unexpected differences, such as a firmware downgrade or a module that no work order explains, deserve investigation.
End-of-life and end-of-support
CERT-In includes release date and EOL date among its minimum HBOM elements [2]. In banking, RBI’s IT governance directions (issued 7 November 2023, effective 1 April 2024) state that regulated entities “shall avoid using outdated and unsupported hardware or software and shall monitor software’s end-of-support (EOS) date and Annual Maintenance Contract (AMC) dates of IT hardware on an ongoing basis”, and should keep a technology refresh plan to replace hardware and software before they reach EOS [3].
| Date to track | Source | Typical action |
|---|---|---|
| End of sale | Vendor lifecycle notice | Stop new purchases; plan standardisation |
| End of firmware updates | Vendor lifecycle notice | Plan replacement; add compensating controls |
| End of support | Vendor lifecycle notice | Replace or document risk acceptance |
| AMC expiry | Contract register | Renew or replace |
| Certificate or validation expiry | Validation body listing | Confirm successor validation |
Validation and approval lifecycles
Some hardware carries formal validations that expire. NIST’s Cryptographic Module Validation Program states that FIPS 140-2 validated modules can continue to be accepted by federal agencies through 21 September 2026, after which the certificates move to historical status [4]. For payment HSMs, the PCI Security Standards Council maintains a listing of approved PTS HSM devices evaluated against its standard [5]. Record the validation, its version and its expiry against the specific hardware and firmware versions in the HBOM.
Advisories and vulnerabilities
Hardware and firmware vulnerabilities typically reach you as vendor advisories. The OASIS Common Security Advisory Framework (CSAF) 2.0 gives vendors a machine-readable advisory format [6], and CISA’s Known Exploited Vulnerabilities catalogue identifies vulnerabilities known to be exploited [7]. Match advisories on manufacturer, model, hardware revision and firmware version, not product names alone. Then record a VEX-style decision per device (affected, not affected, fixed or under investigation), so remediation work reflects real exposure. CERT-In’s minimum elements include both vulnerabilities and patch status for this reason [2].
Ownership
Assign an owner to each HBOM, usually the team responsible for the platform, and make updating it part of change management rather than a separate task. Unowned HBOMs are the ones that quietly go stale.
A management cadence
- Continuously: ingest advisories and KEV updates; re-evaluate affected devices.
- On change: regenerate the operational HBOM and review the diff.
- Monthly: review EOL, EOS, AMC and validation dates falling in the next 12–18 months.
- Quarterly: reconcile supplier HBOMs with operational HBOMs for critical systems.
- Annually: review the field policy against current regulations.
Firmware that cannot move to quantum-resistant signing is a lifecycle issue as well; see Firmware BOMs and the CNSA 2.0 timeline.
How IntelliXBOM helps
IntelliXBOM keeps HBOM version history and diffs, correlates hardware and firmware with vulnerabilities, known-exploited lists and EOL dates, and records VEX decisions per device. It links each device to the business services it supports and maps the result to framework controls as timestamped evidence.
Frequently asked questions
What is the difference between end-of-life and end-of-support for hardware?
Vendors define these terms differently, but end-of-life or end-of-sale usually means the product is no longer sold, while end-of-support means updates and maintenance stop. Track each date separately in the HBOM, because the risk changes at each point.
Do hardware vulnerabilities use VEX?
VEX is not limited to software. Recording whether each device is affected, not affected, fixed or under investigation for a hardware or firmware advisory is just as useful, and CERT-In’s guidance pairs vulnerabilities with patch status.
Why track FIPS 140-2 expiry in an HBOM?
Because validation applies to specific module hardware and firmware versions. NIST’s CMVP accepts FIPS 140-2 certificates only through 21 September 2026, so knowing which HSMs and modules rely on them is a lifecycle task.
Sources
- 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
- Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023Reserve Bank of Indiawww.rbi.org.in/Scripts/NotificationUser.aspx?Id=12562&Mode=0
- Cryptographic Module Validation ProgramNISTcsrc.nist.gov/projects/cryptographic-module-validation-program
- PTS Hardware Security Module (HSM) StandardPCI Security Standards Councilwww.pcisecuritystandards.org/standards/pts-hardware-security-module-hsm/
- Common Security Advisory Framework (CSAF) Version 2.0OASISdocs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html
- Known Exploited Vulnerabilities CatalogCISAwww.cisa.gov/known-exploited-vulnerabilities-catalog
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.