What Is an Open Source Software Steward?

The CRA Gives Open-Source Software Steward a Formal Definition

Article 3 defines an open-source software steward using several cumulative elements. The steward must be a legal person, it must be other than the manufacturer, it must have the purpose or objective of systematically providing sustained support for the development of specific products with digital elements, those products must qualify as free and open-source software and be intended for commercial activities, and the steward must ensure the viability of those products. The definition should therefore be applied as a whole. An organisation does not become a steward simply because it uses the word foundation, hosts a repository or employs maintainers.

• The steward must be a legal person.
• The steward must be other than the manufacturer.
• Support must be systematic.
• Support must be sustained.
• Specific FOSS products must be involved.
• The products are intended for commercial activities.
• The steward ensures their viability.

An Individual Maintainer Is Not an Open-Source Software Steward Under the Definition

The legal-person requirement is important. Article 3 does not define an individual natural person acting alone as an open-source software steward. Individual maintainers can have major technical influence over a project, but stewardship under the CRA concerns an organisational legal person satisfying the full definition. This does not mean an individual can never have another CRA role. A natural person can potentially be a manufacturer under the separate manufacturer definition depending on the facts. But the open-source software steward category itself is expressly defined around a legal person.

• Steward status requires a legal person.
• Technical maintainership alone does not create steward status.
• Individual contributors need separate role analysis.
• Manufacturer status is governed by a different definition.

The Steward Must Be Different From the Manufacturer

A steward is expressly defined as a legal person other than a manufacturer. This prevents the steward regime from becoming a way for a company that actually manufactures and markets its own product to substitute lighter obligations for the normal manufacturer regime. An organisation should therefore start by asking whether it markets the product under its own name or trademark and assumes responsibility for the product in the market. Where the manufacturer definition applies, Article 24 stewardship should not be used to displace those obligations. A separate foundation or organisation supporting upstream development can occupy a steward role even where commercial manufacturers use the resulting software downstream.

• Steward and manufacturer are mutually distinct roles for the same entity in the statutory definition.
• Manufacturer analysis should be performed first.
• The steward regime is not an alternative manufacturer classification.
• Downstream manufacturers can coexist with an upstream steward.

Support Must Be Systematic and Sustained

Occasional help with an open-source project does not automatically satisfy the steward definition. Article 3 requires systematic support on a sustained basis. Recital 19 explains that sustained support can include hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing qualifying free and open-source products and steering their development. These examples point toward an ongoing organisational role rather than isolated contributions. The project should be able to identify continuing activities through which the legal person supports development and continuity.

• One-off contributions are not the same as sustained support.
• Project governance can demonstrate sustained support.
• Development infrastructure can be relevant.
• Steering development can be relevant.
• Long-term organisational involvement is central.

The Steward Supports Specific Open-Source Products

The statutory definition refers to support for the development of specific products with digital elements. A general organisation that advocates for open-source software, funds unrelated projects occasionally or provides broad industry education does not necessarily become the steward of every project it touches. The analysis should identify the particular software products for which the organisation provides systematic sustained support and the mechanisms through which it helps maintain their viability. This product-specific approach also helps define the boundaries of Article 24 cybersecurity policies and authority cooperation.

• Steward status relates to specific products.
• General open-source advocacy is not enough by itself.
• Project-by-project analysis can be necessary.
• The supported products should be identifiable.

The Supported Products Must Be Intended for Commercial Activities

The steward definition also requires the relevant free and open-source products to be intended for commercial activities. Recital 19 explains that the tailored regime should cover open-source products ultimately intended for commercial activity, including integration into commercial services or monetised products. The recital also explains that intention for integration into monetised products can exist where downstream manufacturers regularly contribute to development or provide regular financial assistance to ensure the software's continuity. This is different from saying that every donation or corporate contribution automatically makes the upstream project commercial. The steward analysis focuses on the supported product's intended commercial ecosystem as part of the complete statutory test.

• Commercial intention is part of steward status.
• Integration into commercial services can be relevant.
• Integration into monetised products can be relevant.
• Regular downstream support can help establish the intended commercial relationship.
• Ordinary financial support alone should not be analysed in isolation.

The Steward Must Help Ensure Product Viability

Ensuring viability is another express part of the statutory definition. The CRA does not define stewardship merely by financial sponsorship. The organisation needs to occupy a role that helps keep the supported products viable over time. Depending on the project, that can involve governance, development infrastructure, coordination, release support, vulnerability processes, project management or other sustained organisational mechanisms. A classification record should identify the concrete activities through which the organisation supports continuity. This provides a stronger basis for steward status than relying on organisation type or funding alone.

Foundations Can Qualify, but Foundation Status Is Not Enough

Recital 19 expressly recognises that open-source software stewards can include certain foundations. It also refers to entities that develop and publish free and open-source software in a business context, including not-for-profit entities. The wording is deliberately functional. A foundation should therefore test itself against the legal definition rather than assume that every open-source foundation is a steward. The relevant questions include whether it is a legal person, whether it is distinct from the manufacturer, whether it systematically supports identified projects on a sustained basis, whether those products are intended for commercial activities and whether the foundation helps ensure their viability.

