EU Cyber Resilience Act: SBOM Requirements Explained

If you manufacture products with digital elements sold in the EU, the EU Cyber Resilience Act (CRA) requires you to prepare a software bill of materials (SBOM) in a commonly used, machine-readable format that covers, at minimum, the product’s top-level dependencies. The SBOM is part of the product’s technical documentation, so market surveillance authorities can ask for it, but you do not have to publish it.

When a vulnerability in one of your components is reported or actively exploited, you use the SBOM to find which shipped versions contain it. For an actively exploited vulnerability, you have 24 hours to send an early warning. To describe corrective or mitigating measures in a notification within 72 hours, you need to know which requirements and risk controls depend on that component.

Below, you’ll find each CRA SBOM requirement and what it means, which products and dates it applies to, and how to trace each component to the requirements, risk controls and releases behind that notification.

What Are the CRA SBOM Requirements?

As the manufacturer of a product with digital elements, you have five SBOM requirements under the CRA:

• Draw up an SBOM: You identify and document the components contained in your product, including by drawing up an SBOM (Annex I, Part II, point 1). The SBOM lists components, and you record each vulnerability’s status separately, against that list.
• Pick a commonly used, machine-readable format: You choose the format for now. The two most common are CycloneDX and Software Package Data Exchange (SPDX). The European Commission can later set the SBOM’s format and data elements by implementing act (Article 13(24)).
• Cover at least the top-level dependencies: Those are the components your product depends on directly (Annex I, Part II, point 1).
• Act on it when a vulnerability is reported: The component list is where you find which of your products contain a reported component. You then address and remediate the vulnerability without delay, including by providing security updates (Annex I, Part II, point 2).
• Keep it current in the technical documentation: You keep the technical documentation, SBOM included, up to date where appropriate for at least the support period (Article 31(2)). The support period is at least five years, unless the product is expected to be in use for less time (Article 13(8)).

You can check your own SBOM process against these five before you choose a generator or format. For the CRA’s other Annex I obligations, see the Jama Software® guide on what the CRA requires.

Which Products and Which Companies Does the CRA Apply To?

The CRA covers any product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)). Products with digital elements are software or hardware products, their remote data processing solutions, and components placed on the market separately.

The SBOM duty falls on whoever markets the product under its own name or trademark, whether for payment or free of charge. An importer or distributor becomes a manufacturer, with the same obligations, if it rebrands a product or substantially modifies one already on the market (Article 21). Anyone else who substantially modifies a product and makes it available takes on the same duties (Article 22(1)).

Products covered by the EU medical device, in-vitro diagnostic, vehicle type-approval, aviation and marine equipment rules are excluded, along with like-for-like spare parts and products made exclusively for national security or defence. Free and open-source software is in scope only when it is made available in the course of a commercial activity. For how the CRA’s SBOM duty compares with other regulations, see Jama Software’s chapter on the SBOM.

Every product in scope needs an SBOM, whatever its class. An important product listed in Annex III and a plain connected sensor both need one. Being on the Annex III or Annex IV list changes only how conformity is assessed, not whether you need an SBOM. The European Union Agency for Cybersecurity (ENISA) states that an SBOM is needed for every product with digital elements placed on the EU market.

What Format and Fields Do You Need in a CRA SBOM?

The CRA requires only that the SBOM cover at least the top-level dependencies in a commonly used, machine-readable format. Field lists, format versions and the rule of one SBOM per software version come from technical guidance that is not EU law.

Which Formats Count as Commonly Used and Machine-Readable?

Either SPDX or CycloneDX should qualify. They are the two formats in common use, and the CRA leaves the choice of format to you, so neither is a legal requirement.

Germany’s Federal Office for Information Security (BSI) sets a stricter target in Technical Guideline TR-03183-2. Version 2.1.0, the current one, requires any new or updated SBOM to be valid CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher. TR-03183 is BSI’s interpretation of the CRA requirements, so following it is voluntary and gives you no presumption of conformity.

BSI expects harmonised European standards to replace its guideline. The EN 40000 series for the CRA is in drafting and approval, and no part had been cited in the Official Journal by October 2026, so none yet gives a presumption of conformity. EN 18031, which is sometimes named alongside them, is a harmonised standard under the Radio Equipment Directive, not the CRA.

What Goes in Each CRA SBOM Entry?

A typical entry records the component’s name, version, creator, a unique identifier and its relationship to the product, following the National Telecommunications and Information Administration (NTIA) baseline and BSI’s guideline. For a single top-level dependency, an entry holds the values below, with the matching field names from the CycloneDX documentation and the SPDX 3.0.1 Package class. No format in the table is legally required.

