EU CRA SBOM Requirements: How to Build a Compliant Inventory

A Technical Team Head’s guide for UK manufacturers selling software or connected products into the EU. 

Under the CRA, every product sold in the EU with digital elements needs a software bill of materials. In order for these documents to satisfy their purpose, they need to live within a company’s technical file (and should go to the authorities upon request), have up-to-date data, and comply with the EU CRA SBOM.

The entire scope of Annex I will apply from 11 December 2027 – anyone shipping software or connected hardware into the EU Cyber Resilience Act can expect to find out exactly what’s inside it under the EU’s Cyber Resilience Act (CRA). The tool for that is a software bill of materials, or SBOM. Annex I applies in full from 11 December 2027. But reporting has applied since 11 September 2026, and you can’t report on a component you’ve never listed.

Most teams we speak to treat the SBOM as a late-2027 paperwork job. It isn’t. An SBOM is how you find out, within 24 hours, whether an exploited library sits in your product. 

This guide walks through what the EU CRA SBOM is asking for, what format you need to use, and how to put together an SBOM. But more importantly, we’ll point out where some UK teams might fall short here, based both on the contents of the Act itself as well as the additional guidance published by the government.

What Do the EU CRA SBOM Requirements Say?

The EU CRA SBOM asks for a short list of things. Annex I, Part II, point 1 of Regulation (EU) 2024/2847 tells manufacturers to identify and document components. They do it by drawing up an SBOM “in a commonly used and machine-readable format covering at least the top-level dependencies of the product.” That’s the whole legal test.

Three things follow from that wording:

• Machine-readable. A PDF table doesn’t count. A script should be able to open the file.
• Commonly used format. The Act names no format. CycloneDX and SPDX are the safe picks.
• Top-level dependencies, at least. The Act doesn’t define top-level. Most guidance reads it as the components you add directly.

Notice what’s missing for the EU Cyber Resilience Act. The text sets no field list, no update schedule and no tool. The SBOM must also stay up to date, but nobody has said how often. Until the Commission says more, you’re making judgment calls, so write down why you made them.

Is an SBOM Mandatory Under the EU Cyber Resilience Act?

Yes. It’s part of Annex I, so skipping it is a breach of the essential EU CRA SBOM requirements. That puts you in the top penalty tier, up to €15 million or 2.5% of worldwide turnover, whichever is higher.

You don’t have to publish it, though. Recital 77 says manufacturers shouldn’t be obliged to make the SBOM public. It goes into your technical documentation, and you hand it to a market surveillance authority if one asks. If you choose to share it with customers, Annex II asks you to say where they can find it.

One more point on retention. Article 13(13): Technical documentation shall remain available to authorities for at least ten years after placing the product on the market, or during its support period if this is longer. Therefore, all versions of products shipped with an SBOM in them need a repository that keeps their data safe for at least a decade.

Which Dates Matter for SBOM Compliance?

The SBOM compliance rules apply on different dates from the reporting duty. Teams mix the two up, which is how they end up with a plan that’s a year too late.

The last row matters. Article 13(24) lets the Commission specify the SBOM format and elements through an implementing act. If that lands, your fields may change. Build the file so you can add fields without redoing the pipeline.

Which Format and Fields Should You Use?

The EU CRA SBOM requirements in the Act are thin, so most teams borrow from German guidance. BSI’s TR-03183-2 is the one people copy. It’s voluntary, and it isn’t CRA law. Still, it’s the most detailed spec around, and observers expect it to shape whatever the Commission eventually publishes.

BSI accepts CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher. Both work. CycloneDX tends to suit build pipelines. SPDX tends to suit licence work. Pick the one your tooling already produces, and stick with it across releases.

BSI also encourages unique identifiers such as a package URL (PURL) where you have one. We’d add it. It makes vulnerability matching far less guessy.

One more BSI position is worth knowing. It wants vulnerability data kept out of the SBOM and shared in a separate VEX or CSAF document. The CRA doesn’t require VEX. But the split is sensible: the SBOM says what’s inside, and VEX says whether a known flaw can actually be exploited.

How Do You Build the Inventory, Step by Step?

Scope every product and component first

List each product you place on the EU market. Include firmware, apps, libraries and anything you sell separately. Teams often forget the update agent and the companion mobile app. Both count.

Generate the SBOM in your build pipeline

A hand-made SBOM goes stale the day after you make it. Generate it on every build, from the actual build inputs. Tools such as Syft, cdxgen and the SPDX tooling all do this.

Go past the first layer

The Act says top-level at least. BSI asks you to resolve dependencies recursively, down to the first component outside your delivery scope. We’d follow BSI here. Transitive dependencies are where the surprises live, and a library three layers down is still your problem when it’s exploited.

Keep vulnerability data separate

Match the SBOM against NIST’s NVD and CISA’s KEV catalogue in a separate step. Record the result in VEX or in your ticketing. Don’t write findings into the SBOM itself.

Store one SBOM per release

Keep every version next to its release artefact. If an authority asks about firmware 3.2 from two years ago, you want the list for 3.2, not today’s.

Weak vs Strong: An SBOM Generation Step

This is the pattern we see most in reviews. The first pipeline makes one file by hand at release. The second makes a file on every build, checks it, and stores it.

# Weak: one SBOM, generated at release, never refreshed

release:

  steps:

    – run: syft scan dir:. -o cyclonedx-json=sbom.cdx.json

# Stronger: every build, versioned, sanity-checked, stored with the release

