HBOM for CRA Compliance: Hardware Bill of Materials Guide

While SBOM (Software Bill of Materials) gets most of the attention, products with digital elements often have significant hardware components, each potentially containing firmware with its own vulnerabilities. HBOM (Hardware Bill of Materials) provides visibility into these physical components and their embedded software.

This guide explains HBOM in the CRA context.

What Is HBOM?

Definition

A Hardware Bill of Materials (HBOM) is a structured inventory of physical components in a product, typically including:

• Component identification (part numbers, manufacturers)
• Hardware versions/revisions
• Firmware versions (embedded in components)
• Security-relevant attributes
• Supply chain information

HBOM vs. Traditional BOM

TRADITIONAL BOM (Manufacturing):
Focus: Production and procurement
Content: Parts, quantities, suppliers, costs
Use: Manufacturing, inventory, purchasing

HBOM (Security-focused):
Focus: Security and transparency
Content: Components, firmware, security attributes
Use: Vulnerability management, supply chain security

OVERLAP:
Both list physical components
HBOM adds security-relevant information
HBOM links to firmware/software content

HBOM vs. SBOM

SBOM:
- Software components
- Libraries and dependencies
- Operating system components
- Application code

HBOM:
- Hardware components
- Chips and modules
- Firmware in components
- Physical security features

RELATIONSHIP:
┌─────────────────────────────────────────────┐
│ Complete Product Transparency               │
│                                             │
│  ┌─────────────┐    ┌─────────────┐        │
│  │    SBOM     │    │    HBOM     │        │
│  │             │    │             │        │
│  │ Application │    │ PCB         │        │
│  │ Libraries   │◄──►│ Chips       │        │
│  │ OS          │    │ Modules     │        │
│  │ Firmware*   │    │ Firmware*   │        │
│  └─────────────┘    └─────────────┘        │
│                                             │
│  *Firmware appears in both. It's software   │
│   running on hardware                       │
└─────────────────────────────────────────────┘

Why HBOM Matters for CRA

CRA Requirements and Hardware

While CRA focuses on "products with digital elements," these products are often hardware devices:

CRA Article 3(1) Definition:

"'product with digital elements' means a software or hardware product and its remote data processing solutions..."

Hardware Contains Software:

• Microcontrollers have firmware
• Network chips have embedded code
• Security modules have cryptographic software
• Sensors may have processing firmware

Vulnerability Tracking Requirement

CRA requires manufacturers to:

• Have no known exploitable vulnerabilities
• Handle vulnerabilities in product components
• Provide security updates

For hardware products, this means:

• Tracking vulnerabilities in component firmware
• Knowing what's inside your hardware
• Being able to update or mitigate component vulnerabilities

Supply Chain Traceability

CRA Article 13(5) requires appropriate due diligence for components:

"Manufacturers shall exercise due diligence when integrating components sourced from third parties..."

HBOM supports this by documenting:

• What components are in your product
• Who supplies them
• What firmware versions are present
• What security features they have

What to Include in HBOM

Core Component Information

HBOM COMPONENT ENTRY STRUCTURE

IDENTIFICATION:
- Component type (MCU, radio module, sensor, etc.)
- Manufacturer name
- Part number / Model
- Hardware revision

FIRMWARE INFORMATION:
- Firmware version
- Firmware supplier (if different from HW)
- Update capability
- Known vulnerability status

SECURITY ATTRIBUTES:
- Secure boot support
- Hardware security module
- Tamper resistance
- Cryptographic capabilities
- Unique ID / serial number

SUPPLY CHAIN:
- Direct supplier
- Country of origin (if known)
- End-of-life status

Component Categories to Track

HBOM COMPONENT CATEGORIES

PROCESSING:
- Main processor / MCU
- Co-processors
- FPGA / programmable logic
- Application processors

CONNECTIVITY:
- WiFi modules
- Bluetooth modules
- Cellular modems
- Ethernet controllers
- LoRa / Zigbee / Thread radios

SECURITY:
- TPM / Secure elements
- Hardware security modules
- Crypto accelerators
- Secure memory

STORAGE:
- Flash memory
- EEPROM
- SD card controllers

SENSORS:
- Environmental sensors
- Motion sensors
- Biometric sensors
- Imaging sensors

POWER:
- Power management ICs
- Battery management

INTERFACE:
- Display controllers
- USB controllers
- Audio codecs

Depth Considerations

HBOM DEPTH LEVELS

LEVEL 1: Major Components
- Main processor
- Connectivity modules
- Security elements
- Components with updatable firmware

