The Cyber Resilience Act (CRA) does not give every open-source project a blanket exemption. For free and open-source software, the legal analysis turns on what the software is, who is responsible for it, whether it is supplied for distribution or use in the course of a commercial activity, and whether a supporting legal person instead qualifies as an open-source software steward.
That distinction matters because the same code can appear in very different contexts. A volunteer can contribute to a community project without becoming a CRA manufacturer, while a company can distribute open-source software as part of a monetised offering and take on manufacturer obligations. A foundation or similar legal person can also fall into the separate steward regime without being treated like a manufacturer.
Start with four questions, not the licence name
An open-source licence is relevant, but it does not answer the whole CRA scope question. A practical assessment should begin with four separate questions:
- Does the software qualify as free and open-source software under the CRA?
- Who has responsibility for the product with digital elements?
- Is the software supplied for distribution or use in the course of a commercial activity?
- Is there a legal person providing sustained support that may qualify as an open-source software steward?
Keeping those questions separate prevents two common errors: assuming that all open-source software is outside the CRA, or assuming that any commercial organisation touching an open-source project automatically makes the project commercial.
The Commission's 2026 CRA guidance is useful for applying these concepts, but it is guidance rather than a replacement for the Regulation itself. Where the facts are borderline, the legal role should be assessed against Regulation (EU) 2024/2847 and the organisation's actual distribution, responsibility and monetisation model.
What the CRA means by free and open-source software
Recital 18 describes free and open-source software as software whose source code is openly shared and whose licensing provides rights to make it freely accessible, usable, modifiable and redistributable.
That definition is only the first step. For economic operators covered by the CRA, the Regulation links manufacturer scope to software that is made available on the market. Making available on the market means supplying a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether payment is received or not.
This is why “free of charge” and “non-commercial” are not synonyms. Software can be supplied without a direct purchase price and still be part of a commercial activity. Conversely, a project can receive funding, contributions or donations without those facts alone turning the activity into commercial supply.
Commercial activity is broader than charging for a download
Recital 15 gives concrete indicators for determining whether an activity is commercial. The CRA can treat an activity as commercial where, for example, the supplier:
- charges a price for the product with digital elements;
- charges for technical support beyond the actual cost of providing that support;
- intends to monetise the software through a platform or through other services;
- makes access conditional on processing personal data for reasons beyond improving security, compatibility or interoperability; or
- accepts donations that exceed the costs associated with developing and providing the product.
These examples show why the business model matters more than the download button. A company can publish source code under an open-source licence and still supply the resulting software in the course of a commercial activity.
At the same time, Recital 18 identifies facts that do not, by themselves, establish commercial activity. These include:
- receiving financial support from manufacturers;
- manufacturers contributing to development;
- publishing regular releases; and
- development by a not-for-profit organisation where earnings after costs are used for not-for-profit objectives.
Recital 20 adds another useful boundary: merely hosting software in an open repository, package manager or collaboration platform does not by itself amount to making that software available on the market.
The result is not a simple revenue test. Organisations should document the full operating model: who distributes the software, under whose responsibility, how money or data flows around it, whether support is sold, and how the software connects to other monetised products or services.
Do not confuse contributor, manufacturer and steward
The CRA deliberately separates several roles that can exist around the same open-source project.
Individual or organisational contributor
The Regulation does not apply merely because a natural or legal person contributes source code to free and open-source software that is not under that person's responsibility.
This protects ordinary contribution from being treated as product placement. A developer fixing a bug in someone else's project does not become the manufacturer simply because the patch is accepted.
Responsibility is therefore important. If an organisation controls a product, supplies it under its own responsibility and does so in a commercial activity, the analysis changes even when the code is openly licensed.
Manufacturer of open-source software
Where a manufacturer places free and open-source software on the market in the course of a commercial activity, the Commission states that the manufacturer is subject to the CRA manufacturer obligations.
The fact that recipients can inspect, modify and redistribute the code does not remove those obligations. The relevant question is whether the economic operator is supplying the product on the Union market under the conditions that make it a commercial activity.
Open-source software steward
The CRA creates a separate category for certain legal persons that systematically support specific free and open-source software on a sustained basis, where that software is intended for commercial activities and the legal person helps ensure its viability.
A steward is explicitly not the same role as a manufacturer. Recital 19 describes a light-touch, tailored regime because many important open-source projects support commercial products without themselves being placed on the market by the supporting organisation.
This category can include certain foundations and other entities that govern, manage, host or steer sustained development, depending on the facts. The definition requires more than occasional contribution: it focuses on systematic, sustained support and a role in ensuring the viability of the software.
Four practical scenarios
The role analysis becomes clearer when applied to common operating models.
1. Volunteer-maintained project with no commercial supply
A community publishes source code and releases under an open-source licence. Contributors are volunteers, donations are used to cover project costs, and nobody supplies the project as part of a monetised offering under their responsibility.
Those facts point away from manufacturer treatment. Funding, regular releases and repository hosting do not automatically create commercial activity.
The project should still use sound security practices, but that is different from saying CRA manufacturer obligations apply.
2. Company monetises an open-source product or surrounding service
A company publishes an open-source product but uses it as the basis of a paid platform, sells support beyond cost recovery, or otherwise supplies the software as part of a monetised business model.
Open-source licensing does not prevent manufacturer obligations from applying. The commercial relationship and responsibility for the product are the relevant factors.
A legal team should examine the exact supply model rather than treating “free download” as a scope exemption.
3. Commercial manufacturer integrates a non-commercial open-source component
A manufacturer can integrate an upstream component that is itself developed outside commercial activity. That does not transfer the manufacturer's CRA responsibilities back to volunteer maintainers.
Article 13 requires a manufacturer integrating components from third parties, including free and open-source components not made available on the market in commercial activity, to exercise due diligence when integrating them. The manufacturer's product-level obligations therefore remain relevant even when the upstream project is outside the manufacturer regime.
The CRA also requires manufacturers that identify a vulnerability in such a component to report it to the person or entity maintaining the component and to address and remediate it in accordance with their own vulnerability-handling obligations where applicable.
4. Foundation or similar entity provides sustained support
A foundation may not place the software on the market as a manufacturer, yet it can still systematically support a project intended for commercial use and play a central role in its viability.
That is the situation the open-source software steward concept is designed to address. The organisation should assess Article 3's steward definition and, where it applies, the tailored duties in Article 24.
What open-source software stewards must do
Article 24 requires an open-source software steward to put in place and document a verifiable cybersecurity policy. The policy is intended to foster secure development and effective vulnerability handling and should address documenting, addressing and remediating vulnerabilities as well as information sharing within the open-source community.
Stewards must also cooperate with market surveillance authorities, on request, to mitigate cybersecurity risks posed by the supported free and open-source software.
Article 24 further connects stewards to Article 14 reporting in defined circumstances. The reporting obligations in Article 14 begin applying on 11 September 2026. The exact reporting trigger depends on the steward's involvement and on whether the event is an actively exploited vulnerability or a severe incident affecting relevant development infrastructure.
The steward regime remains distinct from manufacturer conformity obligations. The CRA does not treat a steward as if it had placed the supported software on the market merely because it helps keep the project viable.
Evidence to retain for the scope decision
Open-source scope decisions can become difficult to reconstruct months later, especially when funding, distribution channels or organisational responsibility change. A short written conclusion is more useful when the supporting facts are retained with it.
For each relevant product or component, keep evidence of:
- the legal entity or entities involved;
- the applicable open-source licence and repository;
- who controls releases and under whose responsibility the software is supplied;
- where and how the software is distributed in the Union;
- whether access is paid or free of charge;
- paid support, hosting, platform or service arrangements connected to the software;
- whether personal data is required and for what purpose;
- the treatment of donations, sponsorship or other financial support;
- relationships with manufacturers that integrate the software;
- whether a foundation or other legal person provides systematic, sustained support;
- the reasoning for manufacturer, contributor, steward or out-of-scope treatment; and
- the date and product or release context for the decision.
This evidence matters because the conclusion can change when the operating model changes. A project that begins as a non-commercial community effort can later gain a commercial distribution channel, paid support model or sustained organisational structure. The CRA role should then be reassessed instead of relying on an old label.
Four mistakes to avoid
“Open source means exempt”
It does not. The CRA distinguishes non-commercial open-source development from open-source software supplied in commercial activity.
“Free download means non-commercial”
It does not necessarily. The CRA's concept of commercial activity covers more than a direct sale price and can include surrounding monetisation.
“Funding means the project is commercial”
Not by itself. The Regulation expressly says manufacturer funding or manufacturer contributions do not alone determine that the activity is commercial.
“If upstream is outside scope, the commercial integrator can ignore it”
No. A manufacturer integrating third-party or non-commercial open-source components still has its own product-level due-diligence and vulnerability-handling responsibilities.
Scope decisions can also become difficult to audit when responsibility, distribution channels, monetisation facts and component evidence live in separate records. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, which can help teams keep the basis for a CRA scope decision connected to the affected product and release. AA-sec does not determine whether an activity is commercial or whether the CRA applies; that remains a legal and manufacturer decision.
Key takeaway
The useful question is not whether software carries an open-source licence. The useful question is what role each actor actually performs and whether the software is supplied in the course of commercial activity.
For non-commercial contributors, manufacturer obligations may not apply. For manufacturers monetising and supplying open-source software, the normal CRA manufacturer framework can apply. For legal persons providing systematic, sustained support to commercially intended open-source projects, the separate open-source software steward regime may apply.
Document the facts behind that classification and revisit them when responsibility, funding, distribution or monetisation changes. That is more defensible than treating “open source” as a permanent legal status.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Open source — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers — OpenSSF