Three different positions, three different answers. A maintainer of free software owes nothing. A foundation or company that stewards an open-source project owes a documented security policy and cooperation, but faces no fines. A company that ships open-source components inside a commercial product owes the full set of manufacturer obligations, including for those components.
The regulation is built around products supplied "in the course of a commercial activity". Recital 18 explains that free and open-source software developed or supplied outside a commercial activity is not covered, and that the mere fact that software is open source, or that contributors are paid, or that it is hosted on a platform, does not make it commercial. Charging a price for the product, or monetising it in ways that go beyond covering costs, does.
The CRA created a new role for the entities that support open-source projects without being manufacturers: the open-source software steward, defined in Art. 3(14) as a legal person that systematically provides support for the development of open-source products intended for commercial use. Foundations and the companies behind popular projects fit here.
Their obligations are in Art. 24: put in place and document, in a verifiable manner, a cybersecurity policy covering secure development and vulnerability handling; encourage voluntary vulnerability reporting; promote sharing of vulnerability information in the community; and cooperate with market surveillance authorities on request. The reporting duty of Article 14 applies to stewards only to the extent they are involved in developing the product. And stewards are expressly exempt from administrative fines (Art. 64(10)).
This is the position most companies are actually in. If your commercial product includes open-source components, which nearly every product does, you are the manufacturer of that product and the obligations are yours in full: SBOM, vulnerability handling, technical documentation, reporting, support period. The open-source origin of a component changes nothing about your duties for it. It does change where the pressure flows: integrators need SBOM data and vulnerability information from upstream projects, which is why maintainers will see more such requests even when they themselves owe nothing.
A manufacturer whose product itself qualifies as free and open-source software may use the self-assessment route whatever the product's class, provided the technical documentation is made public when the product is placed on the market (Art. 32(5)). For a Class I or Class II open-source product this is a meaningful relief: no notified body, in exchange for transparency.
First, the boundary between a steward and a manufacturer is drawn by who places the product on the market in a commercial activity, not by who writes the code. A company that sells support contracts and a hosted edition of "its" open-source project should read Recital 18 carefully. Second, the no-fines rule for stewards does not mean no obligations: an authority can still require the policy documentation, and a project with no written security policy at all has nothing to produce.
Two free tools that apply this to your case: the 2-minute applicability check (does the CRA apply to you, with the clauses) and the SBOM generator (CycloneDX + SPDX from your manifest, signed). Neither asks for an account.
Sources, primary only: Regulation (EU) 2024/2847 (EUR-Lex) · European Commission, CRA summary · European Commission, CRA reporting · ENISA, Single Reporting Platform. This is not legal advice; the regulation text controls.