Open Source and the CRA: Stewards, Contributors, and the Commercial-Activity Test

The Fear, and the Reality

When the CRA was first drafted, the open-source community raised a serious concern: would individual maintainers of freely given software be saddled with manufacturer obligations they could never meet? The final regulation answers that carefully. Most genuine open-source activity is out of scope, a tailored lighter-touch category exists for organisations that sustain open-source projects, and full manufacturer duties land where they belong — on the commercial actors who ship products.

Getting the distinctions right matters, because "we use open source" describes almost every modern product.

The Commercial-Activity Test

The core dividing line is commercial activity. Free and open-source software supplied outside the course of a commercial activity is not subject to the CRA's manufacturer obligations. A developer publishing a library on a public repository, accepting no payment and offering no commercial support, is not a CRA manufacturer.

What tips software into commercial activity? Indicators include:

• Charging a price for the software or for technical support
• Monetising the software (for example through paid services or advertising tied to it)
• Supplying it as part of a paid product or offering

The test looks at the nature of the supply, not merely whether money changed hands for a copy. Sustained, monetised distribution is commercial; a genuinely volunteer project is not.

The Open-Source Software Steward

The CRA introduces a distinct, lighter category: the open-source software steward. This is a legal person — typically a foundation or non-profit — that provides sustained support for the development of specific open-source products intended for commercial use, without itself being a manufacturer.

Stewards do not carry the full manufacturer burden. Instead they have proportionate, tailored duties, which include:

• Putting in place a cybersecurity policy for the products they steward
• Cooperating with market surveillance authorities
• Reporting actively exploited vulnerabilities and severe incidents they become aware of in the products they steward

This recognises the reality that foundations shepherding widely used open-source components play a real role in the ecosystem's security, without treating them as if they manufactured and sold a product.

Where Full Obligations Land: Integration

Here is the point that catches product teams out. If you integrate open-source components into a commercial product and place that product on the EU market, you are the manufacturer of that product — and the CRA obligations for it are yours, including for the open-source parts.

The upstream maintainer's out-of-scope status does not transfer to your product. You cannot point at a component's licence and say "not my responsibility." Practically, that means:

• The open-source components appear in your SBOM
• Vulnerabilities in them are your vulnerabilities to monitor and remediate within your support period
• If one is actively exploited in your product, your Article 14 clock starts

A Due-Diligence Duty

The CRA expects manufacturers who integrate third-party components — open source included — to exercise due diligence: choose components with a credible security posture, monitor them for vulnerabilities, and contribute fixes upstream where practical. This is not a burden to resent; it is ordinary good engineering, now with a legal backing.

What to Do

1. Map your open-source usage into your SBOM, transitively — you are accountable for what is in your product regardless of origin.
2. Assess component health as part of selection: is it maintained, does it have a disclosure process, how quickly are issues fixed?
3. Monitor continuously against NVD, OSV, and the EUVD, and feed findings into your own vulnerability handling.
4. Contribute upstream. Fixing a vulnerability in a component you depend on is both good citizenship and risk reduction for your own product.

The CRA does not punish using open source — modern software could not exist without it. It asks that whoever commercialises software takes responsibility for the security of what they ship.