The question comes in three shapes, and the Cyber Resilience Act, Regulation (EU) 2024/2847, answers each differently. A maintainer publishing a library on GitHub. A company whose product is built on that library. A foundation that keeps the library alive. Only one of the three is a manufacturer, and one of the others has a regime of its own.

Case one: open-source software that is not monetised

Recital 18: "only free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity, should fall within the scope of this Regulation." And more specifically: "the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity."

Recital 20 adds that hosting on a repository, a package manager or a collaboration platform "does not in itself constitute the making available on the market", and Recital 18 that how the development was financed does not decide the question either.

So a library published under an open licence, without a paid version, paid support tied to it, or a commercial arrangement around its supply, is outside the manufacturer obligations. Its author has no CE mark to affix, no technical file, no Article 14 duty. Article 15 lets them report vulnerabilities voluntarily; nothing requires it.

Case two: a commercial product built on open-source components

The company that integrates that library into a product it places on the market is the manufacturer of that product. The licence of the component changes nothing. Annex I applies to the whole product, the SBOM lists the component, and Article 13(5) requires the manufacturer to exercise due diligence when integrating components from third parties, including open-source ones, so that they do not compromise the product's security.

Article 32(5) gives one relief: a free and open-source product that falls into an Annex III category may still use the self-assessment procedure, provided its technical documentation is made public when the product is placed on the market. That is for open-source products that are themselves placed on the market commercially, not for the components inside a proprietary one.

Recital 21 foresees voluntary security attestation programmes for open-source components, so that a manufacturer's due diligence has something to rely on. None has been established yet.

Case three: the open-source software steward

Article 3(14) defines a steward as "a legal person, other than a manufacturer, that has the purpose or objective of systematically providing 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". Recital 19 names the kind: certain foundations, and entities that develop and publish open-source software in a business context, including not-for-profits.

"Intended for commercial activities" is the hinge. Recital 19 says it includes integration into commercial services or monetised products, and that the intention exists where manufacturers who integrate the component contribute to its development regularly or fund it regularly. A foundation whose project is embedded in commercial products across the industry is a steward. A hobby project with no such relationship is not.

Article 24 gives stewards a regime the Regulation itself calls light-touch:

A cybersecurity policy, documented in a verifiable manner (Article 24(1)), fostering secure development and effective vulnerability handling by the project's developers, including documenting, addressing and remediating vulnerabilities, sharing information about discovered vulnerabilities within the community, and encouraging voluntary reporting under Article 15.

Cooperation with market surveillance authorities at their request (Article 24(2)), and providing that policy to an authority on a reasoned request.

A narrowed Article 14. Article 24(3): the duty to report actively exploited vulnerabilities applies to stewards "to the extent that they are involved in the development" of the product; the duty to report severe incidents, and to inform users, applies "to the extent that severe incidents ... affect network and information systems provided by the open-source software stewards for the development of such products". The clocks are the same 24 hours and 72 hours, to the same CSIRT and ENISA.

What a steward does not have: Annex I obligations for the product, a technical file, a conformity assessment, a CE mark, a declaration of conformity, a support period. Article 24 is the whole of it. And Article 64(10)(b) says the administrative fines of Article 64 "shall not apply to" any infringement of the Regulation by open-source software stewards; the other corrective measures a market surveillance authority has remain.

What to decide, and write down

Which case you are. If you publish open-source and monetise nothing around it, write that down, with the date, because "not monetised" is a fact about your business that can change. If you ship a product on open-source components, you are in case two and the twelve steps apply in full. If you sustain a project that commercial products depend on, you are a steward: write the Article 24(1) policy, name the person who answers an authority, and decide how you would learn of, and report, an actively exploited vulnerability in the project.

The Commission's guidance of 27 July 2026 turns the two recitals into seven tests with 22 worked examples: where a donation link, a paid support tier, an open-core edition and a foundation each land is the companion to this article.

Sources

  • Regulation (EU) 2024/2847, Article 3(14) (quoted), Article 13(5), Article 15, Article 24(1) to (3) (quoted), Article 32(5), Article 64(10)(b); Recitals 17 to 21 (quoted). Read from the Official Journal text on EUR-Lex on 11 September 2026.

This is not legal advice. The recitals are where the open-source line is drawn, and they are quoted above so you can read them rather than take our reading.