SBOM Requirements under the CRA

Why SBOM requirements matter under the CRA

SBOM requirements under the CRA turn component visibility into a compliance and security expectation. The point is not just to create a document, but to make the product’s software composition understandable enough to support vulnerability handling, secure maintenance, and accountability across the product lifecycle.

For organisations shipping products with digital elements, an SBOM becomes part of the evidence trail that the product can be analysed, updated, and supported over time. It helps answer basic but critical questions such as what is inside the product, which dependencies are inherited, and where exposure may exist if a component becomes known to be vulnerable.

What an SBOM under the CRA is used for

An SBOM under the CRA is a living inventory of software components, versions, and dependencies, not a static procurement artifact. Its practical value is that it supports downstream actions such as vulnerability correlation, patch planning, and internal assessment of whether a product build includes risky or obsolete components.

In practice, the SBOM also helps different teams speak the same language about product composition. Engineering, security, legal, and supply chain functions can use it to align on what was shipped, what changed, and what needs follow-up when a component issue emerges after release.

For a broader view of how SBOMs fit into software supply chain security and open source governance, see Open Source Security Guide.

How SBOMs support CRA compliance and product assurance

The CRA uses SBOMs as part of a wider secure product lifecycle approach. That means the SBOM matters both at development time and after release, because the product must remain supportable and maintainable while vulnerabilities, dependencies, and transitive components continue to evolve.

Good SBOM practice also improves traceability when products are updated, redistributed, or integrated into other environments. It gives manufacturers a structured way to show which components are present, which versions are in use, and where dependency risk may need to be managed through remediation or compensating controls.

For a direct regulatory view of the product obligations behind this requirement, use the EU Cyber Resilience Act.

What makes SBOM quality important

An SBOM only helps if it is accurate, current, and usable. Missing components, ambiguous naming, stale versions, or incomplete dependency relationships can make the record harder to trust and reduce its value for vulnerability response and assurance work.

Quality also affects how easily an organisation can compare releases, correlate disclosures to its own product line, and decide whether a reported issue is actually relevant. A well-formed SBOM should be specific enough to support analysis, but consistent enough to be maintained at scale across products and release cycles.

For practical guidance on structure, formats, and minimum elements, refer to the SBOM Guide.

Risk and Threat Considerations

SBOMs reduce uncertainty, but they do not eliminate dependency risk. If the inventory is incomplete or outdated, organisations may miss vulnerable components, misjudge exposure, or delay response when a supplier, library, or transitive dependency becomes a known problem.

Failure mechanism: Attackers and vulnerability researchers often target widely reused components, so an inaccurate SBOM can hide the presence of a risky dependency, weaken triage, and slow containment or patching when exploitation emerges.

Impact: The result can be prolonged exposure across many shipped products, weaker incident response, and a false sense of compliance because the documentation exists but does not reliably reflect the software actually in use.

Practitioner Guidance

Why practitioners should care: The CRA makes software composition a governed product attribute, so SBOM ownership should sit with the teams that can keep it accurate across builds, releases, and supported versions. Treat it as part of release discipline, not a one-time document.

What to watch for: Gaps between what engineering believes was shipped and what the SBOM records are a warning sign. Pay particular attention to transitive dependencies, package renames, duplicated component names, and release drift after hotfixes or emergency updates.

Practitioner takeaway: An SBOM only becomes useful when it is tied to release engineering, vulnerability intake, and post-release maintenance, so the control should be maintained as an operational source of truth rather than a compliance artifact.

Related resources from NHI Mgmt Group

• Why do SBOM gaps create compliance risk under the CRA?
• What breaks when product teams keep using standing privilege under the CRA?
• Who is accountable when a product cannot prove secure design under the CRA?
• How should organisations prove continuous resilience under CRA and DORA?