HBOM Guide: Hardware Bill of Materials for CRA Compliance

Your SBOM lists libraries and software packages. It will not tell you whether the radio module in your product is out of support, whether the bootloader is updateable, or which batch used a substituted chipset.

That is the job of a Hardware Bill of Materials (HBOM). The CRA does not use the term "HBOM", but hardware products, firmware, 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, and know whether you can act when a vulnerability appears.

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, security settings and support dates. You cannot manage those risks without listing them.

The SBOM requirement is where this evidence usually lands. The CRA asks manufacturers to identify and document components and vulnerabilities, including through a machine-readable SBOM covering at least top-level dependencies. 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 hardware side of the inventory.

Support periods are part of the same picture. The CRA lets you account for core component support periods. Your technical documentation then needs the information used to set the product support period. If a chipset or module reaches end of support before your product support period ends, the HBOM is where that fact should first become visible.

What an HBOM looks like in a real supply chain

Imagine an EU importer buying a connected gateway from a Shenzhen ODM. The importer does not need every resistor. It does need the build facts that change cyber risk: radio module, firmware baseline, support status and approved substitutions.

The key difference is the as-built record. A design BOM says what engineering intended to use. The HBOM should also capture what the factory actually shipped.

HBOM vs SBOM at a glance

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

What to include, and where to stop

The CRA does not give a statutory HBOM field list. It also does not require you to list every passive physical part. Its component-inventory baseline sets a top-level dependency floor for the SBOM, and the hardware side should follow the same risk logic.

Use this threshold: list hardware that can change the product's cyber risk, vulnerability status, update path or support-period evidence.

Start with components that do one of these jobs:

• Process data: main processors, SoCs, microcontrollers, FPGAs and security-related ASICs.
• Store code or secrets: flash, eMMC, Trusted Platform Modules (TPMs), secure elements and storage controllers.
• Transmit data: Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, cellular and GNSS modules.
• Boot or update the product: boot managers, bootloaders, UEFI, BIOS, baseboard management controller (BMC) firmware and update controllers.
• Enforce security: cryptographic accelerators, hardware roots of trust, key stores and secure enclaves.
• Expose service access: production debug ports, JTAG, UART, SWD or management interfaces where the production lock state matters.

Passive parts such as ordinary resistors and capacitors normally fall outside the HBOM unless they have a security function, a digital identity, firmware, or a known substitution risk. The practical test is simple: if a vulnerability, advisory, EOL notice or supplier substitution for the part would change your product risk decision, list it.

High-priority hardware categories

The following categories are not a statutory list. They are the entries most likely to matter in CRA evidence because they carry firmware, keys, interfaces or supplier-support dependencies.

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 with CycloneDX dependency relationships.

Firmware layers people miss

A single "firmware version" field is often too shallow. Many products contain several firmware layers with different owners, update paths and vulnerability sources.

Commonly missed layers include:

• Boot firmware: boot ROM, bootloader, boot manager and secure-boot configuration.
• Radio firmware: Wi-Fi, Bluetooth, cellular baseband, Zigbee, Thread, LoRaWAN and NFC firmware.
• Platform firmware: UEFI, BIOS, BMC, option ROMs and CPU microcode. NIST SP 800-193 treats platform firmware as fundamental hardware and firmware needed to boot and operate a system.
• Controller firmware: storage controllers, network cards, power controllers, sensor hubs and embedded controllers.
• Security firmware: TPM firmware, secure-element operating systems, secure-element applets, trusted execution environment (TEE) images and HSM firmware.
• Programmable logic: FPGA bitstreams and security-related ASIC or FPGA configuration.
• Vendor binary blobs: SDK-supplied firmware blobs that are bundled into the product image but maintained by a chip or module vendor.

Each layer should be a separate component when it has its own version, update path, maintainer or advisory source. That is what lets you answer the useful question later: which exact product versions are affected by this firmware advisory?

Fields that make an HBOM useful

The statutory floor is narrower than a useful HBOM. The fields below are not all mandatory under the CRA. They are the evidence that lets you handle vulnerabilities, supplier changes and support-period decisions without starting from zero.

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.

If firmware cannot be updated

Some firmware cannot be updated in the field. Boot ROM may be mask-programmed. Secure element code may be vendor-controlled. A radio module may expose no customer update path. That does not make the component disappear from CRA evidence.

The CRA expects vulnerabilities to be addressable through security updates where that applies. If a hardware component cannot receive updates, document that fact in the HBOM and the risk assessment.

Record:

• Update status: field-updateable, vendor-only, factory-only or immutable.
• Reason: ROM, one-time programmable memory, locked vendor module, certification constraint or no exposed update channel.
• Compensating controls: isolation, disabled feature, network restriction, extra authentication or product-level mitigation.
• Response route: firmware update, module replacement, unit recall, customer advisory or VEX not_affected statement where the vulnerable path is not reachable.
• Affected range: product version, PCB revision, lot or serial range.

If an exploitable vulnerability cannot be fixed or mitigated, CRA corrective-action duties can force corrective measures, withdrawal or recall. The HBOM should give you the affected product range before that decision becomes urgent.

