Uw SBOM bevat bibliotheken en softwarepakketten, maar wat doet u met de firmware op uw Bluetooth-chip of de microcontroller in het hart van uw apparaat? Een Hardware Bill of Materials (HBOM) breidt de componenteninventaris uit naar fysieke chips, modules en de firmware die daarop draait. De CRA definieert "product met digitale elementen" in Artikel 3, lid 1 als producten inclusief hardware, en definieert "hardware" in Artikel 3, lid 5 als "een fysiek elektronisch informatiesysteem, of delen daarvan, dat digitale gegevens kan verwerken, opslaan of verzenden". De verordening gebruikt de term "HBOM" nergens, maar de verplichting om alle componenten, inclusief hardware, te documenteren en er due diligence op toe te passen, vloeit rechtstreeks voort uit Artikel 3, lid 1, Artikel 13, lid 5, en Bijlage I, Deel II, punt 1.
Samenvatting
- Een HBOM is een gestructureerde inventaris van de fysieke componenten in uw product, inclusief de firmware die elk component draagt
- De CRA verplicht een HBOM niet bij naam, maar Artikel 3, lid 1 brengt hardwareproducten binnen het toepassingsgebied van de CRA, Artikel 13, lid 5 vereist due diligence over alle componenten van derden, en Bijlage I, Deel II, punt 1 verplicht het documenteren van "componenten in producten met digitale elementen"
- Firmware is software onder Artikel 3, lid 4: het "bestaat uit computercode" en moet naast hardwarecomponentvermeldingen in uw SBOM verschijnen
- CycloneDX is het praktische geunificeerde formaat:
type: devicedekt fysieke hardware,type: firmwaredekt ingebedde software, en beide kunnen naast elkaar bestaan in één CycloneDX 1.6-document - BSI TR-03183 dekt HBOM als concept momenteel niet; alle drie de delen richten zich op software bills of materials en kwetsbaarheidsrapporten
- De Commissie kan het SBOM-formaat en de -elementen specificeren via uitvoeringshandelingen (Artikel 13, lid 24), maar er bestaat in de CRA-tekst geen parallel mandaat voor een afzonderlijk HBOM-formaat
Waarom HBOM relevant is onder de CRA
Het toepassingsgebied van de CRA gaat verder dan "softwareproducten". Artikel 3, lid 1 definieert "product met digitale elementen" als:
"product met digitale elementen": een software- of hardwareproduct en zijn oplossingen voor gegevensverwerking op afstand, met inbegrip van software- of hardwarecomponenten die afzonderlijk in de handel worden gebracht
Artikel 3, lid 5 definieert "hardware" als:
"hardware": een fysiek elektronisch informatiesysteem, of delen daarvan, dat digitale gegevens kan verwerken, opslaan of verzenden
Die definitie dekt de processor op uw printplaat, de draadloze module op uw ontwikkelbord en het secure element in uw IoT-gateway. Deze zijn geen bijkomstigheid voor CRA-compliance; ze vallen binnen het toepassingsgebied.
Artikel 13, lid 5 legt u als fabrikant vervolgens een concrete verplichting op:
Met het oog op de naleving van lid 1 betrachten fabrikanten de passende zorgvuldigheid bij de integratie van van derden afkomstige componenten in producten met digitale elementen, zodat die componenten de cyberbeveiliging van het product met digitale elementen niet in gevaar brengen, ook bij integratie van componenten van vrije en opensourcesoftware die niet in het kader van een handelsactiviteit op de markt worden aangeboden.
U kunt geen due diligence toepassen op hardwarecomponenten die u niet hebt geïnventariseerd. Bijlage I, Deel II, punt 1 breidt dit verder uit: de SBOM moet "kwetsbaarheden en componenten in producten met digitale elementen" omvatten. Een product dat een ESP32-module bevat, heeft de firmwarestack van die module als component. Een HBOM is het praktische hulpmiddel om die inventaris vast te leggen.
Er bestaat geen bepaling in de CRA die een document met de naam HBOM vereist. De verplichting is om alle componenten, inclusief hardwarecomponenten, te inventariseren binnen de bestaande SBOM-verplichting onder Bijlage I, Deel II, punt 1. Een HBOM is een praktische aanpak om aan die verplichting te voldoen voor hardware-intensieve producten, geen afzonderlijk compliancedocument.
HBOM versus SBOM in een oogopslag
| Dimensie | SBOM | HBOM |
|---|---|---|
| Primair toepassingsgebied | Softwarebibliotheken, pakketten, frameworks | Fysieke componenten: chips, modules, secure elements |
| Firmwaredekking | Kan type: firmware-vermeldingen bevatten |
Firmware naast de bovenliggende hardwarecomponent vermeld |
| CRA-mandaat | Expliciet, Bijlage I, Deel II, punt 1 | Impliciet, via toepassingsgebied Artikel 3, lid 1 en due diligence Artikel 13, lid 5 |
| BSI TR-03183-dekking | Ja, TR-03183-2 (v2.1.0, 2025) | Nee, geen van de drie TR-03183-delen dekt HBOM |
| CycloneDX-ondersteuning | Alle versies | type: device sinds v1.1; type: firmware sinds v1.2 (mei 2020) |
| Gangbaar generatiehulpmiddel | Syft, Trivy, cdxgen | Handmatig of via hardware-leveranciersdatasheets; nog geen volwassen automatische generatietools |
| Plaats in technisch dossier | Bijlage VII, punt 2(b) en punt 8 | Zelfde locatie, als onderdeel van de geunificeerde componenteninventaris |
Voor de volledige SBOM-verplichting, zie CRA SBOM-vereisten. Voor formatvergelijking, zie CycloneDX versus SPDX.
Wat u in een HBOM opneemt
De volgende categorieën zijn gebaseerd op praktisch technisch oordeel, niet op een wettelijke lijst. De CRA somt geen hardwarecomponentcategorieën op. U moet elk fysiek component opnemen dat digitale gegevens verwerkt, opslaat of verzendt, want dat is wat Artikel 3, lid 5 dekt.
Verwerkings- en connectiviteitscomponenten
Dit zijn de hoogstprioritaire vermeldingen omdat hun firmware het meest waarschijnlijke aanvalsvector is voor kwetsbaarheden:
- Hoofd-applicatieprocessor of SoC (naam, fabrikant, versie/stepping, firmwareversie)
- Draadloze modules: Wi-Fi, Bluetooth, Zigbee, LoRa, mobiel (elk met firmwareversie)
- Secundaire microcontrollers die specifieke subsystemen aansturen
Beveiligingscomponenten
Beveiligingshardware verdient eigen vermeldingen omdat kwetsbaarheden hier de grootste impact hebben:
- Trusted Platform Module (TPM)-chips
- Secure elements en hardware security modules
- Cryptografische accelerators
- Elk component dat sleutels, certificaten of inloggegevens in rust opslaat
Opslagcomponenten
Opslag is relevant wanneer het code, configuratie of gevoelige gegevens bevat:
- Flashgeheugen met bootloader of firmware
- eMMC- of SD-modules voor permanente opslag
- EEPROM met apparaatconfiguratie
Leg voor elke vermelding minimaal vast: componentnaam, fabrikant, hardwareversie of stepping, en firmwareversie waar van toepassing. Koppel elke hardwarevermelding aan de bijbehorende firmwarevermelding via CycloneDX-afhankelijkheidsrelaties.
Een aanzienlijk deel van de IoT-kwetsbaarheden betreft firmware die na verzending nooit meer wordt bijgewerkt. Het documenteren van firmwareversies in uw HBOM is de voorwaarde voor monitoring en herstel. U kunt niet bijhouden wat u niet hebt geregistreerd. Zie veelgemaakte SBOM-fouten voor het bredere patroon.
Hoe firmware past binnen de CRA-definitie van software
Firmware wordt soms behandeld als een aparte categorie, onderscheiden van zowel hardware als software. De CRA creëert die derde categorie niet. Artikel 3, lid 4 definieert software als:
"software": het deel van een elektronisch informatiesysteem dat uit computercode bestaat
Firmware bestaat uit computercode. Onder de CRA is firmware dus software. Dit is geen interpretatie die verder gaat dan de tekst; het volgt rechtstreeks uit de definitie.
Het woord "firmware" komt nergens voor in de CRA-verordening. Dat is bewust: de definitie van Artikel 3, lid 4 is breed genoeg om firmware te omvatten, zodat geen afzonderlijke classificatie nodig is.
De praktische implicatie is eenvoudig. Firmware die draait op een chip in uw product is een softwarecomponent van uw product met digitale elementen. Het moet in uw componenteninventaris staan. Als het een kwetsbaarheid bevat, is die kwetsbaarheid onderworpen aan dezelfde meldingsverplichtingen van Artikel 14 als elke softwarekwetsbaarheid.
CycloneDX als geunificeerd SBOM- en HBOM-formaat
CycloneDX verwerkt zowel hardware- als softwarecomponenten in één document. U hebt geen apart bestandsformaat nodig voor uw HBOM.
Geschiedenis van componenttypen (relevant voor hardware)
| CycloneDX-versie | Releasedatum | Relevante toevoeging |
|---|---|---|
| 1.1 of eerder | 2018 | type: device geïntroduceerd |
| 1.2 | 2020-05-26 | type: firmware toegevoegd |
| 1.5 | 2023-06-26 | type: device-driver toegevoegd |
| 1.6 | 2024 | Huidige aanbeveling voor CRA-conformiteit |
| 1.7 | oktober 2025 | Meest recente stabiele release |
Er bestaat geen type: hardware in enige CycloneDX-versie. Het juiste type voor een fysieke chip of module is type: device.
De CycloneDX v1.2-specificatiegids voor het modelleren van hardware met firmware stelt:
"Een hardwareapparaat zoals een processor of chipset. Een hardwareapparaat met firmware MOET een component bevatten voor de fysieke hardware zelf, en een ander component van het type 'firmware' of 'operating-system' (afhankelijk van wat van toepassing is), met informatie over de software die op het apparaat draait."
Deze richtlijn sluit direct aan op de behandeling in de CRA: het fysieke apparaat en zijn firmware zijn gerelateerde maar afzonderlijke componenten, elk met hun eigen identiteit en versie.
Richt u op CycloneDX 1.6 voor nieuw HBOM-werk. BSI TR-03183-2 v2.1.0 (2025-08-20) heeft de minimale CycloneDX-vereiste verhoogd naar 1.6. Aansluiting bij 1.6 houdt uw SBOM en HBOM in hetzelfde document en voldoet aan TR-03183.
Voorbeeld: ESP32-apparaat met firmwarestack
Het onderstaande voorbeeld toont een realistisch hardwarecomponent (ESP32-WROOM-32E), de bijbehorende firmware (ESP-IDF) en een bibliotheek binnen de firmware (mbedtls), alles in één CycloneDX 1.6-document met afhankelijkheidsrelaties:
{
"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"] }
]
}
De dependencies-array maakt de relatie tussen hardware en firmware expliciet. Wanneer mbedtls een CVE-patch uitbrengt, kunt u traceren welk apparaat getroffen is en welke firmwareversie moet worden bijgewerkt.
Voor formatvergelijking en keuze van tools, zie CycloneDX versus SPDX.
Veelgestelde vragen
Vereist de CRA expliciet een HBOM?
Nee, de CRA gebruikt de term "HBOM" nergens. De verplichting om hardwarecomponenten te documenteren vloeit indirect voort: Artikel 3, lid 1 brengt hardwareproducten binnen het CRA-toepassingsgebied, Artikel 13, lid 5 vereist due diligence over alle componenten van derden, en Bijlage I, Deel II, punt 1 vereist het documenteren van "componenten in producten met digitale elementen". Een HBOM is de praktische aanpak om aan deze verplichtingen te voldoen voor hardwareproducten, geen benoemde wettelijke vereiste.
Wordt firmware in een Bluetooth-chip beschouwd als software onder de CRA?
Ja. Artikel 3, lid 4 definieert software als "het deel van een elektronisch informatiesysteem dat uit computercode bestaat". Firmware bestaat uit computercode en valt dus binnen die definitie. Het woord "firmware" komt niet voor in de CRA; dat hoeft ook niet, want de definitie van Artikel 3, lid 4 dekt het al. Alle firmware die draait op een component in uw product is een softwarecomponent van uw product met digitale elementen en moet in uw componenteninventaris staan.
Dekt BSI TR-03183 HBOM?
Nee. BSI TR-03183 heeft drie delen: Deel 1 (Algemene vereisten), Deel 2 (SBOM) en Deel 3 (Kwetsbaarheidsrapporten). Geen van deze delen dekt HBOM als structureel concept. TR-03183-2 noemt firmware alleen als een componentbestandstype binnen een software bill of materials, via het veld software_additionalPurpose: firmware. Als u hardwarecomponenten moet documenteren voor CRA-compliance, moet u technisch oordeel en de native hardwaretypen van CycloneDX gebruiken, in plaats van te vertrouwen op TR-03183-richtlijnen voor dat deel van uw inventaris.
Welke CycloneDX-versie ondersteunt zowel software- als hardwarecomponenten?
type: device is aanwezig in CycloneDX sinds v1.1 (2018 of eerder). type: firmware werd toegevoegd in v1.2, uitgebracht in mei 2020. Beide zijn dus beschikbaar in elke recente CycloneDX-versie. Richt u voor CRA-werk op v1.6 of later: BSI TR-03183-2 v2.1.0 (augustus 2025) heeft de minimale CycloneDX-vereiste verhoogd naar 1.6, en de meest recente stabiele release is 1.7 (oktober 2025). Er bestaat geen type: hardware in enige CycloneDX-versie; gebruik type: device voor fysieke componenten.