Yes. CycloneDX, for one, states that its specification can represent software, hardware devices, machine learning models, source code, and configurations, with manufacturer, license, and provenance data for each component. A single document can list the board, the radio module, and the firmware running on them.
Why fleets want both
Fleet questions mix layers. "Which devices have the vulnerable modem firmware" needs the module and its firmware version. "Which units use the recalled flash chip" needs the hardware revision. If hardware lives in a spreadsheet and software in an SBOM, nobody can join them quickly.
What to list
| Layer | Examples | Fields to capture |
|---|---|---|
| Device | Product model, hardware revision | Manufacturer, model, revision |
| Modules | Cellular, Wi-Fi, secure element | Supplier, part number, firmware version |
| Boot | ROM, bootloader | Version, signing state |
| OS | Kernel, libc, packages | Name, version, identifier |
| Application | Your code, vendored libraries | Name, version, hash |
| Configuration | Enabled services, default ports | Setting and value |
Not every field will be known. Mark unknowns as unknown, not blank. A silent blank looks like an omission and an explicit unknown looks like a task.
Steps
- Start with the device as the root component and give it a stable identifier.
- Add each hardware module with the supplier and part number you hold.
- Add the firmware or software on each module as its own component, and link it to the module.
- Link the OS and application packages from your build output.
- Record who supplied each component and whether you can regenerate it.
- Store one document per product revision and release.
A short example
Picture a gateway product, revision B. The root component is the gateway. Under it sit the cellular module, with its own firmware version, and the main board running a Linux image. The Linux image lists its kernel and packages. When a modem advisory arrives, you search for the module part number and firmware version and get the list of releases. You then join to the device map and have your affected units. The same document answers a recall question about a chip revision, because the revision is a field on a component, not a note in someone's inbox.
Limits to keep in mind
A hardware inventory is only as accurate as your supplier data. Chip and module firmware is often closed, and the supplier may not share contents. In that case, record the version and the supplier contact, and ask for their advisories. Also remember that a bill of materials describes a build, so the field state still comes from device check-ins.
If your build tooling emits CycloneDX, Safeguard can ingest it and run dependency scanning on the software part. The free scan at gold.safeguard.sh/scan is a quick way to see what a document yields.
Quick check
Is a hardware bill of materials the same as an SBOM?
They describe different layers. The CycloneDX specification can represent both kinds of component in one document.
What if a module supplier will not share firmware contents?
Record the module, firmware version, and supplier, mark the contents as unknown, and ask the supplier for advisories.
Sources
Last reviewed: 19 October 2026.
