Scope hinges on monetisation ยท Regulation (EU) 2024/2847

Is open-source software in scope of the EU CRA?

Verified against the Official Journal text on

Depends on monetisation and role (Art. 3(22), Recital 18)

It depends on whether the software is supplied in the course of a commercial activity. Free and open-source software that its maker does not monetise is not "made available on the market", so the CRA does not apply. How development is financed, sponsorship, and regular releases do not by themselves make it commercial. Monetising it changes that: paid versions or tiers, paid support or hosting beyond cost recovery, or dual licensing pull it into scope. Foundations that support development of commercially used open source without monetising it themselves are stewards, a lighter regime. In-scope open-source important products get a public-documentation relief on the conformity route.

Basis: Art. 3(22), Recital 18, Art. 3(14), Art. 32(5)

Judgment call: Monetisation edge cases (paid support only, a hosted version by the same maker) are the sharpest gray zone in the CRA. If your model is unusual, verify this against the recitals and, if needed, counsel.

The commercial-activity line Art. 3(22), Recital 17, Recital 18

The CRA reaches economic operators only for products made available on the market, meaning supplied for distribution or use in the course of a commercial activity. For open-source software the recitals are explicit: only free and open-source software supplied in the course of a commercial activity falls within scope, and software not monetised by its manufacturer is not a commercial activity.

The recitals go further to reassure maintainers. The circumstances under which the software was developed, how development was financed, financial support or contributions from manufacturers, and the mere presence of regular releases do not, by themselves, make the activity commercial. Persons who merely contribute source code to a project not under their responsibility are outside scope.

What monetisation looks like Recital 15, Recital 18

The recitals describe commercial supply broadly: charging a price, charging for technical support beyond recovering actual costs, an intention to monetise (for instance a platform through which the maker monetises other services), requiring personal-data processing as a condition of use for reasons beyond security or interoperability, or accepting donations that exceed the costs of development and provision.

For components, there is a specific rule: supplying an open-source component intended for integration by other manufacturers counts as making available on the market only if the original manufacturer monetises the component. So an unmonetised component you publish for others to build on is treated differently from one you charge for.

Judgment call: Whether a specific model (paid support only, a maker-hosted version, generous donations) crosses into commercial activity is the sharpest judgment call in the CRA and turns on the facts.

Open-source software stewards, a lighter regime Art. 3(14), Art. 24, Recital 19

A distinct category sits between "out of scope" and "manufacturer": the open-source software steward. That is a legal person, other than a manufacturer, that systematically supports on a sustained basis the development of specific open-source products intended for commercial activities, and ensures their viability, without monetising them. Certain foundations fit here.

Stewards are not manufacturers: no CE marking, no conformity assessment. They put in place and document a cybersecurity policy, cooperate with market surveillance authorities on request, and carry a trimmed reporting duty to the extent they are involved in development.

Judgment call: When the trimmed steward reporting duty starts is unsettled: Art. 71(2) accelerates Art. 14 to 11 September 2026 but does not name Art. 24, whose general date is 11 December 2027. Prudent practice is to be ready for the earlier date.

If in scope, the public-documentation relief Art. 32(5), Art. 71(2)

Where open-source software is in scope and falls under a listed important category, its manufacturer can still use the ordinary conformity procedures of Article 32(1), including internal control, despite the Annex III listing, provided the technical documentation is made available to the public at the time the product is placed on the market. That eases the route the Class listing would otherwise impose. The reporting date of 11 September 2026 and the full-obligations date of 11 December 2027 apply to in-scope open-source products.

What you must do

  • If monetised and in scope as manufacturer: design and build to the essential requirements, handle vulnerabilities (including a coordinated vulnerability disclosure policy), document, assess, and CE mark. (Art. 13, Annex I)
  • For an in-scope open-source important product, you may use the ordinary Article 32(1) procedures if the technical documentation is made public at placing on the market. (Art. 32(5))
  • If a steward: put in place and document a cybersecurity policy, cooperate with market surveillance authorities, and meet the trimmed reporting duty to the extent involved. (Art. 24)

The dates that decide your planning

11 September 2026
For in-scope open-source products, reporting duties start. Actively exploited vulnerabilities and severe incidents must be reported via the single reporting platform: early warning within 24 hours, notification within 72 hours, then a final report (within 14 days after a corrective measure is available for vulnerabilities, within one month after the notification for severe incidents). (Art. 14, Art. 16, Art. 71(2))
11 December 2027
For in-scope open-source products, the full obligations apply: essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking. (Art. 71(2))

Frequently asked

We accept donations and publish regular releases. Are we commercial?

Not on those grounds alone. The recitals say how development is financed and the mere presence of regular releases do not make the activity commercial. Accepting donations without an intention to make a profit is not a commercial activity either. (Art. 3(22), Recital 18)

We sell paid support for our open-source project. Does the CRA apply?

It may. Charging for technical support where this does more than recover actual costs points toward a commercial activity. This is a genuine edge case, so assess it against the recitals and, if your model is unusual, confirm with counsel. (Recital 15, Recital 18)

What is an open-source software steward?

A legal person, not a manufacturer, that systematically supports the development of open-source products intended for commercial use and ensures their viability, without monetising them. Stewards get a lighter regime: a cybersecurity policy and a trimmed reporting duty, no CE marking. (Art. 3(14), Art. 24)

Our open-source tool is a password manager. Do we face the Class I route?

If it is in scope, Article 32(5) lets you use the ordinary procedures, including internal control, despite the Class I listing, as long as the technical documentation is made public when the product is placed on the market. (Art. 32(5))

Find out which side of the line you are on

The Vexwatch Scope Checker walks the same cited decision tree, including the monetisation and steward questions that decide whether open-source software is out, in, or in the lighter steward regime.

Check your scope, free See the Blueprint

This page is general information about Regulation (EU) 2024/2847, the EU Cyber Resilience Act. It is compliance tooling, not legal advice, and creates no client relationship. It may not reflect your specific circumstances or the most recent regulatory guidance. Verify conclusions against the regulation or qualified counsel before relying on them.