CRA topic guide

Software supply chain security under the CRA

Last updated · 8 Jun 2026

Most products are built mostly from other people's code. The CRA makes you responsible for the security of that supply chain: you must exercise due diligence on the components you integrate, track them with an SBOM, and handle their vulnerabilities as if they were your own. This is central to the Annex I vulnerability-handling requirements.

TL;DR

  • You are responsible for the security of third-party and open-source components you ship.
  • Due diligence on integrated components is a CRA obligation, evidenced by an SBOM.
  • Vulnerabilities in dependencies must be handled like your own - fixed without delay.
  • Open-source software stewards get tailored, lighter duties and cannot be fined.
Get the CRA ChecklistCheck if you are in scope

Overview

What it is

Software supply chain security is about managing the risk that comes from everything you did not write yourself: open-source libraries, commercial SDKs, build tools and the infrastructure that assembles your product. Attacks increasingly target this layer - a single compromised dependency can reach thousands of downstream products. The CRA responds by making manufacturers accountable for the components they integrate, and by giving the open-source ecosystem a proportionate role through the new "open-source software steward" category.

The regulation

What the CRA requires

  • When integrating third-party components, manufacturers must exercise due diligence to ensure those components do not compromise the product, and that vulnerabilities in them can be addressed (Art. 13).
  • The SBOM (Annex I, Part II(1)) is the mechanism for knowing and tracking what is in your supply chain.
  • Vulnerabilities in integrated components must be handled and remediated as part of the product's vulnerability handling.
  • Open-source software stewards have tailored obligations (Art. 24) - including a cybersecurity policy and cooperation with authorities - and are not subject to fines.

How to comply

How to comply

  1. Inventory every third-party and open-source component with an automated SBOM.
  2. Do due diligence before adopting a dependency: maintenance health, security track record, licence.
  3. Continuously monitor components for new vulnerabilities and end-of-life status.
  4. Have a plan to patch, replace or mitigate a vulnerable dependency quickly.
  5. Secure the build pipeline itself (signing, provenance, least-privilege CI).
  6. Engage upstream: report and, where you can, contribute fixes to open-source you rely on.

Watch out

Common mistakes

  • Adopting dependencies with no review of their security or maintenance status.
  • Having no inventory, so a headline CVE triggers a frantic manual hunt.
  • Ignoring transitive dependencies, where much of the real risk hides.
  • Assuming "it's open source, so it's someone else's problem" - as the integrator, it is yours.

FAQ

Common questions

Am I liable for vulnerabilities in open-source code I use?
As the manufacturer placing the product on the market, you are responsible for handling vulnerabilities in the components you integrate, including open-source ones. The upstream open-source project itself is generally not the liable party.
What is an open-source software steward?
A new CRA category for organisations (e.g. foundations) that sustainably support open-source used in commercial products. They have lighter, tailored duties under Art. 24 and cannot be fined.
How does an SBOM help supply chain security?
It gives you a precise, machine-readable inventory so that when a vulnerability is disclosed in any component, you can immediately tell which of your products are affected and act.

Related guides

More CRA topic guides

SBOM

SBOM (Software Bill of Materials) under the CRA

An SBOM is an "ingredients label" for your software: a machine-readable inventory of components and dependencies.

Security by design

Security by design under the CRA

Security by design means building in security from the first design decision, proportionate to the product's risk.

Secure by default

Secure by default under the CRA

Secure by default means the out-of-the-box configuration is the safe configuration.

Back to the CRA overview or see all guides.

This is guidance, not legal advice

This guide explains how the Cyber Resilience Act approaches software supply chain security, but it is not legal advice. For decisions specific to your business or product, confirm with the official sources we link or a qualified adviser.

Sources

  1. [1]European Commission - CRA legislative summaryretrieved 8 Jun 2026
  2. [2]Regulation (EU) 2024/2847 - full text (EUR-Lex)retrieved 8 Jun 2026
  3. [3]European Commission - Cyber Resilience Actretrieved 8 Jun 2026

The CRA Brief

Stay current on CRA guidance

We watch Brussels so you don't. Plain-English CRA updates, free.

No spam. Unsubscribe anytime.