The CRA open-source exemption needs a revenue map

An open-source licence answers who may use, inspect and modify code. It does not answer the Cyber Resilience Act’s more awkward question: who is supplying which product, for which commercial purpose, with which security responsibility.

The European Commission published its practical CRA guidance on 27 July 2026. The non-binding annex contains 67 examples, and its open-source section turns a familiar slogan — “free software is exempt” — into a product-by-product test covering price, services, personal data, donations, financing, governance and downstream commercial use.

For an SME maintaining a public repository, shipping an open-core product or integrating community code into a paid service, the first CRA task is therefore not a policy document. It is a revenue and responsibility map.

Free of charge is not the legal test

The CRA applies to products with digital elements made available on the Union market in the course of a commercial activity. That supply may be for payment or free of charge. The open-source treatment is narrower: FOSS that is not monetised by its manufacturer should not be treated as a commercial activity merely because it is published.

Those two propositions can coexist. A zero-euro download may still sit inside a commercial model. A maintained public project may remain outside the manufacturer regime. The guidance asks what is being supplied, who is responsible for it and how the surrounding arrangement works in practice.

The licence is evidence, but not the conclusion. Nor is the location of the repository. A natural or legal person sharing code in a public repository will generally not be placing that code on the market simply by publishing it. The answer changes when a finished product is supplied under a name or trademark and access, features, updates or related value are monetised.

That is why a company-wide statement such as “our software is open source” is too coarse. The unit of analysis is the specific product or edition.

Map the money around each release

The Commission’s examples separate revenue routes that teams often collapse into one label. The practical distinction is whether money or another benefit is attached to access to the product and its maintenance, or to optional services around software that remains freely available.

Route	What the guidance indicates	Evidence to keep
Price for software or binaries	The supplied edition is commercial and the supplier may be its manufacturer	Price list, licence terms, release channel and entity named on the product
Free community edition plus paid enterprise edition	The editions can be different CRA products with different roles	Feature and codebase matrix, update policy and separate release records
Optional consultancy or training	Does not by itself make freely downloadable FOSS a market placement	Contract scope showing that access, maintenance and updates remain unconditional
Paid access to support, optimisation or maintained versions	Can make that edition a monetised product	Entitlement rules, support bundle, update access and security-fix policy
Ads, commissions, subscriptions or unrelated data processing	Can show that the free product monetises another service or benefit	Data-flow map, terms of use and revenue connection
Voluntary donations	Usually do not create a commercial activity when access and updates stay unconditional	Donation terms, benefits, release access and use of funds
Donations tied to releases or security fixes	May operate as a price and bring the supplied product into scope	Donor entitlements and the public/non-donor release path

Source: Commission guidance on the application of the CRA, Section 3.2. Last verified 2026-08-01.

The support distinction deserves care. The guidance says that optional consultancy, training, documentation, configuration or deployment work around freely accessible software does not, by itself, monetise the product. A service provider that helps a customer install FOSS it did not publish is not thereby placing that software on the market, unless its delivery includes a substantial modification that changes the legal position.

The line moves when access to a particular maintained version, technical assistance, performance optimisation, binaries or security fixes is conditional on payment. A sales team may describe both models as “commercial support”. The CRA analysis needs the entitlement details.

One entity can hold three roles

The new category of open-source software steward prevents the analysis from ending with “not a manufacturer”. A steward is a legal person, other than a manufacturer, that systematically supports on a sustained basis the development of FOSS intended for commercial activities and ensures the viability of those products.

This role is specific to a project. The same legal entity may be:

• a manufacturer for a paid edition it places on the market under its name;
• a steward for a non-monetised community edition that it sustains for commercial use;
• neither for a separate repository that it merely hosts without systematic support or responsibility.

The Commission lists sustained support such as hosting and managing collaboration platforms, hosting source code, governing a project, steering development, providing engineering resources, coordinating releases and handling vulnerability reports. Simply being a company that publishes many repositories does not give every repository the same status.

Steward obligations are lighter and tailored, but they are not decorative. Art. 24 CRA requires a cybersecurity policy that fosters secure development and effective vulnerability handling, cooperation with market-surveillance authorities and, depending on the support actually provided, parts of the reporting regime in Art. 14.

The guidance makes that last point operational. A body providing only non-technical governance has a different reporting exposure from one hosting the development infrastructure. A steward providing engineering resources may need to report actively exploited vulnerabilities it becomes aware of. Responsibility follows the support performed, not the organisation’s preferred label.

Downstream users do not inherit an exemption

The open-source status of an upstream component does not exempt a company that integrates it into its own commercial product. The upstream maintainer and the downstream manufacturer answer different questions.

An SME shipping a paid appliance, desktop client, mobile app or software package remains responsible for the product it places on the market, including the open-source components inside it. It cannot replace its product-security file with links to upstream repositories. It needs a component inventory, vulnerability intake, update route and evidence of how essential cybersecurity requirements were addressed.

Conversely, a consultant installing unmodified community software on a customer’s infrastructure is not automatically the manufacturer of that upstream software. If the consultant substantially modifies the product and makes that modified version available, the analysis may change. The delivery record should therefore distinguish configuration, integration, patching and code changes rather than putting them all under “implementation”.

This boundary also matters in procurement. A buyer should not ask only whether a package is open source. It should ask who supplies the deployed edition, who signs or distributes the binaries, who controls the update channel, which party handles vulnerabilities and whether the implementation contains a substantial modification.

Build a six-column CRA map

The Commission guidance is non-binding, so the map is not a safe-harbour form. It is still the fastest way to expose unsupported assumptions before the CRA’s main obligations apply on 11 December 2027. Reporting obligations begin earlier, on 11 September 2026.

Create one row per product, edition or materially distinct release. Do not create one row per legal entity.

Field	Question the file must answer
Product	What exactly can a user download, install or receive, and which version is being assessed?
Supplier	Which natural or legal person supplies it, under whose name or trademark?
Monetisation	What payment, service revenue, data use, commission, subscription or donor benefit connects to access or maintenance?
Support	Who hosts, governs, merges, releases, signs, patches and handles vulnerability reports?
Downstream use	Is the project intended for integration into commercial products or services, including the company’s own?
CRA role	Is the entity acting as manufacturer, steward, service provider, contributor or none for this specific product?

Source: Regulation (EU) 2024/2847, Articles 3, 13, 14 and 24, and the Commission guidance, Section 3. Last verified 2026-08-01.

Attach six pieces of evidence: the licence, public release URL, pricing or donation terms, support entitlements, data-use terms and the current vulnerability-handling route. Add the decision owner and review the row whenever the business model or release channel changes.

That last trigger matters. A project can move from unconditional donations to donor-only updates, introduce a hosted marketplace, launch an enterprise edition or start bundling guaranteed fixes without changing its open-source licence. The code may look the same while the CRA role changes around it.

The useful claim is therefore not “open source means exempt”. It is narrower and auditable: for this release, supplied by this entity, users receive the software and security updates on these terms; revenue and data use work this way; sustained support is provided by these actors; and this is the CRA role the company has recorded. Build that row before the next pricing experiment ships.