Obligations of Open-Source Software Stewards Under the CRA

An open-source software steward is defined as a legal person (not an individual) that:

1. Provides a platform or environment for the development or distribution of open-source software intended for integration into products with digital elements
2. Does so on a non-commercial basis — or where commercial activities do not constitute the primary purpose
3. Does not place products on the market itself in a way that makes it a manufacturer under Article 13

• Linux foundations and similar non-profit organisations managing major open-source projects
• Public benefit entities maintaining security libraries, cryptographic toolkits, or operating system components
• Academic institutions managing software repositories used in commercial products

Individual developers who contribute to open-source projects — but do not manage the overall platform — are explicitly excluded from the steward definition.

Article 24 requires open-source software stewards to put in place and document a cybersecurity policy covering:

• How security vulnerabilities in the managed software are identified, assessed, and addressed
• The processes by which security patches and updates are developed and released
• How external vulnerability reports are received and handled
• How the steward communicates security information to downstream users (manufacturers integrating the software)

This policy need not be as comprehensive as a manufacturer's full security development lifecycle documentation, but it must be documented and publicly accessible. The policy demonstrates that the steward takes a structured approach to security rather than an ad hoc one.

Article 24 requires open-source software stewards to operate a process for receiving and handling vulnerability reports — essentially a CVD policy equivalent. This process must:

• Provide a publicly accessible mechanism for reporting vulnerabilities (typically a security.txt file, a SECURITY.md in the repository, or a dedicated reporting form)
• Acknowledge receipt of vulnerability reports
• Provide reporters with a process timeline and coordinate disclosure
• Publish security advisories when vulnerabilities are fixed

Article 24(3) does extend parts of Article 14 to stewards, so the 24-hour and 72-hour clocks are not switched off across the board. How far they reach depends on the kind of support the steward provides, which is set out further below. Where a reporting duty does not apply, voluntary reporting under Article 15 stays open.

Article 24 requires open-source software stewards to cooperate with national market surveillance authorities (MSAs) when requested. This may involve:

• Providing information about the software's security properties, architecture, or known vulnerabilities
• Assisting MSAs in understanding the supply chain implications of a vulnerability in the managed software
• Providing technical documentation about the software's development processes and security controls

The cooperation obligation is less extensive than a manufacturer's obligations — MSAs cannot order product recall or CE marking withdrawal from an open-source steward. However, the cooperation obligation ensures that MSAs can get the information they need to assess the risk posed by vulnerable open-source components integrated into regulated products.

To avoid chilling open-source development, Article 24 explicitly carves out several obligations that manufacturers face but stewards do not:

• No CE marking — open-source stewards do not need to affix CE markings to software
• No EU Declaration of Conformity — no formal conformity declaration is required
• No conformity assessment — no notified body involvement is required
• Article 14 reporting only where the steward is involved — a steward that neither develops the product nor provides the systems used to develop it carries no 24h/72h duty, but Article 24(3) does apply Article 14(1), (3) and (8) to those that do
• No SBOM requirements — no formal software bill of materials obligation under Article 13(6)

Manufacturers who commercialise open-source software (sell it, monetise it, bundle it in commercial products) become manufacturers under Article 13 and lose the steward carve-out. The line between steward and manufacturer is primarily drawn by commercialisation.

Article 24(3) applies Article 14(1), (3) and (8) to stewards, and Commission guidance C(2026) 5252 makes clear that how far they apply depends on the kind of support the steward provides.

A steward providing only non-technical support, such as managing project branding, laying down governance rules, organising community events or collecting donations, is by definition not involved in developing the product and provides no network and information systems for it. It is not required to report actively exploited vulnerabilities, and not required to report severe incidents. Where it does become aware of an actively exploited vulnerability, for example through a security researcher, it should share the information with the maintainers in line with its cybersecurity policy, and voluntary reporting under Article 15 should be considered.

A steward that provides the underlying IT infrastructure, such as hosting source code repositories, version control or signing keys, must notify ENISA and the CSIRTs under Article 14(3) of severe incidents affecting that infrastructure which have an impact on the security of the products, and inform users where appropriate.

A steward that contributes engineering resources, by employing developers, coordinating development, reviewing or merging code, managing releases or handling vulnerability reports, must additionally notify actively exploited vulnerabilities under Article 14(1) and, where it has a direct relationship with impacted users, inform them under Article 14(8).

A steward is likely to learn of active exploitation through downstream reports, because the component sits inside other products. An entity that stops providing sustained support may cease to be a steward, and is encouraged to communicate that change clearly.