CRA FAQ

Yes, a company can be 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 (CRA Article 3(14), Guidance point 70). Recital 19 of the CRA adds: "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." "Other than a manufacturer" means a company is a steward only for software it publishes without selling it; the same company can be the manufacturer of other software it sells (Guidance points 71 and 73).

A company can even be a steward for a project that also has a commercial version. The company is then the manufacturer of the paid or monetised version, with the manufacturer's obligations, and at the same time the steward of the free or "community" version that it publishes without monetising (Guidance points 52, 53, and 76).

This dual role is possible because the CRA looks at each piece of software separately (Guidance points 72 and 74):

• Manufacturer obligations apply to the paid or monetised version.
• Steward obligations apply to the free open source version and focus on fostering secure development and effective vulnerability handling for its users.

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

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

Who owns or wrote the code does not decide stewardship under the CRA. What matters is whether a company or foundation (a legal person) systematically provides sustained support for the development of specific free and open-source software intended for commercial activities, and ensures its viability, as defined in Article 3(14) of the CRA (Guidance point 70).

For example, a company that develops open source software for its own products, then publishes it separately without selling it, can be the steward of that software (Guidance point 76, Example 29). Likewise, a foundation can be the steward of projects it hosts and supports, whether or not foundation staff wrote the code (Guidance point 78).

A company can even be the manufacturer of one version of the software (such as a paid edition) and at the same time the steward of another version (such as a community edition) of the same project (Guidance points 73 and 76). See Can a manufacturer also be an open-source software steward ? for more on this scenario.

No, common consulting arrangements do not make you a manufacturer. Helping a client install, configure or integrate software is providing a service, not placing a product on the market. The CRA applies to products, not to services, so providing a service does not make you a manufacturer (point 59 of the Commission guidance, Example 19 of the Commission guidance, see Does getting paid for open source software development make you a manufacturer?).

This also holds for consulting around an open source project you publish yourself. Selling implementation, integration, training or other professional services for your own open source software does not, by itself, make you its manufacturer, as long as the software can be downloaded, installed and updated freely and your services are optional (Guidance points 55 and 56, Example 18). What would make you a manufacturer is selling the software itself, for example a version whose updates or technical assistance only paying customers get: see Does providing technical support for a fee put you in scope of the CRA? and Am I subject to the CRA if I earn a living from the open source project I maintain?.

It is worth noting one exception: a service that substantially modifies open source software and provides it to customers without publishing your modifications publicly under an open source licence can make you a manufacturer of the derived work (Guidance point 59, CRA Article 22(1)).

No, receiving donations does not make you a manufacturer, as long as those donations cover your actual costs rather than generate profit.

The CRA says that "accepting donations without the intention of making a profit should not be considered to be a commercial activity", while "accepting donations exceeding the costs associated with the design, development and provision" of the software can be a sign of one (CRA Recital 15). Costs are broader than hosting and hardware: they include reasonable compensation for the people a company or foundation employs on the open source project, and an individual's reasonable living expenses (Guidance point 61).

Putting a donation link on your project is not, by itself, an intention to make a profit, and the Commission's guidance says a project supported only through donations is "unlikely to be considered to be placed on the market".

When assessing whether donations exceed your costs, consider all revenue related to the project, not just one income stream. If total project-related income significantly exceeds the costs of designing, developing, and maintaining the software, this could indicate an intention to profit, which may bring you into scope.

Donations naturally fluctuate, so a degree of flexibility applies: what counts is the overall picture over time, not a month where they exceeded expenses (Guidance point 61, Example 20).

Where donations clearly do make you a manufacturer is when donating is really the price of the software: access to it, to essential features or to updates depends in practice on making a donation, or donors get contractual benefits or exclusive advantages beyond community perks (Guidance point 62). Releases and security updates reserved for donors, or binaries and guaranteed fixes only for donors, are the guidance's examples (Guidance Examples 21 and 22). That is selling the software.

