Quick summary

A software bill of materials, or SBOM, is a machine-readable inventory of every component in a product, and the Cyber Resilience Act makes it mandatory for products with digital elements. Building one is less about a document and more about a repeatable process that keeps the inventory accurate across a product's life.

Introduction

Modern software is assembled, not written from scratch. A typical product pulls in open-source libraries, frameworks and components, each with its own dependencies, so the question regulators now ask is simple but hard to answer: what is actually inside your product?

A software bill of materials answers it. Under the Cyber Resilience Act, producing one stops being good practice and becomes a legal requirement for products sold in the EU. Understanding what an SBOM must contain, and how to generate and maintain it, is now part of shipping connected products. A solid SBOM is one of the building blocks of EU compliance.

What an SBOM is

A software bill of materials is a machine-processable inventory of the components that make up a piece of software. Germany's Federal Office for Information Security describes it as the electronic equivalent of a parts list, recording the components used in a product and their relationships (BSI, 2025).

The comparison to a physical bill of materials is apt. Just as a manufacturer must know every part in a device to manage recalls and quality, a software producer must know every component in a product to manage vulnerabilities. The crucial difference is that software dependencies are layered: a component you include brings its own dependencies, which bring theirs, so a complete SBOM must reach beyond the obvious top level.

An SBOM is only useful if it captures transitive dependencies, because the vulnerability that hurts you is rarely in the component you chose directly.

This is why a list of direct dependencies is not enough. The Log4Shell incident demonstrated that a flaw buried deep in a widely used component can expose countless products whose developers never knowingly installed it.

Takeaway: An SBOM is a machine-readable inventory of all software components and their relationships, and it must capture transitive dependencies, not just the components a team chose directly.

Why the Cyber Resilience Act makes SBOMs mandatory

The Cyber Resilience Act requires manufacturers of products with digital elements to produce and maintain an SBOM as part of their cybersecurity obligations. The regulation entered into force in December 2024, with the main obligations applying from 11 December 2027, and it empowers the European Commission to specify the format and elements of the SBOM through implementing acts (European Commission, 2025).

The reason this matters is that the SBOM is not an isolated requirement. It is the foundation for the CRA's vulnerability handling and reporting duties, which begin earlier, in September 2026. A manufacturer cannot determine whether one of its products is affected by a newly exploited vulnerability, let alone report it on time, without knowing what the product contains.

Germany has moved ahead of the detail with BSI TR-03183, a technical guideline that sets out concrete SBOM requirements as an interpretation of the CRA ahead of harmonised European standards (BSI, 2025). The implication for manufacturers is that the direction of travel is already clear enough to act on, even before the final standards land.

Takeaway: The CRA makes SBOMs mandatory for products with digital elements, and because they underpin the vulnerability reporting that begins in September 2026, building the capability cannot wait for the 2027 deadline.

Formats and minimum elements

An SBOM is only interoperable if it follows a recognised, machine-readable format. The CRA calls for a commonly used, machine-readable format without mandating one, and in practice two dominate:

• CycloneDX, created by the OWASP Foundation, compact and strong on security and vulnerability use cases
• SPDX, originating at the Linux Foundation and standardised as ISO/IEC 5962, strong on detailed licence metadata

Content matters as much as format. The baseline for SBOM content traces to the minimum elements published by the US NTIA in 2021, covering fields such as supplier name, component name, version, unique identifiers, dependency relationships, the SBOM author and a timestamp. In 2025, the US CISA proposed an update expanding these elements with fields such as component hashes and licences to reflect a more mature ecosystem (CISA, 2025).

European requirements are converging on the same shape. BSI TR-03183 mirrors this structure while adding stronger integrity requirements, which signals where CRA-aligned SBOMs are heading. The interpretive point is that producing an SBOM in CycloneDX or SPDX, with the recognised minimum fields, is the safest way to stay aligned as the formal standards crystallise.

Takeaway: CycloneDX and SPDX are the dominant machine-readable formats, and aligning SBOM content with the NTIA and emerging CISA and BSI minimum elements keeps a manufacturer aligned as CRA standards finalise.

How to build and maintain an SBOM

The most important shift is to treat an SBOM as an output of the build process, not a document written by hand. A manually maintained inventory is obsolete the moment a dependency changes, which in active development is constant.

