The CRA and Open-Source: How the Manufacturer Duty Falls on Commercial Distributors, Not Volunteers

The Cyber Resilience Act does not exempt open-source software. It moves the manufacturer duty onto whoever commercialises it — and for most regulated firms, that is you, not the maintainer whose name is in the licence header.

There are two comfortable myths about the Cyber Resilience Act and open source, and they are mirror images of each other. The first is that open-source components are outside the CRA, so anything built on them inherits the exemption. The second, which surfaced loudly while the text was being negotiated, is that every volunteer who ever pushed a commit is now a regulated economic operator. Both are wrong, and the gap between them is where the real allocation of responsibility sits. Regulation (EU) 2024/2847 does not draw its line around the code. It draws it around the commercial act of putting a product on the market — and that is a line most firms have never had to locate for their open-source estate.

The test is commercial activity, not authorship

The CRA defines a manufacturer as a person who develops or has developed a product with digital elements and markets it under their own name or trademark — and the definition is explicit that this holds whether the product is supplied for payment, for monetisation, or free of charge. The word “free” there does a lot of work. Free of charge does not take you out of scope. What takes you out of scope is the absence of a commercial activity.

The recitals make the pivot concrete. Supplying free and open-source software that a manufacturer does not monetise is not, on its own, a commercial activity. Accepting donations without the intention of making a profit is not a commercial activity. A developer contributing source code to a project they do not control is not responsible for that project as a whole. The volunteer, the hobby maintainer, the person fixing a bug in a library they use at work — none of those acts, in themselves, creates a manufacturer.

What creates a manufacturer is placing the product on the market in the course of a commercial activity. Charging for the software does it. Charging for technical support beyond the recovery of actual costs does it. Bundling the open-source component into a paid product does it. Monetising through an adjacent service — the platform is free, the data or the subscription is not — does it. The moment your business model touches the software, you are the accountable economic operator for it, regardless of who wrote a single line.

The steward is a narrow category, not a safe harbour

Between the volunteer and the manufacturer the CRA invents a third role: the open-source software steward. A steward is a legal person that provides sustained support for the development of open-source software intended for commercial activities and plays a main role in ensuring the viability of that software — think of the foundations that host and shepherd major projects. Stewards carry a lighter, purpose-built set of duties under Article 24: a cybersecurity policy, coordinated vulnerability handling, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities and severe incidents. They are not subject to the administrative fines the regulation levies elsewhere.

The mistake I expect to see is firms reaching for the steward label to soften their own exposure. It does not fit. You are not a steward because you use a foundation’s software, and you do not become one by contributing to it. The steward category exists to give the upstream custodians of the commons a defined, proportionate role — it is not a route by which a commercial distributor downgrades a manufacturer duty into a lighter one. If you are shipping the component in a product you sell, Article 24 is not your article. The full manufacturer obligations are. I have set out how that steward category actually works in a separate reading of the new steward role; the point here is only that it is a ceiling for a few, not a floor for everyone.

What the manufacturer duty actually entails

Once you are the manufacturer of a product that contains open-source components, the CRA does not let you disclaim the parts you did not write. You are responsible for the whole product, upstream code included. That means the essential cybersecurity requirements in Annex I apply to the assembled thing — secure-by-design and secure-by-default properties, a risk assessment, and the ongoing handling of vulnerabilities across the support period you declare. It means exercising due diligence on the third-party components you integrate, including the open-source ones, and being able to show that you did. It means producing and maintaining a software bill of materials, keeping the technical documentation, and running a coordinated vulnerability-disclosure process for the product as a whole.

None of this is discharged by the maintainer of the library. The upstream project may fix a flaw, or it may not; either way the reporting clock and the remediation duty are yours, because you are the one who placed the product on the market. The Annex I obligations are a risk assessment rather than a checklist — I have argued that point at length in the context of how Annex I is meant to be read — and the open-source content of your product is simply part of the risk you now own. The practical work of pushing secure-by-design expectations back up your component supply chain is how a manufacturer makes that ownership tractable rather than terrifying.

Map your consumption before the dates bite

The CRA entered into force on 10 December 2024. The reporting obligations for actively exploited vulnerabilities and severe incidents begin on 11 September 2026, and the full body of manufacturer obligations applies from 11 December 2027. That is not a long runway for an estate whose open-source dependencies have never been inventoried against a role in a regulation.

The exercise to run now is not legal, it is architectural. Take each product you place on the market and ask where its open-source content sits: is it a build-time dependency, a shipped library, an embedded runtime, a whole platform you distribute? Then ask which of those you commercialise, because that is what converts consumption into a manufacturer duty. Firms that treat open source as free are usually the ones who never counted its governance cost, and the CRA is about to render that cost explicit and dated. The volunteers are safe. The question the regulation actually asks is whether the person who monetised their work has noticed that the duty landed on them.