Field	Example value	CycloneDX	SPDX 3.0.1
Component name	web-framework	name	name
Version	1.0.0	version	packageVersion
Component creator	[email protected]	components[].manufacturer	originatedBy
Unique identifier	pkg:maven/org.acme/[email protected]	purl	packageUrl
Relationship to the product	Direct dependency: the product’s entry lists this component under dependsOn	dependencies[].dependsOn	Relationship with relationshipType dependsOn

A package URL or Common Platform Enumeration (CPE) name is the look-up key you compare with Common Vulnerabilities and Exposures (CVE) records and supplier advisories when you receive a report. If you follow BSI’s guideline, you also record licence fields, a SHA-512 hash of the deployable component and the SBOM’s own creator and timestamp, none of which the CRA requires.

Do You Have to Publish Your SBOM?

No, you don’t have to publish your SBOM. Manufacturers aren’t obliged to make the SBOM public (Recital 77). Outside conformity assessment, a market surveillance authority can see it by making a reasoned request, when it needs the SBOM to check compliance with the essential cybersecurity requirements (Annex VII, point 8).

Sharing it with users is your decision. If you do, tell them where they can access it (Annex II, point 9). A shared SBOM can help users identify vulnerabilities in your product’s components (Recital 77).

You don’t need a separate SBOM for each unit you ship. Every unit running the same software version can share one SBOM.

When Do the SBOM Obligations Apply?

The SBOM duty applies from 11 December 2027, along with the technical documentation requirements and the rest of the Regulation (Article 71(2)). Reporting of actively exploited vulnerabilities and severe incidents under Article 14 has applied since 11 September 2026. A product placed on the market before 11 December 2027 needs no SBOM unless it is substantially modified from that date (Article 69(2)).

The exemption applies unit by unit, so any unit of an unchanged model placed on the market from 11 December 2027 needs an SBOM. Reporting still applies to the earlier units, because the Article 14 reporting duty also covers products placed on the market before that date. So you have to report an actively exploited vulnerability in a unit already on the market now, even if that unit never needs an SBOM.

A substantial modification is a change after the product is placed on the market that affects compliance with the essential requirements or changes the intended purpose the product was assessed for (Article 3(30)). A security update that reduces risk without changing the intended purpose is not a substantial modification. A feature update that changes the product’s original intended functions can be (Recital 39).

How Do You Use the SBOM When You Have to Report a Vulnerability?

When an actively exploited vulnerability starts the Article 14 deadlines, you look up the affected component in the SBOM to find which shipped versions contain it. To identify affected versions and describe corrective measures in time, you also need each component linked to the requirements, risk controls and releases that depend on it.

What Must You Report, and By When?

You have 24 hours to submit an early warning after you become aware of an actively exploited vulnerability or a severe incident (Article 14). You submit each notification simultaneously to the computer security incident response team (CSIRT) designated as coordinator and to ENISA.

Once a vulnerability is fixed and its security update is available, you also have to share and publicly disclose information about it, including its severity (Annex I, Part II, point 4). Article 14 notifications go through ENISA’s single reporting platform, which launched on 11 September 2026. Each report has its own deadline:

Report	Actively exploited vulnerability	Severe incident
Early warning	Within 24 hours of becoming aware	Within 24 hours, including whether the cause is suspected to be unlawful or malicious
Notification	Within 72 hours, with general information on the exploit and corrective or mitigating measures	Within 72 hours
Final report	No later than 14 days after a corrective or mitigating measure is available	Within one month of the incident notification

Both the early warning and the notification fall within 72 hours of becoming aware, while the final report waits until a corrective or mitigating measure is available. So the records you need fastest are the ones that name affected versions and measures for the 72-hour notification.

What Can You Learn From the Component List?

The component list tells you whether a reported component is in a shipped version, which is usually the first thing the 72-hour notification needs. The list does not tell you whether the vulnerability affects your product.

The SBOM stays the same while the software is unchanged, but what is known about its components’ vulnerabilities keeps changing. To find out whether your product is affected, compare the SBOM against CVE records and component manufacturers’ advisories, then add status information such as a security advisory or a Vulnerability Exploitability eXchange (VEX) statement.

VEX statements are scoped to product versions, with four statuses: not affected, affected, fixed and under investigation. The US Cybersecurity and Infrastructure Security Agency (CISA) says that VEX does not require an SBOM and an SBOM does not require VEX. VEX exists because an upstream vulnerability may not affect a downstream product that never calls the vulnerable code.

