The SBOM Is Not a Vulnerability Program: CRA Readiness for Embedded Teams

The Cyber Resilience Act puts its SBOM clause inside vulnerability handling, so the first thing it asks embedded teams for is a fast answer, not a file

A team building an industrial gateway turns on Software Bill of Materials (SBOM) generation in Yocto and gets a clean SPDX document at every build. The sensor firmware runs Zephyr, so west spdx emits a second one. The management service is Python, so cyclonedx-py emits a third. Three valid documents, each archived beside its image and its Git tag. On paper, the product is covered. Then you merge them, and the Linux kernel reports clean.

That is not a thought experiment. At the Free and Open source Software Developers' European Meeting (FOSDEM) 2026, Yocto Project security team member Marta Rybczynska walked through exactly this build and loaded the output into Dependency-Track. Neither SPDX document would import.

Loading them required a downgrade to SPDX 2.2, an experimental converter run against every per-recipe file, and a merge. The kernel came back with no Common vulnerabilities and Exposures (CVEs), because the conversion had dropped its Common Platform Enumeration (CPE) annotations, the identifiers a scanner matches against a vulnerability record. Zephyr components arrived without version numbers, thinning results there too.

Call the failure mode a silent no-match. The scanner returned nothing, and nothing looks the same as safe.

That gap is what the Cyber Resilience Act (CRA) is about to price. Most embedded roadmaps point at December 11, 2027, when the essential requirements and conformity assessment apply. The live date is September 11, 2026, when Article 14 reporting starts, and Article 69(3) applies it to every in-scope product placed on the market before December 2027. If you learn this September that someone is exploiting that 2019 gateway, you have 24 hours to file an early warning. The remaining requirements attach only on substantial modification, and only after December 2027.

The Regulation Files the SBOM Under Vulnerability Handling

The CRA’s Annex I Part II is the vulnerability handling section. Its first point asks manufacturers to identify and document vulnerabilities and components, including by drawing up a machine-readable SBOM covering "at the very least the top-level dependencies." Annex VII then groups that SBOM with the coordinated disclosure policy, the security contact, and the update mechanism, all of them parts of the vulnerability handling process. Read the placement as a hierarchy. The process is the obligation. The SBOM is one of its inputs.

Article 14 runs two tracks, and they open identically. An actively exploited vulnerability and a severe incident both need an early warning within 24 hours and a fuller notification within 72, counted from the moment the manufacturer becomes aware. They close differently. The vulnerability track ends with a final report 14 days after a corrective measure becomes available, the incident track one month after the notification. Everything goes to the Computer Security Incident Response Team (CSIRT) designated as coordinator and to the European Union Agency for Cybersecurity (ENISA) through a single reporting platform. A stored SBOM satisfies none of it.

That hierarchy moves the SBOM out of the build team, which is the real shift. A release artifact belongs to a build engineer. A record that turns a component name into an affected-unit list in a working day belongs to incident response. Most organizations have not made that handoff. ENISA surveyed 334 organizations in June 2026 and found 78% had started SBOM adoption while 9% called their implementation mature and automated. Two-thirds of those organizations employ more than 250 people, so that 9% comes from the best-resourced part of the market.

Why the Firmware Image Resists the Manifest

Enterprise application teams inherit their dependency signals from tooling. A lockfile pins resolved packages and versions, dynamic linking keeps composition readable at runtime, and short-lived deployments make regeneration cheap. Those inventories have gaps too, and the signals still survive into the shipped artifact.

A firmware build produces almost none of them.

Static linking and vendored source trees dissolve package boundaries, and a stripped production image retains a build ID at most, which will not tell you which versions the linker pulled in. C and C++ have no universal package manager, so dependencies arrive as Git submodules, vendor tarballs, and copied files that no manifest scanner finds. Conditional compilation and linker scripts then decide what reaches the image. Source scanning describes what the tree can produce. Only a build record shows what it did produce.

Then the timeline stretches. Article 13(8) sets the support period by how long the product is expected to be in use, with a five-year floor, so a gateway with a fifteen-year service life carries a fifteen-year obligation. Technical documentation stays available for ten years, or for the support period when that runs longer. Industrial and automotive programs sit at the far end of both. Board revisions and feature flags then multiply the variants you have to track for the duration.

