Open-source software steward

An open-source software steward is a role the Cyber Resilience Act (CRA) created specifically: a legal person that carries the development of certain open-source products on a sustained basis without placing them on the market itself. Recital 19 calls the regime meant for it light-touch and tailor-made.

The definition in Article 3(14) turns on four elements: a legal person that is not a Manufacturer; the purpose or objective of supporting the development of specific products systematically and on a sustained basis; those products qualifying as free and open-source software and being intended for commercial activities; and the steward ensuring their viability. Miss one element and the role does not attach.

Who falls within it

Recital 19 expressly names certain foundations as well as entities that develop and publish free and open-source software in a business context, not-for-profit entities included. It describes sustained support as including:

• hosting and managing software development collaboration platforms
• hosting source code or software
• governing or managing open-source products
• steering the development of such products

On the product side, intended use decides. Only products ultimately intended for commercial activities are covered: integration into commercial services or into monetised products, for example. Where manufacturers that integrate a component contribute to its development regularly, or provide regular financial assistance to keep the software going, the recital treats that as exactly such an intention.

What Article 24 requires

Three things, and no more.

A cybersecurity policy (paragraph 1). The steward puts in place and documents in a verifiable manner a cybersecurity policy fostering secure development of the product and effective vulnerability handling by its developers. It must in particular cover the documenting, addressing and remediating of vulnerabilities, foster voluntary reporting under Article 15, and promote the sharing of information about discovered vulnerabilities within the open-source community. The specific nature of the steward and the legal and organisational arrangements it operates under are expressly to be taken into account.

Cooperation (paragraph 2). On request, the steward cooperates with the Market surveillance authority to mitigate the cybersecurity risks posed by the product. Further to a reasoned request it hands over the policy documentation in paper or electronic form, in a language the authority can easily understand.

Reporting (paragraph 3). The duty in Article 14(1) to report an actively exploited vulnerability reaches the steward only to the extent it is involved in developing the product. Article 14(3) and (8) (reporting severe incidents and informing users) apply only to the extent such an incident affects the network and information systems the steward provides for that development. Both extensions are narrowly cut.

What does not apply

The essential cybersecurity requirements in Annex I, the technical documentation under Article 31, conformity assessment and the EU declaration of conformity address manufacturers, not stewards. Consistently with that, recital 19 says in terms that a steward may not affix the CE marking to products whose development it supports. Nor is there a support period to determine.

Enforcement without fines

Article 52(3) puts market surveillance authorities in charge. Where one finds a breach of Article 24, it requires the steward to ensure that appropriate corrective action is taken. The administrative cooperation group (ADCO) also addresses specific market surveillance matters concerning stewards (Article 52(15)).

Administrative fines are off the table: Article 64(10)(b) exempts open-source software stewards from the fining provisions for any infringement of the Regulation. Recital 120 adds that Member States should not impose other penalties of a pecuniary character on them either. The instrument of enforcement is the demand for corrective action, not the fine.

Where the manufacturer role begins

The definition excludes manufacturers in terms. What tips the balance is marketing: where an entity monetises the product itself, the product is thereby supplied in the course of a commercial activity (recital 18). Whoever develops and markets it under its own name is its manufacturer under Article 3(13), with every obligation that follows. Whether one entity can be a steward for one project and a manufacturer for another, the Regulation does not say expressly: the wording of the definition attaches to the person, while the duties in Article 24 attach to specific products.

What is left open

Two further points the CRA does not settle expressly. First, there is no dedicated rule on when a steward established outside the Union is caught by Article 24; elsewhere the Regulation hinges on products being made available on the market (Article 2(1)), which per recital 19 is precisely what a steward does not do. Second, Article 14 applies from 11 September 2026, but its extension to stewards runs through Article 24(3). That provision, like the rest of the Regulation, applies only from 11 December 2027.

Clarity is meant to come from two directions. The Commission publishes guidance that expressly addresses scope in relation to free and open-source software (Article 26(2)(a)). Separately, it may introduce voluntary security attestation programmes by delegated act in order to ease the due diligence under Article 13(5) (Article 25). Recital 21 wants those programmes designed so that an attestation can be initiated or financed not only by the developers and contributors but by third parties such as integrating manufacturers, users or public administrations.