What Is an SBOM? What the EU Cyber Resilience Act Requires

What is an SBOM? An SBOM (software bill of materials) is a formal, machine-readable record of the software components in your product and how they relate to each other. The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to draw one up as part of vulnerability handling. It must use a commonly used, machine-readable format and cover at least the top-level dependencies. The CRA provision we checked asks you to create the SBOM. On its own, it does not require you to publish it.

Key takeaways

• The CRA defines an SBOM in Article 3(39) as a formal record of the components in a product's software elements and their supply chain relationships.
• Annex I, Part II, point 1 requires an SBOM in a commonly used, machine-readable format, covering at least top-level dependencies.
• The Regulation names no format, and it does not define "top-level dependencies".
• Annex I asks you to draw up the SBOM. Read Article 13 and Annex VII before deciding how you store and share it.
• Generate a fresh SBOM for every release inside your build pipeline.

What is an SBOM, in plain English?

An SBOM is an inventory of the software inside your product. It lists each open-source and third-party component, its version and supplier, and which components depend on which. Most teams generate it automatically from their build rather than writing it by hand.

The CRA gives the term a legal definition in Article 3(39). An SBOM is "a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements".

Two words in that definition do a lot of work:

• Formal. It is a structured record that a machine can read. A wiki page or a spreadsheet someone updates when they remember does not count.
• Software elements. The definition covers software and firmware. Your circuit board and enclosure are not part of the legal SBOM.

Why does an SBOM matter for your business?

An SBOM lets you answer one question fast when a vulnerability is disclosed in a third-party library: are we affected, and in which products and versions? Without one, engineers search repositories and build servers by hand, often across several shipped versions.

Under the CRA, that triage feeds straight into your vulnerability handling and reporting. We cover that in our CRA 24-hour vulnerability reporting checklist.

The same record is useful outside compliance:

• reviewing open-source licences;
• answering security questionnaires from larger customers;
• showing an investor or acquirer what is actually in your code.

Does the Cyber Resilience Act require an SBOM?

Yes. Annex I, Part II, point 1 requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products".

Article 6 says products with digital elements shall be "made available on the market only where" certain conditions are met. One condition is that the manufacturer's processes comply with Part II of Annex I. So the vulnerability-handling processes, including the SBOM, are a condition for making a product available on the EU market.

Here is what the requirement settles and what it leaves open:

Question	What the CRA text says	What it leaves open
Is an SBOM required?	Yes, Annex I, Part II, point 1	Nothing on this point
Which format?	"Commonly used and machine-readable"	No format is named
How deep?	"At the very least the top-level dependencies"	The term is not defined
Publish it?	The duty is to draw one up	Annex I contains no publication duty
What does it cover?	The product's "software elements"	Hardware is outside the definition

Annex I is not the whole story. Article 13 and Annex VII, the Regulation's technical documentation annex, may add detail on how the SBOM is kept and who can see it. Read them before you decide your approach. Also check the European Commission's CRA pages for any later implementing or delegated acts that add detail on SBOM format.

When do the CRA's SBOM obligations apply?

Article 71 of Regulation (EU) 2024/2847 on EUR-Lex sets the dates. Read Article 71 directly before you build a plan, rather than relying on secondary summaries, including ours.

If you are unsure whether the CRA or NIS2 is the rule that matters for your business, read NIS2 vs the Cyber Resilience Act.

Which SBOM format should you use?

The CRA does not list acceptable formats. Whether a format is "commonly used" is a judgement call. The two open formats you will meet most often are SPDX and CycloneDX, and either is a reasonable starting point.

Use this checklist to choose:

• What do your customers ask for? If a key buyer specifies a format, start there.
• What does your tooling support? Pick the format your build ecosystem can generate reliably without manual steps.
• What else do you need? Some teams care most about licence data, others about security tooling. Check which format your downstream tools read.
• Where do you sell? If you sell into Germany, look at the BSI's Technical Guideline TR-03183. Its Part 2 covers SBOMs. It is German national guidance, not EU law, so check the current version on the BSI page.

What does an SBOM look like for a SaaS app versus an IoT device?

The principle is the same for both, but the contents and the hard parts differ.

	SaaS web app	IoT device with firmware
Typical components	Frontend and backend packages, runtimes, container base images	RTOS or embedded Linux, vendor SDKs, bootloader, networking and crypto libraries, plus the companion app and cloud backend
Where the data comes from	Package manifests, lockfiles, container images	Firmware build system, vendor deliveries, sometimes binary analysis
CRA position	Covered where it is a connected product's remote data processing; standalone SaaS is less clear	Firmware and software are the "software elements" the SBOM covers
Hardest part	Keeping pace with frequent deployments	Closed-source vendor binaries and legacy code

