CRA FAQ

Open-source software stewards should expect engagement focused on governance and ecosystem risk, not punishment for individual defects.

Market surveillance authorities are likely to see stewards as system coordinators and will expect them to play a role where their actions materially influence security outcomes across many projects. Enforcement will emphasize processes and accountability—such as vulnerability handling, release practices, and coordination mechanisms—rather than the software itself.

Under Article 52(3), when a market surveillance authority finds that a steward does not comply with its obligations under Article 24, it "shall require the open-source software steward to ensure that all appropriate corrective actions are taken." Corrective actions are likely to involve clarifying roles, improving baseline practices, and publishing or following clear policies.

Stewards also benefit from explicit protection against administrative fines. [[Article 64(10)(b)]] provides that administrative fines "shall not apply to [...] any infringement of this Regulation by open-source software stewards." Sanctions would be unlikely unless a steward controls critical infrastructure and persistently ignores known, systemic risks—and even then, the available remedy would be corrective action rather than financial penalties.

For more details on steward obligations and the consequences of non-compliance, see What are the obligations of open-source software stewards ? and What happens when an open-source software steward doesn't meet its obligations?.

Larger manufacturers should expect earlier, more structured, and more demanding enforcement from market surveillance authorities, including the possibility of penalties and public corrective measures.

Authorities prioritize large manufacturers because fixes at scale have market-wide impact, and because these actors are presumed to have the resources to comply fully with the CRA's requirements.

Mirroring later-stage GDPR enforcement, authorities are more likely to use proactive audits, coordinated inspections, and sector-wide actions (Article 52; Recital 114). Corrective actions may require systemic remediation across product lines, not just fixes for individual issues. Persistent non-compliance, misleading security claims, or repeated vulnerabilities increase the likelihood of formal orders, withdrawals, recalls, or fines (Article 57).

When setting administrative fines, authorities must consider "all relevant circumstances of the specific situation" including whether the manufacturer is a microenterprise or SME, and whether similar fines have already been applied by other authorities for the same infringement (Recital 120). Penalties must always be proportionate, but large manufacturers with greater resources can expect less leniency than smaller entities.

For more on non-compliance consequences, see What will happen to non-compliant products?.

Small and medium manufacturers should expect proportionate, step-by-step enforcement focused on bringing products into compliance rather than imposing immediate penalties. Market surveillance authorities typically scale expectations to risk and capacity, not to formal legal obligations alone.

Authorities are required to carry out their activities "taking due account of the size of undertakings, in particular as regards microenterprises and small and medium-sized enterprises" (Article 47). When determining fines, authorities must consider "whether the manufacturer is a microenterprise or a small or medium-sized enterprise, including a start-up" (Recital 120).

Based on patterns seen under GDPR enforcement, authorities will usually begin with guidance, warnings, or requests for corrective action before considering penalties. Common corrective actions include patching vulnerabilities, improving update mechanisms, or fixing insecure default configurations. Penalties or market restrictions are more likely only if a manufacturer fails to act, repeats issues, or puts users at significant risk.

Smaller entities also benefit from explicit legal safeguards: all penalties must be "effective, proportionate and dissuasive" (Recital 120), and penalties imposed on natural persons must account for "the economic situation" and "size" of the entity (Recital 121). Microenterprises and small enterprises are explicitly exempted from fines for failing to meet the 24-hour early warning deadline for vulnerability and incident notifications (Recital 120).

For more details on penalties, see As a manufacturer , if I make a mistake or a security flaw is found in my project, will I get in trouble?.

Monetizing open source maintainers should expect low-intensity, corrective-first enforcement focused on fixing concrete issues rather than penalties, unless their software causes clear cybersecurity risk at scale.

Authorities are likely to engage only where the maintainer's activities look commercial in practice—for example, paid support, hosted services, enterprise features, or control over releases—not where individuals contribute code without market control. For more on what constitutes monetization that triggers manufacturer status, see Am I subject to the CRA if I earn a living from the open source project I maintain?.

Based on patterns seen under GDPR enforcement, authorities will initially be reactive, responding to complaints, incidents, or known vulnerabilities. Typical actions will be requests to remediate—patching vulnerabilities, improving default security settings, or clarifying responsibilities—rather than immediate fines. All penalties must be "effective, proportionate and dissuasive" (Article 64; Recital 120).

Escalation is most likely if a maintainer who qualifies as a manufacturer ignores known vulnerabilities, misrepresents the security status of their software, or repeatedly fails to cooperate with authority requests. When penalties are imposed on natural persons or small entities, authorities must consider "the economic situation" and "size" of the entity (Recital 121; Article 64). Additionally, microenterprises and small enterprises are explicitly exempt from fines for failing to meet the 24-hour early warning notification deadline (Article 64(10)).

For more details on potential penalties, see If I maintain an open source codebase, and am treated as a "manufacturer" or "steward", what penalties could I face for violating the CRA?

The CRA defines "free and open-source software" in Article 3(48) as "software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable."

This definition mirrors the common understanding of open source's copyright aspects, aligning closely with the widely recognised "four freedoms" of free software and the Open Source Initiative's Open Source Definition. Recital 18 further clarifies that free and open source software is "developed, maintained and distributed openly, including via online platforms."

Notably, the CRA's requirement that source code be "openly shared" goes beyond what the OSD or Free Software Definition formally require; neither explicitly mandates public availability of source code, only licensing rights. This means arrangements where source is not publicly available would not qualify as free and open source software under the CRA, even if the licence itself did.

The definition focuses specifically on the software source code and its licensing terms. For software to qualify as free and open source under the CRA, the licence must provide rights to:

• Freely access the software
• Use it without restriction
• Modify it
• Redistribute it (including modified versions)

Additionally the code must be publicly available.

This definition is relevant for determining whether the CRA's provisions for open source software stewards or the exemptions for non-commercial open source development may apply to a particular project.

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.