CRA SBOM Requirements and Vulnerability Management Guide

Last updated: 24 October 2026

The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) requires manufacturers of in-scope products with digital elements to draw up a software bill of materials (SBOM) and to handle vulnerabilities throughout the product’s support period. Below you will find the legal basis for the SBOM under the Cyber Resilience Act, its format and scope, its link to the Article 14 reporting obligation, and our service in this area.

Related CRA Modules

CRA Compliance Consulting
Scope, classification, gap analysis and compliance roadmap.

Article 14 Reporting Infrastructure
24/72-hour playbook, ENISA SRP registration, CSIRT set-up and drills.

Product Security Testing
Testing and evidence reports against EN 18031, ETSI EN 303 645 and IEC 62443 scenarios.

The SBOM under the CRA at a Glance

An SBOM (Software Bill of Materials) is a machine-readable inventory of the software components, versions and dependencies in a product.
CRA Annex I, Part II requires the manufacturer to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
The SBOM is part of the technical documentation; it does not have to be made public and is provided to the market surveillance authority upon a reasoned request.
The SBOM requirement applies in full from 11 December 2027. Article 14 reporting, however, started on 11 September 2026, so the SBOM needs to be operational already.
Alongside the SBOM, CVE matching, PSIRT operations, a coordinated vulnerability disclosure (CVD) policy and free security updates must also be in place.

What Is an SBOM?
Legal Basis for the SBOM under the CRA
SBOM Format and Scope
The SBOM and the Article 14 Reporting Obligation
Annex I, Part II: Vulnerability Handling Requirements
Open Source and the Supply Chain
Common Mistakes
SBOM and Vulnerability Management Setup with Nesil Teknoloji
Frequently Asked Questions
Official Sources

What Is an SBOM (Software Bill of Materials)?

An SBOM (Software Bill of Materials) is a structured inventory that lists the name, version, supplier and licence of the software components in a software or hardware product, together with the dependencies between them. It shows which open-source libraries, third-party components, operating system packages and embedded software (firmware) the product contains — essentially, a list of ingredients.

An SBOM is most useful in vulnerability management. When a new vulnerability (CVE) is published, a manufacturer with an SBOM can identify the affected products and versions much faster. A manufacturer without one has to search source code, build outputs and supplier documents by hand. Because the reporting deadlines under the Cyber Resilience Act (CRA) are short, this time difference directly affects compliance.

Legal Basis for the Software Bill of Materials (SBOM) Requirement under the CRA

The Cyber Resilience Act (CRA) sets out the SBOM obligation within its provisions on essential cybersecurity requirements (Annex I) and technical documentation (Annex VII).

Provision	Content
Annex I, Part II, (1)	The manufacturer identifies and documents vulnerabilities and components in the product, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies.
Article 13(8)	The manufacturer handles vulnerabilities effectively throughout the support period. The support period is at least five years, unless the product’s expected period of use is shorter.
Article 13(24)	The European Commission may specify the format and minimum elements of the SBOM by means of implementing acts. As of the date this page was updated, no such implementing act has been adopted.
Article 31, Annex VII (2)(b) and (8)	The SBOM is part of the description of vulnerability handling processes in the technical documentation and is provided upon a reasoned request of a market surveillance authority. The technical documentation is kept for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13(13)).

Does the SBOM have to be public? No. The CRA does not require the SBOM to be made public (Recital 77); it stays with the manufacturer and is provided to the authority on request. That said, EU buyers increasingly request SBOMs in supply contracts because of their own CRA obligations.

SBOM Format and Scope: What to Prepare and How

The CRA does not name a specific format; it requires a “commonly used and machine-readable” one. In practice, two standards are most widely used:

SPDX

Developed by the Linux Foundation and adopted as the international standard ISO/IEC 5962:2021. Strong in licence compliance and component identification.

CycloneDX

Developed by OWASP and standardised as ECMA-424. Designed with a security focus; it can also carry vulnerability and VEX information.

Minimum Information an SBOM Should Contain

Until the Commission’s implementing act is published, Germany’s BSI technical guideline TR-03183-2 and the US NTIA/CISA minimum SBOM elements serve as practical references. Taken together, they suggest recording the following for each component:

Component name and version
Supplier or author
Unique identifier (PURL or CPE, where available)
Dependency relationship (which component uses which)
Licence information and cryptographic hash
The tool, author and timestamp of SBOM creation

Scope: What Does “Top-Level Dependencies” Mean?

The CRA’s minimum requirement is to list the components the product uses directly (top-level dependencies). However, a significant share of vulnerabilities appears in indirect (transitive) dependencies. To meet reporting deadlines, it is recommended to generate an SBOM covering the full dependency tree wherever possible. For embedded products, firmware, operating system packages and binary components from suppliers should also be included.

The SBOM and the Article 14 Reporting Obligation

The SBOM obligation applies in full from 11 December 2027; however, the Article 14 reporting obligation has applied since 11 September 2026 and also covers legacy products on the EU market. When a manufacturer becomes aware of an actively exploited vulnerability in its product, it must submit an early warning within 24 hours, a vulnerability notification within 72 hours and a final report no later than 14 days after a corrective measure is available.

To answer “Is our product affected by this vulnerability?” within 24 hours, every product and version needs an up-to-date SBOM that is automatically matched against vulnerability sources. In other words, leaving SBOM preparation until 2027 puts the reporting obligation that already applies in 2026 at risk.

VEX: A vulnerability in a component does not necessarily mean the product is affected. VEX (Vulnerability Exploitability eXchange) records document whether a vulnerability is exploitable in the product. This speeds up internal assessment and keeps the information given to customers consistent.

Annex I, Part II: Vulnerability Handling Requirements

Cyber Resilience Act (CRA) Annex I, Part II defines, alongside the SBOM, the vulnerability handling processes the manufacturer must apply throughout the product’s support period:

Identifying components and vulnerabilities: Documenting the components and vulnerabilities in the product, including through an SBOM.
Remediation without delay: Addressing vulnerabilities without delay; where possible, providing security updates separately from functionality updates.
Regular testing: Reviewing product security through effective and regular tests.
Public disclosure: Publicly disclosing fixed vulnerabilities, including the affected product, impact, severity and remediation (disclosure may be delayed in justified cases).
Coordinated vulnerability disclosure (CVD) policy: Putting in place a policy that defines how vulnerability reports are received and handled.
Contact point: Providing a contact address for reporting vulnerabilities and facilitating information sharing.
Secure update distribution: Distributing updates securely and, where possible, automatically.
Free security updates: Providing security updates without delay and free of charge, accompanied by advisory messages explaining what users should do (unless otherwise agreed for tailor-made products).

Meeting these requirements calls for an organisation-level vulnerability management programme and product-level PSIRT (Product Security Incident Response Team) operations. Publishing a security.txt file and a clear CVD policy on your website to receive vulnerability reports is recommended practice.

Open-Source Components and the Supply Chain

In today’s products, most of the code comes from open-source components. The CRA holds the manufacturer responsible for the third-party and open-source components it integrates; these must be selected with due diligence so that they do not compromise the product’s security (Article 13(5)). When a manufacturer identifies a vulnerability in a component, it must report it to the person or entity that develops or maintains the component (Article 13(6)).

Supply-chain obligations work in two directions:

Upstream: You need to require component SBOMs and vulnerability information from your suppliers contractually; otherwise your own SBOM will be incomplete.
Downstream: If you supply components or software to an EU manufacturer, your buyer will ask you for an SBOM, VEX and a support-period commitment to meet its own CRA obligations.

Common Mistakes in CRA SBOM Preparation

Treating the SBOM as a one-off document: The SBOM must be regenerated for every release and patch; an outdated SBOM leads to wrong reporting decisions.
Looking only at source code: Components added during the build, in container images or in firmware are missed.
Matching vulnerabilities by hand: CVE tracking for hundreds of components cannot be sustained manually; automation is essential.
Forgetting legacy products: Article 14 also covers products already on the EU market; an inventory of older versions still on sale must be drawn up.
Keeping the SBOM separate from the PSIRT: Without a defined workflow between the team producing the SBOM and the team making reporting decisions, the 24-hour deadline is easily missed.

SBOM and Vulnerability Management Setup with Nesil Teknoloji

