CRA FAQ

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

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

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) explains the criteria manufacturers should use to identify the relevant CSIRT.

ENISA is the European Union Agency for Cybersecurity. Its is headquarted in Athens, Greece.

ENISA supports National and EU authorities, the private sector, and European citizens through various activities.

The role of ENISA is defined in the Cybersecurity Act (CSA).

You can find more information on ENISA's website.

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

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

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

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

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

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.

A harmonised standard is a standard adopted by one of the European Standardisation Organisations (ESOs). Certain (but not all) harmonised standards are referenced in the Official Journal of the European Union by the European Commission. Harmonised standards referenced in this way provide products that conform with them a presumption of conformity with the requirements covered by those standards. Harmonised standards may be referenced with restrictions, in which case they only provide partial presumption of conformity. The presumption of conformity provided by harmonised standards referenced in the Official Journal of the European Union is why it is expected that most organisations will choose to implement such standards when they exist, to comply with the CRA.

However, not all harmonised standards are referenced. Those that are not referenced are often foundational standards upon which other standards build. In general, only the vertical (product-specific) standards are referenced, though sometimes horizontal standards that cover generic requirements may be referenced with restrictions.

The ORC WG maintains a list of harmonised standards requested by the European Commission to the ESOs.

No. Monetization by the original manufacturer is what determines whether a product is made available on the market. As per Recital 18, 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, 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.

The CRA regulates natural and legal persons (either an individual or an organisation that has a legal personality, like a business, foundation or charity). There are three possible categories with descending requirements. These categories are manufacturer, Open Source Software Steward, or Out of Scope.

Note: At present, we believe that a natural person (an individual) cannot be considered an Open Source Software Steward, however we are currently verifying this with the European Commission. We will provide more detailed guidance as soon as possible.

• You are out of scope of the CRA (meaning you are not required to comply with the regulation), if you are a natural person (an individual), and:
  • you are not monetising your project at all, or
  • you are monetising your project, without the intention of making a profit. (See Question: What does "Monetizing without making a profit" mean?)

Note: Further information for legal persons (organisations, foundations, associations) will be provided here as soon as we receive further clarifications and information from the European Commission.

Yes, a manufacturer can also be an open-source software steward.

This can happen whenever a manufacturer releases open source software and meets the requirements to be the open-source software steward of that project.

A manufacturer of commercial open source software can even be the open-source software steward of the community edition of the same project that it commercializes. In such a case, it has manufacturer obligations to its customers and steward obligations to the users of its community edition.

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

• If you fail to comply with the CRA, you will likely receive a letter or email from Market Surveillance Authorities asking you to address the issue.
• If you continue to fail to address the issue as a manufacturer, you could receive a fine. The fine will be proportional to the size of your organisation and how severely you broke the law.
• Microenterprises or small enterprises are exempted from fines relating to the obligation to notify authorities about vulnerabilities and severe incidents within 24 hours.

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.

The term Manufacturer is defined in Article 3(13) 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, common consulting arrangements do not make you a manufacturer under the CRA. If you are a consultant providing services (such as helping a client install, configure, or integrate software), you are providing a service, not placing a product on the market.

However, there is an important exception: if you provide consulting services around an open source project that you publish and monetise (for example, selling implementation or integration services for your own software), this commercial activity may mean you are placing that software on the market. In that case, you would have manufacturer obligations toward your clients for that project.

Note that these manufacturer obligations would apply only to the monetised version of your software. For a non-monetised version of the same open source project, you would have steward obligations if you are an organisation (a legal person, see What is a legal person ?) that provides sustained support for its development. If you are an individual (a natural person), the non-monetised version falls outside the scope of the CRA entirely.

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

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.

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

The CRA clarifies that "accepting donations without the intention of making a profit should not be considered to be a commercial activity" (Recital 15). This includes reasonable compensation or living expenses for individual developers.

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. Since donations naturally fluctuate over time, a degree of flexibility applies—including considering the developer's broader financial situation.

Note that donations clearly linked to a service or benefit of equivalent value may not qualify as true donations—such arrangements could be viewed as commercial transactions.

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 broader monetisation questions, see Am I subject to the CRA if I earn a living from the open source project I maintain?.

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