For more on what counts as actual costs, see What does 'actual costs' mean under the CRA?. For how living expenses factor in, see Can a natural person's living expenses count as 'costs' or is that profit?. For the other ways a project can be monetised, see Am I subject to the CRA if I earn a living from the open source project I maintain? and What does 'intention to monetise' mean under the CRA?.

Yes. Reasonable living expenses count as costs, not profit. An individual (a natural person) who publishes open source software and charges for technical support, receives donations or the like to cover their costs, including reasonable living expenses, is not considered to be monetising that software on that basis alone, and so is not in scope of the CRA (CRA Recital 15, Guidance points 58 and 61).

On paid support, see Does providing technical support for a fee put you in scope of the CRA?; on donations, see Does accepting donations make me a manufacturer?. For more on what counts as costs under the CRA, see What does 'actual costs' mean under the CRA?. For what constitutes profit, see What does 'make a profit' mean under the CRA?.

Not as long as what you earn from the project only covers your actual costs, which include a reasonable salary or living expenses (CRA Recital 15, Guidance points 58 and 61). See What does 'actual costs' mean under the CRA? for what counts.

If you earn more than that by charging for the open source software itself, you are monetising it, and the CRA treats you as its manufacturer, with the obligations of Article 13 of the CRA:

• Charging for the software: a price for the software or for its binaries (Guidance point 51), or updates, maintenance or technical assistance reserved for paying users (Guidance point 57). For an individual, a supported version whose price only recovers actual costs is the exception (Guidance point 58). Your manufacturer obligations apply only to the version you charge for: with a paid "enterprise" version and a free "community" version, you are the manufacturer of the enterprise version only, and the community version stays outside the CRA's scope provided you are an individual and not an organisation (see Can a solo maintainer be considered to be an open-source software steward ? for more on this distinction).
• Donations taken with the intention of making a profit (CRA Recital 15). Donations fluctuate, so a degree of flexibility applies, and a project supported only through donations is unlikely to be considered placed on the market; donations that are really the price of access are a sale (Guidance points 61 and 62). See Does accepting donations make me a manufacturer?.
• See What does 'intention to monetise' mean under the CRA? for the other forms monetisation can take, such as monetising other services through the software or requiring users' personal data.

Money that is not for the software itself does not count, whatever the amount:

• Sponsorship, grants or paid development of features that you then release to everyone: how the development was financed does not count (CRA Recital 18, Guidance points 63 and 65).
• Paid services around freely available software, such as consulting, training, integration or optional support: these are services, not a sale of the software, as long as anyone can download, install and update it without paying (Guidance point 56, Example 18). See Do common consulting arrangements make me a manufacturer? and Does providing technical support for a fee put you in scope of the CRA?.

Note however that if you are charging for a paid product built on your project, such as an "enterprise" edition, an open-core product, a plugin, etc., that product is covered by the CRA and you are its manufacturer. But that does not change the status of the open source version: that stays outside the CRA if you are an individual, and makes you its open-source software steward if you are a company or foundation (point 52 of the Commission guidance, point 53 of the Commission guidance, see Can a solo maintainer be considered to be an open-source software steward ?).

No, providing technical support to an open source project for a fee does not put you in scope of the CRA, regardless of whether you are the one publishing it, provided access to the project is not restricted.

Support, consulting, training and similar professional services around open source software that anyone can download, install and update for free are services, not a sale of the software (Guidance points 55 and 56, Example 18). What puts you in scope is when a version of the software, or its updates and maintenance, is only available with paid support: that version is a product you sell, and you are its manufacturer (Guidance point 57, Example 17).

Indeed, if the source code itself is only available to paying customers, the software is not considered to be open source under the CRA, whatever its licence, as defined in Article 3(48) of the CRA (Guidance point 46).

Worth also noting one exception: a service that substantially modifies open source software and provides it to customers without publishing your modifications publicly under an open source licence can make you a manufacturer of the derived work (Guidance point 59, CRA Article 22(1)).

