CRA FAQ

No. Most open source projects will not have a steward.

A steward must be a "legal person" (Article 3(14)), such as a company, and most open source projects are not supported by a company or a foundation.

The stewarding organization must also have "the purpose or objective of systematically providing support on a sustained basis" (Article 3(14)) and their software must be "ultimately intended for commercial activities" (Recital 19). Organizations which do not meet those tests will also not be considered stewards.

Open-source software steward is a term defined in Article 3(14) of the CRA, to subject specific organisations to a subset of CRA obligations because they exist to support free and open source software that is intended for commercial activities:

‘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;

Recital 19 states "Open-source software stewards include certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities." At FOSDEM 2024, the European Commission provided three examples of entities the co-legislators had in mind:

1. Foundations supporting specific FOSS projects
2. Companies that build FOSS for their own use but make it public
3. Not-for-profit entities that develop FOSS

Open-source software stewards are subject to a "light-touch and tailor-made regulatory regime" (Recital 19), defined in Article 24. This regime includes the following:

• Maintaining a cybersecurity policy.
• Maintaining a vulnerability management policy.
• Cooperating with Market Surveillance Authorities when needed.
• Notifiying the relevant CSIRT and ENISA, and informing users of actively exploited vulnerabilities and severe incidents in certain circumstances. More detailed information in What are the notification obligations of open-source software stewards ?

Per Article 24(3), open-source software stewards are subject to a subset of the notification obligations of manufacturers defined in Article 14.

• If a steward is involved in the development of an open source project that it stewards, it must notify both its relevant CSIRT and ENISA of any actively exploited vulnerability in that project, see Article 14(1).
• If a steward provides IT infrastructure used for the development of an open source project that it stewards, it must notify its relevant CSIRT and ENISA of any severe incident having an impact on the security of that project, see Article 14(3).
• In both of those cases, it must inform impacted users (and where appropriate all users) of that open source project through available channels (e.g. changelog, blog post, mailing list, direct contact when available, etc.), see Article 14(8).

The table below provides an actionable summary of those notification and information obligations that accounts for stewards not necessarily being aware of who their users are nor being able to reach out to them individually.

Open-source software stewards must document their cybersecurity policy in a verifiable manner, as described in How do open-source software stewards demonstrate that they meet their obligations?. For evidence specifically related to vulnerability reporting compliance, stewards should be prepared to demonstrate how their policy fosters voluntary reporting of vulnerabilities by developers, as required under Article 24.

Market surveillance authorities, potentially in cooperation with the relevant CSIRTs, may have more specific requirements for what evidence they expect. The exact requirements may vary depending on which authority has jurisdiction, as Member States designate their own market surveillance authorities for this purpose (Article 52(2)).

Identifying the relevant CSIRT for a given steward remains an open question pending further clarification (see [[pending-guidance/csirt-identification]]). Until this is resolved, stewards should focus on maintaining clear, verifiable documentation of their vulnerability handling processes and be prepared to provide this documentation to authorities upon request, in a language that authority can easily understand (Article 24(2)).

No, open-source software stewards are not required to provide a Software Bill of Materials (SBOM). The CRA places SBOM obligations on manufacturers, not stewards.

SBOMs are most meaningful when created by manufacturers at the point of integration, since they are responsible for documenting the components contained in their products with digital elements (Recital 77). The manufacturer's SBOM reflects the specific components they have integrated and helps them track vulnerabilities throughout the supply chain.

However, stewards may choose to provide SBOMs voluntarily. This could be done as part of security attestations, alongside builds, or through other means that help downstream manufacturers exercise due diligence and produce their own SBOMs more easily. Such voluntary efforts can support the broader open source ecosystem without creating regulatory obligations for stewards.

For more on steward obligations, see What are the obligations of open-source software stewards ?.

Open-source software stewards are not required to produce the technical documentation that manufacturers must prepare under Article 31. Their obligations are limited to putting in place and documenting a cybersecurity policy as described in Article 24.

However, stewards may voluntarily choose to provide additional documentation as part of a security attestation program to support manufacturers exercising due diligence when integrating the steward's software into their products.

