26 October 2026, 10:42 PM
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:
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.
Source: https://qualysec.com/eu-cra-sbom-requirements/
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.
Source: https://qualysec.com/eu-cra-sbom-requirements/