Yes, reasonable living expenses count as costs, not profit. A natural person who publishes open source software and charges for technical support services to cover their costs—including reasonable living expenses—is not considered to be monetising that software on that basis alone.

This means individual open source maintainers can accept payment for support services to sustain themselves financially without automatically becoming manufacturers under the CRA. The key distinction is whether the income serves to recuperate actual costs (including fair remuneration) or whether it exceeds what's needed and becomes profit.

Similarly, donations that help cover a natural person's reasonable living expenses are considered costs, not profit. Accepting donations without the intention of making a profit is not considered a commercial activity (Recital 15).

For more on what counts as costs under the CRA, see What does 'actual costs' mean under the CRA?. For information on what constitutes profit, see What does 'make a profit' mean under the CRA?.

No. If your revenue only covers your actual costs—including a reasonable salary or living expenses—then you are not considered to be monetising the project, and you would not be subject to the CRA on that basis. See What does 'actual costs' mean under the CRA? for more details on what counts as actual costs.

However, if you are making a profit (revenue exceeding your costs), this likely indicates you are monetising the project. See What does 'intention to monetise' mean under the CRA? for what constitutes monetisation under the CRA. In that case, you would be considered a manufacturer for the software you monetise, with corresponding obligations under Article 13.

Even in the monetisation scenario, your manufacturer obligations apply only to the monetised version. For example, if you offer both a paid "enterprise" version and a free "community" version, you would be a manufacturer only for the enterprise version. The community version would remain outside the CRA's scope provided you are an indivual and not an organization (see Can a solo maintainer be considered to be an open-source software steward ? for more on this distinction).

No. As defined in Article 3(14), 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, 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, 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 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.

• If you are regulated because you are a manufacturer, penalties must still be constrained. Specifically, all penalties must be "proportionate" (Recital 120; Article 64). In addition, when imposed on a natural person, the penalties must take into account "the economic situation" and "size" of the entity (Recital 121; Article 64). 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 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?.

The CRA should have zero or minimal impact on most open source developers, so you should probably not shut down your open source projects because of the CRA. There are several reasons for this:

First, the CRA likely does not apply to you.

• If you're just a contributor, the CRA explicitly exempts you. For more detail, see Am I subject to the CRA if I only contribute to an open source project?
• If you're a maintainer, and you do not "monetise" your FOSS codebase, the CRA explicitly exempts you. For more detail, see Am I subject to the CRA if I maintain, but do not monetize, an open source project?
• If you're a maintainer, and you do generate revenue from your FOSS codebase, you may still be exempted, depending on exactly how you are monetizing the codebase and your participation in it. For more detail, see Am I subject to the CRA if I earn a living from the open source project I maintain?

Second, even if the CRA does ultimately apply to you, penalties for solo and small-team maintainers are unlikely to be severe. For more detail, 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?

As a result, we would strongly urge you not to shut down any open source projects (or your participation in those projects) just because of the CRA.

No. As defined in Article 3(14), 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 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, not the lighter-touch obligations that apply to open-source software stewards under Article 24. 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?.

Providing technical support for a fee may or may not put you in scope of the CRA, depending on your relationship to the open source project.

If you are the publisher of the project: Charging for technical support services that are closely associated with the supply of the software can constitute monetisation, which would make the software a product placed on the market. However, this only applies where the price charged "does not serve only the recuperation of actual costs" (Recital 15). If you're a natural person and the fees only cover costs related to design, development, and maintenance—including reasonable living expenses—this alone would not make you a manufacturer. If you're a legal person that meets the definition of open-source software steward, you would be subject to steward obligations rather than manufacturer obligations for the non-monetised version of the software.

If you are a not-for-profit organisation: There is additional flexibility. If your organisation is set up to ensure that all earnings after costs are reinvested in not-for-profit objectives, your activities are not considered commercial even if you charge for support services (Recital 18).

If you are not the publisher: You are simply a service provider, and services are not products with digital elements under the CRA. For example, if you help a customer install open source software on their server but don't distribute the software yourself, you are not placing any product on the market and are therefore not in scope.

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

Reply to their requests, stating the following:

