Three possible outcomes
For each project or release, the result may be:
- Manufacturer: a person publishes FOSS under its name or trademark and places it on the market in the course of a commercial activity. The ordinary manufacturer conformity and reporting duties apply.
- Open-source software steward: a legal person does not place the FOSS on the market but systematically provides sustained support for a specific project intended for commercial activities and ensures its viability. The tailored Article 24 duties apply.
- No such duties for that project: for example, an individual contributor without project control or a natural person publishing non-monetised FOSS outside commercial activity. This does not change the duties of a manufacturer that integrates the component into its own product.
One organisation may steward one version or project and manufacture another version or product.
Does the software meet the CRA’s FOSS definition?
Both conditions must be met:
- source code is openly shared, not only disclosed to paying customers or a restricted group; and
- the licence provides the rights to make the software freely accessible, usable, modifiable and redistributable.
If the code is not public or the licence does not grant the full set of rights, the specific FOSS treatment does not apply. A licence name or “open source” marketing claim is insufficient without Article 3(48)’s conditions.
Who is responsible for the project?
Under the Commission guidance, FOSS is under the responsibility of the person that publishes it and exercises primary control over development, releases and distribution decisions—often a maintainer or governing organisation.
A contributor who merely submits a pull request, patch or feature without controlling the roadmap, releases or governance does not become a manufacturer or steward through that contribution. Commit permission alone need not establish responsibility.
For distributed community governance, document who signs releases, manages security notices, decides branches and distribution, operates development infrastructure and determines the project’s long-term direction.
Is supply in the course of a commercial activity?
FOSS placed on the market in the course of a commercial activity is within the ordinary manufacturer regime. A zero price does not automatically take it outside the CRA.
Indicators of commercial activity
- charging for the software, binaries, current release, an essential feature or security updates;
- a paid enterprise edition where access to the edition or its benefits is conditional on payment;
- an app monetising other products or services, such as advertising, commission, subscriptions, paid servers or IP addresses;
- requiring personal-data processing for purposes other than solely the software’s security, compatibility or interoperability;
- a “donation” that is effectively a condition of access to the current release, essential features or security fixes.
What generally does not establish commercial activity by itself
- optional consulting, training or support separate from free access to the software and updates;
- voluntary donations without an intention to make a profit and without product-linked consideration;
- a grant, sponsorship, bounty or paid feature development that is subsequently openly shared and freely available to everyone;
- the circumstances of development or the way development was financed;
- activity by a not-for-profit legal person structured so that all earnings after costs pursue not-for-profit objectives—although that person may be a steward.
Commercial activity requires a case-by-case assessment of all circumstances, including regularity of supply, product characteristics, supplier intention and links to monetised services.
Community and paid editions
Assess editions separately. Where an organisation provides a non-monetised community edition and a separate paid enterprise edition:
- it may be the manufacturer of the paid edition;
- it may be the steward of the community edition if, as a legal person, it provides sustained support for commercial use and ensures viability;
- duties and evidence must be assigned to the specific edition, not automatically carried across every release.
Codebase similarity alone does not make the non-monetised community edition a product placed on the market. Its own supply and monetisation model is decisive.
Open-source software steward test
Answer every question for the specific project:
-
Am I a legal person other than the manufacturer of this FOSS?
A natural person cannot be a steward under the CRA definition.
-
Do I publish the FOSS without placing it on the market in a commercial activity?
If I monetise supply, assess the manufacturer role instead.
- Is it intended for commercial activities, such as integration into commercial products or services?
- Do I systematically provide sustained support for the project?
- Do I ensure its viability?
If every answer is yes, you are likely its steward. Support may include project governance, hosting and managing source code or collaboration infrastructure, managing releases and signing keys, handling security reports or providing engineering resources. General hosting without systematic support and viability work for the specific project may not be enough.
Article 24 steward duties
1. Put in place and verifiably document a cybersecurity policy
The policy must foster secure development and effective handling of vulnerabilities by developers. It must reflect the steward’s nature and legal and organisational arrangements, and cover in particular:
- documenting, addressing and remediating vulnerabilities;
- voluntary vulnerability reporting under Article 15; and
- sharing information about discovered vulnerabilities within the open-source community.
In practice, it should identify a contact and secure reporting channel, triage and escalation, patch and release ownership, coordinated disclosure, cooperation with downstream manufacturers, protection of sensitive information and evidence retention.
2. Cooperate with market-surveillance authorities
At an authority’s request, the steward cooperates to mitigate cybersecurity risks. Following a reasoned request, it provides the policy documentation in paper or electronic form and in a language the authority can easily understand. If non-compliance is found, the steward must take appropriate corrective action.
3. Report according to the support provided
From 11 December 2027, Article 24(3) applies to a steward to the following extent:
- where it is involved in product development, Article 14(1) applies to reporting an actively exploited vulnerability of which it becomes aware;
- where a severe incident affecting product security impacts network and information systems the steward provides for development, Article 14(3) and (8) apply, including the relevant user information duty.
The reporting scope therefore depends on the support. An organisation providing only non-technical governance may not have the same notification duty as a steward providing repositories, build infrastructure or engineering resources. Where mandatory reporting does not apply, its policy should still foster proper handling and voluntary reporting.
CRA notifications are submitted through the CRA Single Reporting Platform. Go to Reporting actively exploited vulnerabilities and severe incidents for the current channel, deadlines and required content.
A steward is not a “light manufacturer”
A steward does not automatically have the manufacturer’s complete obligations: it does not issue an EU declaration of conformity or affix CE marking to a non-monetised community project merely because it is the steward, and it does not conduct manufacturer conformity assessment for that reason. If it begins monetising and placing that specific FOSS on the market, it may become its manufacturer from that point.
Article 64(10) excludes administrative fines for CRA infringements by open-source software stewards. This does not remove their obligations: a market-surveillance authority may require compliance and appropriate corrective action.
Duties of a manufacturer integrating FOSS
The manufacturer of a resulting product is responsible for that product’s compliance, regardless of whether an integrated component has its own manufacturer, steward or only a community. It should:
- identify component version, provenance and dependencies in the software bill of materials;
- examine maintenance status, known vulnerabilities, security policy and available updates;
- exercise due diligence when integrating it and assess risks to the resulting product;
- report a component vulnerability to the person or entity manufacturing or maintaining that component;
- when it develops a security fix for the component, share relevant code or documentation with its manufacturer or maintainer where appropriate, preferably in machine-readable form and consistently with the licence;
- assess whether the vulnerability is reachable or actively exploited in its particular integration and meet its own vulnerability-handling and reporting duties.
A future voluntary security attestation programme under Article 25 may support due diligence, but it will not replace the manufacturer’s responsibility or any mandatory conformity assessment of the resulting product.
What to do now
- Create a register of FOSS projects and versions you publish, steward or integrate.
- Record primary control, business model, intended downstream use and type of support for each.
- Separate community and paid releases and assign manufacturer, steward or no publisher duty as appropriate.
- If you are a steward, approve a verifiable cybersecurity policy and an authority-cooperation process.
- Map technical support to Article 24(3) reporting and prepare for reporting from 11 December 2027.
- If you manufacture a product integrating FOSS, continue to Manufacturer obligations, Conformity assessment and CRA reporting.