LEVEL 2: Secondary Components
- Supporting ICs
- Sensors
- Memory chips
- Power management

LEVEL 3: Passive/Simple Components
- Typically NOT in HBOM
- Resistors, capacitors
- Simple connectors
- Non-programmable components

RECOMMENDATION FOR CRA:
Focus on Level 1 (critical)
Include Level 2 if feasible
Level 3 rarely security-relevant

HBOM Format Options

CycloneDX HBOM

CycloneDX supports hardware components natively:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:...",
  "version": 1,
  "metadata": {
    "component": {
      "type": "device",
      "name": "Smart Sensor Pro",
      "version": "2.0"
    }
  },
  "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": "device",
      "name": "ATECC608B",
      "version": "Rev B",
      "manufacturer": {
        "name": "Microchip"
      },
      "description": "Secure Element",
      "properties": [
        {
          "name": "type",
          "value": "secure-element"
        }
      ]
    }
  ]
}

SPDX HBOM

SPDX can also represent hardware:

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: Smart-Sensor-Pro-HBOM
DocumentNamespace: https://example.com/hbom/ssp-2.0

PackageName: ESP32-WROOM-32E
SPDXID: SPDXRef-MCU
PackageVersion: Rev3
PackageSupplier: Organization: Espressif Systems
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageComment: Main WiFi+BT module, firmware v4.4.1

Unified SBOM+HBOM

Best practice is often a unified BOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "device",
      "name": "ESP32-WROOM-32E",
      "description": "Hardware module"
    },
    {
      "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"]
    }
  ]
}

Creating and Maintaining HBOM

Initial HBOM Creation

HBOM CREATION PROCESS

STEP 1: INVENTORY HARDWARE
- Review schematic / BOM from engineering
- Identify programmable components
- Note components with firmware

STEP 2: GATHER INFORMATION
- Manufacturer datasheets
- Part numbers and revisions
- Firmware versions from suppliers
- Security feature information

STEP 3: ASSESS SECURITY RELEVANCE
- Does component have firmware?
- Can firmware be updated?
- Does it handle security functions?
- Is it network-connected?

STEP 4: STRUCTURE DATA
- Choose format (CycloneDX recommended)
- Enter component information
- Link to firmware SBOM where applicable
- Document security attributes

STEP 5: VALIDATE
- Cross-check with engineering BOM
- Verify firmware versions
- Confirm supplier information

Ongoing Maintenance

HBOM MAINTENANCE PROCESS

TRIGGER: Hardware Revision
- Update component entries
- Note version changes
- Update firmware versions

TRIGGER: Firmware Update
- Update firmware version in HBOM
- Link to updated SBOM for firmware
- Track CVE status changes

TRIGGER: Component End-of-Life
- Mark component status
- Document replacement plan
- Assess security impact

TRIGGER: Vulnerability Discovered
- Check HBOM for affected components
- Assess exploitability
- Plan remediation

REGULAR REVIEW:
- Quarterly HBOM accuracy check
- Annual supply chain review
- Component EOL monitoring

Tool Support

HBOM TOOLING OPTIONS

COMMERCIAL:
- Finite State (firmware/hardware analysis)
- Cybellum (automotive focus)
- Exein (embedded security)

OPEN SOURCE:
- CycloneDX CLI (format validation)
- SBOM tooling (many support hardware types)

INTEGRATION:
- PLM systems (Product Lifecycle Management)
- ERP integration for BOM data
- CI/CD for firmware SBOM

HBOM for Specific Product Types

IoT Devices

IoT DEVICE HBOM FOCUS

CRITICAL COMPONENTS:
- Main MCU/SoC (firmware!)
- Connectivity module (WiFi, BT, cellular)
- Secure element (if present)
- Sensors with processing capability

EXAMPLE ENTRY:
Component: Nordic nRF52840
Type: BLE SoC
Firmware: Zephyr RTOS 3.2.0
Secure Boot: Yes
SBOM Link: /sbom/nrf52840-firmware-v3.2.0.json

Industrial Equipment

INDUSTRIAL EQUIPMENT HBOM FOCUS

CRITICAL COMPONENTS:
- Main PLC/controller
- Communication modules (PROFINET, EtherNet/IP)
- HMI processor
- Safety controller (if separate)
- I/O modules with intelligence

SPECIAL CONSIDERATIONS:
- Long lifecycle components
- Legacy component tracking
- Safety certification impact
- IEC 62443 alignment

Consumer Electronics

CONSUMER ELECTRONICS HBOM FOCUS

