For open-source maintainers ยท Regulation (EU) 2024/2847

What the CRA means for open-source maintainers

Verified against the Official Journal text on

Where you land depends on money, and it forms a ladder. Free and open-source software that you do not monetise is not supplied in the course of a commercial activity, so it is not made available on the market and the CRA does not apply (Art. 3(22), Recital 18). Monetise it (paid versions, paid support or hosting, dual licensing) and you become a manufacturer with the full obligations. Between the two sits the open-source software steward: a legal person that sustains development of open source intended for commercial use, without monetising it, under a lighter regime (Art. 3(14), Art. 24).

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

Rung one: unmonetised open source is out of scope Art. 3(22), Recital 15, Recital 18

The CRA reaches products made available on the market, meaning supplied for distribution or use in the course of a commercial activity (Art. 3(22)). Open-source software that its maker does not monetise is not a commercial activity for these purposes, so it is outside scope (Recital 18).

The recitals are generous about what does not make you commercial. Accepting donations without an intention to profit, receiving financial support or contributions from manufacturers, and publishing regular releases do not by themselves make the activity commercial (Recital 15, Recital 18). Contributing source code to a project that is not under your responsibility is not covered at all.

Rung three: monetise it and you are a manufacturer Art. 3(22), Recital 15, Art. 32(5)

Once you monetise the software, through paid tiers, paid support or hosting that goes beyond recovering actual costs, dual licensing, or monetising a component, the supply becomes commercial and you take on the manufacturer obligations in full (Art. 3(22), Recital 15). At that point the essential requirements, vulnerability handling, documentation, conformity assessment, CE marking, and reporting all apply (Art. 13, Art. 14).

One targeted relief exists for open source in an important Annex III category: you may use the ordinary Article 32(1) procedures, including internal control, despite the class listing, provided the technical documentation is made public when the product is placed on the market (Art. 32(5)).

Rung two: the open-source software steward Art. 3(14), Art. 24, Recital 19

A middle rung exists for foundations and similar bodies. An open-source software steward 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 (Art. 3(14), Recital 19). Stewards are not manufacturers: no CE marking and no conformity assessment.

A trimmed set of duties applies instead. A steward must put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling, and must cooperate with market surveillance authorities on reasoned request (Art. 24(1), Art. 24(2)). A reduced reporting duty applies to the extent the steward is involved in the development (Art. 24(3)).

When the steward reporting duty starts is unsettled Art. 24(3), Art. 14(1), Art. 71(2)

The prudent date to be ready for the trimmed reporting duty is 11 September 2026. Strictly, Article 24 applies from 11 December 2027 and only Article 14 is accelerated to 11 September 2026; whether the steward duty tracks the earlier date is unsettled, so prepare for the earlier one (Art. 24(3), Art. 14(1), Art. 71(2)).

The duty itself covers actively exploited vulnerabilities in products you support, and severe incidents affecting the network and information systems you provide for their development, only to the extent you are involved (Art. 24(3), Art. 14(1)).

Judgment call: Art. 71(2) accelerates Art. 14 but not Art. 24; whether steward reporting starts on 11 September 2026 or 11 December 2027 is unsettled. Shown as the prudent earlier date.

What you must do

  • If you monetise: the full manufacturer obligations apply (essential requirements, vulnerability handling, documentation, conformity assessment, CE marking, reporting). (Art. 13, Art. 14)
  • If you are a steward: put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling. (Art. 24(1))
  • If you are a steward: cooperate with market surveillance authorities on reasoned request. (Art. 24(2))
  • If you are a steward: a trimmed set of the reporting duties applies, to the extent you are involved in the development. (Art. 24(3), Art. 14(1))

The dates that decide your planning

11 September 2026
The prudent date to be ready for your trimmed reporting duty. Strictly, Article 24 applies from 11 December 2027 and only Article 14 is accelerated to 11 September 2026; whether the steward duty tracks the earlier date is unsettled, so prepare for the earlier one. The duty covers actively exploited vulnerabilities in products you support, and severe incidents affecting network and information systems you provide for their development, only to the extent you are involved. (Art. 24(3), Art. 14(1), Art. 71(2))
11 December 2027
The full obligations apply to monetised open source placed on the market: essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking. (Art. 71(2))

Frequently asked

We take donations and GitHub sponsorships. Are we commercial?

Not on that basis alone. Accepting donations without an intention to profit, and receiving sponsorship or contributions, do not by themselves make the activity commercial. Publishing regular releases does not either. Monetising the software is what moves you into scope. (Art. 3(22), Recital 18)

What is an open-source software steward?

A legal person, other than a manufacturer, that systematically and sustainably supports development of specific open-source products intended for commercial use, and ensures their viability. Stewards are not manufacturers: no CE marking or conformity assessment, just a lighter set of duties. (Art. 3(14), Recital 19)

Our project is in an Annex III class but open source. Must we use a notified body?

Not necessarily. Manufacturers of open-source products in an Annex III category can use the ordinary Article 32(1) procedures, including internal control, despite the class listing, provided the technical documentation is made public at the time the product is placed on the market. (Art. 32(5))

When does the steward reporting duty start?

This is unsettled. Article 24 strictly applies from 11 December 2027, but Article 14 reporting is accelerated to 11 September 2026, and whether the steward duty tracks that earlier date is not clear. The prudent course is to be ready for 11 September 2026. (Art. 24(3), Art. 14(1), Art. 71(2))

Find your rung on the ladder, free

The Vexwatch Scope Checker walks the same cited decision tree in about three minutes and tells you whether your project is out of scope, a steward, or a manufacturer.

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.