- On the basis of [Recital 18](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_18 "⚖️ 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)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13 "⚖️ Article 13 - Obligations of manufacturers") 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.

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

In the context of the CRA, a legal person means an legal entity such as a business or nonprofit.

The CRA states in Article 7(1) 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 CRA, 'actual costs' refers to the legitimate expenses associated with designing, developing, maintaining, and providing software. These costs can be recovered through donations or fees for technical support without triggering commercial activity status.

For individual maintainers, actual costs include:

• Expenses related to design, development, and maintenance of the software
• Reasonable living expenses — a natural person covering their costs and earning a fair remuneration through support services or donations is not considered to be monetising the software on that basis alone

For legal persons (such as foundations or companies), actual costs include:

• Costs associated with design, development, and provision of the software
• Reasonable compensation for contributors and developers employed by the organisation

The key distinction is that recovering actual costs is not considered commercial activity, while significantly exceeding those costs — particularly with an intention to make a profit — may indicate the software is being supplied in the course of a commercial activity (Recital 15).

This flexibility is important because donations naturally fluctuate over time. Whether someone intends to make a profit should be assessed by considering the broader financial situation over time, not just isolated instances where income temporarily exceeds expenses.

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

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 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 Cyber Resilience Act (CRA) is a new EU Regulation that aims to safeguard consumers and businesses who use software or hardware products that contain software. It creates mandatory cybersecurity requirements for manufacturers and retailers that extend through those products' lifecycle and software supply chain, including all open source dependencies. It also helps consumers and business identify such products through the CE mark.

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 (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" (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 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 following are NOT regulated by the Cyber Resilience Act (CRA):

• Services
• Software as a service (SaaS) (already regulated by NIS 2 (Directive (EU) 2022/2555) and/or DORA (Regulation (EU) 2022/2554)) and websites, unless used to process data for a product that is regulated by the CRA (see 🌐 Remote Data Processing Solutions FAQ list)
• Products that do not contain software
• Products already covered by other regulations or directives: civil aviation equipment (already covered by Regulation (EU) 2018/1139), marine equipment (already covered by Directive (EU) 2014/90), medical devices (already covered by Regulation (EU) 2017/745 and Regulation (EU) 2017/746), and motor vehicles (already covered by Regulation (EU) 2019/2144)
• Products exclusively designed for national security or defence purposes
• Products specifically designed to process classified information

It is worth noting however, that the intent of the EU legislators is to harmonize the various regulations mentioned above with the CRA in the near future.

Under the CRA, 'making a profit' means earning more money than actual costs. This distinction is important because accepting donations or charging for services without the intention of making a profit is not considered a commercial activity.

What counts as 'actual costs' differs depending on who is receiving the funds:

• For individual maintainers, actual costs include expenses related to the design, development, and maintenance of the software, as well as reasonable living expenses. A natural person covering their costs and earning a fair remuneration is not considered to be making a profit on that basis alone.
• For organisations, actual costs include operational expenses, reasonable compensation for contributors and staff, and other costs associated with the design, development, and provision of the software.

Importantly, not-for-profit organisations that invest all earnings after costs back into achieving their not-for-profit objectives are not considered to be supplying software in the course of a commercial activity, even if they're making a profit (Recital 18).

The following types of products are regulated by the Cyber Resilience Act (CRA):

• Hardware products that contain software (e.g. laptops, smart appliances, mobile phones, network equipment, CPUs, etc.)
• Software products (e.g. operating systems, word processing, games or mobile apps, software libraries, etc.)
• Remote data processing solutions for any of the above, as far as those solutions are necessary for a product to perform its functions (e.g. cloud-based services that allow control of a smart lock at a distance, remote database that backs-up user preferences, etc.); See 🌐 Remote Data Processing Solutions FAQ list

The final text of the Cyber Resilience Act (CRA) can be found on EUR-Lex (English HTML version).

The Cyber Resilience Act (CRA) entered into force on December 11, 2024. Reporting obligations of actively exploited vulnerabilities and severe incidents (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

Security attestations in the CRA are an optional extension that do not exist yet. They may exist in the future, should the European Commission choose to establish them, with a legislative process called a "delegated act". Until such time, any resemblence with concepts elsewhere by the name of "attestation" is coincidental and should not restrict their future design in the CRA. For example, the "Secure Software Development Attestation" as a concept in the US is unrelated to the CRA.