CRITICAL COMPONENTS:
- Application processor
- Connectivity (WiFi, BT)
- Audio/video codecs
- Security elements
- Storage controllers

VOLUME CONSIDERATIONS:
- Component sourcing changes
- Multiple suppliers possible
- Revision tracking at scale

Integrating HBOM with CRA Compliance

In Technical File

TECHNICAL FILE HBOM SECTION

SECTION: Component Inventory (HBOM)

PURPOSE:
Document hardware components with security
relevance, supporting vulnerability management
and supply chain due diligence requirements.

CONTENTS:
1. HBOM document (CycloneDX format)
2. Component security assessment summary
3. Firmware version tracking
4. Supply chain documentation

CROSS-REFERENCES:
- Link to SBOM for firmware components
- Link to supplier security assessments
- Link to vulnerability tracking records

Vulnerability Management

HBOM IN VULNERABILITY WORKFLOW

1. VULNERABILITY ANNOUNCED
   (e.g., CVE in ESP32 firmware)

2. CHECK HBOM
   - Which products use ESP32?
   - What firmware versions?
   - How many units affected?

3. ASSESS IMPACT
   - Is vulnerability exploitable in our use?
   - What's the risk level?
   - Are mitigations available?

4. REMEDIATION
   - Firmware update if available
   - Configuration mitigation
   - Customer notification

5. UPDATE RECORDS
   - Update HBOM firmware version
   - Update vulnerability status
   - Document remediation

Supply Chain Due Diligence

HBOM FOR SUPPLY CHAIN DUE DILIGENCE

SUPPLIER REQUIREMENTS:
- Request component HBOM from suppliers
- Require firmware SBOM for modules
- Establish vulnerability notification agreement

INCOMING INSPECTION:
- Verify component matches HBOM
- Check firmware version
- Validate security features

CHANGE MANAGEMENT:
- Supplier component changes → HBOM update
- Second-source qualification → HBOM entry
- EOL notification → HBOM status update

HBOM Checklist

HBOM IMPLEMENTATION CHECKLIST

INVENTORY:
[ ] All programmable components identified
[ ] Firmware versions documented
[ ] Security features noted
[ ] Suppliers recorded

FORMAT:
[ ] Standard format chosen (CycloneDX recommended)
[ ] Schema validated
[ ] Linked to SBOM where applicable
[ ] Version controlled

PROCESS:
[ ] Creation process documented
[ ] Update triggers defined
[ ] Responsibility assigned
[ ] Review schedule established

INTEGRATION:
[ ] Included in technical file
[ ] Linked to vulnerability management
[ ] Part of supplier requirements
[ ] Accessible for audits

MAINTENANCE:
[ ] Component changes tracked
[ ] Firmware updates reflected
[ ] EOL status monitored
[ ] Regular accuracy reviews

Common Challenges

Challenge: Supplier Data Availability

Problem: Suppliers don't provide detailed component information.

Solutions:

• Include HBOM requirements in supplier contracts
• Request SBOMs for modules with firmware
• Use publicly available datasheets
• Document known limitations

Challenge: Component Variations

Problem: Multiple component sources or revisions in production.

Solutions:

• Track all variants in HBOM
• Use version ranges where appropriate
• Link HBOM to production records
• Regular reconciliation

Challenge: Firmware Visibility

Problem: Can't determine firmware version in received components.

Solutions:

• Require firmware version marking
• Implement incoming inspection process
• Work with suppliers on visibility
• Accept and document limitations

Key Resources

HBOM RESOURCES

STANDARDS:
CycloneDX Specification: https://cyclonedx.org
SPDX Specification: https://spdx.dev

GUIDANCE:
NTIA SBOM (includes hardware): https://ntia.gov/sbom
CISA SBOM Resources: https://cisa.gov/sbom

TOOLS:
CycloneDX Tool Center: https://cyclonedx.org/tool-center/
Finite State: https://finitestate.io

How CRA Evidence Helps

CRA Evidence supports HBOM management:

• Unified BOM: Manage SBOM and HBOM together
• Component tracking: Track hardware components across products
• Firmware linking: Link hardware to firmware SBOMs
• Vulnerability correlation: Match CVEs to hardware components
• Technical file integration: Include HBOM in compliance documentation

Start your CRA compliance at app.craevidence.com.

Related Articles

• SBOM for CRA Compliance: Complete Guide to Software Bill of Materials -- Learn how to create and manage SBOMs, the mandatory complement to your HBOM.
• CRA Technical File: What to Include and How to Prepare -- Understand how HBOM fits into your overall CRA technical documentation.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.