A modern IoT device is a stack of software layers: a real-time operating system (RTOS), a networking stack, cryptographic libraries, drivers and application code — 70–90% of which comes from open source and third-party SDKs. An SBOM for IoT devices (Software Bill of Materials) is a machine-readable inventory of every one of those components, together with versions, licences and dependencies. Without it, a manufacturer does not know exactly what ends up in the flash memory of its devices — and that means a blind spot in both security and regulatory compliance.
In short: an SBOM for IoT devices is a complete, structured list of firmware components (open source and proprietary) with their versions, licences and dependency relationships. It lets you establish in hours rather than weeks which fielded devices are exposed to a newly disclosed flaw (for example in a TLS library), speeds up incident response, and is explicitly required by the EU Cyber Resilience Act.
What is an SBOM in the IoT context?
An SBOM is a formal, machine-readable inventory of all the software components that make up a device firmware image, analogous to the bill of materials (BOM) familiar from electronics manufacturing. The difference is that instead of resistors and integrated circuits it describes packages, libraries and code modules.
The US agency NTIA defined the minimum set of fields every entry should carry: supplier name, component name, version, unique identifiers (such as CPE or PURL), the dependency relationship, plus the SBOM author and a timestamp. In practice, IoT projects add licence data and cryptographic hashes of the files.
An SBOM for embedded firmware differs from an SBOM for a server-side application. The code is cross-compiled, statically linked into a single image, and some components arrive from closed silicon-vendor SDKs. Reviewing a package manager is therefore not enough — you also have to analyse the finished binaries.
Why is an SBOM critical for IoT security?
An SBOM cuts the response time to a newly disclosed vulnerability from weeks to hours. When a critical CVE lands in a widely used component — such as zlib, OpenSSL, mbedTLS or lwIP — a manufacturer with an up-to-date SBOM instantly filters the fleet and knows which models and firmware versions need a patch.
Log4Shell showed the scale of the problem back in 2021: many organisations needed weeks simply to work out where they were using the vulnerable library at all. In IoT devices, scattered across the field and hard to update, that kind of uncertainty is even more expensive. Because most embedded code originates in open source, software supply chain risk grows with every transitive dependency.
An SBOM is also the foundation of licence hygiene and due diligence. It exposes components under copyleft licences (such as GPL) that may force you to release source code, as well as abandoned and unsupported packages. Treat it as part of the wider IoT security best practices, alongside firmware encryption and boot integrity checks.
SBOM formats: SPDX, CycloneDX and SWID
The market has settled around three standards worth knowing before you choose tooling. Each has a slightly different purpose and set of strengths:
- SPDX — a Linux Foundation standard, published as ISO/IEC 5962:2021 (currently at SPDX 3.0). Strongest at describing licences and legal compliance; widely supported, notably by the Yocto build system.
- CycloneDX — an OWASP standard (version 1.6) built around security. It natively supports VEX, vulnerability data, and the SaaSBOM and HBOM (hardware) variants — a good fit for the IoT world.
- SWID — software identification tags per ISO/IEC 19770-2, used mainly for asset management and installation inventories.
For IoT devices the usual pick is CycloneDX (for its integration with vulnerability data) or SPDX (when licence compliance is the priority). Both are text formats (JSON/XML), so they are easy to version-control and sign digitally.
How do you generate an SBOM for IoT firmware?
An SBOM is best generated automatically in the CI/CD pipeline, on every firmware build, rather than by hand just before release. Only then does the inventory match what actually landed in the image. The following approach works well:
- From build manifests — tools such as Yocto/OpenEmbedded (the create-spdx class), west in Zephyr or CycloneDX generators read the list of packages and versions straight from the build configuration.
- From binary analysis — for blobs without sources (vendor SDKs, precompiled libraries) you use scanners such as Syft or binwalk, which recognise components inside the finished image.
- Signing and storage — the finished SBOM is signed, attached to the release artefact and fed into a monitoring system such as Dependency-Track.
Wiring SBOM generation into your CI/CD pipeline for embedded firmware means every image carries a verifiable inventory. That matters most for OTA updates at scale, where a fleet runs many software versions in parallel.
SBOM and the Cyber Resilience Act (CRA)
The SBOM is ceasing to be a good practice and becoming a legal obligation. The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — requires manufacturers to maintain an SBOM and handle vulnerabilities across the entire lifecycle of a product with digital elements.
The key dates are the duty to report actively exploited vulnerabilities from September 2026 and full application of the requirements from 11 December 2027. We cover the detail in our article on the CRA obligations of IoT manufacturers. Outside Europe, US Executive Order 14028 and the FDA requirement to include an SBOM in medical device submissions point in the same direction.
How an SBOM supports vulnerability response — the role of VEX
An SBOM alone tells you what is inside the device; VEX tells you whether it is genuinely a threat. VEX (Vulnerability Exploitability eXchange) is a companion document stating whether a given vulnerability actually affects the product — a component may be present but unused or unreachable.
Combining SBOM, VEX and continuous monitoring of vulnerability databases (NVD, OSV) drastically reduces false positives and lets the team focus on real risk. It creates a closed loop: detect the flaw, assess the impact, patch it, and deliver it safely as a signed update with boot integrity verification (secure boot).
Frequently asked questions (FAQ)
How does an SBOM for IoT differ from one for a cloud application?
An SBOM for IoT describes firmware that is cross-compiled and statically linked into a single image, often with components from closed silicon-vendor SDKs. It therefore requires binary analysis as well, not just a read of the package manager as in a typical server-side application.
Is an SBOM a legal requirement?
Yes. In the European Union the Cyber Resilience Act requires an SBOM for products with digital elements, with full application from December 2027. In the US the obligation covers government suppliers and manufacturers of medical devices submitted to the FDA, among others.
How often should an SBOM be updated?
An SBOM should be generated automatically on every firmware build so that it matches the released version exactly. It is also worth reassessing it whenever new vulnerabilities are disclosed in the components you use, even if the code itself has not changed.
Summary and key takeaways
An SBOM for IoT devices is now the basis of mature software supply chain security: it shortens vulnerability response, brings order to licensing and satisfies growing regulatory demands. The key is automated generation in CI/CD, the right format (CycloneDX or SPDX), and pairing the SBOM with VEX and continuous monitoring.
At FSS Technology we design IoT devices end to end — from hardware and firmware through secure boot and signed OTA updates to the cloud — with the SBOM built into the development process. If you want to prepare your products for the CRA and bring order to your firmware supply chain, explore our IoT device design services.