← CRA Guide
Article 24

Obligations of Open-Source Software Stewards Under the CRA

Article 24 introduces the concept of 'open-source software steward' — an entity that provides a platform or support for the ongoing development of open-source software used in products with digital elements, without placing a product on the market itself. Open-source stewards are not manufacturers and are not subject to CE marking or EU Declaration of Conformity obligations. However, they must put a cybersecurity policy in place, publish a vulnerability disclosure process, and cooperate with market surveillance authorities — recognising their structural role in the supply chain.

Effective: September 2026Applies to: Non-profit foundations managing open-source software widely used in CRA-regulated products

Who Is an Open-Source Software Steward?

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.

CRA reference:Article 24(1)

The Cybersecurity Policy Requirement

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.

CRA reference:Article 24(2)

Vulnerability Disclosure for Open-Source Stewards

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

Note that open-source stewards are not subject to the Article 14 mandatory notification deadlines (24h/72h/14d to ENISA). Their CVD obligations are process-level requirements, not time-triggered regulatory notifications. They may voluntarily notify under Article 15.

CRA reference:Article 24(3)

Cooperation with Market Surveillance Authorities

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.

CRA reference:Article 24(4)

What Open-Source Stewards Are NOT Required to Do

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
  • No Article 14 mandatory notifications — no 24h/72h deadlines to ENISA
  • 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.

CRA reference:Article 24

CVD Portal helps you comply with Article 24 automatically.

Public submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free for Article 14 compliance — for all manufacturers placing products with digital elements on the EU market.

Start your free portal

Frequently asked

Does my open-source project need to register with anyone to be treated as a steward?+

No registration is required to be treated as an open-source software steward. The classification is determined by whether your entity and activities meet the Article 24 definition. ENISA provides guidance to help organisations self-assess their steward status. Documenting the basis for steward classification is advisable in case of MSA scrutiny.

What if our foundation has some commercial revenue (e.g., training, consulting)?+

Article 24's 'non-commercial' requirement does not mean zero revenue. A foundation with incidental commercial activities (consulting, training, hosted services) may still qualify as a steward if the primary purpose is non-commercial open-source development. The key test is whether the software is placed on the market as a product — if yes, manufacturer obligations apply. If the software is freely available and not sold as a product, steward treatment is likely appropriate.

Are open-source libraries used as components subject to the CRA at all?+

Open-source libraries used as components are regulated through the manufacturers who integrate them. The manufacturer of the final product is responsible for due diligence on the security of integrated components (Article 13(6)-(8)). The CRA does not impose direct obligations on open-source component authors who are not stewards, but stewards of widely-used libraries face the Article 24 obligations.

How should we document our steward status in case of market surveillance inquiry?+

Maintain a brief written record explaining: (1) why your entity qualifies as a steward rather than a manufacturer; (2) the published cybersecurity policy covering your projects; (3) your published CVD process. Store this alongside your project's security documentation so it can be produced quickly if an MSA asks questions.

Need a CVD policy that satisfies Article 24?

Download a free CRA-compliant template and deploy it in minutes.

Browse templates →