At Nesil Teknoloji, we set up SBOM and vulnerability management as a process integrated into your development and production pipeline. Our typical workflow:

Step	Content	Output
1. Product and component inventory	Identifying products, versions and support status on the EU market, including legacy products.	Product/version inventory
2. SBOM generation integration	Automated SBOM generation in SPDX or CycloneDX format in the CI/CD pipeline; firmware and binary component analysis.	Release-level SBOMs
3. Vulnerability matching	Continuous matching of SBOMs against CVE and other vulnerability sources; impact assessment with VEX.	Vulnerability monitoring dashboard
4. PSIRT and CVD	Vulnerability intake channel, security.txt, CVD policy, prioritisation and the Article 14 decision flow.	PSIRT procedure and policy
5. Validation testing	Static and dynamic analysis (SAST/DAST) with product security testing; linking findings to the SBOM.	Test report (technical file evidence)
6. Linking to the technical file	Adding the SBOM and vulnerability processes to the Annex VII technical file as evidence.	Technical file section

We can run this work as part of a CRA compliance consulting project or on its own. If the product is still in the design phase, we address it together with security by design principles.

Frequently Asked Questions

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is an EU regulation that sets common cybersecurity requirements for products with digital elements placed on the EU market. It entered into force on 10 December 2024. Article 14 reporting obligations have applied since 11 September 2026, and the essential requirements, including the SBOM, apply from 11 December 2027. The SBOM and vulnerability handling are among the core obligations set out in Annex I, Part II of the CRA.

What is an SBOM?

An SBOM (Software Bill of Materials) is a machine-readable inventory listing the name, version, supplier, licence and dependency relationships of the software components in a product. Under the CRA, it is the primary way to quickly determine whether a vulnerability affects a product.

Is an SBOM mandatory under the CRA?

Yes. CRA Annex I, Part II (1) requires manufacturers of in-scope products to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Under Annex VII, the SBOM is part of the technical documentation.

By when do we need to have an SBOM?

The CRA’s essential requirements, including the SBOM, apply in full from 11 December 2027. However, the Article 14 reporting obligation that started on 11 September 2026 requires an early warning within 24 hours for an actively exploited vulnerability, so in practice the SBOM needs to be operational already.

Do we have to share the SBOM with customers or the public?

No. Under CRA Recital 77, the SBOM does not have to be made public. Under Annex VII (8), it is provided upon a reasoned request of a market surveillance authority. EU buyers may, however, request the SBOM as a contractual requirement.

Which SBOM format should we use?

The CRA does not name a specific format; it requires a commonly used, machine-readable one. In practice, the two most widely used standards are SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424).

Has the European Commission specified the SBOM format?

Not yet. CRA Article 13(24) empowers the Commission to specify the format and minimum elements of the SBOM by implementing acts; as of the date this page was updated, no such implementing act has been adopted. In the meantime, BSI TR-03183-2 is used as a practical reference.

Is listing only direct dependencies enough?

The minimum requirement of CRA Annex I, Part II (1) is top-level (direct) dependencies. However, because a significant share of vulnerabilities appears in indirect dependencies, an SBOM covering the full dependency tree is recommended in order to meet reporting deadlines.

What is VEX, and is it required for the CRA?

VEX (Vulnerability Exploitability eXchange) is a record documenting whether a vulnerability in a component is exploitable in the product. The CRA does not require VEX by name, but it is widely used to meet the vulnerability handling and information-sharing obligations in Annex I, Part II.

What is the penalty for not having an SBOM?

The SBOM is part of the Annex I essential requirements. Under CRA Article 64(2), infringements of Annex I and of the obligations in Articles 13 and 14 can lead to administrative fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

How do the SBOM and vulnerability management relate?

The SBOM shows which components are in the product; vulnerability management determines how security flaws in those components are monitored and fixed. CRA Annex I, Part II requires both together: the SBOM, vulnerability remediation, a CVD policy, secure update distribution and free security updates throughout the support period.

Author: Afra Görgen

Official Sources

Preliminary Meeting on CRA SBOM and Vulnerability Management

Let’s assess your SBOM and vulnerability management readiness together, based on your product inventory and current development pipeline.

Request a Quote