Open source and the CRA: stewards, commercial use, reporting obligations

Free and open-source software only falls under the Cyber Resilience Act if it is made available on the market in the course of a commercial activity (Article 3, point (22), recitals 15 and 18). Anyone who publishes a project without any business behind it stays outside. A foundation or association that supports a project on a sustained basis for products intended for commercial use is an "open-source software steward", with light-touch obligations under Article 24, no CE marking and no administrative fines. Anyone who sells open source is a manufacturer like any other. And every manufacturer that builds open-source components into its products owes due diligence under Article 13(5) and reports vulnerabilities back to the project (Article 13(6)).

What is free and open-source software within the meaning of the CRA?

Article 3, point (48) defines it as software whose source code is openly shared and which is made available under a free and open-source licence granting all the rights: to make it accessible, use it, modify it and redistribute it. According to the Commission guidance, "openly shared" means publicly available, not only for paying customers or a limited group (guidance, paragraph 46). The definition does not yet say whether the CRA applies; that depends on commercial activity.

When does open source become a commercial activity?

Making available on the market presupposes a commercial activity (Article 3, point (22)). Recital 15 lists the indicators:

• A price for the product.
• A charge for technical support that goes beyond recovering actual costs.
• An intention to monetise, for instance where the software serves as a platform for other services.
• The processing of personal data as a condition of use, unless it serves solely security, compatibility or interoperability.
• Donations that exceed the costs of design, development and provision. Recital 15 itself adds that accepting donations without the intention of making a profit is not a commercial activity, and the Commission guidance narrows this indicator further: a donation link is not an intention to make a profit, even where donations exceed the costs (paragraph 61).

Recital 18 makes clear that the circumstances of development and the way it is financed play no role. Manufacturers supporting a project financially, regular releases, or development by a not-for-profit organisation do not make open source commercial. Components that other manufacturers integrate only count as made available on the market if the original manufacturer monetises them. Recital 20 excludes the infrastructure: hosting on package managers and collaboration platforms is not placing on the market.

The Commission guidance C(2026) 5252 makes this more concrete in section 3. There is placing on the market where a price is charged for the software or binaries (paragraph 51), where the software is a platform for monetising other products or services (paragraph 54), and for paid editions where access, including technical assistance or performance optimisation, is conditional on payment (paragraph 57). There is no placing on the market for separately offered consultancy, training or support (paragraphs 55 and 56), for voluntary donations as long as releases and updates are not reserved for donors (paragraphs 61 and 62), or where revenue is used for not-for-profit purposes (paragraph 77). The manufacturer of open source is whoever publishes it and exercises primary control over its development, releases and distribution, in other words the maintainer; contributors without control over releases are not responsible (paragraph 49).

What is an open-source software steward and what must it do?

Under Article 3, point (14), an open-source software steward is a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of open-source products intended for commercial activities. Recital 19 names foundations and not-for-profit entities that develop open source in a business context; support includes hosting platforms and source code, and managing and governing development. Only projects whose output flows into commercial services or monetised products are covered. An individual developer cannot be a steward.

The obligations under Article 24 are deliberately light:

• Cybersecurity policy (paragraph 1): documented in a verifiable manner, covering secure development, vulnerability handling, fostering voluntary reporting under Article 15, documenting and remediating vulnerabilities, and sharing information within the community.
• Cooperation (paragraph 2): cooperating with market surveillance authorities and providing documentation following a reasoned request.
• Limited reporting obligation (paragraph 3): notifying actively exploited vulnerabilities under Article 14(1) to the extent that the steward is involved in development; severe incidents and informing users under Article 14(3) and (8) to the extent that network and information systems provided by the steward are affected.

The obligations for stewards only apply from 11 December 2027 (Article 71(2); ENISA says the same in its FAQ on the reporting platform), unlike the manufacturers' reporting obligation, which has applied since 11 September 2026. Stewards may not affix the CE marking (recital 19), and Article 64(10)(b) exempts them from the administrative fines in paragraphs 2 to 9, including those for infringements of Article 14 (as amended by the corrigendum in OJ L 2025/90555 of 2 July 2025); under recital 120, Member States should not impose other financial penalties on them either. According to ENISA, steward notifications go through the same reporting platform as manufacturer notifications; ENISA has announced voluntary notifications under Article 15 for a later phase.

