Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

The CRA and open source: maintainers, stewards and manufacturers

8 min read

On this page
  1. 1. Open source outside commercial activity: out of scope
  2. 2. Open-source software stewards: a light regime
  3. 3. Manufacturers who use open source: fully responsible
  4. A quick self-check
  5. What maintainers can do anyway
  6. How Provetry helps
  7. Sources

Open source was the most debated part of the Cyber Resilience Act. Early drafts worried maintainers that publishing code on GitHub could make them liable as manufacturers. The final text draws a clear line: the CRA follows commercial activity, not code. It gives three positions to people and organisations around open source, each with different duties.

1. Open source outside commercial activity: out of scope

Free and open-source software that is developed or supplied outside the course of a commercial activity is not covered. The recitals spell out what that means in practice:

  • An individual or a group publishing code, accepting contributions and fixing bugs for free is not a manufacturer.
  • Contributing to a project you are not responsible for never makes you a manufacturer of it.
  • Donations that do not aim at making a profit do not turn a project into a commercial activity.
  • Non-profit organisations developing open source are not considered commercial, provided any income is reinvested in non-profit goals.

What can make an open-source product commercial: charging a price for it, charging for technical support beyond recovering actual costs, monetising it through a software platform or other services, or making the processing of personal data a condition of use for reasons other than security, compatibility or interoperability.

2. Open-source software stewards: a light regime

The CRA creates a new role, the open-source software steward: a legal person, other than a manufacturer, whose purpose is to provide systematic and sustained support for the development of specific open-source products intended for commercial activities, and that ensures their viability. Foundations that host and support widely used projects are the typical example.

Stewards have a light regime of their own (Article 24). They must:

  • put in place and document a cybersecurity policy that fosters secure development and the effective handling of vulnerabilities, and encourages the voluntary reporting of vulnerabilities by the developers;
  • cooperate with market surveillance authorities when asked;
  • report actively exploited vulnerabilities in products whose development they are involved in, and severe incidents only where they affect the networks and information systems they provide for that development. These steward reporting duties apply from 11 December 2027.

They do not do conformity assessments, CE marking or technical documentation. And they cannot be fined under the CRA’s penalty rules (Article 64(10)).

The regulation also foresees voluntary security attestation programmes for open-source software, to help manufacturers rely on it (Article 25).

3. Manufacturers who use open source: fully responsible

When a company places a product on the market, it is the manufacturer of the whole product, open-source components included. That has three consequences:

  • Due diligence on components. When integrating third-party components, including open source, manufacturers must make sure they do not compromise the product’s cybersecurity (Article 13(5)).
  • Report upstream. A manufacturer that finds a vulnerability in an open-source component must report it to the person or organisation maintaining that component, and act on it; where it develops a fix, it must share the code or documentation with the maintainer, in a machine-readable format where appropriate (Article 13(6)).
  • Vulnerability handling for the product. The SBOM, the daily watch for new and exploited vulnerabilities, the fixes and advisories are the manufacturer’s job for every component it ships, including libraries it did not write.

A company that publishes its own open-source project and sells it, or makes money from it as described above, is the manufacturer of that product, with all the obligations. Free and open-source products in the important categories have one advantage: they can use the self-assessment route if their technical documentation is public (Article 32(5)).

A quick self-check

You are Your position
A volunteer maintainer or contributor Out of scope
A foundation hosting projects used commercially Probably a steward
A company selling a product that includes open source Manufacturer of the whole product
A company selling support for an open-source project it maintains, where that monetises the product Possibly a manufacturer: check the Commission’s guidance
A company publishing open source it uses internally, without selling it Usually out of scope for that code

Edge cases are real. The Commission’s guidance on applying the CRA (July 2026) and its FAQ give examples; read them, and ask a lawyer if your model sits on the line.

What maintainers can do anyway

Even out of scope, maintainers of popular projects will feel the CRA through the companies that use their code. Helpful things that cost little:

  • publish a security policy and a contact point (SECURITY.md, security.txt);
  • produce an SBOM for releases;
  • publish advisories in a standard format when you fix something;
  • say which versions are supported.

How Provetry helps

For manufacturers, Provetry lists every open-source component of each release, watches them for new and exploited vulnerabilities, and records your decisions. Each product records your role (manufacturer, importer, distributor or open-source steward), so your documentation says which obligations you carry.

This guide is general information, not legal advice.

Sources