SaaS. Article 3(1) defines a product with digital elements as a software or hardware product "and its remote data processing solutions". Article 3(2) limits remote data processing to two conditions:

• the product could not perform one of its functions without the processing;
• the processing is designed by, or under the responsibility of, the manufacturer.

A cloud backend that meets both tests is part of the product. Whether a standalone SaaS with no downloadable product falls under the CRA is less clear. We cover that in the Cyber Resilience Act for software and SaaS.

IoT. Because the definition refers to software elements, the legal SBOM is about firmware and software, not the PCB. Firmware is usually the harder case. Closed-source vendor binaries come with no manifest to read, so their contents often have to be recorded manually or recovered through binary analysis. For a full walk-through, see our CRA worked example for an IoT startup.

If you are building firmware or a connected app now, it is far cheaper to put SBOM generation into the build stage than to retrofit it later.

How do you create and maintain an SBOM? 6 steps

Creating an SBOM is a pipeline task, not a one-off document.

1. Define what ships. List each product and each software version you make available on the market. Each version needs its own SBOM.
2. Pick a format. Choose SPDX or CycloneDX using the checklist above, and stick to it across products.
3. Generate in the build. Use a generator for your language ecosystem or firmware build system that outputs your chosen format. Run it automatically on every release build.
4. Check depth and quality. The CRA floor is top-level dependencies. Because the term is undefined, resolve deeper where your tooling allows, and review the output for missing suppliers or versions.
5. Keep vulnerability status separate. An SBOM describes what a release contains, which does not change after you ship it. Vulnerability status does change, so record it in separate advisories that reference the SBOM.
6. Store and version. Keep each SBOM with that release's records so you can produce it quickly if a customer or authority asks.

How much does an SBOM cost in time and tools?

We found no reliable published figures for SBOM cost, so we will not invent any. Licences are rarely the main expense, because open-source generators exist for the common ecosystems. The real cost is engineering time, and it rises with:

• the number of language ecosystems and build systems you use;
• binary-only vendor components that need manual entries or binary analysis;
• release frequency, since every release needs a new SBOM;
• the review effort needed to check accuracy rather than just generate output.

In our view, a modern web stack with lockfiles is usually the cheap case. Embedded firmware built on vendor SDKs is usually the expensive one.

What are the common SBOM mistakes to avoid?

Most SBOM failures come from treating the SBOM as paperwork rather than build output.

• Generating once. An SBOM from last year's build does not describe this year's release.
• Editing vulnerabilities into the SBOM. The SBOM goes stale the day a new issue is disclosed. Keep vulnerability status in separate documents.
• Stopping at top-level dependencies. This is the CRA floor. A vulnerable library can sit several levels down, where a top-level list will not show it.
• Treating national guidance as EU law. BSI TR-03183 is useful German guidance, but it does not replace reading the CRA itself.
• Ignoring the cloud side. A connected device's backend can count as remote data processing.
• No owner. Without a named person, nobody notices when generation silently breaks.

Frequently asked questions

Do I have to publish my SBOM under the CRA?

Annex I, Part II, point 1 asks you to draw up an SBOM and contains no duty to publish it. Check Article 13 and Annex VII, the technical documentation annex, for how the SBOM must be kept and who can access it. You can still share it with customers voluntarily.

Which SBOM format does the CRA require?

None by name. It asks for a "commonly used and machine-readable format" and gives no list. SPDX and CycloneDX are the obvious candidates in our view. Check the Commission's CRA pages for any later acts that add detail.

Does my SaaS product need an SBOM?

Your SaaS is within the CRA's product definition if it meets the Article 3(2) test for a connected product's remote data processing. The product must be unable to perform one of its functions without it, and it must be designed by or under the responsibility of the manufacturer. Whether a standalone SaaS with nothing downloadable is in scope is less clear, so take advice on your specific setup.

Does an SBOM for an IoT device include the hardware?

The CRA defines the SBOM in terms of the product's software elements, so firmware and software are what count legally. If a customer wants a hardware bill of materials, treat it as a separate commercial request, not part of the CRA SBOM.

How often should I regenerate my SBOM?

The CRA text we checked does not set a frequency. An SBOM describes one specific build, so regenerate it for every release that changes components. The simplest way to do that is to run generation automatically in your build pipeline.

If you want a second pair of eyes on your SBOM pipeline or wider CRA readiness, book a free 30-minute call with Hephaestus.

Cover photo by cottonbro studio on Pexels.