For more details on steward obligations, see What are the obligations of open-source software stewards ?. For information on security attestations, see What is a security attestation in the CRA?.

None. The essential cybersecurity requirements set out in Annex I do not apply to open-source software stewards under their light-touch regulatory regime.

Stewards are subject only to the specific obligations outlined in Article 24, which focus on facilitating secure development practices rather than meeting the product-level requirements that apply to manufacturers. As Recital 19 explains, the steward regime "should take account of their specific nature and compatibility with the type of obligations imposed" and recognises that stewards "should not be permitted to affix the CE marking" to the products they support—precisely because they are not required to demonstrate conformity with Annex I requirements.

However, stewards may choose to participate in voluntary security attestation programmes established under Article 25. These programmes allow assessment of conformity with "all or certain essential cybersecurity requirements or other obligations laid down in this Regulation." When stewards obtain such attestations, it can help lighten the due diligence burden for manufacturers who integrate the attested open source components into their own products.

For more on steward obligations generally, see What are the obligations of open-source software stewards ?.

Yes, a company can be classified as an open-source software steward. The CRA defines a steward as "a legal person, other than a manufacturer" that systematically provides sustained support for the development of free and open-source software intended for commercial activities (Article 3(14)). Recital 19 provides additional context: "Open-source software stewards include certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities."

A company can even be a steward for a project that also has a commercial version. In this scenario, the company would be a manufacturer for the paid or monetised version (with corresponding manufacturer obligations), while simultaneously being a steward for the free or "community" version that it publishes but does not monetise.

This dual role is possible because the CRA assesses each product separately:

• Manufacturer obligations apply to the monetised version and flow to organisations that have purchased it or are the source of monetisation.
• Steward obligations apply to the non-monetised open source version and focus on fostering secure development and effective vulnerability handling for users of that version.

For more details on how manufacturers and stewards interact, see Can a manufacturer also be an open-source software steward ?.

A manufacturer and an open-source software steward are completely different roles under the CRA, with distinct origins and purposes.

Manufacturer is a role established in the New Legislative Framework (NLF) and the Blue Guide. In the context of the CRA, it applies to any natural or legal person who develops or manufactures products with digital elements and markets them under their name or trademark—whether for payment, monetisation, or free of charge (see Article 3(13)). The key factor is engaging in commercial activity by placing products on the market.

Open-source software steward is a new role created specifically for the CRA to accommodate the unique nature of open source development. As defined in Article 3(14), a steward is a "legal person, other than a manufacturer", that systematically provides sustained support for free and open-source software intended for commercial activities and ensures its viability. This role recognises organisations that support open source outside of direct monetisation—such as foundations or entities that publish free and open-source software in a business context without placing it on the market themselves (see Recital 19).

The steward role exists because many important open source projects are published but not "made available on the market" in the CRA's legal sense. Without this category, the organisations supporting such projects would fall outside the CRA entirely. The steward obligations are deliberately "light-touch and tailor-made" compared to manufacturer obligations, reflecting that stewards do not directly monetise the software they support.

For more details, see What is an open-source software steward ? and What is a manufacturer ?.

Yes, you can be an open-source software steward of your own codebase or someone else's.

Ownership or authorship of the code is not a determining factor for stewardship under the CRA. What matters is whether a legal person systematically provides support on a sustained basis for the development of specific free and open-source software intended for commercial activities, and ensures the viability of that software, as defined in Article 3(14).

For example, a company that develops open source software for integration into its own products, then publishes it separately without placing it on the market, can be the steward of that software. Similarly, a foundation can be a steward for projects it hosts and supports, regardless of whether foundation staff originally authored the code.

A legal person can even be a manufacturer for one version of software (such as a paid edition) while simultaneously being a steward for another version (such as a community edition) of the same project. See Can a manufacturer also be an open-source software steward ? for more details on this scenario.

No. Whether a non-profit uses donations to pay developers or for other purposes is irrelevant to determining whether there is an intention to monetise.

The CRA explicitly states that "the development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives" (Recital 18).

Furthermore, "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" (Recital 18).

For more on how intention to monetise is assessed, see What does 'intention to monetise' mean under the CRA?.