The CRA Is Coming. What Do Embedded Teams Really Need From SBOM Tools?

How many Software Bills of Materials (SBOMs) does your embedded product need? The answer is rarely one.

Embedded products are systems made up of several parts—a device, remote processing, and an application, for example—and each part requires its own SBOM. 

Embedded Linux engineer Marta Rybczyńska explored this problem in her FOSDEM 2026 presentation, When One Product Has Three SBOMs: Lessons from Embedded Vulnerability Management. 

“What could go wrong,” she quipped, before detailing a project with multiple conversion issues, incompatible formats, and miscommunications between tools. 

Three SBOMs for a single embedded product might sound excessive, but according to Rybczyńska, three is actually a low number.

A modern connected device may include separate SBOMs for its operating system, bootloader, firmware, wireless modules, mobile apps, cloud services, and supplier-provided components. Instead of managing a single software inventory, embedded teams are increasingly responsible for maintaining a collection of overlapping SBOMs throughout a product's lifecycle.

An SBOM for an embedded product isn’t really a single inventory. It’s more like a collection of interconnected records.

As the EU Cyber Resilience Act (CRA) approaches, requiring manufacturers to maintain greater visibility into the software components within their products, embedded teams are changing the way they think about SBOM tooling.

SBOM Generation Isn't the Problem Anymore, Management Is

Embedded teams don’t need a tool that generates an SBOM. They need a tool that can manage a growing ecosystem of software inventories throughout the product lifecycle.

"Generating SBOMs is the easy part. Using the SBOM and making sense of the data is the hard part,” Rybczyńska said.

The challenge with embedded SBOMs isn't just the number of components involved. It's the way those components enter the product. A traditional software application relies on package managers, manifests, and lockfiles that preserve information about dependencies. Embedded systems frequently lack the same sources of visibility.

“Enterprise package ecosystems preserve dependency signals by default,” said Collin Hogue-Spears, a senior director at Black Duck. “Firmware strips them out along the way.”

Embedded products often combine operating systems, bootloaders, real-time operating systems, vendor SDKs, proprietary application code, and firmware running on individual hardware components. Some components may come from suppliers. Others may be copied into a codebase, modified internally, or delivered as binary blobs with limited metadata.

That creates an inventory challenge: teams may know what software they intended to ship, but not always what software actually ended up in the final product.

In fact, it can be hard to actually know how complete an SBOM is, says Rybczyńska. She notes that embedded SBOMs may miss modules, contain unreliable version information, or fail to account for forked code.

The problem becomes even more complicated when multiple organizations contribute to the same product. A wireless chip vendor may provide firmware and its own SBOM. A supplier may provide another component inventory. Internal teams may generate additional SBOMs during their own builds.

The result is not one definitive software inventory, but a collection of records that must be reconciled, and as Rybczyńska points out, SBOM formats can be difficult to merge. 

"Identity is the one that bites hardest," said Ankit Kumar Honey, senior engineering manager at GitHub. “An SBOM entry is only useful if you can match it to an advisory or a supplier record later, and the same component travels under different names: the upstream project name, the distro package name, whatever the vendor called it. Add patched forks and the version string stops meaning what you think it means.”

Because embedded environments can include so many renamed components, vendor modifications, patched forks, and inconsistent version information, an SBOM can become a puzzle rather than a map: it’s hard to know exactly what each component is, where it came from, and whether it’s still present in products deployed in the field.

An incomplete SBOM is still better than no SBOM. But its value comes from what teams do with that information after it's generated.

SBOM Generation Must Be an Ongoing Process, Not a Check Box

Creating an SBOM is only the first step. The CRA requires manufacturers to maintain accurate SBOMs. This means the challenge for embedded teams is ensuring that inventory remains accurate, connected to the right products, and useful when a vulnerability emerges.

“The SBOM stops being a document someone assembles at release and becomes an artifact the build produces every time,” Honey said. “That sounds like a small change. It isn't.”

For embedded teams, that means integrating SBOM generation into development workflows rather than treating it as a final deliverable. When SBOMs become part of every build, teams can identify changes as they happen instead of trying to reconstruct years of software changes after a vulnerability is announced.

Honey recommends treating SBOM generation as an automated process.

"Generate, never curate," he said. "Any SBOM a human edits by hand is stale the day after it's written."

Instead, each software layer should produce its own SBOM during the build process, with automated workflows responsible for creating a product-level view. Teams should also compare SBOMs between builds to understand what changed.

"The diff is where the value lives," Honey said. "It's how you spot the component that snuck in through a supplier update."

A continuous approach to SBOM generation is especially important under the CRA, which shifts the focus from simply documenting software components to responding quickly when vulnerabilities emerge.

"The CRA turned the SBOM from a transparency artifact into the data layer under a legal clock," Hogue-Spears said.

