The Cyber Resilience Act and Open Source: Maintainers, Stewards and Companies Using FOSS

The starting point: only commercial activity counts

The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements made available on the market, meaning supplied in the course of a commercial activity (recital 15). Free and open-source software is software whose source code is openly shared under a licence that gives all rights to access, use, modify and redistribute it (Article 3(48)).

Situation	Commercial activity under the CRA?	Recital
A maintainer publishes a project and does not monetise it	No	18
The project receives donations without intent to make a profit	No	15
Companies contribute code or funding to the project, or it has regular releases	Not in itself	18
A not-for-profit develops it and uses all earnings after costs for not-for-profit objectives	No	18
Someone contributes source code to a project that is not under their responsibility	The CRA does not apply to the contributor	18
The software is sold, or support is charged above actual costs, or it is a vehicle to monetise other services, or use requires processing personal data for other than security, compatibility or interoperability	Yes, it can be	15
A component is supplied for integration into others' products	Only if the component is monetised by its original manufacturer	18

If the activity is commercial, the supplier is a manufacturer with the full set of obligations, including the Annex I requirements and reporting. See our CRA requirements checklist.

Open-source software stewards

Between maintainers and manufacturers sits a new role. An open-source software steward is a legal person, other than a manufacturer, whose purpose is to systematically provide sustained support for the development of specific free and open-source products intended for commercial activities, and that ensures their viability (Article 3(14)). Recital 19 gives certain foundations, and entities that develop and publish open-source software in a business context, including not-for-profits, as examples.

Stewards get a light-touch regime (Article 24):

put in place, and document in a verifiable manner, a cybersecurity policy that fosters secure development and effective vulnerability handling by the project's developers, encourages voluntary reporting of vulnerabilities, and covers documenting, addressing and remediating them and sharing information in the open-source community (Article 24(1));
cooperate with market surveillance authorities on request, and provide the policy documentation after a reasoned request (Article 24(2));
report actively exploited vulnerabilities to the extent they are involved in development, and severe incidents affecting the systems they provide for development, such as build or hosting infrastructure (Article 24(3), applying Article 14).

Article 64(10)(b) provides that the administrative fines in Article 64(3) to (9) do not apply to any infringement of the CRA by open-source software stewards. Article 24 applies with the rest of the CRA from 11 December 2027 (Article 71(2)).

If you ship open-source components in your product

For a company building a commercial product, using open source does not move responsibility upstream. As manufacturer you must:

Duty	Article
Exercise due diligence when integrating third-party components, including free and open-source components not supplied commercially, so they do not compromise the product	13(5)
Report a vulnerability you find in an integrated component, including an open-source one, to whoever maintains it, and remediate it in your product; share your fix with the maintainer where appropriate	13(6)
Identify and document components, including a software bill of materials covering at least top-level dependencies	Annex I, Part II(1)
Handle vulnerabilities in components throughout the support period, like vulnerabilities in your own code	13(8), Annex I Part II

The Commission may set up voluntary security attestation programmes for free and open-source software, to help manufacturers with this due diligence (Article 25). Until such programmes exist, due diligence means looking at the project yourself: maintenance activity, security policy, vulnerability response, and whether a steward or foundation stands behind it.

Open-source important products: if you are the manufacturer of a free and open-source product in an Annex III category, you can use internal control instead of third-party assessment, provided the technical documentation is made public when the product is placed on the market (Article 32(5)).

Practical steps

For maintainers and foundations

Decide, project by project, whether anything you do is a commercial activity in the sense of recital 15, and record why.
If you act as a steward, write and publish a security policy: how to report vulnerabilities, how they are triaged and fixed, how advisories are published.
Secure your development infrastructure (repository, CI, package publishing), since severe incidents affecting it fall under your reporting duties.

For companies using open source

Generate an SBOM in your build pipeline and keep it per release.
Set criteria for accepting a new dependency: maintenance, security policy, known vulnerabilities, licence.
Monitor advisories for your dependencies and track fixes through your vulnerability process.
Report vulnerabilities you find upstream, and contribute fixes back where you can.
Consider supporting the projects you depend on most; it is due diligence as much as goodwill.

A vulnerability process to build on. The Cybersecurity Starter Pack includes a patch and vulnerability management procedure, an asset inventory, a penetration test scoping document, an incident response plan and a 90-day security roadmap.

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 3(14), 3(48), 13, 24, 25, 32(5), 64(10) and 71, Annex I, recitals 15 to 19, EUR-Lex