For years, IoT firmware was a black box. Manufacturers shipped devices with proprietary firmware, and nobody outside the company knew what open-source components were inside. That era is ending.
The US Executive Order 14028, the EU Cyber Resilience Act, and emerging FDA requirements for medical devices are converging on a single demand: if you ship software, you need to provide a Software Bill of Materials. For IoT manufacturers, this means documenting every component in your firmware, from the RTOS kernel to the third-party libraries handling network protocols.
Why IoT Firmware Is Especially Challenging
Generating SBOMs for a modern web application is relatively straightforward. Package managers maintain dependency trees. Build tools resolve and record versions. The ecosystem has standardized on formats like SPDX and CycloneDX.
IoT firmware is a different world.
Binary-only components. Many IoT devices include binary blobs from silicon vendors. Wi-Fi drivers, Bluetooth stacks, and hardware abstraction layers are often provided as precompiled libraries with no source code. Identifying the open-source components within these blobs requires binary analysis, not just parsing a manifest file.
Custom build systems. IoT firmware rarely uses npm, pip, or Maven. Build systems like Yocto/OpenEmbedded, Buildroot, and custom Makefiles manage compilation from source. These tools have varying levels of support for SBOM generation, and the output often requires significant post-processing.
Deeply embedded dependencies. An IoT device's firmware might include a stripped-down version of OpenSSL, a custom fork of BusyBox, and patches applied to the Linux kernel that are specific to the hardware platform. Tracking these modifications and mapping them to upstream versions requires tooling that understands firmware-specific build patterns.
Long device lifetimes. An IoT device deployed in 2024 might run for 10-15 years. The SBOM needs to remain accurate and accessible for the device's entire lifecycle, even as the manufacturer's tooling and processes evolve.
Multi-layer firmware. Modern IoT devices often have multiple processors, each running its own firmware. A smart camera might have an application processor running Linux, a network processor running an RTOS, and a dedicated AI accelerator with its own software stack. A complete SBOM covers all layers.
The Regulatory Landscape
US Executive Order 14028 requires SBOMs for software sold to the federal government. For IoT devices deployed in government facilities (building management systems, security cameras, sensors), this means firmware SBOMs are already mandatory for federal contracts.
EU Cyber Resilience Act (CRA) will require manufacturers of products with digital elements sold in the EU to maintain and provide SBOMs. The CRA applies broadly to IoT devices and carries significant penalties for non-compliance. Expected enforcement begins in 2027, but preparation should start now.
FDA premarket cybersecurity guidance requires medical device manufacturers to provide SBOMs as part of premarket submissions. The FDA specifically calls out the need to include third-party components, open-source software, and off-the-shelf software in the SBOM.
NIST Cybersecurity Framework and the associated SP 800-218 (Secure Software Development Framework) recommend SBOM practices that are increasingly being incorporated into procurement requirements.
The trajectory is clear: SBOMs for IoT firmware are moving from recommended to required across major markets.
Practical Steps for IoT Manufacturers
Start with what you know. Even before tackling binary blobs and custom build systems, document the components you manage directly. The RTOS, network stacks, cryptographic libraries, and application frameworks you've chosen are the foundation of your SBOM.
Integrate SBOM generation into your build process. Retroactively generating SBOMs for shipped firmware is painful and error-prone. Build SBOM generation into your CI/CD pipeline so that every firmware build automatically produces an SBOM. Yocto has native SPDX support since the Kirkstone release. Buildroot is adding similar capabilities.
Address the binary blob problem. For binary-only components from silicon vendors, require SBOMs from your suppliers. If suppliers won't provide them, use binary analysis tools to identify embedded open-source components. Tools like Black Duck Binary Analysis and SCANOSS can identify known libraries within binary blobs.
Choose a standard format. CycloneDX and SPDX are both accepted. CycloneDX tends to be more developer-friendly and has strong support for vulnerability correlation. SPDX has deeper roots in licensing compliance and is an ISO standard. Either works; consistency matters more than the specific choice.
Plan for lifecycle management. An SBOM is a living document. When you release a firmware update, the SBOM needs to be updated. When a vulnerability is found in a component listed in the SBOM, you need a process to assess impact, develop a fix, and communicate with affected customers. Build this lifecycle management into your product security program.
Test your SBOM's usefulness. A good test: take a recently disclosed CVE in a component you use and see how quickly you can determine which firmware versions and device models are affected using only your SBOM data. If the answer is "hours or days," your SBOM process needs improvement. If it's "minutes," you're on the right track.
Common Mistakes to Avoid
Incomplete SBOMs. An SBOM that only lists top-level packages is insufficient. It needs to include transitive dependencies, the components that your components depend on. A vulnerability in zlib affects every package that links against it, even if zlib isn't in your direct dependency list.
Stale SBOMs. Generating an SBOM once and shipping it unchanged with every firmware version defeats the purpose. Automate generation as part of your build to keep it current.
Treating SBOMs as a compliance checkbox. The value of SBOMs comes from using them operationally: querying them during incident response, monitoring them for new vulnerabilities, and sharing them with customers who need to assess their own risk. An SBOM that sits in a folder is paperwork. An SBOM integrated into your security operations is a security tool.
Ignoring the bootloader and pre-boot environment. Many IoT SBOMs cover the main firmware but ignore U-Boot, the secure boot chain, and other pre-boot components. These components have their own dependencies and vulnerability histories.
How Safeguard.sh Helps
Safeguard.sh simplifies IoT firmware SBOM management by providing a centralized platform for generating, storing, and querying SBOMs across your entire product portfolio. Our platform supports both CycloneDX and SPDX formats and integrates with common IoT build systems to automate SBOM generation as part of your firmware build process.
For regulatory compliance, Safeguard.sh maintains the complete audit trail regulators expect: when each SBOM was generated, what changed between firmware versions, and how vulnerabilities were addressed. Policy gates ensure that firmware builds meet your security and compliance requirements before release. When a new CVE drops, Safeguard.sh lets you query across all your product SBOMs instantly, identifying affected devices and firmware versions in minutes instead of days, exactly the capability that regulators expect and your customers deserve.