SBOM TotalMulti-engine analysis

Guide, with primary sources

SBOM evidence for the EU Cyber Resilience Act

The Cyber Resilience Act makes a software bill of materials and a vulnerability-handling process part of how you put a product with digital elements on the EU market. This guide sets out exactly what the regulation says, quotes the text, links every claim to its source, and shows how to produce the evidence.

This is an engineering guide, not legal advice, and it makes no certification claims. It cites the regulation and official guidance so you can verify every statement against the source.

Scan an SBOMHow the scan works

23 Oct 2024

Regulation (EU) 2024/2847 adopted

10 Dec 2024

CRA enters into force

11 Sep 2026

Vulnerability and incident reporting obligations apply

11 Dec 2027

Essential requirements and technical documentation apply

Dates from the regulation and the European Commission. Regulation (EU) 2024/2847, EC: CRA reporting.

The regulation

What the CRA is, and who it applies to

The Cyber Resilience Act is Regulation (EU) 2024/2847, on horizontal cybersecurity requirements for products with digital elements. It sets cybersecurity rules for the design, development and lifecycle of hardware and software placed on the EU market, and is enforced through CE marking and conformity assessment. See the European Commission overview.

A "product with digital elements" covers software and hardware that connects to a device or network, which is why it squarely affects embedded and IoT vendors. Obligations fall mainly on manufacturers, with related duties for importers and distributors.

Annex I, Part II, point (1)

The SBOM requirement, in the regulation's own words

The SBOM obligation sits in the vulnerability-handling requirements of Annex I. The text requires manufacturers to:

"identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products"
Regulation (EU) 2024/2847, Annex I, Part II, point (1). EUR-Lex.

Three things follow directly from that wording:

  • Top-level dependencies are the floor, not the ceiling.The regulation says "at the very least" the top-level dependencies. Deeper, transitive components are where most known vulnerabilities actually live, so a fuller SBOM is better evidence even though it is not the legal minimum.
  • Machine-readable. A PDF or a spreadsheet is not enough; the SBOM has to be in a format tools can parse.
  • Not public. The CRA does not require you to publish the SBOM. It belongs in the technical documentation and is provided to market surveillance authorities on request.

Annex I, Part II

Vulnerability handling is the bigger obligation

The SBOM is one item in a list of vulnerability-handling requirements that run for the whole support period. Under Annex I, Part II, manufacturers must, among other duties:

  • Identify and document components and vulnerabilities (the SBOM point above).
  • Address and remediate vulnerabilities without delay, including by providing security updates.
  • Apply effective and regular security tests and reviews.
  • Once a security update is available, share and publicly disclose information about fixed vulnerabilities.
  • Put in place a coordinated vulnerability disclosure policy and a contact address for reporting.
  • Distribute security updates securely, and where feasible without delay and free of charge, with advisory messages.

Source: Regulation (EU) 2024/2847, Annex I, Part II. The SBOM exists to make these duties possible: you cannot patch or report on a component you have not inventoried.

Article 14

The 24 / 72 / 14 reporting clock

Separately from the essential requirements, Article 14 sets mandatory reporting for actively exploited vulnerabilities and severe incidents, through the ENISA Single Reporting Platform:

24h

Early warning

after becoming aware of an actively exploited vulnerability

72h

Notification

a fuller vulnerability notification

14d

Final report

after a corrective measure is available

These obligations apply from 11 September 2026. Source: European Commission: CRA reporting, Regulation (EU) 2024/2847, Article 14.

What a usable SBOM contains

Minimum elements: NTIA 2021 and the CISA 2025 draft

The CRA does not enumerate SBOM fields, so the working baselines come from the US. The NTIA Minimum Elements (2021) defined seven data fields that every SBOM should carry. These are exactly the fields SBOM Total scores for quality and NTIA conformance.

NTIA 2021 fieldWhat it is
Supplier NameWho creates, defines and identifies the component
Component NameName the supplier gives the unit of software
VersionIdentifier for a change in the software
Other Unique IdentifiersLookup keys such as PURL or CPE
Dependency RelationshipHow an upstream component relates to the software
Author of SBOM DataWho created the SBOM entry
TimestampDate and time the SBOM was assembled

CISA published a 2025 Minimum Elements draft that updates this baseline. It is a pre-decisional public-comment draft (Federal Register request for comment), not final policy, but it signals the direction: it adds a component hash, a license field, and tool name and generation context (how, when and by whom the SBOM was made), and renames Supplier Name to Producer Name. SBOM Total already reports hash and license coverage, so you are ahead of that curve.

Formats

CycloneDX or SPDX

Because the CRA only says "commonly used and machine-readable," the two formats that satisfy it in practice are CycloneDX and SPDX. Both encode the NTIA fields and the dependency graph. For why the dependency graph matters to security, the OWASP Dependency Graph SBOM cheat sheet is a good reference: it lets you show why a vulnerable transitive component is present.

From SBOM to evidence

How SBOM Total helps you produce the evidence

SBOM Total does not certify anything. What it does is turn an SBOM into the verifiable facts the obligations above call for:

Inventory and SBOM quality

Normalizes CycloneDX, SPDX and Syft, scores coverage of the NTIA fields, and checks NTIA minimum elements, so the SBOM itself holds up.

Vulnerability handling

Correlates components against multiple engines, flags CISA KEV known-exploited and EPSS probability, and triages real risk from noise.

Decisions you can defend

VEX statements record whether each CVE actually affects the product, which is the input the disclosure and reporting duties need.

Exports for the technical file

JSON, CSV, PDF, DOCX, Markdown and VEX exports give you artifacts to attach to the technical documentation kept for authorities.

The SBOM and these reports are inputs to several CRA obligations. They do not by themselves make a product compliant: conformity is a broader assessment. This tool documents facts and prioritizes risk, and makes no certification claims.

FAQ

Common questions

Does the EU Cyber Resilience Act require an SBOM?

Yes. Annex I, Part II, point (1) of Regulation (EU) 2024/2847 requires manufacturers to identify and document the components in a product with digital elements by drawing up a software bill of materials in a commonly used and machine-readable format, covering at least the top-level dependencies.

Does the SBOM have to be made public under the CRA?

No. The CRA does not require the SBOM to be published. It must be included in the product's technical documentation and made available to market surveillance authorities on request.

Which SBOM format does the CRA mandate?

The CRA does not mandate a specific format; it says a commonly used, machine-readable format. Harmonised standards are still being developed, so in practice teams use CycloneDX or SPDX.

When do the CRA obligations apply?

The CRA entered into force on 10 December 2024. The vulnerability and incident reporting obligations apply from 11 September 2026, and the bulk of the obligations, including the essential requirements and technical documentation, apply from 11 December 2027.

What are the CRA vulnerability reporting deadlines?

Under Article 14, a manufacturer must send an early-warning notification within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available. Reports go through the ENISA Single Reporting Platform.

Does an SBOM make my product CRA compliant?

No single artifact makes a product compliant. An SBOM and a vulnerability-handling process are necessary inputs to several CRA obligations, but compliance is a broader conformity assessment. This page and SBOM Total help you produce evidence; they make no certification claims.

Sources

References

NextScan your SBOM and export the evidence