Your customer wants an SBOM: a guide for component and software suppliers

This guide is for suppliers inside a manufacturing supply chain: ECUs, displays, controllers, gateways, drives, embedded Linux stacks and firmware modules. If you sell software and a customer sent a one-off request, start with how to answer a customer SBOM request, which covers that case.

Why OEMs are asking now

An OEM's SBOM request is usually the OEM's regulation arriving at your door through a contract. Which regulation it is decides what the OEM must have, and how much of it is passed down to you.

The Cyber Resilience Act

Under the Cyber Resilience Act, Regulation (EU) 2024/2847, a product with digital elements includes "software or hardware components being placed on the market separately" (Article 3(1)). A component you sell on its own into the EU is a product in its own right, and you are its manufacturer, with your own SBOM obligation: Annex I, Part II, point (1) asks for an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". If the component is intended for integration into other products, your instructions must also give "the information necessary for the integrator to comply" with the essential requirements (Annex II, point 8(f)).

The OEM has obligations that reach you too. It must "exercise due diligence when integrating components sourced from third parties" (Article 13(5)), and when it finds a vulnerability in a component it integrated, it must report it to the person or entity that manufactures or maintains the component (Article 13(6)). The Commission's CRA guidance of July 2026 says due diligence evidence "may consist of documentation obtained from the component manufacturer", and does not mention SBOMs; in practice, an SBOM is often the documentation OEMs ask for. Reporting obligations apply from 11 September 2026 and the regulation applies in full from 11 December 2027. Spare parts made to the same specification as the components they replace are excluded (Article 2(6)). For the rest of the regulation, see what the CRA is and the CRA guide.

Vehicles

The CRA does not apply to products covered by Regulation (EU) 2019/2144, the vehicle type-approval regulation (Article 2(2)(c)). Components for type-approved vehicles reach the market under vehicle rules instead, and those rules never mention an SBOM.

• UN Regulation No. 155 (cybersecurity) requires the manufacturer to collect and verify information "through the supply chain so as to demonstrate that supplier-related risks are identified and are managed" (5.1.1(a)), to show how its cybersecurity management system "will manage dependencies that may exist with contracted suppliers, service providers or manufacturer's sub-organizations" (7.2.2.5) and to "identify and manage, for the vehicle type being approved, supplier-related risks" (7.3.2).
• UN Regulation No. 156 (software updates) requires all initial and updated software versions to be uniquely identifiable (7.1.1.2) and, for every RX Software Identification Number (RXSWIN), "an auditable register describing all the software relevant to the RXSWIN" (7.1.2.3).
• ISO/SAE 21434 organizes cybersecurity work between OEM and supplier as distributed activities, with the split agreed in a cybersecurity interface agreement.
• The Auto-ISAC SBOM Informational Report (February 2025) gives the industry's own guidance.

In automotive, an SBOM arrives as a contract requirement, not a legal one.

Industrial automation

IEC 62443-4-1 applies to suppliers of industrial automation and control system products. It does not name SBOMs, but practice 6, management of security-related issues (DM-1 to DM-6), and practice 7, security update management (SUM-1 to SUM-5, including SUM-3, "Dependent component or operating system security update documentation"), are where an SBOM serves as evidence.

Machinery

The Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and does not mention SBOMs. Its essential requirements on protection against corruption (Annex III, 1.1.9) ask that software critical for compliance be identified and protected, that the machinery can "identify the software installed on it that is necessary for it to operate safely", and that evidence of interventions in that software be collected. Machinery with digital elements also falls under the CRA, unlike type-approved vehicles, which is why machinery OEMs ask their suppliers for SBOMs now. See CRACI for machinery makers and industrial IoT.

NIS2 and certified customers

If you supply essential or important entities, for example in semiconductors, NIS2 Article 21(2)(d) requires your customer to address supply chain security. It does not name SBOMs. Customers turn it into questionnaires, and ISO/IEC 27001 Annex A controls 5.21 and 8.8 are where an SBOM serves as evidence. See SBOMs as ISO 27001, SOC 2 and NIS2 evidence.

The regimes side by side

Regime	Applies to	Names an SBOM?	What reaches the supplier
Cyber Resilience Act	Products with digital elements on the EU market, including components sold separately	Yes, Annex I, Part II (1)	Directly if you place the component on the market; through the OEM's due diligence (Art. 13(5)) and vulnerability reports (Art. 13(6))
UN R155 and R156	Vehicle manufacturers seeking type approval	No	Supplier risk management (R155 7.2.2.5, 7.3.2) and software identification (R156), through contracts
ISO/SAE 21434	Road vehicle cybersecurity engineering, OEMs and suppliers	Not in its public description	Distributed activities and a cybersecurity interface agreement
IEC 62443-4-1	Suppliers of industrial automation and control system products	No	Directly if you are the product supplier; SBOMs serve as evidence for DM and SUM
Machinery Regulation	Machinery and related products on the EU market	No	Software identification and protection (Annex III 1.1.9); the CRA applies alongside it
NIS2	Essential and important entities	No	Supply chain security questionnaires and contract terms (Art. 21(2)(d), 21(3))

