CRA FAQ

No. How a product is developed or financed does not determine manufacturer status under the CRA.

A company becomes a manufacturer only when it places a product on the market; meaning it supplies the product for distribution or use in the course of a commercial activity under its own name or trademark, whether for payment or free of charge (Article 3(13)).

A key factor is whether the company markets the product under their own name or trademark. Simply funding development or maintenance of an open source project does not make the funder a manufacturer (Recital 18).

No. Companies that get paid for open source development work are service providers, not manufacturers under the CRA.

The CRA applies to products being placed on the EU market, not to development services. A manufacturer is defined as a person who develops or manufactures products with digital elements and "markets them under its name or trademark" (Article 3(14)). A company providing contracted development services for open source software it is not responsible for is not marketing a product under its own name.

This distinction holds regardless of the client's status. Whether the client is an open-source software steward, a manufacturer, or another type of organization, the service provider relationship does not make the contractor a manufacturer. The determining factor is who places the product on the market under their name or trademark, not who performs the development work.

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 ?.

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 ?.

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 ?.

No — the mere popularity of your open source project does not expose you to CRA regulation.

The CRA does not use popularity, user count, or widespread adoption as criteria for determining whether a project falls within scope. What matters is whether the software is supplied in the course of a commercial activity — meaning whether it is monetised or placed on the market under circumstances that indicate commercial intent.

As Recital 18 clarifies, "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." This means you can have millions of users, including in enterprise or critical infrastructure environments, without triggering CRA obligations, as long as you are not monetising the project.

While popularity itself creates no legal obligations, it may:

• Increase visibility to downstream users or market surveillance authorities
• Lead to requests from companies seeking help with their own compliance efforts
• Create demand for security attestations for your project

None of these change your legal status under the CRA unless you begin monetising or otherwise supplying the software in a commercial context.

For more details on what determines whether an open source project is in scope, see What criteria determine whether an open source project is in scope of the CRA?. For information on what constitutes monetisation, see Am I subject to the CRA if I maintain, but do not monetize, an open source project? and Am I subject to the CRA if I earn a living from the open source project I maintain?.

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.