SBOM Generation for Embedded Products: A Practical Guide

SBOM meaning: a software bill of materials is a nested inventory, a list of the ingredients that make up a piece of software ^[1].

SBOM generation for a web service is mostly a dependency-manifest problem. For embedded firmware it isn’t. Your image may hold a vendor BSP, an RTOS, statically linked libraries and binary blobs nobody on your team has the source for. This guide covers where firmware SBOMs come from, which format to choose, what to put in them, and how to use them for vulnerability handling. It’s part of our product security operations hub.

What the Cyber Resilience Act asks

For products sold in the EU, the EU Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies ^[2]. This sits in the vulnerability-handling requirements (Annex I, Part II), which apply from 11 December 2027 ^[2][3].

Three related points from the text:

• The SBOM is part of the technical documentation on vulnerability handling, and must be provided to a market surveillance authority on reasoned request ^[2].
• You don’t have to publish it. If you choose to share it with users, the user information must say where to find it ^[2].
• The Commission may specify the SBOM’s format and elements through implementing acts ^[2]. We found no such act listed on the Commission’s Cyber Resilience Act implementation page as of 2026-11-10 ^[4]. Check before publishing.

In the US, CISA and partner agencies published updated joint guidance, "2026 Minimum Elements for a Software Bill of Materials (SBOM)", on 29 July 2026. It replaces the NTIA minimum elements from 2021 ^[5]. For a side-by-side view, see SBOM requirements: US vs. the Cyber Resilience Act.

"Top-level dependencies" is the minimum the CRA states ("at the very least") ^[2]. For triage, deeper coverage is usually more useful.

Why embedded is different

• Binary blobs. Wi-Fi firmware, GPU drivers, DSP code and boot ROM patches often arrive as binaries with little metadata.
• Vendor BSPs. SoC vendors ship forked kernels and bootloaders with their own patches. Upstream version numbers don’t tell you which fixes are in.
• RTOS and bare metal. On microcontrollers, the RTOS, HAL and middleware are compiled into one image. There’s no package manager to query.
• Static linking. Libraries disappear into the binary, so file-level scanning of the final image can miss them.
• Long lives. A product shipped today may still need component data during its support period, at least five years under the CRA unless its expected use is shorter ^[2].

These are common situations, not true of every product.

Where SBOMs come from

There are two main approaches. Most embedded teams need both.

1. From the build system (preferred where possible). The build knows exactly what went in. For example, the Yocto Project’s build system generates an SPDX SBOM by default for images, listing components, licenses, dependencies, sources, applied patches and fixed known vulnerabilities ^[6]. Other build systems can produce similar data with plugins or scripts. See our Yocto SBOM deep dive.

2. From binary analysis. Tools scan the finished image for signatures of known components. This helps with vendor blobs and third-party binaries, and checks the build-derived SBOM. It produces guesses with confidence levels, not facts.

For MCU firmware without a package-aware build, one option is to maintain a component list in the repository (e.g. a manifest next to the build files) and generate the SBOM from it in CI.

Choosing tooling is covered in our SBOM tools comparison framework. We don’t recommend specific tools here.

SPDX or CycloneDX

Both are open, machine-readable standards, and both are widely supported.

Pick the format your build produces natively and your customers ask for. Converting between them is possible, but check that the fields you need survive the conversion.

What to put in a firmware SBOM

Start from the CISA 2026 minimum elements ^[5] and add what embedded triage needs. Fields commonly included:

• SBOM author, tool and timestamp
• the firmware image it describes (product, hardware revision, firmware version, image hash)
• each component’s producer (CISA’s term, formerly supplier), name and version
• a unique identifier (e.g. package URL or CPE) to match against vulnerability databases
• a cryptographic hash where available
• dependency relationships
• for vendor blobs: what you know and what you don’t (an explicit "unknown" beats a silent gap)
• patch information for forked components (e.g. vendor kernel with backported fixes)

The author, tool, timestamp, producer, name, version, identifier, hash and dependency fields correspond to CISA’s 2026 minimum elements ^[5]; the image, blob and patch lines are our additions for embedded firmware.

Sample SBOM excerpt (illustrative)

Illustrative example we wrote for this guide. The product, supplier and hashes are fictional (all-zero placeholder hashes). It’s a CycloneDX-style JSON fragment for one firmware release, showing a vendor kernel, a statically linked library and a binary blob.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:00000000-0000-0000-0000-000000000000",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-10T00:00:00Z",
    "component": {
      "type": "firmware",
      "name": "example-controller-fw",
      "version": "4.2.1",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "0000000000000000000000000000000000000000000000000000000000000000"
        }
      ],
      "bom-ref": "example-controller-fw"
    }
  },
  "components": [
    {
      "type": "operating-system",
      "name": "linux-vendor",
      "version": "6.6.y-vendor-r3",
      "supplier": {
        "name": "Example SoC Vendor"
      },
      "description": "Vendor kernel fork based on 6.6 LTS; vendor patch set r3",
      "bom-ref": "linux-vendor"
    },
    {
      "type": "library",
      "name": "mbedtls",
      "version": "3.6.x",
      "purl": "pkg:generic/mbedtls@3.6.x",
      "description": "Statically linked into the update agent",
      "bom-ref": "mbedtls"
    },
    {
      "type": "firmware",
      "name": "wifi-radio-blob",
      "version": "unknown",
      "supplier": {
        "name": "Example Radio Vendor"
      },
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "0000000000000000000000000000000000000000000000000000000000000000"
        }
      ],
      "description": "Binary-only; version not published by supplier",
      "bom-ref": "wifi-radio-blob"
    }
  ],
  "dependencies": [
    {
      "ref": "example-controller-fw",
      "dependsOn": [
        "linux-vendor",
        "mbedtls",
        "wifi-radio-blob"
      ]
    }
  ]
}

The excerpt validates against the CycloneDX 1.6 JSON schema ^[10]. Versions containing "x" or "y" and the all-zero hashes are placeholders, not real releases or hashes.

One SBOM per release, kept for the support period

• Generate the SBOM in CI for every firmware build you could ship, and keep it with the release artifacts.
• Version it with the firmware: one image, one SBOM.
• Keep SBOMs for every release still in the field, at least for the support period. The CRA requires each security update to remain available for 10 years or the rest of the support period, whichever is longer ^[2], so it’s sensible to retain the matching SBOMs too. This retention suggestion is ours, not a legal requirement.
• Store them where your PSIRT can query across products: "which shipped versions contain component X?"

Linking SBOMs to vulnerability triage

An SBOM is only useful if someone checks it against new vulnerabilities.

1. Match components against vulnerability data on every new advisory and on a schedule.
2. Triage each match: is the vulnerable code present and reachable in this build?
3. Record the answer. A VEX (Vulnerability Exploitability eXchange) document is a form of advisory stating whether a product is affected by a known vulnerability ^[1].
4. Feed confirmed issues into your PSIRT process and, if actively exploited, the CRA reporting clock. See how to set up a PSIRT.

Where to start

1. Pick one product line and generate an SBOM from its build today.
2. List the binary blobs and vendor components it can’t describe, and ask suppliers for data.
3. Choose SPDX or CycloneDX and make SBOM generation a CI step.
4. Set up component-to-advisory matching and a triage record.
5. Score your gaps with the SBOM and vulnerability response readiness assessment, or the update-focused Secure Update Readiness Assessment.

Spotted an error? Report it to our corrections log. Read our editorial methodology.