The practical approach is to generate the SBOM automatically within the development pipeline, so every build produces a fresh, accurate inventory. This is where embedding SBOM generation into the software development process pays off, because an SBOM produced by the same pipeline that builds the product stays in step with reality rather than drifting away from it. A workable practice typically includes:

• Generating the SBOM automatically in continuous integration for every release
• Capturing all dependencies, direct and transitive, across the languages and package managers in use
• Producing the output in a recognised format such as CycloneDX or SPDX
• Versioning each SBOM so it matches the exact product release it describes
• Maintaining SBOMs across the product's full support period, not just at launch

The reason automation is non-negotiable is scale. A product may contain hundreds or thousands of components, and only an automated, repeatable process can keep an accurate inventory across frequent releases and a support lifetime measured in years.

Takeaway: An SBOM should be generated automatically in the build pipeline for every release, capturing transitive dependencies in a recognised format and maintained across the entire support period.

Turning an SBOM into compliance

An SBOM on its own is an inventory, not protection. Its value is realised when it is connected to vulnerability management, so that a new vulnerability disclosure can be checked against the inventory to identify which products are affected.

This is the link that satisfies the CRA's deeper intent. By matching SBOM components against vulnerability databases, a manufacturer can answer the question the regulation forces, whether a given product is affected by an actively exploited flaw, and act within the required reporting timelines. Pairing an SBOM with a VEX, or Vulnerability Exploitability eXchange document, refines this further by recording whether a present vulnerability is actually exploitable in the product.

The strategic lesson is that the SBOM is the foundation of CRA compliance rather than the whole of it. Built into the pipeline and connected to vulnerability monitoring, it turns the abstract obligation to manage product security into a concrete, repeatable capability that scales across a portfolio.

Takeaway: An SBOM becomes compliance only when linked to vulnerability monitoring, letting a manufacturer identify affected products and meet the CRA's reporting timelines.

Conclusion

The Cyber Resilience Act has turned the software bill of materials from a transparency nicety into a legal foundation for selling connected products in the EU. The shift it demands is from documents to process: an SBOM generated automatically, kept current, and tied to vulnerability management.

For manufacturers across the EU, the practical message is to start now rather than waiting for the final harmonised standards. The formats and minimum elements are already clear enough, the reporting obligations arrive in 2026, and the teams that build SBOM generation into their pipelines today will absorb the CRA far more smoothly than those who treat it as a last-minute document.

FAQ

What is an SBOM and why does the Cyber Resilience Act require one?

An SBOM, or software bill of materials, is a machine-readable inventory of every software component in a product, including direct and transitive dependencies, with details such as version, supplier and relationships. The Cyber Resilience Act requires manufacturers of products with digital elements to produce and maintain one, because it is the foundation for identifying and reporting vulnerabilities, which the regulation also mandates.

What format should an SBOM use under the CRA?

The CRA calls for a commonly used, machine-readable format without naming a specific one. In practice, two formats dominate: CycloneDX, created by the OWASP Foundation and strong on security use cases, and SPDX, from the Linux Foundation and standardised as ISO/IEC 5962, strong on licence metadata. Both are widely accepted, and Germany's BSI TR-03183 guideline maps requirements to both.

What information must an SBOM contain?

The baseline traces to the US NTIA's 2021 minimum elements, including supplier name, component name, version, unique identifiers, dependency relationships, the SBOM author and a timestamp. A 2025 CISA update proposes expanding these with fields such as component hashes and licences. European requirements, including BSI TR-03183, are converging on a similar, slightly stronger set of fields.

How should an SBOM be generated and maintained?

An SBOM should be generated automatically within the build pipeline so that every release produces a fresh, accurate inventory covering all direct and transitive dependencies. It should be produced in a recognised format, versioned to match the exact release, and maintained across the product's full support period. Manual SBOMs do not scale and quickly become inaccurate as dependencies change.

Sources

• The Cyber Resilience Act, summary of the legislative text – European Commission – 2025 – https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• Technical Guideline BSI TR-03183, cyber resilience requirements for manufacturers and products – BSI – 2025 – https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html
• 2025 Minimum Elements for a Software Bill of Materials (SBOM) – CISA – 2025 – https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom