Hardware Bill of Materials (HBOM) and CRA Compliance

Your SBOM lists libraries and software packages, but what about the firmware burned into your Bluetooth chip or the microcontroller at the heart of your device? A Hardware Bill of Materials (HBOM) extends the component inventory to cover physical chips, modules, and the firmware running on them. The CRA does not use the term "HBOM", but hardware products, separately marketed hardware components, third-party component due diligence, and the SBOM component inventory all point to the same practical need: know which hardware and firmware are inside the product.

Why HBOM matters under the CRA

The CRA's scope is broader than software-only products. Hardware products, separately marketed hardware components, and the firmware inside those components all sit inside the product inventory problem.

That matters for manufacturers because component due diligence is not limited to open-source libraries. A processor on your PCB, a wireless module on your development board, or a secure element in your IoT gateway can carry firmware and security-relevant versions. You cannot manage those risks without inventorying them.

The SBOM requirement is the legal home for this work: it asks for the components contained in products with digital elements. An ESP32 module therefore brings both the physical module and its firmware stack into the component record. An HBOM is the practical tool for capturing that inventory.

HBOM vs SBOM at a glance

Dimension	SBOM	HBOM
Primary scope	Software libraries, packages, frameworks	Physical components: chips, modules, secure elements
Firmware coverage	Can include type: firmware entries	Firmware listed alongside its parent hardware component
Compliance role	Explicit component inventory requirement	Practical extension of that same component inventory for hardware products
BSI TR-03183 coverage	Yes, TR-03183-2 (v2.1.0, 2025)	No, none of the three TR-03183 parts cover HBOM
CycloneDX support	All versions	type: device since v1.1; type: firmware since v1.2 (May 2020)
Typical generation tool	Syft, Trivy, cdxgen	Manual or hardware vendor datasheets; no mature auto-generation tooling yet
Place in technical file	Technical file, component inventory section	Same location, as part of the unified component inventory

For the full SBOM obligation, see CRA SBOM requirements. For format comparison, see CycloneDX vs SPDX.

What to include in an HBOM

The following categories reflect practical engineering judgment, not a statutory list. The CRA does not enumerate hardware component categories. You should include any physical component that processes, stores, or transmits digital data because those components can affect cybersecurity.

Processing and connectivity components

These are the highest-priority entries because their firmware is the most likely vector for vulnerabilities:

• Main application processor or SoC (name, manufacturer, version/stepping, firmware version)
• Wireless modules: Wi-Fi, Bluetooth, Zigbee, LoRa, cellular (each with firmware version)
• Secondary microcontrollers handling specific subsystems

Security components

Security hardware deserves its own entries because vulnerabilities here carry the highest impact:

• Trusted Platform Module (TPM) chips
• Secure elements and hardware security modules
• Cryptographic accelerators
• Any component that stores keys, certificates, or credentials at rest

Storage components

Storage matters when it holds code, configuration, or sensitive data:

• Flash memory holding bootloader or firmware
• eMMC or SD modules if used for persistent storage
• EEPROM holding device configuration

For each entry, record at minimum: component name, manufacturer, hardware version or stepping, and firmware version where applicable. Link each hardware entry to its corresponding firmware entry via CycloneDX dependency relationships.

How firmware fits the CRA definition of software

Firmware is sometimes treated as a special category distinct from both hardware and software. For CRA work, treat firmware as software because it is computer code running inside an electronic information system.

The practical implication is straightforward. Firmware running on a chip in your product is a software component of your product with digital elements. It must appear in your component inventory. If it contains a vulnerability, that vulnerability follows the same vulnerability-handling and reporting workflow as any other software vulnerability.

CycloneDX as a unified SBOM and HBOM format

CycloneDX handles both hardware and software components in a single document. You do not need a separate file format for your HBOM.

Component type history (relevant to hardware)

CycloneDX version	Release date	Relevant addition
1.1 or earlier	2018	type: device introduced
1.2	2020-05-26	type: firmware added
1.5	2023-06-26	type: device-driver added
1.6	2024	CRA baseline target
1.7	October 2025	Latest stable release

Note that there is no type: hardware in any CycloneDX version. The correct type for a physical chip or module is type: device.

The CycloneDX v1.2 specification guidance on modelling hardware with firmware states:

"A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device."

This guidance maps directly to the CRA's treatment: the physical device and its firmware are related but distinct components, each with their own identity and version.

Target CycloneDX 1.6 or later for new HBOM work. BSI TR-03183-2 v2.1.0 (2025-08-20) raised its minimum CycloneDX requirement to 1.6. Aligning to 1.6 or later keeps your SBOM and HBOM in the same document and satisfies TR-03183.

Example: ESP32 device with firmware stack

The example below shows a realistic hardware component (ESP32-WROOM-32E), its firmware (ESP-IDF), and a library within the firmware (mbedtls), all in a single CycloneDX 1.6 or later document with dependency relationships:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "device",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "WiFi+BT SoC Module",
      "properties": [
        { "name": "firmware-version", "value": "4.4.1" },
        { "name": "secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Firmware on ESP32"
    },
    {
      "type": "library",
      "name": "mbedtls",
      "version": "2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "ESP32-WROOM-32E", "dependsOn": ["ESP-IDF"] },
    { "ref": "ESP-IDF", "dependsOn": ["mbedtls"] }
  ]
}

The dependencies array makes the relationship between hardware and firmware explicit. When mbedtls releases a CVE patch, you can trace which device is affected and which firmware version to update.

For format comparison and tooling choices, see CycloneDX vs SPDX.