This CRA FAQ helps understand when free and Open-Source Software falls within the CRA, how commercial activity is assessed, and how steward, contributor, and manufacturer roles differ.
Built for open-source maintainers, legal teams, foundations, platform operators, and manufacturers integrating FOSS.
Structured answer sets in this page tree.
Cited legal and guidance references.
The CRA does not create a blanket exemption for . This FAQ separates non-commercial FOSS publication from commercial market placement, explains the role, and shows what manufacturers must still do when they integrate open-source components into products with digital elements.
Under the CRA, means software whose source code is openly shared and which is made available under a licence that provides the rights to make it freely accessible, usable, modifiable, and redistributable.
Article 3(48), recital 18
Use Research Copilot to map FOSS publication, steward support, commercial editions, integrated dependencies, and vulnerability-handling duties to the CRA sources cited on this page.
Turn CRA open-source software questions into cited role assessments, evidence lists, and implementation tasks.
Review FOSS scope, steward duties, manufacturer due diligence, and unresolved evidence gaps.
No.
For the economic operators covered by the CRA, only made available on the market, meaning supplied for distribution or use on the Union market in the course of a , falls under the full CRA product regime.
Article 3(22), recital 18
No.
Open-source status does not by itself decide the issue. The key CRA question is whether the software is supplied on the Union market in the course of a .
Article 3(22), recital 18
The CRA does not reduce it to a single formal test.
Recital 15 gives practical indicators. may be characterised not only by charging a price for the software itself, but also by charging for technical support where that does not merely recover actual costs, by an intention to monetise, by using the software to monetise other services, by requiring personal-data processing as a condition of use for reasons other than security, compatibility, or interoperability, or by accepting donations exceeding the costs associated with the software's design, development, and provision.
recital 15
Yes, in principle.
If the software is supplied on the Union market in the course of a , open-source status does not prevent it from being treated as a product with digital elements under the CRA.
Article 3(22), recital 18
Yes.
The CRA makes clear that is not limited to charging a price for the software itself. It can also arise from monetisation of related services or from the other commercial indicators listed in recital 15.
recital 15
No.
The CRA says that accepting donations without the intention of making a profit should not be considered a . The March 2026 draft guidance adds that a FOSS project funded only through voluntary donations is unlikely to be treated as placed on the market where access to the software, source code, and updates is not conditioned on donating.
But donations can still amount to where, in practice, they function like the price of access, for example if releases, binaries, updates, or other essential benefits are available only to donors, or if the donation model is organised to generate systematic profit rather than sustain the project.
recital 15
section 3.2.4
No.
The CRA says that the circumstances in which the software was developed, and how its development was financed, should not by themselves determine whether the activity is commercial or non-commercial.
recital 18
No.
The CRA expressly says that the mere presence of regular releases should not in itself lead to the conclusion that is supplied in the course of a .
recital 18
No.
The March 2026 draft guidance says the decisive factor is whether access to the FOSS itself, including its maintenance and support, is conditioned on remuneration. If the FOSS can be downloaded and installed freely and users can separately buy consultancy or support, that does not by itself mean the FOSS is placed on the market.
But where a specific edition or version is supplied only under a paid arrangement that includes support or performance optimisation, that provision is monetised and is treated as being placed on the market.
recital 15, recital 18
section 3.2.3
Then the CRA says that should not be treated as a on that basis alone.
Recital 18 states that products with digital elements qualifying as that are not monetised by their manufacturers should not be considered to involve a .
recital 18
Not automatically, but the CRA gives not-for-profit organisations a specific rule.
For the purposes of the CRA, development and publication of by a not-for-profit organisation should not be considered a if the organisation is set up so that all earnings after costs are used to achieve not-for-profit objectives.
The March 2026 draft guidance adds that this can remain true even where the FOSS is directly monetised, for example through search-engine partnerships, as long as the organisation meets that not-for-profit condition. If such a legal person also meets the Article 3(14) criteria, it may be a steward rather than a manufacturer for that FOSS.
recital 18, Article 3(14)
sections 3.2.6 and 3.3.1
No.
The CRA says it does not apply to natural or legal persons who contribute source code to that is not under their responsibility.
recital 18
No.
The CRA says a component intended for integration by other manufacturers is considered to be made available on the market only if that component is monetised by its original manufacturer.
recital 18
No.
The CRA says the sole act of hosting products with digital elements on open repositories, including package managers or collaboration platforms, does not in itself constitute making them available on the market.
recital 19
No.
Under recital 19, providers of repositories, package managers, and collaboration platforms are distributors only if they actually make the software available on the market, meaning they supply it for distribution or use on the Union market in the course of a .
recital 19
An is a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of specific intended for commercial activities and ensures the viability of those products.
Article 3(14), recital 19
No.
The Article 3(14) definition is limited to a legal person.
Article 3(14)
No.
Steward status is narrower. The legal person must systematically provide support on a sustained basis, the software must be intended for commercial activities, and the legal person must ensure the software's viability.
Article 3(14), recital 19
The CRA gives broad examples.
Recital 19 says that sustained support may include hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing products, and steering their development.
recital 19
Yes.
The March 2026 draft guidance says this assessment is specific to each FOSS product. A legal person may be the manufacturer for a specific FOSS that it places on the market, while being the steward for another specific FOSS that it publishes without placing on the market. The same split can also arise between a monetised version and a free or community version of related software.
Article 3(13), Article 3(14), recital 19
sections 3.3 and 3.3.1
They have a lighter, tailored regime under Article 24.
Stewards must put in place and document, in a verifiable manner, a cybersecurity policy that fosters secure development, effective vulnerability handling, voluntary reporting of vulnerabilities, and sharing of vulnerability information within the open-source community. They must also cooperate with market-surveillance authorities and, on a reasoned request, provide the documented policy to the authority.
Article 24(1)-(2)
Yes, but only to the limited extent set out in Article 24(3).
Article 14(1) applies to stewards only to the extent that they are involved in development of the products. Article 14(3) and 14(8) apply only to the extent that severe incidents affect network and information systems provided by the steward for the development of those products.
Article 24(3)
No.
Recital 19 makes clear that open-source software stewards should not be permitted to affix the CE marking to the products whose development they support.
recital 19
Yes.
The market-surveillance authorities designated under Article 52 are also responsible for activities relating to steward obligations under Article 24. If a steward does not comply, the authority must require appropriate corrective action.
Article 52(3)
Not to the administrative fines referred to in Article 64(2) to (9).
Article 64(10)(b) expressly says those administrative fines do not apply to infringements of the Regulation by open-source software stewards.
Article 64(10)(b)
The corrigendum fixes Article 64(10)'s cross-reference so the steward exclusion refers to paragraphs 2 to 9.
The manufacturer still has due-diligence obligations for its own product.
Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including components that have not been made available on the market in the course of a , so those components do not compromise the cybersecurity of the final product.
Article 13(5), recital 34
section 4.4.4
It must report the vulnerability upstream and remediate it in its own product.
Article 13(6) says that where manufacturers identify a vulnerability in an integrated component, including an open-source component, they must report it to the person or entity manufacturing or maintaining the component, address and remediate it in accordance with the CRA vulnerability-handling requirements, and share the relevant fix or documentation where appropriate.
Article 13(6), recital 34
The integrating manufacturer remains responsible for user-facing security information for the finished product.
If a vulnerability in an integrated open-source component affects the product, the Commission FAQ says the manufacturer still has to fulfil its own vulnerability-handling duties, including keeping users informed, providing mitigating measures, and updating documentation. For software versions or products where support ends, the draft guidance also points to the CRA requirement to inform users when vulnerability remediation for earlier versions is discontinued and users need to upgrade.
Article 13(6), Article 13(9), Article 13(18), Annex II
section 4.3.6
points 116-120
No, not in general.
If a manufacturer places open-source software on the market in the course of a , the ordinary CRA manufacturer regime applies to that product. The main special rule is Article 32(5), which preserves access to the Article 32(1) conformity-assessment procedures for Annex III products qualifying as if the technical documentation is made public at the time of placing on the market.
recital 18, Article 32(5)
In one specific case, yes.
Article 32(5) allows manufacturers of Annex III products qualifying as to use one of the Article 32(1) procedures, including module A, provided the technical documentation referred to in Article 31 is made available to the public at the time of placing on the market.
The Commission FAQ explains this as preserving the possibility of module A for important class I and class II when that public-documentation condition is met.
Article 32(5)
sections 6.1 and 6.6
Yes.
Article 25 empowers the Commission to establish voluntary security attestation programmes for , in particular to help manufacturers perform due diligence when integrating such components.
Article 25
section 4.4.4
The timing is split.
Article 24(3), because it links to Article 14 reporting obligations, becomes relevant from 11 September 2026 when Article 14 starts to apply. The rest of the Regulation, including the main Article 24 obligations, applies from 11 December 2027.
Article 24(3), Article 71(2)
No.
Article 3(48) requires both a qualifying free and open-source licence and that the source code be openly shared. The March 2026 draft guidance says "openly shared" means publicly available, not merely shared on a restricted or conditional basis. So software whose source code is available only to paying customers or a limited user group is not FOSS within the CRA's definition.
Article 3(48), recital 18
points 41-43
Responsibility lies with those who publish the FOSS and exercise primary control over its development, releases, and distribution decisions.
The March 2026 draft guidance says contributors who merely submit code are not responsible on that basis alone, even if they have technical permissions such as commit access. Responsibility is tied to publishing and control over releases, roadmaps, or governance decisions.
recital 18
points 45-46
No.
The March 2026 draft guidance says that a monetised version and a free or community version should be treated as different products for CRA purposes. The paid version is placed on the market if it is monetised. The free or community version is not placed on the market on that basis alone.
If the publisher is a legal person, that same entity may still be the steward for the free or community version if the steward conditions are met. If the publisher is a natural person, the free or community version may instead fall outside the CRA.
points 49-50 and 69-74
Article 3(14)
Yes, potentially.
The March 2026 draft guidance says that, particularly for natural persons publishing FOSS, bundled support does not by itself amount to where the price serves only to recover actual costs. It adds that those actual costs can include design, development, and maintenance costs, including reasonable living expenses and fair remuneration for the person.
No, not on that basis alone.
The March 2026 draft guidance says a person offering technical support services for a FOSS that is not under its responsibility is not deemed to be placing that FOSS on the market, unless it substantially modifies the FOSS as part of delivering those services.
No.
The March 2026 draft guidance says steward status is assessed project by project. A foundation can be a steward for specific FOSS intended for commercial activities where it provides sustained support and ensures viability. But merely hosting other FOSS projects, without systematic support, a viability role, or software intended for commercial activities, does not make it the steward for those other projects.
Article 3(14), recital 19
points 75-76
No.
All stewards must comply with the policy and cooperation duties in Article 24(1) and (2). But the March 2026 draft guidance explains that the Article 24(3) reporting duties vary with the kind of support provided.
A steward that only provides non-technical support is not, on that basis alone, required to report actively exploited vulnerabilities or severe incidents. A steward that provides development infrastructure may need to notify severe incidents affecting those systems. A steward that also provides engineering resources may need to notify actively exploited vulnerabilities that it becomes aware of and, where appropriate, inform users.
Article 24(1)-(3), Article 15
points 76-79