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 defines "product with digital elements" in Article 3(1) to include hardware products and defines "hardware" in Article 3(5) as "a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data". The regulation does not use the term "HBOM" anywhere, but the obligation to document and exercise due diligence over all components, including hardware, flows directly from Article 3(1), Article 13(5), and Annex I, Part II, point (1).
Summary
- An HBOM is a structured inventory of the physical components in your product, including the firmware each component carries
- The CRA does not mandate an HBOM by that name, but Article 3(1) extends CRA scope to hardware products, Article 13(5) requires due diligence over all third-party components, and Annex I, Part II, point (1) requires documenting "components contained in products with digital elements"
- Firmware is software under Article 3(4): it "consists of computer code" and must appear in your SBOM alongside hardware component entries
- CycloneDX is the practical unified format:
type: devicecovers physical hardware,type: firmwarecovers embedded software, and both can coexist in a single CycloneDX 1.6 document - BSI TR-03183 does not currently cover HBOM as a concept; all three parts focus on software bills of materials and vulnerability reports
- The Commission may specify SBOM format and elements via implementing acts (Article 13(24)), but no parallel mandate for a separate HBOM format exists in the CRA text
Why HBOM matters under the CRA
The CRA's scope is broader than "software products". Article 3(1) defines "product with digital elements" as:
"a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately"
Article 3(5) defines "hardware" as:
"a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data"
That definition covers the processor on your PCB, the wireless module on your development board, and the secure element in your IoT gateway. These are not incidental to CRA compliance; they are within its scope.
Article 13(5) then places a concrete obligation on you as manufacturer:
"For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity."
You cannot exercise due diligence over hardware components you have not inventoried. Annex I, Part II, point (1) extends this further: the SBOM must cover "vulnerabilities and components contained in products with digital elements". A product that contains an ESP32 module contains that module's firmware stack as a component. An HBOM is the practical tool for capturing that inventory.
There is no provision in the CRA requiring a document called an HBOM. The obligation is to inventory all components, including hardware components, within the existing SBOM obligation under Annex I, Part II, point (1). An HBOM is a practical approach to meeting that obligation for hardware-heavy products, not a separate compliance document.
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 |
| CRA mandate | Explicit, Annex I, Part II, point (1) | Implicit, via Article 3(1) scope and Article 13(5) due diligence |
| 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 | Annex VII, point 2(b) and point 8 | 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 that is what Article 3(5) covers.
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.
A significant share of IoT vulnerabilities involve firmware that is never updated after shipment. Documenting firmware versions in your HBOM is the prerequisite for monitoring and remediation. You cannot track what you have not listed. See common SBOM mistakes for the broader pattern.
How firmware fits the CRA definition of software
Firmware is sometimes treated as a special category distinct from both hardware and software. The CRA does not create that third category. Article 3(4) defines software as:
"the part of an electronic information system which consists of computer code"
Firmware consists of computer code. Therefore, under the CRA, firmware is software. This is not an interpretation that goes beyond the text; it follows directly from the definition.
The word "firmware" does not appear anywhere in the CRA regulation. This is intentional: the Article 3(4) definition is broad enough to include it, so no separate classification is needed.
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 is subject to the same Article 14 reporting obligations as any 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 | Current CRA-conformity recommendation |
| 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 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 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 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.
Frequently asked questions
Does the CRA explicitly require an HBOM?
No, the CRA does not use the term "HBOM" anywhere. The obligation to document hardware components flows indirectly: Article 3(1) brings hardware products within CRA scope, Article 13(5) requires due diligence over all third-party components, and Annex I, Part II, point (1) requires documenting "components contained in products with digital elements". An HBOM is the practical approach to meeting these obligations for hardware products, not a named regulatory requirement.
Is firmware in a Bluetooth chip considered software under the CRA?
Yes. Article 3(4) defines software as "the part of an electronic information system which consists of computer code". Firmware consists of computer code, so it falls within that definition. The word "firmware" does not appear in the CRA; it does not need to, because the Article 3(4) definition already covers it. Any firmware running on a component in your product is a software component of your product with digital elements and must appear in your component inventory.
Does BSI TR-03183 cover HBOM?
No. BSI TR-03183 has three parts: Part 1 (General requirements), Part 2 (SBOM), and Part 3 (Vulnerability Reports). None of them cover HBOM as a structural concept. TR-03183-2 mentions firmware only as a component file-type within a software bill of materials, using the software_additionalPurpose: firmware field. If you need to document hardware components for CRA compliance, you must use engineering judgment and CycloneDX's native hardware types, rather than relying on TR-03183 guidance for that part of your inventory.
Which CycloneDX version supports both software and hardware components?
type: device has been in CycloneDX since v1.1 (2018 or earlier). type: firmware was added in v1.2, released May 2020. Both are therefore available in any recent CycloneDX version. For CRA work, target v1.6 or later: BSI TR-03183-2 v2.1.0 (August 2025) raised its minimum CycloneDX requirement to 1.6, and the latest stable release is 1.7 (October 2025). There is no type: hardware in any CycloneDX version; use type: device for physical components.