What to do: Generate from the build, while configuration and link decisions are still visible. Reconcile that output against an analysis of the shipped binary, and when the two disagree, treat the disagreement as a supply chain signal rather than a merge conflict. For field-level requirements, Germany's TR-03183 Part 2 is the most detailed specification published so far, and it grades SBOM depth on a ladder rather than a checkbox.

One Product, Three SBOMs, and the Conversion Tax

Most products now need more than one SBOM. One gateway carries a real-time operating system (RTOS) image, a Linux user space, blobs from two silicon vendors, and a cloud service, each with its own tooling, format, and granularity. When an authority asks what is in the product, it means the version you shipped. Four subsystem documents in four formats do not answer that.

Two architectures dominate. Composition keeps each subsystem document intact and references it from a product-level parent, through CycloneDX BOM-Link or SPDX external document references, preserving the provenance of every entry. Merging flattens all of it into one document per product version, which queries faster when an advisory lands.

Both paths charge the same tax, and the FOSDEM run is what it costs. Granularity does not match across generators, and identifier quality does not survive conversion. A merged document carrying no completeness flag reads as authoritative when it is partial. Triage gets harder still when one copy of zlib appears under three names in three subsystems.

What to do: Take your real documents, run them through your real scanner, and confirm your kernel still returns CVEs. Do it this quarter. It is the cheapest test on this list and the one most likely to fail.

Four Capabilities That Decide Whether You Can Answer

Generation is table stakes. These four capabilities decide whether a tool produces documents or answers questions while a clock runs.

1. Detection: Find what the manifest never declared

Start with what the manifests leave out, because in embedded, that is most of the image. Binary and firmware analysis covers the first gap, working directly on the compiled binary, so a legacy image still yields entries even when the source is gone. Snippet-level matching covers the second, because open source in C and C++ arrives copied into the tree rather than declared, and copied code carries the same license obligations as declared code. Vendor blobs and proprietary modules are components too, including any AI model on a firmware path, and each gets a name, a supplier, a version, and a hash.

Prove it: Take the ugliest artifact you ship, a binary-only SDK or a ten-year-old image with no surviving build environment. Scan it, then check the result against something you know is true: a preserved build record, a supplier inventory, or a test image you seeded yourself. Coverage is the fraction recovered, not the rows returned.

2. Identity: Resolve a component to something a scanner can match

An entry that names a component without pinning it is decoration. Pinning takes an exact version, a supplier, a hash, and identifiers that survive format conversion, plus an honest confidence signal so you can tell a declared match from an inferred one. Run supplier documents through that same pipeline. Reconciling their component names against identities you already track turns a supplier SBOM from a file you store into a record you can query.

Prove it: Convert and merge a sample, then diff the identifiers before and after. Anything that drops a CPE or a version has failed. Run the diff, because a merged document reports success whether or not the identifiers survived.

3. Awareness: The feed that starts your clock

Here is the change most teams have not absorbed. In April 2026, NIST stopped attempting to enrich every CVE. It now prioritizes entries in CISA's Known Exploited Vulnerabilities catalog, federal software, and critical software. Everything else still publishes, without NIST-supplied CPE identifiers, CVSS scores, or weakness mappings, and roughly 29,000 older records moved into that category at once. Now run the FOSDEM failure in reverse. There, the kernel went unmatched because its SBOM entry lost an identifier. Here, the advisory never had one.

No regulation names a data source, and a late match breaches nothing, because the reporting clock starts on your awareness and nowhere earlier. That is the trap. A late match moves your awareness date. It does not move the date exploitation started, and the gap between those dates is time an attacker spends inside your fielded devices. Annex I Part II asks for effective vulnerability handling, which means closing that gap rather than reporting fast once you notice. Vulnerability research that does not wait for NVD enrichment, mapped to identities you already track, is what closes it.

Prove it: Pick three advisories from last quarter that affect components you ship, and find the date each one reached your inventory. The lag between publication and that date is what an auditor will ask you to explain.

4. Continuity: Monitor the same inventory for a decade

A scan at release solves nothing for a product that ships for fifteen years. Continuity keeps the record monitored long after that release, produces a readable diff between any two versions, and enforces policy at the build gate instead of in a report. A kernel module compiled out gets filtered before triage, and that decision travels as a VEX statement rather than a spreadsheet comment. Industrial and defense programs add one more constraint. The analysis has to work inside an air-gapped environment, because a scanner that phones home for its vulnerability data cannot be the reason a build host reaches the internet.