Why Does the SBOM Need to Trace to Requirements and Releases?

To identify affected versions and describe corrective or mitigating measures in a notification, you need links from each component to the requirements, risk controls and release baseline that depend on it. You also have to document known vulnerabilities and relevant third-party information and, where applicable, update the risk assessment (Article 13(7)).

ENISA describes the record you need in three parts: a tracking register of issues with affected components and versions, an SBOM or dependency inventory for each release, and a feedback loop from significant vulnerabilities into the risk assessment and security requirements. Tracing a package URL by hand is slow when those records are kept on a build server, in a spreadsheet and in a risk file.

Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development. Linking component items to those records in Jama Connect lets you start an impact analysis from the affected component. Because the reporting period starts when you become aware of a vulnerability, that tracing has to be quick. With Jama Connect, Össur reports an impact analysis review in five minutes against hours.

How Do You Keep the SBOM Current as the Product Changes?

Current guidance calls for a new SBOM for every software version and every component update. BSI asks for a separate SBOM for each software version. NTIA likewise expects a new SBOM per release. CISA calls for a new SBOM when a component is updated, ideally shown by a new version string.

Where a substantial modification may affect compliance, or the intended purpose changes, you have to verify compliance and, where applicable, run a new conformity assessment (Recital 41). You also update the cybersecurity risk assessment in the technical file where applicable. So after any component change, review the dependency manifest and the requirements and risk items that trace to that component.

You can organise the review of each software version around component records and release baselines:

• Component record: You can hold each top-level component as an item in the same record as the requirements it implements and the risk controls that depend on it. Each release then gets a baseline, which the SBOM for that version refers to.
• Change review: When a component version changes, you review each requirement, test and risk item linked to it and record the decision against the new baseline.

Reports to component suppliers can go in the same record. When you find a vulnerability in an integrated component, you have to report it to the component’s manufacturer or maintainer. IEC 62443-4-1 sets secure development lifecycle requirements, including defect management. If you already work to that standard, which Jama Software’s IEC 62443 chapter introduces, you may be able to record the supplier report under its defect management practices.

How Jama Connect Supports EU Cyber Resilience Act SBOM Traceability

For SBOM traceability, apply Jama Software’s Live Traceability™ approach by linking component items to the security requirements, risk items and tests that depend on them in Jama Connect. When a linked component item changes, suspect links flag the downstream items for review. A baseline records the state of those items for a release, which the SBOM for that version can refer to.

For consumer electronics products, the out-of-the-box Consumer Electronics Solution in Jama Connect integrates cybersecurity, safety and risk management, so you can record the controls and requirements linked to each component. Release baselines and item version histories in Jama Connect cover the requirements, risk items and tests linked to SBOM components. Jama Connect doesn’t generate the SBOM; your build pipeline generates it.

Getting Your EU Cyber Resilience Act SBOM Ready Before December 2027

Reporting already applies, but the SBOM duty starts on 11 December 2027. Use the time before then to choose an SBOM generator and format.

Then take one shipped version and test whether its records get you from a matched component to a draft notification before a real vulnerability starts the reporting period. A free 30-day trial of Jama Connect includes full platform access, guided onboarding and sample projects, so you can test links between one product’s components and its requirements and risk controls before the next vulnerability report arrives.

Frequently Asked Questions About EU Cyber Resilience Act SBOM

Does the SBOM have to include transitive dependencies?

No. The CRA requires only the top-level dependencies, and no adopted EU text asks for more. Listing transitive dependencies does make vulnerability matching more complete. To choose your inventory depth, compare a top-level list with a fuller inventory for one release and check which additional components you can match to supplier advisories.

Can a market surveillance authority ask for SBOMs across a whole product category?

Yes. The Administrative Cooperation Group (ADCO), which brings together the national market surveillance authorities for the CRA, can decide to run a Union-wide dependency assessment for specific categories of products. Market surveillance authorities may then request the relevant SBOMs from manufacturers in those categories and pass anonymised, aggregated information about software dependencies to ADCO.

How long do you have to keep the SBOM?

The technical documentation, SBOM included, has to stay at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer. Authorised representatives and importers have parallel duties to make the documentation available on request.

Does a small manufacturer get any relief on the reporting deadlines?

Partly. Microenterprises and small enterprises can’t be fined for missing the 24-hour early warning deadline, according to the Commission’s summary of the Regulation. Their reporting duty still applies.

YOU MAY ALSO LIKE