CycloneDX for hardware BOMs: device and firmware components

CycloneDX was designed for software but has explicit component types for hardware and firmware. This is how to use them to build an HBOM that links cleanly to SBOMs and CBOMs.

Why CycloneDX for hardware

OWASP CycloneDX describes its HBOM capability as capturing “detailed inventories of physical hardware components and associated firmware” and representing configurations and dependencies for IoT, embedded and industrial systems ^[1]. The practical advantage is that hardware, firmware, software and cryptographic assets live in one specification, so an HBOM can point directly to the SBOM of its firmware and the CBOM of its keys.

Component types that matter

Descriptions are from the CycloneDX 1.6 reference, which also states that “a hardware device containing firmware SHOULD include a component for the physical hardware itself” ^[2].

A minimal structure

A server HBOM might have a device component for the server, nested device components for the mainboard, BMC and network adapter, and a firmware component under each that carries firmware. In JSON, the mainboard entry could look like:

{"type":"device","name":"Mainboard X","version":"rev B","supplier":{"name":"Example OEM"},"components":[{"type":"firmware","name":"UEFI","version":"2.14.0","hashes":[{"alg":"SHA-256","content":"…"}]}]}

Use the dependencies array for relationships beyond simple nesting, for example a firmware image that depends on a specific controller revision.

Identifiers

CycloneDX supports several identity fields, including cpe, purl, swid, swhid and omniborId ^[2]. For hardware, CPE is the most widely used for vulnerability matching, since CPE 2.3 distinguishes hardware from applications and operating systems in its part attribute ^[3]. Manufacturer part numbers and serial numbers have no dedicated field, so carry them as properties with a consistent naming convention.

Mapping the CISA taxonomy

The CISA HBOM Framework discusses mapping its fields to CycloneDX and SPDX and notes that not all of them map directly ^[4]. A workable approach: supplier and manufacturer to the component’s supplier and manufacturer data; part numbers, date codes, technology node and locations to namespaced properties; component hash to hashes. Agree the property names with suppliers so that files are machine-comparable.

CERT-In alignment

CERT-In’s Table 11 elements map naturally: name, version and supplier to core fields; licence to licenses on firmware; dependencies to nesting and dependencies; vulnerabilities to the vulnerabilities section; hashes to hashes; and EOL date, criticality and patch status to properties ^[5]. See CERT-In HBOM requirements.

Versions and standardisation

CycloneDX is standardised by Ecma International as ECMA-424 ^[6]. The CycloneDX project states that v1.6 was ratified as ECMA-424 1st edition in June 2024, and v1.7, released on 21 October 2025, adds citations, intellectual property data and cryptography improvements ^[7]. The hardware component types are present in both. Validate files with the CycloneDX CLI, which accepts versions up to 1.7 ^[8].

Instances versus types

Decide whether each HBOM describes a product type (one model and revision) or a specific unit. Supplier HBOMs usually describe types; operational HBOMs describe instances, with serial numbers as properties. Keeping the two distinct avoids duplicating component definitions across hundreds of identical devices.

SPDX as an alternative

SPDX 3.0 can also describe hardware using the device purpose, “a chipset, processor, or electronic board”, and the firmware purpose ^[9]. Choose the format your SBOM programme already uses.

How IntelliXBOM helps

IntelliXBOM generates and ingests CycloneDX and SPDX HBOMs with device and firmware components, validates them against field policies and keeps version history and diffs. It links firmware to SBOMs and cryptographic assets, and correlates hardware with vulnerabilities and EOL dates.