How SBOMs Help Secure Your Embedded System

Key takeaways:

• Embedded firmware combines multiple layers, each with its own dependencies and potential vulnerabilities. This makes SBOMs a necessity rather than a nice-to-have.
• Lack of an SBOM can slow down incident response and lead to missed vulnerabilities and compliance issues.
• Keeping an embedded SBOM current is challenging because IoT and embedded devices are frequently updated, and each change must be documented.
• Regulatory requirements for embedded SBOMs vary significantly by industry, with each imposing its own compliance standards.
• Automated SBOM tools often fall short during initial SBOM generation. To make sure your SBOM is complete, you need to validate it manually.

Businesses across industries use embedded devices — medical devices for patient monitoring, vehicle control systems, smart cars, and so on — to collect information, control equipment, and build smart ecosystems.

But due to their complexity, embedded systems are vulnerable, especially when they include parts created by different manufacturers and software developers. Each driver, configuration file, bootloader, and operating system file can be an entry point for hackers. 

To protect your embedded solution in all its complexity, your team needs to document what it consists of and record ongoing updates and changes. This is where a software bill of materials (SBOM) comes into play. 

In this article, you’ll learn how to create an SBOM for your embedded system and how it can help to secure your embedded device fleet. 

This article will be useful for tech leaders, product managers, and CISOs who want to ensure the security of their Internet of Things (IoT) systems to effectively protect all devices from exploits and attacks.

What is an SBOM?

A software bill of materials (SBOM) is a document that lists all components, libraries, and modules used in a software application or device. Each component includes detailed information about its origin, version, and any known vulnerabilities, providing a comprehensive view of the software’s makeup.

An SBOM provides visibility into the following:

In short, an SBOM is a complete component inventory of your system. It allows you to easily audit licenses, simplifies due diligence during mergers and acquisitions, and makes the system visible to procurement and legal teams.

For embedded systems specifically, SBOMs serve as living technical documentation. Your team can use an SBOM during maintenance and hardware revisions, or when onboarding new engineers who need to understand what a device actually runs.

However, the area where SBOMs have the most immediate impact is cybersecurity.

Benefits of SBOM for embedded system security

An SBOM maps out potential security risks, helps ensure compliance with industry requirements, and allows you to quickly discover and respond to vulnerabilities.

You can use SBOMs to protect your ecosystem of embedded devices and your business in general from risks of:

• Security breaches or exploits that can lead to loss of integrity and data
• Complications during mergers and acquisitions that arise from the risk of inheriting security issues when acquiring a company, or not being able to provide proof of your product’s security when being acquired
• Compliance and regulatory issues, such as fines and blacklists
• Unclear supply chains that lead to risks of unknown vulnerabilities, supply chain attacks, and the inability to respond to incidents quickly, which diminishes trust in the business

By having an SBOM, you achieve:

• Proactive protection of your embedded system. When a critical CVE drops, teams without an SBOM spend weeks manually auditing which of their deployed devices are affected. With an SBOM, you easily get an answer and can quickly act accordingly.
• Fast incident response. If an incident occurs, an SBOM will tell you exactly what was running on the affected device, which is especially important when you can’t pull a device from the field to inspect it. 
• Improved supply chain management. Embedded supply chains involve multiple hardware vendors, chipset manufacturers, and third-party firmware blobs. An SBOM is the only way to make provenance auditable across that chain.
• Long-term maintainability. Embedded devices often stay in the field for 10–15 years. An SBOM enables continual monitoring of components for new vulnerabilities long after initial deployment. 

An SBOM is especially important for industries that rely on highly specialized, critical devices.

Regulatory requirements for embedded system SBOMs

For a long time, SBOMs were just a nice-to-have. In recent years, they have become a legal requirement in many regions and industries.

The United States was among the first countries to formalize SBOM requirements. Executive Order 14028 of May 12, 2021, mandated SBOMs for all federal agencies and their software vendors, establishing SBOM as a cybersecurity and procurement baseline. 

This was followed by the National Telecommunication and Information Administration’s (NTIA’s) minimum elements framework and the Cybersecurity and Infrastructure Security Agency’s (CISA’s) expanded 2024 guidance, which remains the most up-to-date directive on what to include in an SBOM and how to create it. 

