SBOM and the EU Cyber Resilience Act (CRA) – What Software Vendors Need to Know

The EU Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 — makes an SBOM mandatory for every “product with digital elements” sold in Europe. From 11 December 2027, manufacturers (including software publishers) must generate a machine-readable SBOM covering at least top-level dependencies, keep it up to date, and supply it to market-surveillance authorities on request. Non-compliance can trigger fines of up to €15 million or 2.5% of global turnover. This post unpacks what the CRA really requires, compares it with the US SBOM playbook, answers four practitioner questions, and shows where SafeDep’s open-source tool Vet slots in.

Introduction

The European Union’s Cyber Resilience Act (CRA) is a new regulation aimed at improving the cybersecurity of products with digital elements. It imposes mandatory security requirements on hardware and software products, requiring manufacturers (and others who place products on the EU market) to ensure security throughout the product’s lifecycle. From IoT gadgets to software applications, the CRA seeks to address the current inadequate security in many products and the lack of timely updates. Crucially for software vendors, the CRA introduces an obligation to produce a Software Bill of Materials (SBOM) for products: essentially an “ingredients list” of software components. This matters because it pushes vendors to maintain transparency about third-party components and known vulnerabilities, which in turn helps regulators and customers trust that products are built and maintained securely.

CRA Legislative Timeline

To understand the CRA’s journey and compliance deadlines, let’s look at the key milestones from proposal to enforcement. The table below highlights the legislative timeline of the CRA and when its provisions kick in:

The timeline allows a three-year transition, so organizations have until December 2027 to achieve full compliance, with some requirements (notably vulnerability disclosure processes) kicking in earlier in September 2026.

SBOM in the Cyber Resilience Act — What the Law Says

One of the most significant elements of the CRA for software producers is the Software Bill of Materials (SBOM) requirement. Here’s a breakdown of where and how SBOMs are addressed in the text of the CRA:

• Definition: The CRA defines a “software bill of materials” as “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”. In other words, an SBOM enumerates the software components (libraries, modules, packages, etc.) that make up a product.

• Obligation to produce an SBOM: According to Article 13 §1(h) + Annex I Part II (1), Manufacturers must “identify and document components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies.”

  This essentially requires an SBOM that lists the direct software components your product uses.

  Notably, listing only top-level dependencies is the minimum. You are not explicitly required by law to include nested sub-components, which is a relief for vendors concerned about disclosing deep dependency trees. (However, as we’ll discuss, including more detail can be good practice for security.)

• No public disclosure requirement: Importantly, the CRA explicitly states that “Manufacturers should not be obliged to make the SBOM public”. The EU lawmakers acknowledge that SBOMs can contain sensitive information (e.g. revealing proprietary components or potential vulnerabilities) and therefore stop short of requiring you to publish them openly.

• Possible future standards for SBOMs: The European Commission is empowered to specify SBOM formats and elements more precisely via implementing acts. CEN/CENELEC workshop notes (Apr 2025) confirm that a draft horizontal standard will flesh out Annex I requirements—including the SBOM schema—by mid-2026. For now, the law doesn’t dictate a specific format like SPDX or CycloneDX, but it does require a “commonly used, machine-readable format”.

  The key takeaway is to ensure your SBOM is structured and digital (not just a PDF list of components)

• Provide SBOM to authorities on request: Market surveillance authorities in the EU can request the SBOM to check compliance. Manufacturers must be able to supply the SBOM upon a “reasoned request” from regulators. This emphasizes that SBOMs are primarily seen as a regulatory transparency tool.

  You don’t have to automatically share them with each customer, but you do need them ready for inspection.

• Security focus: The CRA’s text makes clear that SBOMs are intended to improve cybersecurity. The recitals note that an SBOM “helps manufacturers and users track newly emerged vulnerabilities and cybersecurity risks”. The law positions SBOMs as a tool to enable situational awareness for authorities and facilitate vulnerability management (e.g., if a new critical flaw in a library is announced, those with SBOMs can quickly identify if they use that library).

Scope of CRA — Who Is Covered (and Who Is Exempt)

The scope of the CRA is broad — it covers virtually all “products with digital elements” that are placed on the EU market, whether hardware or software, if they have any direct or indirect connectivity to a device or network. This includes obvious items like computers, IoT devices, and software packages, but also less-obvious products like firmware, operating systems, developer libraries distributed commercially, and so on. If you are a manufacturer or developer selling a digital product in Europe, the CRA likely applies to you.

That said, the law carves out some important exemptions and clarifications:

• Open-Source Software (non-commercial): The CRA does not generally apply to free and open-source software that is not marketed as part of a commercial activity. This means open-source projects or developers publishing code for free, without any commercial sale or support, are outside the scope. The rationale is to avoid discouraging open-source collaboration.

  However, if an open-source component is integrated into a commercial product, the manufacturer of that product is responsible for its security (even though the open-source author isn’t directly liable).

  Furthermore, the supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should be considered to be making available on the market only if the component is monetised by its original manufacturer.

  The final text even introduces the concept of “open-source software stewards” for cases where organizations support open-source projects in a structured way, but these stewards have only light obligations (like maintaining a security policy) and do not bear the same responsibilities as manufacturers.

  Taking into account the importance for cybersecurity of many products with digital elements qualifying as free and open-source software that are published, but not made available on the market within the meaning of this Regulation, legal persons who provide support on a sustained basis for the development of such products which are intended for commercial activities, and who play a main role in ensuring the viability of those products (open-source software stewards), should be subject to a light-touch and tailor-made regulatory regime.

