Free tool

CRA SBOM Tool

The EU Cyber Resilience Act requires manufacturers to produce and maintain a machine-readable Software Bill of Materials (SBOM) as part of their technical documentation. This tool helps you pick the right format, check your readiness against the seven key requirements, and get a starter template - no external dependencies, no login.

What the CRA requires

Manufacturers must draw up a machine-readable SBOM covering at least all top-level dependencies. It must be included in the technical documentation (Annex VII) and kept for ten years after placing the product on the market. Regulation (EU) 2024/2847, Annex VII

Last updated · 8 Jun 2026

Which SBOM format should I use?

The CRA does not mandate a specific standard, but it says "machine-readable". In practice, only two formats have broad tooling support:

Select a format above to see guidance. If you are starting fresh and have no existing toolchain preference, CycloneDX JSON is a reasonable default - it has the broadest tool support right now.

SBOM readiness self-check

0/7

Your SBOM is generated automatically (e.g. in CI/CD)Manual SBOMs go stale fast. A CI step that regenerates on every release is the baseline.
All top-level dependencies are capturedThe CRA requires at minimum all top-level dependencies (direct deps). Transitive deps are best practice and may be expected by notified bodies.
The SBOM is machine-readable (CycloneDX JSON/XML or SPDX)The CRA specifies machine-readable format in the technical documentation. CycloneDX and SPDX are the two recognised standards.
The SBOM is stored in your technical documentation (Annex VII)Annex VII of the CRA lists the SBOM as a required component of the technical documentation you must keep and be able to produce on request.
The SBOM is wired to a vulnerability monitoring processThe SBOM only fulfils its compliance purpose if you act on it. You need a process that ingests the SBOM, checks CVE databases, and triggers your CVD workflow when a component is affected.
You have a public CVD contact point for vulnerability reportsThe CRA requires a coordinated vulnerability disclosure (CVD) policy and a publicly accessible contact point. Link to it from your product documentation and website.
You have a process for issuing security updates when vulnerabilities are foundThe CRA requires free security updates throughout the support period, which is presumed to be at least five years unless you declare otherwise.

Step by step

How to use this tool

From blank page to CRA-ready SBOM in four steps.

Pick your SBOM format

Choose between CycloneDX and SPDX based on your toolchain and supply-chain context. The format picker explains the trade-offs and gives you the minimum required fields for each.

Run the readiness self-check

Work through the seven-item checklist: automated generation, dependency coverage, machine-readable output, storage in technical docs, vulnerability monitoring, CVD contact point, and security update process.

Read your plain-English summary

The tool scores your readiness and tells you which gaps to tackle first - prioritised by what the CRA actually requires versus what is good practice.

Download the starter template

Get a CycloneDX JSON starter template pre-populated with the minimum CRA-required fields. Email yourself a copy or download directly - no login needed.

In short

Under the CRA, your product needs a machine-readable SBOM - at least top-level dependencies, in CycloneDX or SPDX format - stored in your Annex VII technical documentation. It should be generated automatically, kept current, and wired to your vulnerability monitoring and CVD process.

What an SBOM is under the CRA

A Software Bill of Materials is a structured, machine-readable list of the software components - libraries, packages, dependencies - that make up a product. Think of it as a recipe list for your software, formal enough that a machine can read it and check each ingredient against a database of known vulnerabilities.

The CRA makes the SBOM a legal requirement for products with digital elements. It must be included in the technical documentation that manufacturers draw up before placing a product on the EU market, and it must be available to market surveillance authorities on request. Annex VII, point 3(e), Reg. (EU) 2024/2847

Minimum required content

All top-level (direct) dependencies, by name and version
Machine-readable format: CycloneDX (JSON/XML) or SPDX (JSON/RDF/tag-value)
Stored as part of the Annex VII technical documentation
Kept for ten years after placing the product on the market

Best practice (beyond the minimum)

Include transitive (indirect) dependencies for complete vulnerability coverage
Add Package URLs (PURLs) so tooling can match components to CVE databases
Regenerate automatically on every release in your CI/CD pipeline
Wire the SBOM to your CVD workflow so affected products are flagged automatically

For a deeper dive into SBOM tooling, formats and integration patterns, see the SBOM guide.

SBOM questions people ask

Does the CRA mandate a specific SBOM format?

The CRA requires a machine-readable SBOM but does not mandate a specific standard. In practice, CycloneDX (OWASP) and SPDX (ISO 5962) are the two formats that have broad tooling support and are recognised by the European Commission. Either is acceptable; the choice should be driven by your toolchain and your customers' tooling.

What must the SBOM contain under the CRA?

At minimum: all top-level (direct) dependencies, with their name and version. The SBOM must be machine-readable and form part of your technical documentation as required by Annex VII. Best practice - and likely required for high-risk products - is to include transitive dependencies and package URLs (PURLs) so the SBOM can be used for automated vulnerability scanning.

Where does the SBOM live in the CRA technical documentation?

The CRA Annex VII lists the SBOM as a required element of the technical documentation manufacturers must draw up. The technical documentation must be kept for ten years after placing the product on the market and produced on request to market surveillance authorities.

Do I need to publish the SBOM publicly?

The CRA does not require the SBOM to be publicly available - it must be in your technical documentation and available to authorities. However, sharing it with downstream customers (for example, via a software distribution channel) is increasingly expected and may be required by enterprise buyers. Check what your customer contracts require.

What is the link between the SBOM and the CVD requirement?

The SBOM is the input to your vulnerability monitoring process. When a CVE is published for a component in your SBOM, your coordinated vulnerability disclosure (CVD) workflow - which the CRA requires you to have - should trigger an assessment. Without the SBOM, knowing which products are affected by a given CVE is manual and error-prone.

Next steps

Need the full documentation pack? Get the CRA documentation templates.
Not sure the CRA applies to your product? Run the scope checker.
Want the complete readiness checklist? Download the CRA Readiness Checklist.

Get the CRA Readiness Checklist

This is guidance to help you understand SBOM requirements under the CRA, not legal advice. For decisions specific to your product and business, confirm with the official sources we link or a qualified adviser.

Sources

[1]Regulation (EU) 2024/2847 (Cyber Resilience Act), on EUR-Lexretrieved 8 Jun 2026
[2]European Commission, Cyber Resilience Act summaryretrieved 8 Jun 2026

The CRA Brief

Subscribe to The CRA Brief

We watch Brussels so you don't. Plain-English CRA updates, free.

No spam. Unsubscribe anytime.