Whatever the route, the customer needs the same thing: an accurate SBOM for every software version you deliver.

What OEMs typically ask for

Requirements differ by OEM, but they converge on the same list. Check your SBOM against it before the first delivery.

Requirement	Typical expectation
Format	CycloneDX or SPDX, JSON or XML, with a minimum spec version. BSI TR-03183-2 sets CycloneDX 1.6 or later, or SPDX 3.0.1 or later.
Fields	Aligned with the CISA 2026 Minimum Elements or BSI TR-03183-2: author, timestamp, and for each component a name, version, producer and identifiers
Identifiers	A package URL wherever the ecosystem has one, a CPE where it does not, so components can be matched to vulnerability databases
Licenses	SPDX license identifiers. The OEM's license specialist reads them to judge copyleft and other license risk.
Hashes	A hash of each delivered binary, so the OEM can confirm the SBOM describes the file it received. BSI asks for SHA-512.
Depth	Transitive dependencies, not only the top level
Granularity	One SBOM per delivered software version or part number
Delivery and response	A delivery channel, and response times for vulnerability questions

Many OEMs check these automatically on arrival. See the SBOM quality checklist for what your customer will check, and the tools they use, and SBOM examples for what the fields look like in a file.

Your SBOM when there is little or no open source

A bare-metal ECU or controller with proprietary firmware from model-based code generation has an honest SBOM that can be short: the proprietary application, your bootloader, a silicon vendor's libraries or calibration, and any open source such as a cryptography library. That is a valid answer. The rules:

• List proprietary components with your own identifiers: name, version and you as the producer.
• State the known unknowns, such as a vendor library whose contents you cannot see.
• Never pad the SBOM to look thorough, and never leave out an open source library because it is small.

For Linux-based displays and gateways the opposite holds: hundreds or thousands of components, including the kernel, the bootloader and the base system packages (see connected devices). An SBOM that lists only your application and a few libraries is the first thing a receiving team flags. If you build with Yocto, see why scanners miss what is in Yocto builds.

Contracts: what to agree before the first delivery

Term	Why it matters
Products and software versions covered	So nobody argues later about whether a variant or a service release needed an SBOM
Format and spec version	Their intake pipeline may reject anything else
Fields and the framework they follow	"BSI TR-03183-2 v2.1.0" or "CISA 2026 Minimum Elements" is testable; "a complete SBOM" is not
Delivery trigger	Each release, each software version shipped to the OEM, and each correction
Delivery channel	The OEM's supplier portal, secure file exchange or email under NDA
Confidentiality	An NDA or the existing supply agreement, naming the SBOM as confidential information
Use restrictions	Vulnerability management and compliance only, no onward sharing without consent
Vulnerability notification, both ways	The OEM reports vulnerabilities it finds in your component (CRA Art. 13(6)); you notify it of yours
VEX expectations	Which format, and how quickly you assess a new CVE
Retention	How long you keep the SBOM of each version, matched to the product's support period
Accuracy and known unknowns	An honest clause on what the SBOM can and cannot cover protects both sides

CISA's SBOM Sharing Primer describes the automotive case the same way: SBOM requests "would be included in standard information exchange agreements (e.g., non-disclosure agreement, cybersecurity interface agreement, development interface agreement)".

Sharing without leaking IP

An SBOM is not your source code. It lists component names, versions, producers, licenses, hashes and relationships. It does not contain your code, your algorithms, your calibration data or your design.

• The CRA does not oblige manufacturers to make the SBOM public (Recital 77). It goes to a market surveillance authority on a reasoned request (Annex VII, point 8).
• CISA's sharing guidance describes the usual channels for proprietary software: email under an NDA, the customer's supplier portal or a secure document exchange, or an access-controlled portal of your own, with contracts governing confidentiality and access.
• Practical options: one full SBOM per OEM under contract; identifiers for proprietary parts that do not reveal internal project names; and a separate VEX document, so you can update a vulnerability's status without sending the SBOM again.

How often, and what happens after delivery

• A new SBOM for every software version you deliver, under the same identifier the OEM flashes or registers. For vehicles that ties into the R156 software identification.
• A corrected SBOM when you find an error in one you sent.
• A VEX statement or an advisory when you have assessed a vulnerability.

The follow-up question, "are you affected by CVE-X?", arrives with the next big vulnerability. Be ready to answer it per delivered version, which is only possible if you kept the SBOM of each one.

VEX: what your customer will expect next

A VEX document says whether a product is affected by a vulnerability. CISA's Minimum Requirements for VEX (April 2023) define four statuses: not_affected, affected, fixed and under_investigation. A not_affected statement should give one of five justifications, or else an impact statement:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