Meanwhile, the EU took a broader approach: the Cyber Resilience Act entered into force in December 2024 and will require SBOMs for all products with digital elements by December 2027.

The most significant frameworks to be aware of include:

• Executive Order 14028 (US) — Signed in 2021, this order established SBOMs as a requirement for software sold to the US federal government and set the foundation for all subsequent SBOM guidance from the NTIA and CISA.

• CISA 2024 Framework — The most detailed US guidance on SBOM implementation, introducing a three-tier maturity model and expanded metadata requirements. While not legally binding, it underpins enforcement by agencies like the FDA.

• FDA Cybersecurity Guidance (updated June 2025) — Makes SBOMs legally mandatory for “cyber devices” under Section 524B of the FD&C Act, and strongly recommends them for all other software-containing medical devices.

• EU Cyber Resilience Act — The broadest SBOM mandate globally, applying to all products with digital elements sold in the EU. Full obligations apply from December 11, 2027, giving organizations a closing window to prepare.

Regulations for SBOMs are especially widespread in industries that rely on critical embedded devices.

Table 1: Main SBOM requirements

Industry	Regulations & frameworks	Embedded device examples
Healthcare	FDA regulations (mandatory for medical devices) IMDRF guidelines EU MDR	– Pacemakers – Insulin pumps – MRI machines
Automotive	UNECE WP.29 (ISO/SAE 21434) NHTSA guidance EU Cyber Resilience Act	– Electronic control units – Advanced driver assistance systems – Infotainment systems
Industry & critical infrastructure	CISA recommendations EO 14028 IEC 62443	– Power grid controllers – Manufacturing robots – Oil and gas pipeline monitoring systems
Consumer electronics & IoT	EU Cyber Resilience Act US Cyber Trust Mark ETSI EN 303 645	– Smart home devices – Wearable health tech – Vehicle infotainment systems
Defense & aerospace	DoD requirements CMMCDO-326A / ED-202A	– Drones – Aircraft software – Military vehicles

Best tools for SBOM generation

The SBOM market offers dozens of tools for SBOM generation, management, and security. Here are some of the tools that Apriorit experts often use to automate their work with SBOMs:

• Syft — a CLI tool that allows you to efficiently create accurate SBOMs from container images and filesystems.
• Grype — a vulnerability scanner by Anchore that works alongside Syft. Syft generates the SBOM, and Grype scans it against known vulnerability databases to identify affected components. Together, they cover the full generate-then-analyze workflow. 
• FOSSA — an automated tool focused on open-source compliance and security, capable of generating SBOMs while ensuring adherence to licensing requirements.
• Trivy — a popular open-source security scanner that generates SBOMs from container images, filesystems, and Git repositories while simultaneously scanning for vulnerabilities. Its broad ecosystem support and native CI/CD integration make it one of the most widely adopted SBOM tools in DevSecOps workflows. 
• CycloneDX CLI — a command-line tool for working with existing SBOMs: converting between formats, merging multiple SBOMs, analyzing components, and validating against the CycloneDX specification. Useful for teams managing SBOMs across complex, multi-component projects.
• OWASP Dependency-Track — an open-source SBOM management platform that ingests CycloneDX SBOMs and continuously monitors components for new vulnerabilities, license risks, and policy violations across your entire software portfolio.
• Microsoft’s SBOM Tool — a command-line utility that generates SBOMs for software projects, integrating with Microsoft’s security and compliance frameworks to enhance transparency and security across the software supply chain.

Note: Although tools can aid your team in creating SBOMs for regular software solutions, they can’t always fully capture the complexity of embedded systems. This may lead to overlooking components or vulnerabilities that can expose your systems to significant cybersecurity risks.

Challenges of building SBOMs for embedded systems

Building SBOMs is inherently complex, but embedded systems add multiple layers of difficulty. To get detailed SBOMs and keep your systems secure, it’s important to watch out for certain nuances typical of embedded systems. Let’s look at them in detail.

• Complex and multilayered systems. Embedded firmware often includes multiple layers, such as operating systems, bootloaders, libraries, and application code. Each layer and component can have its own dependencies, making it difficult to document everything comprehensively. Moreover, each component often has a different origin, and you have to ensure it is secure and complies with regulatory standards.
• Limited processing power and storage. Embedded devices often have resource constraints that can limit the ability to run tools that might automatically generate a firmware SBOM on the device itself. That’s why tools often can’t give you a full picture of your embedded systems, and you have to explore components manually to create an SBOM that has complete information.