Component EOL affects the support period

The product support period is not only a customer-service promise. It is part of the CRA vulnerability-handling model.

The CRA lets you take account of the support periods of integrated core third-party components when setting the product support period. Your technical documentation then needs the information used to determine that support period. CRA guidance on long-lived hardware examples includes motherboards, microprocessors, routers, modems, switches and industrial control systems, which are often used for more than five years.

That makes component EOL an HBOM field, not just a procurement note.

For core components, record:

• Supplier support end date: month and year where available.
• Last firmware release date: the latest date the supplier shipped a security-relevant firmware update.
• Advisory source: PSIRT page, CSAF feed, mailing list or supplier contact.
• Replacement route: pin-compatible part, redesign plan, last-time-buy decision or product EOL decision.
• Contract cover: whether supplier patch and notice duties cover your declared product support period.

If a core module ends support before your product does, you have a decision to make before market placement. Extend supplier cover, choose a different part, limit the product support period where justified, or document a replacement plan.

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)

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

CycloneDX component-type guidance treats the physical device and the software running on it as separate components. A processor or chipset should be represented as a device, while the code running on it should be represented as firmware or operating-system, depending on the case.

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.

CycloneDX also has official cdx:device:* properties for hardware details such as function, board location, device type, serial number, lot number and GS1 identifiers. Use those names where they fit. If you add custom properties for updateability or security state, namespace them clearly so readers do not confuse them with official CycloneDX taxonomy.

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",
  "version": 1,
  "components": [
    {
      "type": "device",
      "bom-ref": "device:esp32-wroom-32e",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "Wi-Fi and Bluetooth SoC module",
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf"
        }
      ],
      "properties": [
        { "name": "cdx:device:function", "value": "Wi-Fi and Bluetooth connectivity" },
        { "name": "cdx:device:deviceType", "value": "SMD module" },
        { "name": "example:firmware:updateable", "value": "vendor-supported" },
        { "name": "example:security:secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "firmware:esp-idf-4.4.1",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Espressif IoT Development Framework running on ESP32"
    },
    {
      "type": "library",
      "bom-ref": "library:mbedtls-2.28.0",
      "name": "mbedtls",
      "version": "2.28.0",
      "purl": "pkg:generic/mbedtls@2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "device:esp32-wroom-32e", "dependsOn": ["firmware:esp-idf-4.4.1"] },
    { "ref": "firmware:esp-idf-4.4.1", "dependsOn": ["library:mbedtls-2.28.0"] }
  ]
}

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.

The example omits a hardware CPE on purpose. National Vulnerability Database (NVD) CPE strings are product-specific, and module-level and die-level identifiers do not always line up. Add a cpe field only when you have verified the exact NVD entry for the component. For format comparison and tooling choices, see CycloneDX vs SPDX.

Hardware vulnerability matching is different

Software vulnerability scanners often match by Package URL (PURL), Common Platform Enumeration (CPE) or package metadata. Hardware is messier.

PURL is built around software package ecosystems such as npm, Maven, PyPI, Debian and RPM. It is useful for firmware packages or libraries where the software is distributed like a package. It is not the right identifier for a physical chip.

CPE can represent hardware through part=h, and CycloneDX has a top-level cpe field on components. Use it when a verified NVD CPE exists. But do not assume every chip, module or firmware image has one.

For hardware entries without a reliable CPE, keep the matching trail human-readable:

• exact manufacturer name
• manufacturer part number
• hardware revision or stepping
• firmware name and version
• vendor advisory or PSIRT URL
• supplier contact
• GS1 identifier where available, using the relevant cdx:device:gs1:* property

Then monitor the sources that actually publish hardware and firmware advisories: the supplier's PSIRT page, NVD, CISA Known Exploited Vulnerabilities, CISA ICS advisories where relevant, and sector-specific feeds for industrial, medical or radio products. Use VEX or equivalent evidence when a component is present but the vulnerable function is not reachable in your product. For the reporting workflow, see CRA vulnerability and incident reporting.

What to ask suppliers and contract manufacturers

The manufacturer owns component due diligence. For hardware, that means asking for security and lifecycle data before the part is locked into the product.

Ask suppliers and contract manufacturers for:

• Exact shipped identity: manufacturer part number, hardware revision, firmware version and any approved substitutions.
• Update route: whether firmware is field-updateable, vendor-only, factory-only or immutable.
• Update security: signing, authentication, anti-rollback and secure-distribution details.
• Support dates: component EOL, last-time-buy, last firmware release and support end date.
• Advisory channel: PSIRT page, security mailing list, CSAF feed, support portal or named contact.
• Known-vulnerability status: current advisories, fixed firmware versions and any VEX or CSAF statement.
• Production traceability: as-built BOM per production run, lot or serial range where substitutions can occur.
• Supply-chain route: authorised distributor or original component manufacturer source where counterfeit or grey-market risk matters.

A design BOM is not enough when an original design manufacturer (ODM) or contract manufacturer can substitute modules during production. You need the as-built component record for the units you place on the EU market.