An affected statement needs an action statement: what the customer should do. VEX comes in three formats: the CSAF 2.0 VEX profile, CycloneDX VEX and OpenVEX. Yocto's SPDX 3.0 output includes VEX data by default (the SPDX_INCLUDE_VEX variable).

Worked example. A Linux-based display ships OpenSSL 3.0.8. CVE-2023-0464 describes excessive resource use when verifying X.509 certificate chains that include policy constraints. Policy processing is disabled by default, and the display's software never enables it. The supplier sends an illustrative OpenVEX statement:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Producing SBOMs repeatably

How you build	Realistic way to produce the SBOM
Software built in CI	Generate the SBOM in the build that produces the delivered software, and keep it with the release
Yocto-based embedded Linux	Yocto's own SPDX output (create-spdx), checked for what it leaves out, or a recording of the Yocto build
Bare-metal firmware from model-based tools	A generator library or tool, never a text editor, maintained with each release and validated before sending
Third-party binaries you integrate	Ask your own supplier for its SBOM; binary analysis as a stand-in until it arrives

Whatever the route, validate the file before sending it. The SBOM quality checklist lists the validators your customer is likely to run, CycloneDX vs SPDX helps with the format, and standardizing SBOM generation covers making it the same across teams.

How CRACI fits

For suppliers who build on GitHub Actions, CRACI replaces the GitHub-hosted runners and records an SBOM from every build, so each delivered version already has one.

• The SBOM lists what the build actually pulled in, including transitive dependencies, with a package URL per package and the declared license of every component.
• Each job's SBOM carries a completeness state, so you know what you are sending before you send it.
• SBOMs export as CycloneDX or SPDX, and CRACI supports VEX.
• Monitored SBOMs are re-evaluated as new vulnerabilities are published, and build history shows which builds contained a vulnerable dependency, within your retention period.
• Yocto builds run on CRACI runners and are documented.
• Third-party SBOMs can be added, so components you buy in are monitored alongside your own builds.

When CRACI is not the answer

• You have no CI, or you build on GitLab, Jenkins or a build server. CRACI supports GitHub Actions only today; other CI systems are on the roadmap.
• Your firmware is generated from model-based tools with no package fetching. A build recorder adds little there.
• You need to host SBOMs for many OEMs in a sharing portal, or to sign SBOMs. CRACI offers neither.
• Your builds must run on your own infrastructure. Customer-hosted runners are on the roadmap.
• Your customer wants proof of your organization's security management, such as an ISO 27001 certificate or answers to a NIS2 questionnaire. An SBOM is evidence for part of that, not a certification. CRACI's own ISO 27001 certificate covers CRACI's service, not yours.

SBOMs for suppliers: frequently asked questions

My customer, an OEM, asked for an SBOM. Am I required to provide one?

Often the contract requires it rather than the law. If you place a component with digital elements on the EU market yourself, the Cyber Resilience Act requires your own SBOM. Otherwise the obligation is the OEM's, which passes it to you through due diligence and the supply agreement.

Does the CRA apply to components I sell to a manufacturer?

If you place the component on the EU market separately, yes: Article 3(1) includes software or hardware components placed on the market separately. If it only reaches the market inside the OEM's product, the OEM is the manufacturer and must exercise due diligence on your component (Article 13(5)). Components of type-approved vehicles are outside the CRA (Article 2(2)(c)).

Does UN R155 or ISO/SAE 21434 require an SBOM?

No. R155 never mentions an SBOM; it requires the vehicle manufacturer to manage supplier-related risks. ISO/SAE 21434 organizes cybersecurity work with suppliers through interface agreements. In automotive, SBOMs arrive as a contract requirement.

Which format and fields will an OEM expect?

Usually CycloneDX or SPDX in JSON or XML, aligned with the CISA 2026 Minimum Elements or BSI TR-03183-2: author and timestamp, and per component a name, version, producer, package URL or CPE, license and hash, with transitive dependencies.

How often do I have to send an updated SBOM?

For every software version you deliver, whenever you correct an error, and with a VEX statement or advisory when you have assessed a vulnerability. Agree the trigger in the contract.

Will sharing an SBOM expose our intellectual property?

No. An SBOM lists component names, versions, producers, licenses, hashes and relationships, not source code, algorithms or calibration data. Share it under an NDA or the supply agreement, with use restricted to vulnerability management and compliance. The CRA does not require it to be public.

What is VEX, and will my customer ask for it?

VEX states whether a product is affected by a vulnerability: not_affected, affected, fixed or under_investigation, with a justification for not_affected. Expect to be asked for one after the next widely reported vulnerability in a component you ship.

Our ECU firmware has no open source. What does our SBOM look like?

Short and honest: the proprietary application, the bootloader, any silicon vendor libraries or calibration, and any open source such as a cryptography library, each with your own identifiers, plus the known unknowns. Do not pad it.