HBOM-gids: Hardware Bill of Materials voor CRA

Uw SBOM vermeldt bibliotheken en softwarepakketten. Het vertelt u niet of de radiomodule in uw product buiten ondersteuning valt, of de bootloader bij te werken is, of welke batch een vervangen chipset bevat.

Dat is het werk van een Hardware Bill of Materials (HBOM). De CRA gebruikt de term "HBOM" niet, maar hardwareproducten, firmware, due diligence op componenten van derden en de SBOM-componenteninventaris wijzen allemaal op dezelfde praktische behoefte: weten welke hardware en firmware in het product zitten, en weten of u kunt handelen wanneer een kwetsbaarheid verschijnt.

Waarom HBOM relevant is onder de CRA

Het toepassingsgebied van de CRA is breder dan alleen softwareproducten. Hardwareproducten, afzonderlijk verhandelde hardwarecomponenten en de firmware in die componenten horen allemaal bij het inventarisatieprobleem van het product.

Dat is relevant voor fabrikanten, omdat due diligence voor componenten niet beperkt is tot opensourcebibliotheken. Een processor op uw PCB, een draadloze module op uw ontwikkelbord of een secure element in uw IoT-gateway kan firmware, beveiligingsinstellingen en ondersteuningsdatums meebrengen. U kunt die risico's niet beheren zonder ze te inventariseren.

De SBOM-verplichting is de juridische plek voor dit bewijs. De CRA vraagt fabrikanten om componenten en kwetsbaarheden te identificeren en documenteren, onder meer via een machine-leesbare SBOM die ten minste afhankelijkheden op het hoogste niveau dekt. Een ESP32-module brengt dus zowel de fysieke module als de firmwarestack in het componentenrecord. Een HBOM is het praktische hulpmiddel om die hardwarekant van de inventaris vast te leggen.

Ondersteuningsperioden horen bij hetzelfde plaatje. De CRA staat toe dat u rekening houdt met de ondersteuningsperioden van kerncomponenten. Uw technische documentatie heeft dan de informatie nodig die is gebruikt om de productondersteuningsperiode te bepalen. Als een chipset of module eerder buiten ondersteuning valt dan uw productondersteuningsperiode eindigt, is de HBOM de plek waar dat feit als eerste zichtbaar wordt.

Hoe een HBOM eruitziet in een echte toeleveringsketen

Stel dat een EU-importeur een verbonden gateway koopt van een ODM in Shenzhen. De importeur heeft niet elke weerstand nodig. Wel heeft hij de bouwgegevens nodig die het cyberrisico bepalen: radiomodule, firmware-basislijn, ondersteuningsstatus en goedgekeurde vervangingen.

Het cruciale verschil is het gerealiseerde bouwrecord. Een ontwerp-BOM laat zien wat engineering van plan was te gebruiken. De HBOM moet ook vastleggen wat de fabriek werkelijk heeft geleverd.

HBOM versus SBOM in een oogopslag

Voor de volledige SBOM-verplichting, zie CRA SBOM-vereisten. Voor formatvergelijking, zie CycloneDX versus SPDX.

Wat u opneemt en waar u stopt

De CRA geeft geen wettelijke HBOM-veldenlijst. De CRA vereist ook niet dat u elk passief fysiek onderdeel vermeldt. De componenteninventarisdrempel stelt een minimum van afhankelijkheden op het hoogste niveau voor de SBOM, en de hardwarekant moet dezelfde risicoaanpak volgen.

Gebruik deze drempelregel: vermeld hardware die het cyberrisico, de kwetsbaarheidsstatus, het updatepad of het bewijs voor de ondersteuningsperiode van het product kan beïnvloeden.

Begin met componenten die een van deze functies vervullen:

• Gegevens verwerken: hoofdprocessors, SoC's, microcontrollers, FPGA's en beveiligingsgerelateerde ASIC's.
• Code of geheimen opslaan: flash, eMMC, Trusted Platform Modules (TPM's), secure elements en opslagcontrollers.
• Gegevens overdragen: Wi-Fi-, Bluetooth-, Zigbee-, Thread-, LoRaWAN-, NFC-, Ethernet-, mobiele en GNSS-modules.
• Het product opstarten of bijwerken: bootmanagers, bootloaders, UEFI, BIOS, baseboard management controller (BMC) firmware en updatecontrollers.
• Beveiliging afdwingen: cryptografische accelerators, hardware roots of trust, sleutelopslag en secure enclaves.
• Servicetoegang bieden: productiedebugpoorten, JTAG, UART, SWD of beheerinterfaces waarbij de productiesluitingsstatus relevant is.

Passieve onderdelen zoals gewone weerstanden en condensatoren vallen normaliter buiten de HBOM, tenzij ze een beveiligingsfunctie hebben, een digitale identiteit, firmware of een bekend vervangingsrisico. De praktische test is eenvoudig: als een kwetsbaarheid, advies, EOL-bericht of leveranciersvervanging voor het onderdeel uw productrisicoafweging zou veranderen, neem het dan op.

Prioritaire hardwarecategorieën

De volgende categorieën vormen geen wettelijke lijst. Het zijn de vermeldingen die het meest waarschijnlijk relevant zijn als CRA-bewijs, omdat ze firmware, sleutels, interfaces of leveranciersondersteuningsafhankelijkheden bevatten.

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.

Firmwarelagen die mensen missen

Eén "firmwareversie"-veld is vaak te oppervlakkig. Veel producten bevatten meerdere firmwarelagen met verschillende eigenaren, updatepaden en kwetsbaarheidsbronnen.

Veelgemiste lagen zijn:

• Opstartfirmware: boot-ROM, bootloader, bootmanager en secure-bootconfiguratie.
• Radiofirmware: Wi-Fi-, Bluetooth-, mobiele baseband-, Zigbee-, Thread-, LoRaWAN- en NFC-firmware.
• Platformfirmware: UEFI, BIOS, BMC, option ROM's en CPU-microcode. NIST SP 800-193 behandelt platformfirmware als fundamentele hardware en firmware die nodig zijn om een systeem op te starten en te bedienen.
• Controllerfirmware: opslagcontrollers, netwerkkaarten, vermogenscontrollers, sensorhubs en ingebedde controllers.
• Beveiligingsfirmware: TPM-firmware, secure-elementbesturingssystemen, secure-elementapplets, TEE-images (trusted execution environment) en HSM-firmware.
• Programmeerbare logica: FPGA-bitstreams en beveiligingsgerelateerde ASIC- of FPGA-configuratie.
• Binaire blobs van leveranciers: SDK-geleverde firmwareblobs die in het productimage worden gebundeld maar worden onderhouden door een chip- of moduleleverancier.

Elke laag moet een afzonderlijk component zijn wanneer het een eigen versie, updatepad, beheerder of adviesbron heeft. Zo kunt u later de relevante vraag beantwoorden: welke exacte productversies worden getroffen door dit firmwareadvies?

Velden die een HBOM bruikbaar maken

De wettelijke ondergrens is smaller dan een bruikbare HBOM. De onderstaande velden zijn niet allemaal verplicht onder de CRA. Het zijn de gegevens die u in staat stellen kwetsbaarheden, leverancierswijzigingen en beslissingen over de ondersteuningsperiode te verwerken zonder van nul af aan te beginnen.

Hoe firmware past binnen de CRA-definitie van software

Firmware wordt soms behandeld als een aparte categorie, onderscheiden van zowel hardware als software. Voor CRA-werk behandelt u firmware als software, omdat het computercode is die draait in een elektronisch informatiesysteem.

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, volgt die kwetsbaarheid dezelfde kwetsbaarheidsafhandeling en meldingsstroom als elke andere softwarekwetsbaarheid.

Als firmware niet kan worden bijgewerkt

Sommige firmware kan niet in het veld worden bijgewerkt. Boot-ROM kan maskerprogrammeerd zijn. Secure-elementcode kan door de leverancier worden beheerd. Een radiomodule biedt mogelijk geen updatepad voor de klant. Dat doet het component niet verdwijnen uit het CRA-bewijs.

De CRA verwacht dat kwetsbaarheden via beveiligingsupdates te verhelpen zijn waar dat van toepassing is. Als een hardwarecomponent geen updates kan ontvangen, documenteer dat feit dan in de HBOM en de risicobeoordeling.

Leg vast:

• Updatestatus: in het veld bij te werken, alleen door leverancier, alleen in de fabriek of onveranderlijk.
• Reden: ROM, éénmalig programmeerbaar geheugen, vergrendelde leveranciersmodule, certificeringsbeperking of geen zichtbaar updatekanaal.
• Compenserende maatregelen: isolatie, uitgeschakelde functie, netwerkbeperking, extra authenticatie of mitigatie op productniveau.
• Responsroute: firmware-update, modulevervanging, terugroeping van eenheden, klantadvies of VEX not_affected-verklaring wanneer het kwetsbare pad niet bereikbaar is.
• Getroffen bereik: productversie, PCB-revisie, lot of serienummerbereik.

Als een exploiteerbare kwetsbaarheid niet kan worden opgelost of gemitigeerd, kunnen de corrigerende-actieplichten van de CRA corrigerende maatregelen, terugtrekking of terugroeping verplichten. De HBOM moet u het getroffen productbereik bieden voordat die beslissing urgent wordt.

Component-EOL beïnvloedt de ondersteuningsperiode

De productondersteuningsperiode is niet alleen een klantenservicebelofte. Het is onderdeel van het kwetsbaarheidsafhandelingsmodel van de CRA.

De CRA staat toe dat u rekening houdt met de ondersteuningsperioden van geïntegreerde kerncomponenten van derden bij het vaststellen van de productondersteuningsperiode. Uw technische documentatie heeft dan de informatie nodig die is gebruikt om die ondersteuningsperiode te bepalen. De CRA-begeleiding over voorbeelden van langlevende hardware omvat moederborden, microprocessors, routers, modems, switches en industriële controlesystemen, die vaak meer dan vijf jaar worden gebruikt.

Dat maakt component-EOL een HBOM-veld, niet alleen een inkoopnota.

Leg voor kerncomponenten vast:

• Einddatum leveranciersondersteuning: maand en jaar waar beschikbaar.
• Datum laatste firmware-release: de meest recente datum waarop de leverancier een beveiligingsrelevante firmware-update heeft uitgebracht.
• Adviesbron: PSIRT-pagina, CSAF-feed, mailinglijst of leverancierscontact.
• Vervangingsroute: pincompatibel onderdeel, herontwerpplan, besluit voor laatste aankoop of EOL-besluit voor het product.
• Contractdekking: of de patch- en meldingsplichten van de leverancier uw gedeclareerde productondersteuningsperiode dekken.

Als een kernmodule buiten ondersteuning valt vóór uw product, moet u voor marktintroductie een beslissing nemen. Verleng de leveranciersdekking, kies een ander onderdeel, beperk de productondersteuningsperiode waar dat gerechtvaardigd is, of documenteer een vervangingsplan.

CycloneDX als uniform 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)