• Frequent updates. Embedded devices are frequently updated due to emerging security vulnerabilities or changing standards. This is especially true for IoT devices used in the healthcare and automotive sectors. It can be challenging to keep your SBOM up to date without errors.
• Obscured hardware–software dependencies. Embedded device firmware can consist of a mix of open-source, proprietary, and third-party components, which are often tightly integrated and interdependent. This makes it difficult to discover dependencies and document them correctly, particularly when dealing with specialized hardware drivers or firmware.
• Varying security requirements. Different industries have varying requirements for SBOMs, and ensuring that an SBOM meets all relevant compliance requirements (e.g., FDA requirements for medical devices, NHTSA requirements for automotive) can be complicated. Some industries lack standardization, which can make it difficult to ensure security and compliance across the supply chain. In sectors without clear regulatory guidelines, organizations must navigate ambiguous requirements and may struggle to align their SBOM practices with the best security measures. 
• Outdated or incompatible software. Many embedded systems are built on legacy software that may not be compatible with modern SBOM tools. Documenting these older systems requires significant manual effort and expertise.

Creating SBOMs for embedded systems requires extra care, both in tool use and manual processes, so your inventory is complete.

Apriorit can help you create accurate, up-to-date SBOMs for complex embedded systems by combining automation with in-depth analysis of firmware components and dependencies.

Apriorit’s best practices for embedded SBOMs

Now, let’s focus on five SBOM best practices that help to build a high-quality inventory for your embedded software system and improve the security of your embedded devices.

Generate an SBOM with proven tools — confirm with a manual review

To generate a SBOM faster, you can use automated tools. But first, you need to select the right SBOM generation tools for your specific environment. Tooling that works well for a containerized application won’t necessarily capture everything in embedded firmware. 

Our engineers choose tools based on your device architecture, firmware format, and ecosystem. We use solutions like Syft, Trivy, or embedded-specific analyzers to produce an accurate baseline inventory. 

From there, automated tools are complemented with manual source code reviews, since tools can miss components that aren’t declared through conventional package managers, are statically linked, or are bundled without standard metadata. 

Manual review ensures nothing is overlooked — especially in complex firmware where dependencies may be obscured or proprietary. When automated tools hit their limits, our experts step in to make your SBOM as comprehensive as possible. 

Validate your SBOM against the real environment

Due to the complexity and multi-layered nature of embedded systems, SBOMs require continuous validation to remain accurate and useful. It’s important to compare the SBOM you generated to your real environment. This includes inspecting kernels, features, and dependencies as they actually exist in your deployed systems. 

At Apriorit, our engineers do exactly this, using binary SBOM analysis combined with supplier validation to give you an accurate picture of what’s running on your devices.

Integrate SBOM management into your CI/CD pipeline from the start

An SBOM that isn’t updated with every firmware change quickly becomes a liability. Seamless integration into CI/CD pipelines and version control systems ensures your inventory stays current with every software revision. 

Our engineers set this up so firmware changes are tracked in real time, without adding manual overhead to your team.

An SBOM isn’t a document you create once and forget about. You need to update it continuously as your software evolves. Building SBOM generation into your SDLC and CI/CD pipeline from the start is the only reliable way to ensure your inventory stays accurate and actionable.

Lidia Mandrovna, R&D Delivery Manager at Apriorit

Prioritize critical components

When time is limited or the system is too complex to address all at once, start with the components that pose the highest risk. This allows you to mitigate vulnerabilities faster and ensure high-priority issues are addressed first. 

Apriorit can help you identify and rank these components so remediation efforts are focused where they matter most.  

Ensure compliance with industry standards

Identify applicable requirements across both industry- and region-specific frameworks before building your product’s SBOM. While compliance frameworks often share some requirements, there can be significant differences in scope, format, and metadata requirements. Our specialists help you resolve possible requirement conflicts and structure your SBOM to satisfy multiple frameworks.

With Apriorit, you’ll receive end-to-end support in creating and managing SBOMs for your products. Whether you need help securing your embedded devices or managing complex software supply chains, we’ll ensure you have the tools and processes to stay secure and compliant.

FAQ