Open source under the CRA: makers, stewards, maintainers

The Cyber Resilience Act exempts free and open-source software as long as it is not supplied in the course of a commercial activity. But anyone integrating open-source components into their own product carries full responsibility for them as manufacturer – and must exercise due diligence in selecting and maintaining them (Art. 13(5)).

For organisations that sustainably support open-source projects, the CRA creates a lighter role: the open-source steward. This post covers three perspectives – manufacturer, steward, maintainer.

When is open source exempt?

The key question is whether the software is made available in the course of a commercial activity. A hobby project on GitHub with volunteer contributors is not covered. It is different when a company monetises open-source software, for example by charging for the software itself or for services inseparable from its use. Company developers merely contributing to a project does not automatically make it commercial.

The open-source steward (Art. 24)

An open-source steward is a legal person, not a manufacturer, that systematically and sustainably supports the development of specific open-source products intended for commercial activities – typically foundations. Stewards have a reduced set of obligations:

• a documented cybersecurity policy fostering secure development and vulnerability handling,
• cooperation with market surveillance authorities,
• reporting of actively exploited vulnerabilities and severe incidents to the extent they are involved in development.

Due diligence for integrated components

Art. 13(5) requires manufacturers to exercise due diligence when integrating third-party components – including open source – so that they do not compromise the product's cybersecurity. In practice:

• Selection: is the project actively maintained? Does it have a security policy and respond quickly to reports?
• Inventory: every component is in the SBOM – see our guide how to create an SBOM.
• Monitoring: new vulnerabilities in dependencies are continuously detected and assessed.
• Exit plan: what if a project is abandoned? Fork, replace or maintain it yourself – for the whole support period.

The numbers

According to the 2026 OSSRA report, the average codebase contains 581 vulnerabilities – up 107% from 280 the year before. At these volumes, due diligence is impossible without automated monitoring.

Report vulnerabilities upstream

If a manufacturer finds a vulnerability in an integrated component, it must report it to the person or entity maintaining the component and address it. If it has developed a fix, it shares the relevant code or documentation with the maintainer, in a machine-readable format where appropriate (Art. 13(6)). Open source benefits directly from manufacturer obligations.

Licence risk

The CRA does not regulate licensing. A good SBOM does, however, surface licence conflicts – and with 68% of codebases affected it is worth a look. Combining SBOM and licence checks in one pipeline handles two tasks with one tool.

Due diligence in practice: a check scheme

Due diligence cannot rest on one criterion. A simple scheme for new dependencies makes decisions traceable:

Examples

Software house with an outdated library

A software house uses a PDF library whose maintainer has abandoned the project. Under the CRA, waiting for a fix is not enough. Options are switching to a maintained alternative, a fork with security maintenance, or isolating the component. The decision and its reasoning belong in the technical documentation.

Agency with a shared framework

An agency uses the same open-source framework in many client projects. A vulnerability in it suddenly affects many manufacturers. Knowing which project uses which version lets you inform all affected clients in a targeted way – instead of checking each client individually.

Giving back to the community

Manufacturers benefit when the projects they depend on are well maintained. Beyond the duty to report vulnerabilities upstream, they can contribute fixes, fund maintainers or support foundations acting as open-source stewards. That reduces their own risk sustainably.

If you publish open source yourself

Many mid-sized companies and agencies publish their own libraries or plugins as open source. The key question is whether this happens in the course of a commercial activity. Publishing a library without monetisation points towards the exemption. If you sell support or a commercial version inseparably tied to the open-source component, check and document the classification carefully.

• Describe the monetisation and business model of the release.
• Check whether the project ships as part of one of your own products.
• Set up a vulnerability reporting channel – regardless of the legal classification.

Supply-chain scan with Nuowei

Nuowei (beta, launch November 2026) scans your dependencies, assesses project health and vulnerabilities and documents your due diligence for the technical documentation. More on vulnerability handling.