Open source and the CRA: who has to do what

The Cyber Resilience Act has caused more anxiety in the open-source community than any EU regulation in recent memory. Most of that anxiety is misplaced — but parts of it are warranted. This explainer separates the two.

Pure non-commercial OSS is exempt

The regulation explicitly carves out non-commercial open source. A hobbyist project on GitHub, with no revenue stream, no paid support, no sponsored roadmap, and no commercial dual licence is not within scope of the CRA. Individual contributors to such projects have no CRA duties.

This is not a loophole — it’s a deliberate policy choice the EU took after the original draft caused a lot of pushback.

The “open source steward” role

The CRA introduces a new actor: the open source steward. A steward is a legal person — typically a foundation or a company — that systematically supports the development of OSS that is intended for commercial activities.

Stewards have lighter obligations than manufacturers:

• Maintain a documented vulnerability-disclosure policy
• Notify ENISA of actively exploited vulnerabilities they become aware of
• Cooperate with market-surveillance authorities

They do not:

• Apply CE marking
• Draw up a Declaration of Conformity
• Run a full conformity-assessment procedure

If you run an OSS foundation that publishes commercially used libraries, you are very likely a steward. The Apache Software Foundation, the Eclipse Foundation, the Linux Foundation — all stewards under the CRA’s definitions.

Bundling OSS into a commercial product

This is where most of the practical compliance work lands. When a manufacturer bundles OSS into a commercial product they place on the EU market, that manufacturer is responsible for CRA compliance of the bundled software. The OSS project itself doesn’t suddenly become a manufacturer — but the company shipping it does.

Practical implication: if you ship Linux on a router, Open SSL in firmware, log4j in a SaaS download, or React Native modules in your mobile app, you are responsible for those components. That is why an SBOM is mandatory — you can’t be responsible for what you can’t enumerate.

What hobbyist maintainers should still do

Even though you are not in scope:

• Publish a clear SECURITY.md on the project repo
• Use a coordinated disclosure process
• Tag releases and sign release artefacts where practical

These are good practices regardless of regulation, and they make life easier for the downstream commercial users who are in scope.

What funded OSS projects should do

If your project receives commercial sponsorship, employs paid maintainers, sells dual licences, or runs a hosted commercial offering — you are likely a steward. To prepare:

• Formalise the vulnerability-disclosure process and publish SLAs
• Set up an internal “actively exploited” trigger that initiates ENISA notification
• Publish an SBOM where feasible (it’s not strictly required for stewards but is useful)
• Decide the legal entity that holds the steward role

Where to read more

The relevant CRA passages are Recitals 18–21 and Article 24. ENISA publishes ongoing OSS guidance on its website.

If you are an OSS maintainer with a commercial sponsor and you’re unsure where you stand, the free CRA assessment gives a personalised summary.