Er bestaat geen type: hardware in enige CycloneDX-versie. Het juiste type voor een fysieke chip of module is type: device.

De CycloneDX-componenttyperichtlijn behandelt het fysieke apparaat en de software die erop draait als afzonderlijke componenten. Een processor of chipset moet als een device worden weergegeven, terwijl de code die erop draait als firmware of operating-system moet worden weergegeven, afhankelijk van het geval.

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 of later 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 of later houdt uw SBOM en HBOM in hetzelfde document en voldoet aan TR-03183.

CycloneDX heeft ook officiële cdx:device:*-eigenschappen voor hardwaredetails zoals functie, boardlocatie, apparaattype, serienummer, lotnummer en GS1-identificatoren. Gebruik die namen waar ze van toepassing zijn. Als u aangepaste eigenschappen toevoegt voor bijwerkmogelijkheden of beveiligingsstatus, geef ze dan een duidelijke naamruimte zodat lezers ze niet verwarren met de officiële CycloneDX-taxonomie.

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 of later document met afhankelijkheidsrelaties:

{
  "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"] }
  ]
}

De dependencies-array maakt de relatie tussen hardware en firmware expliciet. Wanneer mbedtls een CVE-patch uitbrengt, kunt u traceren welk apparaat is getroffen en welke firmwareversie moet worden bijgewerkt.

Het voorbeeld laat opzettelijk een hardware-CPE weg. CPE-strings van de National Vulnerability Database (NVD) zijn productspecifiek, en identificatoren op module- en dieniveau kloppen niet altijd. Voeg een cpe-veld alleen toe wanneer u het exacte NVD-item voor het component hebt geverifieerd. Voor formatvergelijking en keuze van tools, zie CycloneDX versus SPDX.

Kwetsbaarheidsmatching voor hardware is anders

Softwarekwetsbaarheidsscanners matchen vaak via Package URL (PURL), Common Platform Enumeration (CPE) of pakketmetadata. Hardware is minder gestandaardiseerd.

PURL is gebouwd rond software-package-ecosystemen zoals npm, Maven, PyPI, Debian en RPM. Het is nuttig voor firmwarepakketten of bibliotheken waarbij de software als een pakket wordt gedistribueerd. Het is niet de juiste identificator voor een fysieke chip.