When a vulnerability is discovered, organizations need to quickly determine which products are affected, whether the vulnerable component is actually exploitable, and what remediation steps are required. An SBOM that exists only as a static file cannot answer those questions.

What Should Embedded Teams Look for in an SBOM Tool?

If embedded teams are moving beyond SBOM generation, their tooling needs to solve a much bigger problem than simply producing a machine-readable file.

Most organizations already use tools that can generate SBOMs. Embedded teams need tools that can help them understand what is actually in their product, how inventory changes over time, and what action is required when vulnerabilities emerge.

In embedded environments, that starts with visibility.

“First, build-time generation paired with binary and firmware verification,” Hogue-Spears said, “because neither view alone finds every statically linked, copied, or supplier-delivered component.”

This distinction matters because embedded software often contains components that traditional software inventory approaches miss. Code may be copied directly into a project, bundled into firmware, modified from an upstream project, or delivered as a binary from a supplier. A tool that only analyzes declared dependencies may provide an incomplete picture of the final product.

Embedded teams should also look closely at how tools handle component identity. An SBOM is only useful if organizations can reliably connect a component to vulnerability information, supplier records, and specific product versions.

That can be difficult in embedded environments, where the same component may appear under different names, include vendor-specific modifications, or use version numbers that do not clearly map back to upstream releases.

Another important capability is continuous vulnerability management. A product’s software inventory should not become outdated the moment it ships. When a new vulnerability is discovered months or years later, teams need to quickly determine whether affected components exist in products still in the field.

“The capability that determines outcomes is re-evaluation,” Honey said. “When a new advisory publishes, can the tool re-check every SBOM you’ve already produced, without a rebuild, and tell you which shipped products are affected?”

That ability becomes especially important for embedded products with long support lifecycles. A device deployed today may still require security maintenance years after its original release, meaning organizations need a reliable way to connect new vulnerability information back to older software inventories.

Finally, teams should consider how well a tool supports the decisions that come after vulnerability identification. A vulnerable component does not always mean a vulnerable product. Organizations need ways to document whether a vulnerability is exploitable, whether mitigations exist, and what actions were taken.

Tools that support vulnerability context, exploitability assessments, and machine-readable VEX information can help organizations avoid treating every vulnerability match as an emergency while still maintaining an accurate security record.

The Final Product Isn’t Really an SBOM. It’s Confidence.

For embedded teams preparing for the Cyber Resilience Act, creating an SBOM may feel like the finish line. In reality, it is the beginning of a much longer process: ensuring that the inventory can actually support vulnerability management throughout a product’s lifecycle.

"Generally, creating an SBOM is relatively easy; creating an SBOM that can accurately be monitored for vulnerabilities is difficult," said Alan Parkinson, a medical device cybersecurity consultant at Threat Detective.

An SBOM is only useful if organizations can reliably connect software components to vulnerability information. A component that is incorrectly identified, missing a unique identifier, or mapped to the wrong version may prevent teams from discovering known security issues.

Embedded software creates particular challenges because many components do not fit neatly into traditional software identification models. C and C++ projects frequently include vendored code, modified libraries, and supplier-provided SDKs, making it difficult to determine exactly which component version exists in a shipped product.

"Finding out after five years your tooling has been missing vulnerabilities will generate a lot of work, negative PR and possible regulator actions," Parkinson said.

For that reason, organizations should evaluate SBOM workflows based on their ability to identify vulnerabilities accurately, not simply their ability to generate an SBOM file.

That also means preparing for what happens after vulnerabilities are discovered. A vulnerability match does not automatically mean a product is vulnerable. The affected component may not be reachable, exploitable, or even present in the final device configuration.

This is where Vulnerability Exploitability Exchange (VEX) information becomes important. VEX allows organizations to document the status of identified vulnerabilities, including whether a vulnerability is exploitable, mitigated, or not applicable to a specific product.

Without that context, every vulnerability match becomes a new investigation for customers, security teams, and support organizations.

"Without VEX, every CVE becomes a question your support channel will have to answer manually," Parkinson said. "Ship both or drown."

For embedded manufacturers, that transparency can become a competitive advantage. Organizations that can explain how they validated their SBOM, which vulnerability sources they monitor, and why a particular vulnerability does or does not affect their product can build trust with customers and regulators.

And customers are becoming a much bigger driver of SBOM adoption. According to RunSafe Security’s 2026 Medical Device Cybersecurity Index, 81% of healthcare professionals rated an SBOM as “important” or “essential.” Thirty-five percent said they wouldn’t consider purchasing a device without one.

Ultimately, the goal of an SBOM program is not simply to produce a software inventory. It is to create confidence that when a vulnerability emerges, the organization knows what is affected, understands the risk, and can make a decision on what to do next.

‍