build:

  steps:

    – run: syft scan dir:. -o cyclonedx-json=sbom-${VERSION}.cdx.json

    – run: jq -e ‘.bomFormat == “CycloneDX”‘ sbom-${VERSION}.cdx.json

    – run: jq -e ‘.components | length > 0’ sbom-${VERSION}.cdx.json

    – uses: actions/upload-artifact@v4

      with:

        name: sbom-${VERSION}

        path: sbom-${VERSION}.cdx.json

The checks stop an empty file from shipping as “the SBOM.” The upload keeps a copy per version. Add a check on the spec version too, once you’ve settled on one. The evidence an authority wants is the stored file for the release in question, plus proof your pipeline made it.

Get your SBOM checked by Qualysec before an authority does!

How Do You Keep the SBOM Current?

Generating the file is the easy part. Keeping your EU CRA SBOM current is where most setups fail. Plenty of teams build one at release, then a library picks up a CVE six months later, and the file says nothing.

Rebuild on every build for SBOM requirements, and also on a schedule. A product that’s on the market but isn’t being rebuilt still needs its dependencies watched. Run the SBOM against vulnerability feeds weekly at least.

Track end-of-life dates for each component too. Your support period is five years at minimum, unless the product’s expected use is shorter. If an upstream library stops getting patches in year three, you’ve got two years of exposure and nobody to blame but your own roadmap.

Where Do UK Teams Usually Fall Short?

We see the same few gaps again and again. Each one is fixable, and most are cheap before an audit and expensive after.

A quick test helps. Pick a well-known library and ask your team which of your products ship it. If the answer takes more than an hour, your SBOM compliance gap is bigger than you think.

What About Open-Source and Supplier Components?

The EU SBOM Act makes you do due diligence on third-party and open-source components you build in. If you find a vulnerability in one, you report it upstream. Pulling in a popular library doesn’t move the burden to whoever maintains it.

The CRA doesn’t force suppliers to hand you an SBOM. Still, you should ask. Add EU CRA SBOM requirements to your supplier contracts, so a vendor of a binary component tells you what’s inside it. Where something truly can’t be known, mark it as unknown rather than leaving a quiet gap. SPDX has a NOASSERTION value for exactly this.

For open-source stewards, the picture is different. Their reporting duties start on 11 December 2027, not September 2026, and they carry no fines. If you build their code into a commercial product, though, you still answer for it.

What Does an EU SBOM Mean for UK Companies?

You’re in scope the moment you sell a product with digital elements into the EU. Where your company sits doesn’t change that. A UK manufacturer shipping to Germany follows the same rules as a German one.

Use an EU CRA checklist to verify that your SBOM process, vulnerability handling, documentation and reporting procedures meet the applicable requirements.

The UK’s own rules don’t cover this ground. The Product Security and Telecommunications Infrastructure (PSTI) regime applies to consumer connectable products. It bans universal default passwords, requires a vulnerability disclosure channel and asks you to state a support period. It doesn’t ask for an SBOM. So a product can pass PSTI and still fail the CRA.

Practically, that means one EU CRA SBOM process should serve both markets, and one technical file should serve any EU authority that asks.

How Qualysec Helps UK Manufacturers With the EU CRA

Qualysec is a CREST-accredited firm, and penetration testing is what we do most, with over 3,700 assessments completed. For EU SBOM CRA work, we focus on one output: evidence that drops straight into your technical file. We’re not a notified body, so we can’t issue the formal third-party assessment that critical products need.

SBOM Completeness Review

You will get a report showing us testing all these things – what we tried to test (and why) and whether we succeeded, either because we didn’t see anything wrong with your file (in this case, there would be a list of what you had to fix), or it failed some tests. Additionally, each engagement contains a ‘re-test’ phase to ensure that the vulnerabilities were addressed as necessary. 

Dependency and Vulnerability Testing

We match your components against known vulnerabilities and perform vulnerability testing to determine whether the ones that matter can actually be reached. That gives you a short, honest list to fix, instead of a thousand-line scanner export.

Penetration Testing Evidence for the Technical File

This means that the final output from your file is a closed vulnerability rather than an open one. BSI accepts both CycloneDX v1.6+ and SPDX v3.0.1+. Make sure to go for at least one version above those numbers if possible.

Conclusion

The EU SBOM isn’t a document you write once. It’s a build output, and it’s only worth anything if it’s current, versioned and stored. The legal test in the Act is short. The hard part is the pipeline behind it.

Start with three SBOM requirements. Add SBOM generation to your build. Resolve past the first layer of dependencies. Store a copy with every release. None of that needs a big budget, and all of it is easier before an incident than during one.

Talk to Qualysec about your CRA roadmap!

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQ

1. Is an SBOM required under the CRA?

Yes. Annex I, Part II, point 1 requires one in a commonly used, machine-readable format covering at least top-level dependencies. It applies in full from 11 December 2027.

2. Which SBOM format should we use?

The Act names none. CycloneDX and SPDX are both commonly used. BSI’s guidance accepts CycloneDX 1.6 or higher and SPDX 3.0.1 or higher, so those versions are a safe target.

3. Do we have to make SBOM public?

No. It sits in your technical documentation, and you give it to market surveillance authorities when they ask. If you do share it, you need to say where customers can find it.

4. How often should we update it?

The Act says “up to date” and gives no schedule under SBOM requirements. It is suggested to regenerate on every build and re-check against vulnerability feeds at least weekly.

5. Does an EU SBOM obligation apply to UK companies?

Yes, if you place a product with digital elements on the EU market. The test is where you sell, not where your company is based.

6. What must an SBOM contain under the CRA?

At minimum, the product’s top-level dependencies, in a machine-readable format. BSI TR-03183-2 lists far more fields, such as versions, hashes and licences. It’s voluntary, but it’s the best guide available.