The Cyber Resilience Act and Open Source: The Steward Role and Scope

Few topics stirred as much anxiety around the Cyber Resilience Act (Regulation (EU) 2024/2847) as its treatment of open source. The concern was real: would volunteer developers suddenly be liable for a project that others use commercially? The final text answers this in a nuanced way. It draws a clean line between contributors who make free and open-source software (FOSS) available outside a commercial activity, a new role called the open-source steward, and manufacturers who integrate open-source components into their products. This article maps out those three layers and states plainly where genuine ambiguity remains.

The trigger is commercial activity, not source code

The core idea is this: the CRA applies only when a product with digital elements is made available on the market in the course of a commercial activity. What determines whether the rules apply is not the fact that software is open source, but the economic context of making it available. Non-commercial FOSS therefore falls outside the scope of the Regulation.

For individual contributors, this means something concrete: anyone contributing to a free project without acting in the course of a commercial activity is not subject to the CRA's manufacturer duties. A volunteer maintaining a library, a student publishing a tool on a platform, a community with no business model behind it – none of them become a manufacturer within the meaning of the Regulation simply by publishing code. The mere act of developing or making source code available is not a placing on the market in the legal sense.

An important distinction: "commercial activity" is not the same as "for a fee." Accepting donations or occasionally providing paid support does not automatically turn a project into a commercial product – the legislator asks for an assessment of the overall picture. It is precisely at these edges that the residual ambiguity sits, and the Commission has announced guidance to address it.

The open-source steward (Art. 24): a deliberately light regime

The CRA introduces a dedicated role in Article 24 (defined in Art. 3(14)): the open-source steward. This is a legal person – expressly not a manufacturer and not a natural person – that systematically and sustainably supports the development of open-source products with digital elements intended for commercial activities. Typical candidates are foundations and non-profit organisations that fund, host, or govern critical open-source ecosystems.

Stewards face a deliberately light set of duties, built around three points:

• Documented cybersecurity policy (Art. 24(1)): the steward puts in place a verifiably documented cybersecurity policy that fosters the development of secure software and the handling of vulnerabilities in the supported ecosystem.
• Cooperation with authorities (Art. 24(2)): the steward cooperates with market surveillance authorities to mitigate risks and provides the necessary information upon reasoned request.
• A limited slice of reporting (Art. 24(3)): only a narrow portion of the Article 14 reporting obligations applies – for instance, when the steward becomes aware of an actively exploited vulnerability in the code it supports.

Equally important is what does not apply: stewards affix no CE marking, perform no conformity assessment, and draw up no full manufacturer-grade technical documentation. And open-source stewards are not subject to administrative fines. The regime rests on cooperation rather than sanction – an acknowledgement that stewards carry the ecosystem without themselves placing a finished product on the market.

What changes for companies that use open source

The most practically relevant situation involves neither volunteers nor foundations, but companies that integrate open-source software into their own commercially distributed products. For them, the CRA changes the starting point clearly: they remain manufacturers within the meaning of the Regulation and are therefore responsible for their entire product – including the embedded open-source components. The origin of a building block does not relieve them of the duty to meet the essential requirements in Annex I.

In concrete terms: responsibility for vulnerability handling, security updates, coordinated vulnerability disclosure (CVD), and reporting under Article 14 lies with the integrating manufacturer – even where a vulnerability sits in a third-party open-source library. Due care cannot be "delegated" to the upstream project.

This is exactly where the Software Bill of Materials (SBOM) becomes the central tool. Annex I Part II requires manufacturers to identify and document the components contained in a product – at least the top-level dependencies – in a commonly used, machine-readable format. A maintained SBOM gives an overview of which open-source components are built in and in which version, and only that makes it possible to determine whether a newly disclosed vulnerability affects your own product. Anyone who already keeps a reliable component inventory today will cut their response time significantly later on. You will find details in our article on the CRA's SBOM requirements.

A pragmatic approach for manufacturers with a high FOSS share: watch upstream security advisories systematically, set up a contact point for vulnerability reports, separate security from feature updates, and establish processes that also work when the upstream project does not ship a fix. The CRA does not ask you to write every library yourself – but it does ask you to know what is inside your product and to be able to act when it matters.

Remaining ambiguity – and what to do now

To be honest: the boundaries are not yet sharply drawn in several places. Exactly when a supply happens "in the course of a commercial activity," when an organisation qualifies as a steward, and how far the limited steward duties reach – these are matters of judgement on which the European Commission has announced further guidance. Until it arrives, a conservative self-assessment along the known criteria is advisable.

For most companies, the practical takeaway holds regardless of these subtleties: if you make a commercial product with digital elements available, you are a manufacturer – and using open source does not change that; it simply shifts the task onto sound component and vulnerability management. Whether your specific project falls within scope at all is best clarified with our scope check. For a comprehensive overview of the Regulation, see our CRA overview page.