• Certain foundations can be stewards.
• Not every foundation automatically qualifies.
• Not-for-profit entities can qualify.
• The statutory functional test controls.

Article 24 Requires a Verifiably Documented Cybersecurity Policy

Article 24(1) requires an open-source software steward to put in place and document in a verifiable manner a cybersecurity policy. The policy must foster development of secure products with digital elements and effective handling of vulnerabilities by the developers of those products. It must take account of the steward's specific nature and legal and organisational arrangements. This makes the policy more than a generic security statement. The organisation should be able to demonstrate how its governance, development processes and project infrastructure encourage secure development and vulnerability handling.

• The policy must exist.
• The policy must be documented in a verifiable manner.
• It should foster secure development.
• It should foster effective vulnerability handling.
• It should reflect the steward's actual organisational structure.

The Policy Must Address Vulnerability Handling

Article 24 specifically requires the steward cybersecurity policy to include aspects related to documenting, addressing and remediating vulnerabilities. It must also promote sharing of information about discovered vulnerabilities within the open-source community and foster voluntary vulnerability reporting by developers under Article 15. A useful policy should therefore define where vulnerabilities can be reported, how project teams receive and triage them, how remediation is coordinated and how relevant information is shared without unnecessarily exposing users to additional risk. The exact implementation can reflect the project's collaborative development model.

• Vulnerabilities should be documented.
• Processes should support addressing vulnerabilities.
• Remediation should be supported.
• Voluntary reporting should be fostered.
• Information sharing within the open-source community should be promoted.

Stewards Must Cooperate With Market Surveillance Authorities

Article 24(2) requires open-source software stewards to cooperate with market surveillance authorities at their request with a view to mitigating cybersecurity risks posed by qualifying free and open-source products. Following a reasoned request, the steward must provide the authority with the cybersecurity-policy documentation referred to in Article 24(1), in paper or electronic form and in a language that can be easily understood by that authority. Organisations should therefore maintain the policy and supporting evidence in a form that can actually be produced rather than treating Article 24 as an informal governance expectation.

• Market surveillance authorities can request cooperation.
• The purpose is mitigation of product cybersecurity risk.
• Policy documentation can be requested.
• Documentation should be maintained in a producible form.

Article 24(3) Creates Limited Reporting Duties

Article 24(3) applies parts of the manufacturer reporting framework to open-source software stewards, but only within the limits stated in that provision. Article 14(1), concerning notification of actively exploited vulnerabilities, applies to stewards to the extent that they are involved in development of the relevant products. Article 14(3) and Article 14(8) apply to stewards to the extent specified where severe incidents affect network and information systems the steward provides for development of those products. The steward reporting regime should therefore not be described as identical to the full manufacturer reporting framework.

• Article 14(1) is incorporated within the Article 24(3) limits.
• Article 14(3) applies within the specified steward incident scenario.
• Article 14(8) can also apply within that scenario.
• Steward reporting is narrower than manufacturer reporting.

Steward Reporting Applies From 11 December 2027

The timing distinction is important because Article 14 itself began applying to manufacturers on 11 September 2026. Article 24, however, is part of the general CRA application from 11 December 2027. The European Commission's CRA reporting guidance expressly confirms that open-source software stewards are subject to the Article 24(3) reporting obligations from 11 December 2027. Projects preparing for steward status should therefore use the period before that date to establish reporting ownership, vulnerability intake, escalation procedures and access to the information necessary to make notifications where the Article 24 conditions are met.

• Manufacturer Article 14 reporting began on 11 September 2026.
• Steward Article 24(3) reporting starts on 11 December 2027.
• The two application dates should not be conflated.
• Stewards can prepare reporting processes before the obligation begins.

Stewards Do Not Use the Manufacturer CE Marking Role

Recital 19 explains that the tailored steward regime does not impose the same obligations as the manufacturer regime and that stewards should not be permitted to affix CE marking to the products whose development they support merely in their steward capacity. This reinforces the distinction between sustaining an upstream open-source ecosystem and acting as the manufacturer responsible for placing a product on the market. A downstream manufacturer integrating the software into a commercial product can still have its own conformity assessment and CE-marking responsibilities.

• Steward status is not manufacturer status.
• The steward role does not itself provide the manufacturer CE-marking role.
• Downstream manufacturers remain separately responsible.
• Role separation should be documented.

Document Why the Organisation Is or Is Not a Steward

An organisation working around open-source software should create a short role assessment for each significant project. It should identify the legal entity, supported software products, whether those products qualify as free and open-source software, how the organisation supports development, how long and how systematically that support is provided, whether the products are intended for commercial activities and how the organisation helps ensure viability. It should also record whether another entity acts as manufacturer. This evidence gives the organisation a reproducible basis for applying Article 24 and for explaining its position if a market surveillance authority later asks about the project.

• Identify the legal entity.
• Identify the supported projects.
• Document sustained support.
• Document commercial intention.
• Document viability activities.
• Identify any separate manufacturer.
• Connect the conclusion to Article 24 processes.