What is in your firmware: the bill of materials nobody asked for before
The manufacturer's lead embedded engineer is running an SBOM generation tool against the firmware image of one of their main controller products. The tool — Syft, Trivy, or a commercial equivalent — works by analysing the binary contents of the firmware and identifying known components by signature, file structure and content matching. It runs for several minutes and produces a JSON file with over a thousand entries.
The engineer scrolls through. The first hundred entries are unsurprising — BusyBox, glibc, OpenSSL, Dropbear, the Linux kernel, the lwIP stack, several standard libraries the team explicitly maintains. The next several hundred are unfamiliar. ZeroMQ. mbedTLS in addition to OpenSSL. An old version of cJSON. A Bluetooth stack the engineer is certain has never been used in this product. Half a dozen libraries with German-language comments. A build of OpenJDK the team has no record of including. Several proprietary binary blobs identified only by their cryptographic hashes.
The lead engineer reads the list twice. Most of it is correct — these libraries are in the firmware. Some have been there since the original product version six years ago, inherited from a base image the team adopted without auditing. A few entries genuinely surprise: components the team thought had been removed, versions they thought had been upgraded, modules they did not know were present at all.
This is the discovery moment, and for most non-EU industrial manufacturers, it is the first time it happens. The Cyber Resilience Act will require it to happen continuously, every release, with the resulting bill of materials made available to the asset owner and to market surveillance authorities. The CRA's SBOM obligation sits in Annex I Part II point 1, imposed via Article 13. The clause is short and specific. Most of the work it implies is not.
A software bill of materials is what its name suggests — a list of every software component present in a product, along with version numbers, license information, supplier identity, and, where available, cryptographic hashes. The format is structured and machine-readable. The two standard formats are SPDX (Software Package Data Exchange, ISO/IEC 5962) and CycloneDX (an OWASP project). Both are widely supported by tooling, by procurement processes and by the Cyber Resilience Act's implementing acts.
What the SBOM enables is not, in itself, security. It is visibility. With an SBOM, the manufacturer knows what is in their firmware. With access to an SBOM, the asset owner knows what is in the equipment they are operating. With a published SBOM, the security research community can cross-reference vulnerabilities against deployed assets. Without one, none of these parties can act on vulnerability information except by going back to the manufacturer and asking individually, every time.
What an SBOM is, and what it is not
The SBOM is an inventory. It states what is present. It does not state whether what is present is secure. It does not state whether it is current. It does not state whether the components have been patched. It does not state whether the cryptographic algorithms used are still considered fit for purpose. It does not state whether the open source licenses have been complied with. It does not state whether the supplier of any third-party component is still trading.
These are all separate analyses that consume the SBOM as input. The vulnerability scanner consumes it to identify which deployed CVEs apply. The license compliance tool consumes it to verify obligations. The supply chain risk tool consumes it to identify dependencies on sanctioned or untrusted suppliers. The asset owner's procurement team consumes it to cross-reference against organisational policies on component preferences.
A useful framing: the SBOM is the bill of materials for a complex machine. A car has a bill of materials. It lists every part — brake pads, alternator, ignition coil, fuel pump — by part number, supplier and version. The bill does not state whether the brake pads are worn, whether the alternator is approaching end of life, or whether any specific component has been subject to a recall. It states what is there. Other systems — service records, recall databases, condition monitoring — handle the rest.
The Cyber Resilience Act does not require manufacturers to certify their components as vulnerability-free. It requires them to know what they ship, and to make that knowledge available to the parties downstream who need to act on vulnerabilities when they emerge. The SBOM is the foundational artefact of that visibility.
What goes in firmware that catches manufacturers out
For most non-EU industrial manufacturers, the first SBOM is an education. Several categories of component routinely surprise.
Open source libraries are the largest and most consistent category. A typical embedded Linux firmware image contains several hundred open source components, often with deep transitive dependencies. The build system pulled them in. The engineering team did not necessarily review them individually. Some have been there since the original product version. A first-pass SBOM frequently identifies open source components the team had no specific knowledge of including, often because they were inherited from a base image, a board support package, or a vendor-supplied software development kit.
White-label boards and reference designs are the most awkward category. The manufacturer's product may use a System-on-Module purchased from a third-party vendor — Toradex, Variscite, Compulab, several others — that ships with its own firmware, its own bootloader, its own kernel build, its own pre-installed components. The manufacturer integrated the module into their product but did not author the lower-level firmware. The SBOM must cover everything in the deployed product, including the module's contribution. Generating this part of the SBOM requires either cooperation from the module supplier (who may or may not provide one) or independent binary analysis of the module's firmware (which is technically possible but rarely standard practice).
Chipset vendor blobs are the third surprise. Cellular modems, GNSS chips, Wi-Fi chipsets, Bluetooth controllers, FPGAs, hardware accelerators — almost all of these ship with proprietary firmware blobs that load at boot and execute on the chip itself. The vendors typically provide the blob as a binary, sometimes with an opaque license. The SBOM should identify the blob, its version, its supplier and any known vulnerabilities — but the manufacturer's view into what the blob actually contains is, by design, limited.
Inherited firmware from previous corporate transactions is the fourth, less common but more difficult. A product line acquired through corporate transaction, an OEM rebadge agreement, or a long-standing technology licensing arrangement may carry firmware components for which the operating manufacturer does not have full provenance. The components are in the product. Documenting them in the SBOM is the right thing to do. Tracing their full origin may require effort the engineering team has not previously expended.
How an SBOM is actually produced
Two complementary approaches, usually run together.
Build-time SBOM generation integrates with the manufacturer's build system. As the firmware is compiled, the build system records every package, library and source file that contributes to the final image. Tools that support this include Yocto's built-in SBOM generation, SPDX support in Buildroot, and the Software Composition Analysis tools that integrate with continuous integration pipelines — Snyk, Sonatype, Black Duck, Mend, several others — alongside the open source CycloneDX tooling. Build-time generation is more accurate because it knows what was intentionally included. It requires the manufacturer to have a build system they can instrument — which is normal practice for mature engineering organisations, but not universal.
Binary analysis examines a compiled firmware image and identifies components by signature, file structure and content matching. Tools include Syft, Trivy, Binwalk in combination with other identification tools, and commercial binary analysis platforms (ReversingLabs, Cybellum, Finite State, several others). Binary analysis is less accurate at the version level but more honest about what is actually in the deployed binary — it catches components that the build system may not be aware of, including those introduced by third-party modules and chipset blobs. Many manufacturers run both approaches and reconcile the results, treating the union as the authoritative SBOM.
The first generation is the hardest. The team finds components they did not know were present, discovers version mismatches between what was intended and what shipped, identifies licensing situations that had not been raised. The second and subsequent generations are routine, because the engineering process and the build system are now instrumented to produce SBOMs as a continuous output rather than as a one-off exercise.
The Cyber Resilience Act expects SBOMs to be available for every product release. The expectation is that SBOM generation is a normal output of the development lifecycle, not a separate exercise scheduled before regulatory submission.
Who reads it, and why
The lender's risk team often reads the SBOM before the asset owner's security team does. Three reasons.
First, the lender's risk team is conducting cybersecurity due diligence at a stage when the asset owner's security team is still being assembled for the project. The SBOM is one of the earliest artefacts that gives the lender a concrete view of what they are financing. A clean SBOM that lists current versions of well-maintained components, with no unsupported dependencies and no components from sanctioned suppliers, is a strong early signal of engineering discipline.
Second, the lender's risk team cross-references the SBOM against EU and US sanctions lists, dual-use export control schedules under EU Regulation 2021/821, and the supplier lists maintained by their internal compliance function. Components from sanctioned suppliers, or from suppliers whose beneficial ownership is unclear, create compliance exposure for the lender. The SBOM reveals supplier identity at a granularity that contractual due diligence does not.
Third, the lender's risk team uses the SBOM to assess long-tail risk. A firmware that depends on a library last updated in 2017, maintained by an individual who no longer responds to issues, is a risk that compounds over the twenty-five-year asset life. The SBOM surfaces this kind of dependency in a way that no other artefact does.
The asset owner's security team consumes the SBOM differently. They feed it into their vulnerability management infrastructure, cross-reference it against advisories from the manufacturer's PSIRT and from independent sources, monitor for new CVEs against the listed versions, and prioritise patching based on actual exposure rather than generic severity scores. With an SBOM, vulnerability management is a continuous process. Without one, it is a series of after-the-fact crises. The evidence pack post covers the asset-owner-side artefact set this consumption feeds into.
A specific artefact that pairs with the SBOM is the Vulnerability Exploitability eXchange document — VEX — which states, for each known CVE against a listed component, whether the vulnerability is actually exploitable in the manufacturer's product. A library may be present in the firmware but its vulnerable function may not be reachable from any code path the product actually uses. The VEX statement says so, with reasoning. Without VEX, the asset owner sees every CVE against every component and must assume the worst. With VEX, the asset owner can prioritise patching against actual exposure. The CRA's implementing acts will reference VEX or an equivalent mechanism as part of the manufacturer's vulnerability handling obligation.
The security research community consumes the SBOM to focus their effort. A researcher who finds a vulnerability in a specific library, then cross-references published SBOMs to identify which products are affected, can coordinate disclosure efficiently. Without published SBOMs, the same researcher has to test every product they suspect — far less efficient, far less likely to result in coordinated disclosure across the affected fleet.
A final consumer worth mentioning is the manufacturer's own engineering team. The discipline of producing an SBOM continuously, and reviewing it across releases, surfaces internal issues the team would otherwise not see — supply chain creep, unintended dependencies, components that have not been updated, license obligations that have accumulated. The SBOM is, in this sense, also an internal management tool.
At proposal stage
A manufacturer's bid that includes a sample SBOM for the relevant product, or a commitment to deliver SBOMs for every product release in SPDX or CycloneDX format with VEX statements for material CVEs, is a bid that has resolved a topic the lender's technical adviser will otherwise raise as an outstanding item. The conversation that follows is about delivery cadence, format preference, storage location and update mechanism — not about whether the SBOM will be produced.
A manufacturer's bid that does not mention SBOMs, or that proposes to provide a high-level inventory document at first article inspection, signals one of two things. Either the manufacturer's build system does not produce SBOMs as a normal output and the team is hoping the question does not arise, or the manufacturer is uncertain what an SBOM is and is hoping the topic does not become a procurement criterion. Both are surmountable. The first is the work of weeks, integrating SBOM tooling into an existing build system. The second is the work of one focused engineering review, after which the team will produce SBOMs routinely.
There is a useful framing for the manufacturer's internal conversation. Every chip on the board is, in some sense, a supplier. Every library in the firmware is a supplier. Every binary blob from a chipset vendor is a supplier. The product manager already knows their physical supply chain — who delivers what part, in what volume, with what lead time, at what cost, against what quality history. The SBOM is the equivalent map for the software supply chain. Mature engineering organisations have been building this map for years, under various names. The Cyber Resilience Act simply requires it to be visible to others.
This is the eighth article in the series, and the last one that asks the manufacturer to produce a new artefact. The pieces that follow describe disciplines the manufacturer's organisation will recognise — cryptography, identity and access management, patch handling, logging, data flow architecture — albeit applied with constraints they may not have encountered before. The next article picks up the most prescriptive of these: the cryptographic baseline assumed in every European bid, where vendor and operator expectations diverge most quietly.
This article reflects the regulatory and standards landscape at publication. The Cyber Resilience Act's implementing acts continue to be issued through 2026–2027 and may alter specific SBOM and vulnerability handling obligations. Named tools, vendors and platforms are illustrative rather than endorsements. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.