SBOM for IoT and Embedded Systems: The Hardest Supply Chain Security Problem

Why Embedded SBOMs Are Different

Enterprise software SBOMs describe the components in an application built by one team from known dependencies. An embedded device SBOM must describe components assembled from multiple supply chain tiers: the device vendor's application code, the real-time operating system (RTOS) or embedded Linux distribution, the bootloader (often U-Boot or a vendor-specific implementation), hardware abstraction layers provided by the silicon vendor, and firmware for peripheral components (radios, sensors, secure elements). Each tier may be provided by a different vendor with different SBOM practices.

Regulatory Pressure on IoT Security

The EU Cyber Resilience Act applies to IoT devices and connected products, requiring SBOMs as part of the technical documentation for CE marking. The NIST IR 8259 series provides SBOM guidance for IoT manufacturers. The UK Product Security and Telecommunications Infrastructure (PSTI) Act requires minimum security standards for consumer IoT devices. Medical device manufacturers are subject to FDA Section 524B requirements. Industrial IoT falls under IEC 62443 security standards that are increasingly incorporating SBOM practices.

Practical SBOM Generation for Embedded Systems

For Linux-based embedded systems, Yocto-based builds can generate SBOMs using the Yocto license manifest infrastructure combined with SBOM generation tools that integrate with BitBake. For RTOS-based systems without package managers, SBOM generation requires manual inventory combined with binary analysis of the firmware image. Binary analysis tools (Black Duck Binary Analysis, Fossity Binary, and others) can analyze firmware images to identify open source components without a build system integration.

The Lifetime Challenge

An enterprise application might have a three-to-five-year lifecycle. An industrial controller or medical device might be deployed for 15-20 years. The SBOM you generate at ship time must remain accessible and accurate for the device's entire operational lifetime — and you must have a monitoring process to identify newly disclosed vulnerabilities in device components for that entire period. This requires archiving SBOMs in a format and location that will be accessible for decades, and monitoring infrastructure that can match historical SBOM component inventories against current vulnerability intelligence.