Imagine your company's platform is built on 30 open-source libraries. One of your developers occasionally contributes patches to two of them. You sell the product commercially to enterprise customers across the EU.
So what does the CRA require of you – and for what, exactly?
Until now, getting a clear, unambiguous answer to that question has been difficult. Not because the CRA is silent on open source – or Free and Open-Source Software, as it's formally known – but because the open source world is built on informal structures that don't map neatly onto the legal categories the CRA works with:
You can contribute code without owning the project. You can publish software without selling it. You can maintain a library that others profit from, without profiting yourself.
The Commission's new FOSS guidance on the CRA now provides those answers. And they are far more precise – and in many cases far more favourable – than most people fear. Provided, that is, you understand what actually determines who bears responsibility for what.
The CRA was not written to regulate open source as a technology. The regulation governs products with digital elements that are placed on the market as part of a commercial activity – that is the decisive criterion.
FOSS that is published openly and freely, without any commercial activity attached, is not covered, at least not by default. That means the vast majority of open source software in existence falls outside the CRA's scope – for now.
But "by default" is a critical qualifier. Because what matters is not the software itself. What matters is what you do with it, and under what conditions.
To determine whether the CRA applies to you, start by asking one straightforward question: what role do you play in relation to the specific piece of FOSS?
The guidance effectively identifies four scenarios.
Contributor. You contribute code to a project but don't control its releases, roadmap, or governance. The FOSS is not under your responsibility, and the CRA does not apply to you in that context.
Individual publisher. If you publish a FOSS project openly and freely as a private individual, without monetising it commercially, you have no obligations under the CRA. The guidance treats this as an exemption rather than a regulated role. Accepting voluntary donations doesn't change that – as long as those donations don't effectively function as a price for access to the software.
Steward. The steward role is a CRA innovation, and it applies exclusively to legal entities – companies, foundations, and organisations – not to individuals in the ordinary sense. A steward is an entity that systematically and sustainably supports the development of FOSS intended for commercial use and ensures its continued viability, without itself placing the software on the market. Classic examples include open-source foundations and companies that publish and maintain a library they rely on in their own products without selling it separately.
Manufacturer. If you publish FOSS as part of a commercial activity, you are a manufacturer with full compliance responsibility. This applies regardless of whether you formally call yourself a nonprofit, a foundation, or anything else. The deciding factor is whether you bring the software to market.
The contributor role assumes that the FOSS is not under your responsibility. But what determines that in practice?
It comes down to control – not contribution volume. FOSS is under your responsibility if you publish it and exercise primary control over its development, releases, and distribution decisions. It's not about what you contribute; it's about who ultimately calls the shots on the project's direction.
In practice, the person who sends pull requests for others to merge is a contributor. The person deciding whether those pull requests get merged at all is a maintainer.
That distinction is critical under the CRA.
The practical implication is significant: having commit access to a repository does not make you responsible for the project under the CRA. Many companies have employees who contribute to open-source projects as part of their work. That doesn't automatically create CRA obligations – unless those employees or the company itself effectively controls the project.
If your company falls within the steward definition, it is subject to the lighter obligations under Article 24 rather than full manufacturer liability. A steward does not need to go through the full conformity assessment procedure, CE marking, or technical documentation. But the obligations are real, and they vary depending on the type of support provided.
All stewards must have a vulnerability-handling policy that, among other things, promotes the sharing of vulnerability information within the open-source community. They must also cooperate with market surveillance authorities on request. Stewards that provide IT infrastructure for the project – such as hosting code repositories or managing signing keys – must additionally report serious incidents to ENISA and the national CSIRTs.
Stewards that contribute actual engineering resources – employed developers, code review, release management – must actively report any actively exploited vulnerabilities they become aware of.
One important nuance: a company can be a steward for one FOSS project and a manufacturer for another. The roles are project-specific, not company-wide.
The question of when you cross into manufacturer territory is actually simpler than it sounds. It comes down to one criterion: whether you publish FOSS as part of a commercial activity, thereby placing it on the market in the CRA's sense. It's a question of what you do with the software – and what you get out of it.
Charge for the software? You're a manufacturer. That holds even if you only charge for pre-compiled binaries while the source code is free – it's still a price for the product.
Monetise in other ways? Collecting and selling personal data through the software, selling commercial support as part of the distribution, or running paid SaaS services that depend directly on the FOSS product – all of these make you a manufacturer under the CRA.
Publish both a free community edition and a paid enterprise edition of the same FOSS? You're a steward for the free version and a manufacturer for the paid one. Both roles can exist in parallel for the same product.
There is one important exception worth flagging: substantial modification. If you modify a FOSS product that has already been placed on the market and release the modified version yourself, you become the manufacturer of that modified version. This is fundamentally different from integration – and the two should not be conflated.
Many companies worry that simply integrating a FOSS component into their product makes them the "manufacturer" of that component.
It doesn't.
The guidance is unequivocal: if you integrate FOSS into your product, you are the manufacturer of that product – and you bear full CRA responsibility for it. But integrating a component does not change that component's CRA status. Its status depends solely on whether the person or organisation publishing it has placed it on the market.
What you do carry as an integrator is a due diligence obligation under Article 13(5). That means ensuring the FOSS components you integrate are adequately documented, meet the relevant requirements, and that you maintain a software bill of materials (SBOM).
Article 13(6) also requires you to report any vulnerabilities you discover in your integrated components to the upstream maintainers. You're equally obligated to share any security fixes you develop for use in those components. The guidance frames this as a direct duty to act, not a best-practice recommendation.
Whether your company uses, publishes, or contributes to open source, there are three things worth doing now.
Map your FOSS roles. Who in the organisation has commit access to external projects? Do you publish FOSS, and if so, with or without monetisation? Are your own products dependent on FOSS components? The answers to these questions determine which obligations apply.
Build an SBOM of the FOSS components you integrate. The due diligence requirements under Article 13(5) presuppose that you know what you're running. An up-to-date software bill of materials isn't just good hygiene – it's the foundation for CRA compliance, full stop.
Establish a vulnerability handling process that includes upstream reporting. Handling vulnerabilities internally isn't enough. If you discover a vulnerability in a component you use, you have an obligation to report it. Know who maintains the components you depend on, and make sure you have a channel to reach them.
Open source has made software development faster, better, and more open. The CRA doesn't change that. But it does require you to know exactly what you are – contributor, steward, or manufacturer – and act accordingly.
Whether you use, publish or contribute to open source, your role determines your obligations. NorthGRC’s consultants can help you map your FOSS roles, identify compliance gaps and establish the processes and documentation you need.