Which role applies in which case?

What applies to open-source components in your own product?

This is the part that concerns every manufacturer. Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, expressly including non-commercial open source. Recital 34 scales the effort to the risk: check whether the component bears the CE marking, look at its update history, compare known vulnerabilities against the European vulnerability database, and carry out additional tests where needed. Measured against this, using a project without a maintainer is a decision that should be documented.

Article 13(6) governs reporting back. If a manufacturer finds a vulnerability in a component, including an open-source one, it reports it to the person or entity maintaining the component and remediates it in its own product. It shares its own fixes with the project, as code or documentation, where appropriate in machine-readable form. A machine builder who finds a flaw in an open-source TLS library therefore does not keep the patch to itself. According to the guidance, the integrating manufacturer is not responsible for the conformity of the component itself, even if it contributes to it (Example 32), but it is fully responsible for the end product (paragraph 120). The basis for all this is the software bill of materials; what it must contain is explained in SBOM under the CRA.

Is there a quality label for open source?

Article 25 allows the Commission to introduce, by delegated act, voluntary security attestation programmes that can be used to demonstrate the conformity of open-source products with Annex I. According to recital 21, third parties such as integrating manufacturers or public administrations can also initiate or finance an attestation. No such act is known so far (as of October 2026). One relief already exists: under Article 32(5), open-source products in the categories of Annex III may use any conformity assessment procedure, including internal control, provided the technical documentation is made public.

Common mistakes

• Assuming across the board that "open source is exempt". Monetised open source is fully covered, and an enterprise edition turns a project into a manufacturer.
• Failing to recognise open core for what it is. If you offer a community edition and a paid edition, assess both expressly and separately and state the monetisation openly, instead of presenting the model as "open source".
• Using components without checking how well they are maintained. Recital 34 calls for due diligence in proportion to the risk; an orphaned project in your control system is a finding that has to be documented.
• Keeping fixes in-house. Article 13(6) requires reporting back to the project.
• Assuming the steward regime applies to individuals or to your own company. Only a legal person that is not a manufacturer can be a steward.
• Treating donations and sponsorship as a free pass. They do no harm as long as there is no intention to make a profit. As soon as a price or a paid tier is added, the classification tips over.

For manufacturers using open-source components, this has a practical consequence for readiness: an actively exploited vulnerability in a library must be reported as soon as it is contained in your own product and exploited there (guidance, paragraph 218), with the 24-hour deadline under Article 14(2)(a). CRA Response Center recognises such reports at the manufacturer's reporting address, including reports about libraries built into its products, and alerts the people responsible; the manufacturer submits the notification on the ENISA platform itself.

Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kit

Frequently asked questions

Further reading

• SBOM under the CRAThe bill of materials in which open-source components must be listed.
• Who is the manufacturer under the CRA?The manufacturer role, including for open-source providers with a business model.
• Manufacturer obligationsArticle 13 at a glance, including paragraphs 5 and 6.
• Actively exploited vulnerabilityWhat must be reported, even when the flaw sits in a library.
• The CRA for agencies and custom software: who is the manufacturer and who is notCommissioned development, your own plugin, websites, open source: when the agency or the client is the manufacturer.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 3, points (14), (22) and (48), Article 13(5) and (6), Articles 24, 25, 32(5), Article 64(10), recitals 15, 18, 19, 20, 21 and 34, Publications Office of the EU, accessed 7 October 2026; Article 64(10) as amended by the corrigendum OJ L 2025/90555 of 2 July 2025.
• Commission guidance C(2026) 5252, Annex, section 3 (paragraphs 44 to 81, Examples 13 to 33), paragraphs 120 and 218, European Commission, 27 July 2026.
• The CRA Single Reporting Platform is launched, ENISA, 11 September 2026.
• Single Reporting Platform: Frequently Asked Questions, ENISA, as of 3 October 2026.
• Cyber Resilience Act guidance: products and obligations, Gamingtechlaw, 5 August 2026.
• EU clarifies CRA rules for non-commercial open source, Open Source For U, 29 July 2026.
• CRA Commission guidance, Noze, 28 July 2026.