• Highly regulated sectors: Products that are already subject to equally rigorous EU cybersecurity rules are mostly excluded to avoid double regulation. For example, medical devices, automobiles, aviation products, and military equipment are exempt from the CRA because these sectors have their own laws that cover product security and safety.

  exclusions such as certain open-source software or services products that are already covered by existing rules, which is the case for medical devices, aviation and cars.

• Software-as-a-Service (SaaS) and cloud services: Pure services are generally outside the CRA’s scope. The CRA is about products (tangible or downloadable) placed on the market. Cloud services and SaaS offerings with no tangible product distributed are instead addressed by the NIS2 Directive on network and information security.

  So, if you run a cloud software service without supplying software to customers to install, CRA requirements like SBOMs do not directly apply. However, if you deliver any client software or appliance as part of the service, that delivered component would fall under CRA.

Open Questions for Practitioners (and SafeDep’s Take)

Even with the legislation in hand, practitioners still face some open questions about how to implement SBOM requirements in day-to-day practice. Here are four pressing questions, along with SafeDep’s perspective on each:

What exactly needs to be in our SBOM to satisfy the CRA?

The law mandates at least top-level components, but doesn’t list specific fields. Aim to include all the “minimum elements” you would for any robust SBOM. At a minimum, list each software component name, version, and supplier, and ideally the dependency relationship. Using a standard format like CycloneDX or SPDX will inherently cover the key fields (component ID, version, relationships, licenses, etc.). While CRA says top-level only, consider capturing deeper dependencies where feasible. It will improve your security posture.

The good news is that authorities aren’t expecting an exhaustive tree of every nested module and transitive dependencies; a comprehensive list of direct dependencies (third-party libraries, open-source packages, etc.) in the product will meet the requirement.

However, do keep an eye on forthcoming EU guidance – but if you follow NTIA/NIST’s SBOM guidance, you’ll likely exceed CRA’s baseline.

How often should we update SBOMs

The CRA implies SBOMs should be updated as part of technical documentation, but doesn’t dictate frequency. You should generate a fresh SBOM for every product release or update. In practice, integrating SBOM generation into your CI/CD pipeline is ideal. Every build that could go to production should produce an SBOM, so that you always know the exact components in that version. Also, if you patch or hotfix a component, update the SBOM accordingly. Regulators will want to see that your SBOM is current – an outdated SBOM is nearly as bad as none at all.

Many teams use tools (like SafeDep’s Vet or other SCA tools) to auto-generate SBOMs as part of the build process, ensuring continuous SBOM availability. Remember, the SBOM is part of “technical documentation” that must be kept for 10 years after a product is on the market. Hence, treat SBOM updates as a routine part of your development lifecycle.

What if some components are open source or from suppliers who don’t give SBOMs

In other words, how do we handle SBOM for third-party components we use?

Most open-source components won’t come with an SBOM from their maintainers – you’ll have to generate the entries for them yourself. Use your SCA tooling to identify all included OSS libraries and include those in your SBOM (the tool can pull info like name, version, license, etc.). For third-party commercial software or binary blobs, request an SBOM from those suppliers; if they can’t provide one, you may need to treat that component as a “black box” but at least list it in your SBOM as a top-level item. The CRA is ultimately holding you, the product manufacturer, responsible for knowing what’s in your product.

How will compliance actually be verified, and what about sensitive IP in the SBOM

Are we going to be audited? Will regulators or customers demand the SBOM routinely?

The enforcement model for CRA will likely be spot-checks or incident-driven. You might never be asked for your SBOM unless there’s a security incident or a random audit. However, from December 2027 onward, you should operate under the assumption that at any moment, a regulator could request your SBOM to verify you’re meeting requirements.

where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I.

The CRA does not force you to disclose source code or deep design secrets - only the identity of software components. If you’re concerned about confidentiality, note that authorities must treat SBOM info confidentially and only share aggregated, anonymized dependency data at the EU level.

SafeDep Vet: CRA-Aligned SBOM Generation and Policy-as-Code

SafeDep’s open-source tool Vet is designed to make SBOM and compliance management easier for teams preparing for regulations like the CRA. SafeDep Vet can automatically generate SBOMs in standard formats (including CycloneDX support), as part of your build pipeline, ensuring you have up-to-date SBOMs for every release. It’s as easy as:

vet scan -D ./project/ --report-cdx=sbom.json

Moreover, Vet provides policy-as-code capabilities, allowing you to encode your compliance rules and security policies (for example, “no high-severity vulnerabilities present” or “no GPL-licensed components in product”) and automatically enforce them. This means you can set up Vet to fail a build or alert your team if a new dependency violates your policies — effectively embedding CRA-related controls into CI/CD.