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

The treatment of open source caused considerable concern around the Cyber Resilience Act (Regulation (EU) 2024/2847). 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 (officially: open-source software 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: making available in the course of a commercial activity

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 (Art. 3(22)). Whether software is open source plays no role here; what counts is the economic context in which it is made 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. Code published outside a commercial activity is not made available on the market (recital 18).

An important distinction: a commercial activity can exist without a purchase price. Donations without a profit motive do not make a project commercial. According to the recitals, however, indicators of a commercial activity include charging for technical support beyond the recovery of actual costs, accepting donations that exceed the costs of design, development and provision, or an intention to make a profit (recital 15). Financial support from manufacturers or regular releases are not sufficient on their own (recital 18). It is precisely at these edges that the residual ambiguity sits; Art. 26(2)(a) provides for Commission guidance on it.

This construction is meant to protect the free software ecosystem: it is intended to prevent the Regulation from deterring contributors or driving projects to give up merely because third parties later reuse the code commercially. Manufacturer responsibility only arises once a product is made available in the course of a commercial activity, and it lies with whoever makes the product available on the market; the original author of the library is not affected as long as they do not act commercially themselves.

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 other than a manufacturer that systematically provides support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products. 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 documentation of that policy upon reasoned request.
• A limited slice of reporting (Art. 24(3)): the reporting of actively exploited vulnerabilities (Art. 14(1)) applies to stewards to the extent that they are involved in the development of the products; Art. 14(3) and (8) apply to the extent that severe incidents affect the network and information systems the steward provides for the development.

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. On fines, Article 64(10)(b) exempts open-source stewards from the fines in paragraphs 3 to 9 for any infringement of the Regulation. For the reporting obligations from Article 14, which also apply to stewards under Article 24(3) (paragraph 1 to the extent that they are involved in the development of the products), the wording is not clear: infringements of Article 14 fall under paragraph 2, to which paragraph 10 does not refer. Recital 120 assumes that no fines are imposed on stewards. In individual cases, your legal department or a law firm should clarify this. The regime relies on cooperation with the authorities and takes into account that stewards support the ecosystem without themselves placing a finished product on the market.

What changes for companies that use open source

A situation of great practical relevance 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. Keeping an up-to-date component inventory today lets you respond faster 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. You may use third-party libraries; the CRA requires you to know what is inside your product and to be able to act when it matters.

A special rule applies to manufacturers of open-source products: if a product qualifying as free and open-source software falls into a category in Annex III (important products), the manufacturer may use any procedure under Art. 32(1), including internal control under Module A, provided the technical documentation is made public when the product is placed on the market (Art. 32(5)).

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 Art. 26(2)(a) provides for Commission guidance. Check its current status; until these points are settled, a conservative self-assessment along the known criteria is advisable.

Regardless of these subtleties, the practical takeaway is: if you place a product with digital elements on the market under your own name in the course of a commercial activity, 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.