Skip to content
UPSTREAM
CRA

Cyber Resilience Act: what manufacturers should know about open source.

Last updated: · ALVPHA Tech GmbH

The deadlines

  • 10 December 2024: entry into force
  • 11 June 2026: provisions on conformity assessment bodies (Chapter IV)
  • 11 September 2026: reporting duties for actively exploited vulnerabilities and severe incidents (Article 14)
  • 11 December 2027: full application of all requirements

What manufacturers must do about vulnerabilities and components

  • identify and document components, including with an SBOM in a commonly used machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1)
  • handle and remediate vulnerabilities without delay, including through security updates
  • exercise due diligence when integrating third-party components, explicitly including free and open-source software (Article 13(5))
  • report actively exploited vulnerabilities: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a fix is available (Article 14(2))

And the open-source projects themselves?

Free and open-source software that is not made available in the course of a commercial activity is generally outside the manufacturer obligations. For organisations that systematically support such software intended for commercial use, the CRA introduces the role of open-source software steward with lighter obligations. Responsibility for a product remains with the manufacturer that integrates the components.

Where teams sensibly start

  • Generate release-specific SBOMs for the most important products
  • Define a triage process with owners and deadlines
  • Prepare the reporting route for actively exploited vulnerabilities
  • Document review status and open risks traceably for customers and authorities

Frequently asked questions

Does the CRA also apply to pure software?

Yes, as long as it is made available in the EU as a product with digital elements. Whether and how a specific product is covered should be assessed legally on a case-by-case basis.

Are we liable for every open-source component?

The manufacturer is responsible for the cybersecurity of its product, including integrated components, and must exercise due diligence in doing so. This does not turn the projects themselves into suppliers in a contractual sense.

SOURCES

This article provides technical orientation and is not legal advice. The linked primary sources in their current version are authoritative.

Where does your team stand?

The free Trust Check classifies your self-assessment across seven dimensions, from component inventory to evidence capability. For specific cases, we arrange an introductory call.

Start your free Trust Check Book an introductory call

Related service: Vulnerability handling

More articles

All articles →
SBOM

What is an SBOM and what must it contain?

An SBOM (Software Bill of Materials) is a machine-readable inventory of all components in a piece of software, with version, origin and dependencies. It is the basis for knowing quickly whether a product is affected when a new vulnerability appears. The Cyber Resilience Act requires manufacturers to maintain an SBOM covering at least the top-level dependencies.

Read article TRIAGE

Vulnerability triage: from CVE report to decision.

Triage means assessing a vulnerability finding in a structured way: is our product actually affected, how urgent is it, and what do we decide? Severity (CVSS) alone is not enough; likelihood of exploitation (EPSS), evidence of exploitation (KEV) and how the component is actually used in the product all matter. The outcome is documented traceably, for example as a VEX statement.

Read article GOVERNANCE

Open-source governance: rules, licences, ownership.

Open-source governance defines how an organisation selects, uses, documents and maintains open source. It combines licence compliance, security processes and clear ownership. The aim is not to slow open source down but to make its use traceable and accountable.

Read article