Does the Cyber Resilience Act Apply to Your Open-Source Project?

On July 27, 2026, the European Commission published its first substantive guidance on the Cyber Resilience Act (Communication C(2026) 5252) — non-binding, but the clearest signal yet of how the Commission intends the regulation to work in practice. Sixty-seven examples, a public consultation, and input from the Commission's own cybersecurity expert group went into it. The single most consequential section, for the largest number of organizations, addresses a question the regulation's text alone left genuinely unclear: when does publishing free and open-source software make you subject to the CRA?

This matters because the CRA's main obligations arrive December 11, 2027, and its reporting requirements are already active as of September 11, 2026. Getting the scope question wrong in either direction is costly — either taking on compliance obligations that don't apply, or missing ones that do.

The Core Distinction: Publishing FOSS Is Not the Same as Placing It on the Market

The CRA only applies to products "placed on the market" — supplied in the course of a commercial activity. The guidance is explicit that how software was developed or funded doesn't determine whether that threshold is crossed. A well-resourced, corporately-backed open-source project and a solo maintainer's side project are evaluated by the same test, and that test isn't about money changing hands in general — it's about whether access to the software itself is monetized.

The guidance lays out, in effect, a four-question test:

1. Is it actually a product with digital elements? Documentation, sample code, and research projects generally aren't.
2. Are you responsible for publishing it? A contributor who submits a pull request that a project's maintainers review and merge is not responsible for that project — responsibility sits with whoever controls releases and governance, not whoever has commit access.
3. Are you placing it on the market in the course of a commercial activity? This is the crux, and the guidance is specific about what counts and what doesn't.
4. If you are a legal person providing sustained support to a FOSS project you don't monetize, are you instead a "steward"? This is a new legal category the CRA introduces specifically for this situation — lighter obligations than a manufacturer, but not zero.

What Actually Triggers "Commercial Activity" for FOSS — and What Doesn't

The guidance's examples resolve a lot of ambiguity software teams have been sitting with since the CRA entered into force.

Generally does NOT place FOSS on the market:

• A free, fully-functional "community" version, even when a separately-monetized paid version of the same codebase exists — the community version and the paid version are treated as different products.
• Voluntary donations, even where the total collected exceeds the actual cost of development — provided donations aren't a condition of access to the software or its updates.
• Third-party sponsorship or grant funding for specific features or maintenance work, regardless of who's paying.
• Optional, separately-offered professional services (consulting, training, support) sold alongside freely-downloadable software, as long as the software itself isn't gated behind payment.
• Software published by a not-for-profit whose earnings, after costs, go toward not-for-profit objectives — even if that software is directly monetized in some way.

Generally DOES place FOSS on the market:

• Charging a price for the software itself, including pre-compiled binaries.
• Using a free FOSS product to monetize something else — e.g., a free app that takes a commission or subscription fee on transactions conducted through it.
• Conditioning use on processing personal data for purposes unrelated to the software's own security, compatibility, or interoperability.
• A "donation" model where paying is de facto required to get current releases or security updates — the guidance treats this as a price by another name.
• A paid tier that includes technical support or performance benefits bundled with access itself, as distinct from support sold separately from a freely-available product.

Why This Matters Beyond Compliance Paperwork

An organization wrongly assuming the CRA doesn't apply to its monetized "enterprise" fork of an otherwise-free project would miss real obligations — including the vulnerability reporting timelines already in effect since September 11: a 24-hour early warning and 72-hour full notification to the relevant CSIRT and ENISA once a manufacturer becomes aware of active exploitation, with a complete report due within 14 days of a fix becoming available. Conversely, a maintainer who wrongly assumes a donation-funded project is in scope may be over-engineering compliance processes for software that was never covered in the first place.

For any organization integrating third-party FOSS components — which is to say, nearly everyone building software today — the guidance is also clear that the CRA doesn't shift responsibility onto contributors or unaffiliated maintainers. It does, however, require the integrator to exercise due diligence on the components it pulls in, and to report vulnerabilities upstream to component maintainers where practical.