The CRA for open-source maintainers and stewards
Short answer. Three outcomes, and one question decides between them: is the software monetised?
Not monetised, and yours alone: outside the regulation. Monetised in any of the several ways the regulation recognises: you are a manufacturer, with the full obligations. Sustaining somebody else's project intended for commercial use: you may be a steward, a third category with three duties and no CE marking.
This is the part of the Cyber Resilience Act that was most fought over and is now most misdescribed. The two common summaries — “open source is exempt” and “the CRA will kill open source” — are both wrong, and in opposite directions.
Three categories, not two
| You are | If | What you owe |
|---|---|---|
| Outside the regulation | Your open-source product is not monetised by you, or you contribute code to a project that is not under your responsibility | Nothing under the CRA |
| An open-source software steward | You are a legal person, not the manufacturer, systematically providing sustained support for the development of open-source products intended for commercial activities, and ensuring their viability | Article 24: a documented cybersecurity policy, cooperation with authorities, and part of the Article 14 reporting duties |
| A manufacturer | You supply the software in the course of a commercial activity — which includes monetising it | Everything: Annex I, the technical file, the declaration of conformity, the CE marking, Article 14 reporting |
The jump from the middle row to the bottom row is the largest cliff edge in the regulation, and it is triggered by a commercial decision rather than a technical one.
The monetisation test
Recital 18 is the provision that does the work, and it is unusually detailed for a recital. The core sentence:
… for the purposes of this Regulation and in relation to the economic operators that fall within its scope, to ensure that there is a clear distinction between the development and supply phases, 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.
It then rules several things out as determinative, which is where it becomes genuinely useful:
- How the project was developed or financed is irrelevant. “The mere circumstances under which the product with digital elements has been developed, or how the development has been financed, should therefore not be taken into account when determining the commercial or non-commercial nature of that activity.”
- Financial support from manufacturers is not enough. “the mere fact that an open-source software product with digital elements receives financial support from manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature”.
- Regular releases are not enough. “the mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity”.
- Not-for-profit development is not commercial, provided the organisation is set up so that all earnings after costs are used to achieve not-for-profit objectives.
And one thing it rules in, which catches component authors by surprise: supplying an open-source component intended for integration by other manufacturers into their products is making available on the market only if the component is monetised by its original manufacturer. So publishing a library that thousands of commercial products depend on does not, without monetisation, put you in scope.
Contributors are not in scope at all
The last sentence of Recital 18 is short and worth quoting because it settles the anxiety that drove most of the opposition to this part of the regulation:
This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility.
Sending a patch to a project you do not run does not make you an economic operator. That is the end of it.
What a steward actually is
The definition in Article 3 has four limbs, and all of them have to be met:
‘open-source software steward’ means 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
- A legal person. An individual maintainer is not a steward. A foundation, association or company can be.
- Other than a manufacturer. The categories are exclusive. If you monetise it, you are the manufacturer, not its steward.
- Systematic, sustained support for development of specific products. Recital 19 gives examples: hosting and managing software development collaboration platforms, hosting source code or software, governing or managing the products, and steering their development.
- Products intended for commercial activities, and you ensure their viability. Recital 19 explains this covers products ultimately intended for commercial activities, such as integration into commercial services or into monetised products — including where integrating manufacturers contribute regularly to development or provide regular financial assistance to ensure continuity.
The practical upshot: a solo maintainer is not a steward, and a foundation that hosts a widely-commercially-used project probably is. That is a different distribution of obligations from the one most commentary assumes.
The three steward duties
Article 24 has three paragraphs, and it is short enough to work through properly.
Article 24(1) — a documented cybersecurity policy. The steward must “put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product”. The policy must also foster the voluntary reporting of vulnerabilities under Article 15 by those developers, and take account of the steward's own specific nature and the legal and organisational arrangements it is subject to. It must in particular include aspects related to documenting, addressing and remediating vulnerabilities, and promote the sharing of information about discovered vulnerabilities within the open-source community.
Article 24(2) — cooperation. Stewards must cooperate with market surveillance authorities, at their request, with a view to mitigating cybersecurity risks posed by the product. Further to a reasoned request, they must provide that authority with the Article 24(1) documentation, in paper or electronic form, in a language the authority can easily understand.
Article 24(3) — reporting, partially. This is the paragraph that catches people, and it is carefully limited on both limbs:
- The Article 14(1) obligations — notifying an actively exploited vulnerability — apply to stewards to the extent that they are involved in the development of the products.
- The Article 14(3) and (8) obligations — notifying a severe incident, and informing impacted users — apply to the extent that severe incidents affect network and information systems provided by the steward for the development of such products.
Read that second limb carefully: for severe incidents, the trigger is an impact on the development infrastructure the steward provides — the forge, the build system, the package hosting. A steward running a code-hosting platform has a reporting duty about that platform.
Note what is absent from Article 24: Annex I. No essential cybersecurity requirements, no technical documentation, no declaration of conformity, no conformity assessment, no support period. Recital 19 calls it a “light-touch and tailor-made regulatory regime”, and the text matches the description.
The duty that already applies
Article 71(2) applies Article 14 from 11 September 2026 and the rest of the Regulation from 11 December 2027. Because Article 24(3) works by extending parts of Article 14, the reporting duties for stewards are already live, while the Article 24(1) policy duty and the Article 24(2) cooperation duty are not.
That is an odd order — the obligation to report arrives before the obligation to have a policy for handling what you report — and it is worth stating plainly because it inverts the sensible sequence. ENISA's own announcement of the single reporting platform's launch noted that the reporting obligations also apply to open-source software stewards to the extent they are involved in the development of products with digital elements.
If you are a steward, the practical consequence is that the thing to have ready is not the policy. It is an account on ENISA's reporting platform, because that has to exist before the 24-hour clock starts, and a determination of which CSIRT you report to.
Why a steward cannot CE mark
Recital 19 closes with the reason, and it is a fair one:
Given that the light-touch and tailor-made regulatory regime does not subject those acting as open-source software stewards to the same obligations as those acting as manufacturers under this Regulation, they should not be permitted to affix the CE marking to the products with digital elements whose development they support.
The consequence for everyone else is the important half: you cannot rely on an upstream project's marking, because there will not be one. A manufacturer integrating an open-source component is the manufacturer of the resulting product, and the Annex I assessment is theirs.
If you integrate open source into your product
Most readers of this page are here for this rather than for the steward regime. The position is straightforward and unwelcome:
- The components are in your scope even though their authors are not. Article 13(8) requires vulnerabilities of the product “including its components” to be handled for the whole support period. Nothing distinguishes code you wrote from code you imported.
- Annex I Part II point 1 requires an SBOM covering at the very least top-level dependencies, in a machine-readable format. That is how your components become visible — see the SBOM requirements.
- Point 6 extends your disclosure duty to third-party components. Your disclosure policy has to say what happens when a report concerns a dependency, because that is where most reports land.
- Upstream end-of-life is your problem. If a component providing a core function stops being maintained inside your support period, you are still obliged to handle its vulnerabilities. Article 13(8) expressly lets you take third-party component support periods into account when setting yours — which is an invitation to check those dates before you publish a number.
An honest note on our own confidence. The definitions, Article 24's three paragraphs and Recitals 18 and 19 we are confident of. Two things are genuinely unresolved and we will not pretend otherwise. First, what counts as monetisation is not defined in the operative text, and the hard cases — paid support, dual licensing, hosting — have no authoritative answer that we have found. Second, the boundary between a steward and a manufacturer for an entity that both sustains a project and earns from it is a question the text raises and does not settle. On both, take advice rather than a page. Nothing here is legal advice.
Find out which of the three you are, free
The check asks the monetisation question and the steward question directly, and gives you a reasoned answer rather than a verdict — including telling you when your situation sits in the part of the regulation nobody has settled yet.
If it turns out you are a manufacturer, here is what the document set costs — and a steward's policy is generated too, if that is what you turn out to be.