Open source under the Cyber Resilience Act: who carries what

The Cyber Resilience Act does not ask what licence your code carries. It asks what you do with it: publish it, build it into something you sell, make money from it, or look after it for others. Each of those puts a different weight on you, and most companies do more than one.

Publishing it, outside a commercial activity

Free and open-source software developed or supplied outside a commercial activity is not covered. The Regulation does not define "commercial activity"; the examples usually quoted for it — charging for support, monetising the software, a dual licence — come from the recitals, which guide interpretation rather than bind, so whether a given project crosses the line is a question of fact.[Art. 2(1); Art. 3(22); Art. 3(48); recitals for the commercial-activity examples]

The examples that decide the question are in the recitals, and so are the cases they carve back out. The examples usually quoted for whether open-source software is supplied in the course of a commercial activity — charging a price for technical support services where this does not serve only the recuperation of actual costs, an intention to monetise, requiring the processing of personal data as a condition for use for reasons other than exclusively improving the security, compatibility or interoperability of the software, or accepting donations exceeding the costs associated with the design, development and provision of a product — are set out in the recitals and not in the enacting terms. The same recitals carve two cases straight back out, and they are part of the same intent: accepting donations without the intention of making a profit should not be considered to be a commercial activity, and neither should the development of free and open-source products by a not-for-profit organisation set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. Recitals record the legislator's stated intent and are read as an aid to interpreting the articles; they are not themselves operative provisions, so anything resting on them is stated as intent rather than as a rule of the text. The same is true of what the legislator meant by open-source products ultimately intended for commercial activities, which is the limb the steward regime turns on.[Recital 15; Recital 18; Recital 19 for the steward limb; read with Art. 3(22) and Art. 3(14), which are the operative provisions]

In practice: a project published and maintained without any of those features is outside the Act, however widely it is used. The moment a company uses the project to support something it sells, charges for more than its costs, or monetises the software another way, the answer can change.

Building it into a product you sell

This is where most manufacturers meet open source, and it does not lighten anything. You are the manufacturer of the whole product, open-source parts included, and the Act says what that means for the parts you did not write. Manufacturers exercise due diligence when integrating third-party components, including free and open-source components, so that they do not compromise the security of the product.[Art. 13(5)]

Three duties follow from it:

• Know what is in the product. Manufacturers must identify and document the vulnerabilities and the components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies.[Annex I, Part II, point 1]
• Fix it, and tell the maintainer. When a manufacturer identifies a vulnerability in a component built into its product — an open-source component included — it must report that vulnerability to whoever manufactures or maintains the component, as well as fixing it in its own product. Where it has written a software or hardware change to address the vulnerability in that component, it must share the code or the documentation for that change with the component's maintainer, in a machine-readable form where that is appropriate.[Art. 13(6)]
• Report it if it is being exploited in your product. An open-source library under attack in your product is your reporting duty, not the library's. The reporting guide covers the clocks.

Making money from your own open-source project

If you supply your project in the course of a commercial activity, you are its manufacturer, with the same duties as anyone else.

Making a product available on the market means supplying it for distribution or use on the Union market in the course of a commercial activity, whether it is paid for or free, and placing on the market is the first such supply. Because the test is supply onto the Union market, a seller established outside the EU is caught in the same way as one inside it, and the size of the company makes no difference. The Regulation does not define "commercial activity" itself; the examples usually quoted for it come from the recitals, which guide interpretation rather than bind.[Art. 3(21), Art. 3(22); recitals for the commercial-activity examples]

There is one concession, and it is worth knowing if your project does something sensitive. A manufacturer of free and open-source software whose product falls in an Annex III category may still use the ordinary routes, internal control included, provided the technical documentation is made public at the time the product is placed on the market. This does not reach the critical products in Annex IV.[Art. 32(5); Art. 31]

Looking after it for others: stewards

Foundations and similar organisations that support open-source projects used commercially have a regime of their own, lighter than a manufacturer's and not empty. An open-source software steward is a legal person, other than a manufacturer, whose purpose is to provide support systematically and on a sustained basis for the development of specific free and open-source products intended for commercial activities, and that keeps those products viable. Its regime is lighter than a manufacturer's, but it is not empty. A steward must put in place and document a cybersecurity policy, must cooperate with market surveillance authorities on request, and carries part of the reporting duty: notifying an actively exploited vulnerability where the steward is involved in developing the product, and notifying a severe incident and informing users where the incident affects the systems the steward provides for that development. Article 24 is not among the provisions brought forward to 11 September 2026, so on the face of the text those duties start on 11 December 2027 with the rest of the Regulation. No administrative fine may be imposed on a steward for any infringement of the Regulation — but that is true only of the corrected text: as first published, Article 64(10) started at paragraph 3 and left a steward exposed to the top band.[Art. 3(14); Art. 24(1), 24(2), 24(3); Art. 14(1), 14(3), 14(8); Art. 71(2)] The Act also limits the fines that can be imposed on a steward; the fines guide sets out the bands.

The checklist

• You know which of the four roles above you are in, for each project and each product — it is often more than one.
• Every product you sell has a component list that includes its open-source parts, generated from the build.
• Someone watches those components for vulnerabilities, and knows who maintains each one.
• Fixes you write for an upstream component go back upstream.
• If you publish open source yourself, you have written down whether any of it is supplied in the course of a commercial activity, and why.

If you want help

Our scope check asks whether your software is supplied in the course of a commercial activity, and whether you are a steward, and tells you — free, in about two minutes — whether the Act applies and which duties are yours, with the article behind each answer. It is our engineering reading of the law, not a legal ruling.