See also: Can a natural person's living expenses count as 'costs' or is that profit? and Does getting paid for open source software development make you a manufacturer?.

Under the CRA, 'actual costs' are the legitimate expenses of designing, developing, maintaining and providing open source software. You can recover them through various means (including donations and technical support) without that counting as a commercial activity (CRA Recital 15, Guidance points 58 and 61).

For individual maintainers, actual costs include:

• Expenses related to the design, development and maintenance of open source software
• Reasonable living expenses — an individual who covers their costs and earns a fair remuneration through support services or donations is not considered to be monetising the software on that basis alone (Guidance points 58 and 61)

For companies and foundations (legal persons), actual costs include:

• Costs associated with the design, development and provision of the open source software
• Reasonable compensation for the contributors and developers the organisation employs (Guidance point 61)

Recovering actual costs is not a commercial activity. Taking in significantly more than your costs, with the intention of making a profit, can be one: the CRA names "accepting donations exceeding the costs associated with the design, development and provision" of the software, and charging for technical support beyond the recovery of actual costs, as signs of a commercial activity (CRA Recital 15). The clearest case is when paying is in practice the price of the software: access to it, to essential features or to updates depends on donating or on buying support, or donors get exclusive benefits beyond community perks (Guidance points 56 and 62).

Donations naturally fluctuate over time, so a degree of flexibility applies when assessing them: whether you intend to make a profit is judged on the overall picture over time, not on a month where income exceeded expenses. A project supported only through donations is unlikely to be considered placed on the market (Guidance point 61).

See also: Can a natural person's living expenses count as 'costs' or is that profit?, What does 'make a profit' mean under the CRA? and Does accepting donations make me a manufacturer?.

Under the CRA, 'making a profit' means earning more money than your actual costs. The distinction matters because accepting donations, or charging for services, without the intention of making a profit is not a commercial activity (CRA Recital 15, Guidance point 61).

What counts as 'actual costs' depends on who receives the money:

• For individual maintainers, actual costs include the expenses of designing, developing and maintaining the software, and reasonable living expenses. An individual who covers their costs and earns a fair remuneration is not making a profit on that basis alone (Guidance point 58).
• For companies and foundations, actual costs include operating expenses, reasonable compensation for contributors and staff, and the other costs of designing, developing and providing the software (Guidance point 61).

Worth noting that not-for-profit organisations set up so that all earnings after costs go to their not-for-profit objectives are not supplying software commercially, even when they make a profit (CRA Recital 18, Guidance point 66). However, if such an organisation meets the definition of an open-source software steward, it has the steward's obligations instead (Guidance point 77).

Reply to their requests, stating the following:

- On the basis of [Recital 18][] of the Cyber Resilience Act, I do not fall within the scope of the regulation, and cannot be considered as a Manufacturer or an Open source software steward under the Cyber Resilience Act.
- On the basis of [Recital 15 of the Product Liability Directive][PLD Recital 15], I cannot be held liable for your use of my code.
- **While I don't have obligations towards you, you may have some towards me:**
	- On the basis of [Article 13(6)][] the Cyber Resilience Act, if you believe you have found a security flaw in this code, you are responsible for reporting it by following the vulnerability disclosure process here: << project link >>. You are also responsible for fixing it within your product and providing the fix upstream.

[Recital 18]: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_18
[Article 13(6)]: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_13
[PLD Recital 15]: https://eur-lex.europa.eu/eli/dir/2024/2853#rct_15	

CSIRT stands for Computer Security Incident Response Team.

In Europe, there are multiple national CSIRTs which are part of the European Union CSIRTs network.

But Article 12(1) of the NIS 2 Directive states that each European country must designate a single CSIRT to manage coordinated vulnerability disclosures.

In the context of the CRA, that CSIRT is the relevant CISRT that is referenced throughtout the text and defined as the CSIRT designated as coordinator in Article 3(51) of the CRA.