Prove it: Take a version you shipped in 2021 and ask whether a new advisory applies to it. If answering means regenerating the SBOM, and regenerating means resurrecting a five-year-old build environment first, you have generation, not continuity.

Four Misconceptions and What the Record Holds

1. Generating an SBOM in CI is CRA compliance. It is one duty in the vulnerability handling annex. An inventory detects nothing, assesses nothing, and notifies no one.

2. Top-level dependencies are a safe minimum. That is what the annex requires, not what the response will need. Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component to report it to whoever maintains that component, and to hand over the code if it wrote the fix. Annex I Part II adds remediation without delay. Neither duty runs on a list that stops at the top layer. You cannot notify the maintainer of a component you never recorded, so the duties decide the depth, not the annex.

3. A CVE match is a reportable event. Article 3(42) defines an actively exploited vulnerability as one with reliable evidence that an attacker used it without the owner's permission. Presence is not applicability, applicability is not exploitability, and exploitability is not active exploitation. Filing every match floods the early-warning channel you will need for the real one.

4. A vague document is safer than an incomplete one. You are not required to share the SBOM with customers; Annex II makes that your choice. The one reader who can demand it is a market surveillance authority, the national enforcement regulator.  Supplying that authority with incorrect, incomplete, or misleading information carries its own penalty tier, up to EUR 5 million or 1% of total worldwide annual turnover. A declared gap is defensible. A concealed gap is a second offense.

What survives all four is a record, versioned with the release and owned by a named person. Annex VII specifies what goes into the technical documentation. The list below is the working record that supplies that content, offered as a recommendation rather than a statutory minimum.

The record holds:

• Image hash, source revision, and the board and configuration variants this build covers
• Supplier, version, and hash for every binary-only and proprietary component, with gaps declared rather than papered over
• How each subsystem's SBOM was generated, and how deep it claims to go
• Conversion and merge path, with the identifier diff that validated it
• Vulnerability sources monitored, timestamp of the last resolution run, and the named owner

Start manually. Build the record for the product with the largest fielded base, and have it before the next release review. A spreadsheet mapping forty firmware versions to a component list beats a perfect pipeline arriving in 2027.

Start on the Clock, Not the Maturity Model

Every capability in the last section is something you can buy. What follows is not, and it decides how September goes. The list is short enough to stand up before September 11, 2026 even with an incomplete inventory.

• Name the decision-maker. One person decides whether a report goes in, with a named deputy and no committee in the path.
• Write the awareness rule. Define which signals count as evidence that a vulnerability in your product is being exploited, which inbox and which feeds carry them, who assesses them, and when the timestamp gets written. That timestamp starts the 24-hour clock and is the first thing anyone will audit.
• Set the evidence bar. Article 3(42) needs reliable evidence of exploitation, and someone has to be authorized to declare it. Write down what counts before the night you need it, and cover the incident branch, because malicious code running through your product starts the same clock.
• Line up the reporting channel. The single reporting platform routes every notification to your coordinator CSIRT and to ENISA together, and it is not yet live. Identify your coordinator and create the EU Login account registration that will be required, so the first hour of an incident is spent on the notification rather than on account setup.
• Assign remediation and closure. The vulnerability track ends at a final report, not at the notification, so name who owns the fix and who files that report.
• Pre-draft both notifications and run one tabletop. Timed, with a notification actually written and closure scheduled to the right deadline.

Measure the Answer, Not the Document

Regulated hardware solved a version of this already. An airworthiness directive names a part number and a serial range, and applicability gets settled from the configuration record of the individual airframe, not from the manufacturer's parts catalog. A bill of materials for a product line cannot answer a question about one tail number, and embedded teams now face that question about a fleet of gateways.

Embedded teams already work this way. They have tracked part numbers, board revisions, and field configurations for decades, and they know a catalog from a build record. The SBOM is the newest entry in that tradition, and it inherits the same discipline.

So the question is not whether your team can produce an SBOM. It is what your team can prove about the firmware it shipped in 2019, in the twenty-four hours after you learn somebody is exploiting it.

‍