CPE kan hardware vertegenwoordigen via part=h, en CycloneDX heeft een cpe-veld op het hoogste niveau van componenten. Gebruik het wanneer een geverifieerde NVD-CPE bestaat. Maar ga er niet van uit dat elke chip, module of firmware-image er een heeft.

Voor hardwarevermeldingen zonder betrouwbare CPE houdt u het matchingspoor leesbaar voor mensen:

• exacte fabrikantsnaam
• onderdeelnummer van de fabrikant
• hardwarerevisie of stepping
• firmwarenaam en -versie
• URL van het leveranciersadvies of PSIRT
• leverancierscontact
• GS1-identificator waar beschikbaar, met de relevante cdx:device:gs1:*-eigenschap

Monitor vervolgens de bronnen die daadwerkelijk hardware- en firmware-adviezen publiceren: de PSIRT-pagina van de leverancier, NVD, CISA Known Exploited Vulnerabilities, CISA ICS-adviezen waar relevant, en sectorspecifieke feeds voor industriële, medische of radioproducten. Gebruik VEX of gelijkwaardig bewijs wanneer een component aanwezig is maar de kwetsbare functie niet bereikbaar is in uw product. Voor de meldingsstroom, zie CRA-kwetsbaarheids- en incidentmelding.

Wat u aan leveranciers en contractfabrikanten vraagt

De fabrikant is verantwoordelijk voor due diligence voor componenten. Voor hardware betekent dat: beveiligings- en levenscyclusgegevens opvragen voordat het onderdeel definitief in het product wordt vastgelegd.

Vraag leveranciers en contractfabrikanten om:

• Exacte verzonden identiteit: onderdeelnummer van de fabrikant, hardwarerevisie, firmwareversie en eventuele goedgekeurde vervangingen.
• Updateroute: of firmware in het veld, alleen door de leverancier, alleen in de fabriek of helemaal niet kan worden bijgewerkt.
• Updatebeveiliging: ondertekening, authenticatie, anti-rollback en gegevens over veilige distributie.
• Ondersteuningsdatums: component-EOL, datum voor laatste aankoop, datum van laatste firmware-release en einddatum ondersteuning.
• Advieskanaal: PSIRT-pagina, beveiligingsmailinglijst, CSAF-feed, ondersteuningsportaal of benoemde contactpersoon.
• Status bekende kwetsbaarheden: actuele adviezen, gecorrigeerde firmwareversies en eventuele VEX- of CSAF-verklaring.
• Productietraceerbaarheid: as-built BOM per productierun, lot of serienummerbereik waar vervangingen kunnen optreden.
• Toeleveringsketenroute: geautoriseerde distributeur of originele componentenfabrikant als bron, wanneer het risico op namaak of grijze markt relevant is.

Een ontwerp-BOM is niet voldoende wanneer een original design manufacturer (ODM) of contractfabrikant modules tijdens de productie kan vervangen. U hebt het gerealiseerde componentenrecord nodig voor de eenheden die u op de EU-markt plaatst.

Wat u nu kunt doen

1. Stel de HBOM-drempel in: neem hardware op die gegevens verwerkt, opslaat, overdraagt, opstart, bijwerkt, beveiliging afdwingt, servicetoegang biedt of het bewijs voor de ondersteuningsperiode beïnvloedt.
2. Vraag leveranciersgegevens op vóór de productierelease: onderdeelnummer, revisie, firmwareversie, updatepad, advieskanaal en einddatum van ondersteuning.
3. Maak een CycloneDX 1.6 of later document met één type: device-vermelding per hardwarecomponent en één type: firmware-vermelding per firmware-image. Koppel ze met dependencies.
4. Leg bijwerkmogelijkheden en EOL vast voor kerncomponenten. Als een kernmodule niet kan worden bijgewerkt of buiten ondersteuning valt vóór het einde van uw productondersteuningsperiode, documenteer dan de mitigatie of het vervangingsplan.
5. Monitor leveranciersadviezen, NVD, CISA KEV en sectorfeeds voor elk kerncomponent. Zoekopdrachten in de CVE-database kunnen hardware- en firmware-issues missen waarbij identificatoren zwak zijn.
6. Plaats de verenigde SBOM, inclusief hardwarevermeldingen, in uw technische documentatie, waar deze op verzoek beschikbaar moet zijn voor markttoezichtautoriteiten. Als u SBOM- en HBOM-intake liever niet handmatig beheert over productversies heen, handelt CRA Evidence CycloneDX-intake en componenttracking over uw productportfolio af.