If you are headquartered in Europe, you can easily find the relevant CISRT on the member section of the network's website.

If you are not headquartered in Europe, Article 17(4) of the CRA explains the criteria manufacturers should use to identify the relevant CSIRT.

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

A steward must be a "legal person" (CRA 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" (CRA Article 3(14)) and their software must be "ultimately intended for commercial activities" (CRA Recital 19). Organizations which do not meet those tests will also not be considered stewards.

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

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

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) of the CRA, when a market surveillance authority finds that a steward does not comply with its obligations under Article 24 of the CRA, 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) of the CRA 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?.

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 of the CRA, which focus on facilitating secure development practices rather than meeting the product-level requirements that apply to manufacturers. As Recital 19 of the CRA 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 of the CRA. 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 of the CRA.

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 (CRA 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 (CRA Article 24(2)).

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) of the CRA). 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) of the CRA, 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 of the CRA).

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

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

• 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) of the CRA.
• 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) of the CRA.
• 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) of the CRA.

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 are subject to a "light-touch and tailor-made regulatory regime" (CRA Recital 19), defined in Article 24 of the CRA. 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 ?

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

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

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 (CRA 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 steward is a term defined in Article 3(14) of the CRA 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 of the CRA 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

Yes. Third party remote data processing solutions are in scope of the CRA. They are subject to the due diligence requirements defined in Article 13(5) of the CRA.

Remote data processing is defined in Article 3(2) of the CRA of the CRA. It extends the scope of the CRA to any remote backend software and hardware that supports a product's user-facing features (such as login, data storage, third party AI models, etc.).

Yes. Remote data processing solutions that are built in-house are subject to the CRA just as if they were a product. They are therefore subject to all of the essential requirements of Annex I of the CRA.

Absolutely! Any third-party infrastructure that supports remote data processing is in scope of the CRA and is subject to the due diligence requirements of Article 13(5) of the CRA.

No. Monetization by the original manufacturer is what determines whether a product is made available on the market. As per Recital 18 of the CRA, merely supplying open source components isn't indicative of a commercial activity:

Furthermore, the supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should be considered to be making available on the market only if the component is monetised by its original manufacturer. […] In addition, the mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity.

• As an individual, if you are monetizing your project without the intention of making a profit, you are outside the scope of the regulation.
• According to Recital 15 of the CRA of the CRA, monetising without intention of making a profit means you fulfil the following cumulative requirements:
  • You are not providing a software platform through which you monetise other services (for instance, Google's Android).
  • You are not requiring as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of your software. (in particular, you're not giving people access to your software in exchange for their personal data)
  • You are receiving donations or providing technical services in exchange for remuneration, where the total received does not exceed the cost of development of your software (hosting, hardware, compute etc..).

Note: We are waiting for clarification from the Commission as to if remuneration for hours worked on the project can be counted in the cost of development.

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 of the CRA; Recital 114 of the CRA). 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 (CRA 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 (CRA 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" (CRA 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" (CRA 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" (CRA Recital 120), and penalties imposed on natural persons must account for "the economic situation" and "size" of the entity (CRA 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 (CRA 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?.

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 (CRA 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 (CRA 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" (CRA 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.

The term Manufacturer is defined in Article 3(13) of the CRA of the CRA:

‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge;

No. Contributions to open source projects are explicitely not in scope of the CRA, as stated in Recital 18 of the CRA:

This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility.

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 of the CRA; Recital 120 of the CRA).

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 of the CRA; Article 64 of the CRA). Additionally, microenterprises and small enterprises are explicitly exempt from fines for failing to meet the 24-hour early warning notification deadline (CRA 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?

No. Receiving grants does not make you a manufacturer under the CRA.

Grants provide financial support for the development of open source projects, but they are not a commercial transaction where the recipient is monetising a product that the grantor is purchasing. The CRA explicitly states that "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" (CRA Recital 18).

Similarly, "the mere fact that an open-source software product with digital elements receives financial support from manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature" (CRA Recital 18).

For more information on what does trigger manufacturer obligations, see What criteria determine whether an open source project is in scope of the CRA?.

No. As defined in Article 3(14) of the CRA, an open-source software steward must be a legal person, which in the context of the CRA means a legal entity such as a business or nonprofit.

If you are the maintainer of an open source codebase, and you do not monetize it, then the CRA does not apply to you.

The CRA applies

only in relation to products […] supplied […] in the course of a commercial activity (Recital 15 of the CRA, emphasis added)

And it states that

the provision of […] free and open-source software that are not monetized by their manufacturers should not be considered to be a commercial activity (Recital 18 of the CRA, emphasis added)

Yes, you can get paid to develop an open source project without being considered a manufacturer under the CRA.

The CRA distinguishes between being paid for the software (monetisation) and being paid to work on the software (development funding). Receiving payment to develop or maintain an open source project does not, by itself, make you a manufacturer. As Recital 18 of the CRA clarifies, "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."

This means that various common funding arrangements do not trigger manufacturer status:

• Employment or contracting: Being hired or contracted to work on an open source project does not make you a manufacturer—your employer or client may have obligations, but you as a paid developer do not.
• Grants and sponsorships: Receiving grants, sponsorships, or foundation funding to support development work does not constitute monetisation of the software itself.
• Donations for living expenses: A natural person receiving donations that cover reasonable living expenses and development costs is not considered to be monetising the project.

What does make someone a manufacturer is monetising the software itself—for example, by charging for access to the software, selling paid support services that exceed cost recovery, or using the software as a platform to monetise other services.

For more information on what constitutes monetisation, see Am I subject to the CRA if I earn a living from the open source project I maintain?. For details on how contributions affect CRA status, see Am I subject to the CRA if I only contribute to an open source project?.

If you are a solo or small-team maintainer of an open source codebase, but do get treated as a manufacturer or steward for some reason (such as monetization), you may be subject to some penalties. However, the penalties should be limited. In particular:

• If you are regulated because you are a steward, stewards are explicitly exempted from any fines, though you may still be required to take corrective actions for any problems that are uncovered. See Article 64 of the CRA.

• If you are regulated because you are a manufacturer, penalties must still be constrained. Specifically, all penalties must be "proportionate" (Recital 120 of the CRA; Article 64 of the CRA). In addition, when imposed on a natural person, the penalties must take into account "the economic situation" and "size" of the entity (Recital 121 of the CRA; Article 64 of the CRA). As a result, while it is not formally required, most regulators will likely to request corrective action before imposing a fine.

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 of the CRA 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?.

No. As defined in Article 3(14) of the CRA, an open-source software steward must be a legal person (e.g. a company, a foundation, an association) in contrast with a natural person (i.e. a human being). The obligations of open-source software stewards described in Article 24 of the CRA therefore do not apply to solo maintainers acting in their personal capacity.

However, should a solo maintainer set up a single-member company that is a legal entity in its own right, distinct from the natural legal persona of the solo maintainer, that entity could qualify as an open-source software steward if it meets the criteria for doing so.

It is also worth noting that natural persons who monetise their project become subject to the CRA as manufacturers. In that case, they face the same obligations as any other manufacturer under Article 13 of the CRA, not the lighter-touch obligations that apply to open-source software stewards under Article 24 of the CRA. For more on what qualifies as monetisation, see Am I subject to the CRA if I earn a living from the open source project I maintain?.

Sponsorware is a model where sponsors receive early access to software that is later released as open source. Under the CRA, the regulatory treatment depends on which phase of the sponsorware model is being considered.

During the exclusive sponsor phase, when only paying sponsors can access the software, this arrangement might be considered as tailor-made development. As explained in When is a product "tailor-made"? What documentation is required in these cases?, the person publishing the software would be considered a manufacturer during that phase but could deviate from a small subset of the essential cybersecurity requirements provided they met the conditions outlined in Recital 64 of the CRA; the person publishing the software would be subject to the full obligations of a manufacturer otherwise.

Once the software is released as open source, it is treated like any other open source software under the CRA. At that point, the standard criteria for determining whether open source software is in scope apply; primarily whether the person publishing it is monetising it through that release. See Am I subject to the CRA if I earn a living from the open source project I maintain? for details on how monetisation affects CRA obligations.

The Blue Guide is one of the main reference documents of the European Commission explaining how to implement legislation based on the New Legislative Framework (NLF). Unlike the CRA, the Blue Guide does not have legal force. It predates the CRA and only discusses software as something embedded into a physical product, not as standalone. For this reason, until an updated version is available, the Blue Guide's guidance should be read in light of the CRA's wider scope and take into account the nuances introduced in the CRA for software. For example, on the concept of "commercial activity", Recital 18 of the CRA CRA provides more specific guidance on "monetisation" and "non-profit organisations" than is available in the Blue Guide's "Making available on the market" section.

The CRA states in Article 7(1) of the CRA that "the integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to the conformity assessment procedures referred to in Article 32(2) and (3)." Therefore, products do not automatically inherit the classification of an integrated component. Instead, it comes down to the intended core functionality.

Example: if an operating system, which is a type of product classified as important, is integrated into a product which provides functionality that is not classified as important (e.g., an alarm clock), then this particular product (the alarm clock) is not classified as important product. If the core functionality of the product itself however is an operating system and can be used as such, it qualifies as an important product.

Under the Cyber Resilience Act, due diligence refers to the obligation of manufacturers to ensure that any third-party components integrated into their products, including Free and Open Source Software, adhere to the essential cybersecurity requirements of Annex I of the CRA. Manufacturers remain responsible for the security of the final product as a whole, and failure to comply may result in administrative fines.

The appropriate level of due diligence depends on the nature and cybersecurity risk of the component. As outlined in Recital 34 of the CRA, due diligence typically involves one or more of the following actions:

• Verifying conformity: Checking if the component already bears the CE marking or has demonstrated conformity with the CRA, for example through a security attestation.
• Checking maintenance: Verifying that the component receives regular security updates (e.g., checking its update history).
• Vulnerability scanning: Ensuring the component is free from known vulnerabilities listed in public databases (e.g., the ENISA database).
• Security testing: Carrying out additional security tests relative to the risk.

If a vulnerability is identified during this process, the manufacturer must remediate it and share the applied fix with the upstream maintainer (i.e., open a merge/pull request upstream).

The CE mark is a distinctive symbol indicating that a product complies with the relevant EU product regulations. Under the CRA, only manufacturers are authorized to add the CE mark to a product. Open source software stewards and developers outside the scope of the CRA cannot do so.

Article 30 of the CRA of the CRA outlines how manufactures need to add the CE mark to the their product.

For hardware, the CE mark must be placed directly on the product. If this is not possible, it must be placed on the packaging and in the EU declaration of conformity.

For software, the CE mark must appear either in the EU declaration of conformity or on a website accompanying the software product, provided it is easily accessible to consumers.

Failure to properly add the CE mark may result in financial penalties.

The CRA Expert Group is a consultative body set up by the European Commission to provide it with advice and expertise during the implementation of the CRA. It is composed of 60 members which include:

• individual experts appointed in their personal capacities,
• industry representatives,
• trade and business associations,
• NGOs,
• member state authorities (plus the Norwegian Communications Authority), and
• ENISA.

Open source is particularly well represented, as the following open source organizations are members:

• the Apache Software Foundation,
• the Eclipse Foundation,
• OpenSSF, and
• the Sovereign Tech Agency.

As described in Article 9 of the CRA, the CRA Expert Group is consulted by the European Commission as it:

• prepares Guidance as described in Article 26 of the CRA,
• prepares the technical descriptions of the important and critical product categories described in Article 7 of the CRA and Article 8 of the CRA, and listed in Annex III of the CRA and Annex IV of the CRA respectively, and
• undertakes preparatory work for the evaluation and review of the CRA.

In practice, the CRA Expert Group meets in plenary sessions 2-3 times a year. It has multiple work strands on specific topics, including one on open source, which meet on an ad-hoc basis. The agenda and minutes of the plenary sessions are public and are available on the CRA Expert Group's offical page. Draft regulation and guidance shared with the CRA Expert Group may not be shared publicly until it is officially published.

You can find an explainer on expert groups in general on the European Commission's website.

Freeware that is not free and open-source software (FOSS) is treated differently under the CRA. Unlike FOSS, which benefits from specific exemptions based on how it is developed and distributed, non-FOSS freeware does not qualify for these carve-outs.

The CRA's special provisions for open source apply only to software that meets the definition of "free and open-source software"—meaning software whose source code is openly shared under a licence that allows it to be freely accessible, usable, modifiable, and redistributable (CRA Article 3(48)). Freeware that is distributed free of charge but without open source code and licensing does not meet this definition.

For freeware, the key question is whether it is supplied "in the course of a commercial activity" (CRA Article 3(22)). Even software provided free of charge can fall within the CRA's scope if there is commercial intent—for example, if the software is used to monetise other services, collects personal data for non-security purposes, or serves as part of a broader business model.

If freeware is supplied in the course of a commercial activity, the person or entity distributing it under their name or trademark would be considered a manufacturer and must comply with full CRA obligations, including conformity assessment and CE marking requirements. The fact that no price is charged does not, by itself, place the software outside the CRA's scope.

For more on what constitutes commercial activity, see What does 'intention to monetise' mean under the CRA?.

Under the CRA, 'intention to monetise' refers to the goal of generating revenue from a product, even when the product itself is provided free of charge. This concept helps determine whether software is being supplied in the course of a commercial activity.

Recital 15 of the CRA provides several examples of monetisation that go beyond directly charging for a product:

• Monetising related services: Providing a software platform through which the manufacturer monetises other services
• Monetising user data: Requiring the processing of personal data as a condition for use, for reasons other than exclusively improving the security, compatibility, or interoperability of the software
• Monetising support: Charging for technical support services beyond the recuperation of actual costs
• Excessive donations: Accepting donations beyond the recuperation of actual costs

The key distinction is whether revenue generation is a purpose of making the software available, rather than simply a means of covering legitimate development and maintenance costs.

For more on related concepts, see What does 'actual costs' mean under the CRA? and What does 'make a profit' mean under the CRA?.

The CRA defines "free and open-source software" in Article 3(48) of the CRA 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 of the CRA 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.

The Cyber Resilience Act (CRA) entered into force on December 11, 2024. Reporting obligations of actively exploited vulnerabilities and severe incidents (CRA Article 14) start to apply on September 11, 2026. All other obligations for software developers start to apply on December 11, 2027.

%%{init: {'theme':'base'}}%%
gantt
    title CRA Implementation Timeline
    dateFormat  YYYY-MM-DD
    axisFormat %Y
    tickInterval 1year

    Drafting phase: 2024-01-01, 2024-11-20
    Publication in the Official Journal of the EU (November 20, 2024): milestone, 2024-11-20, 5m
    Entry into force (December 11, 2024): milestone, 2024-12-11, 5m
    Implementation phase: 2024-12-11, 3y
    Notification of conformity of assessment bodies (June 11, 2026): milestone, 2026-06-11, 5m
    Reporting obligations of vulnerabilities and incidents (September 11, 2026): milestone, 2026-09-11, 5m
    All other obligations (December 11, 2027): milestone, 2027-12-11, 5m
    Application phase: 2026-09-11, 2029-06-30