The figure of the OSS Steward (“open-source software steward”) emerges within the framework of the Cyber Resilience Act (CRA) as a response to a key reality of the digital ecosystem: the growing integration of open-source software into products with digital elements and the need to strengthen their security without altering their non-commercial nature.
The CRA establishes a structured regulatory framework for managing the security and vulnerabilities of products with digital elements marketed on the European market, recognising different types of actors with differentiated responsibilities. Among them, it introduces a new category: the OSS Steward.
Concept of products with digital elements
Article 3.1 CRA defines products with digital elements as any software or hardware product, including its remote data processing solutions, as well as components marketed separately:
Article 3.1 CRA: “product with digital elements”: a software or hardware product and its remote data processing solutions, including software or hardware components that are marketed separately.
In practice, this category covers IoT and everything that is “smart” (smartwatch, smart car, interactive toys…), as well as software marketed independently and platforms connected to these products.
The Commission’s Draft Guidelines confirm that this concept must be interpreted broadly, functionally and in a technologically neutral manner. In particular:
- Section 2.1.1: standalone software — applications, operating systems or enterprise software — may in itself constitute a product with digital elements when it is made available on the market.
- Section 2.1.2: the product must be understood as a complete functional unit, including the remote data processing solutions necessary for its operation.
- Section 2.2: the concept is connected with that of an “electronic information system”, extending the scope to any system capable of processing, storing or transmitting digital data.
Therefore, the category covers a very broad range. In the field of connected hardware: routers, smart security cameras, home alarm systems, access-control and biometric-authentication readers, smartwatches, smart TVs and connected vehicles. In the field of standalone software: operating systems, enterprise applications, antivirus solutions, software firewalls, or cloud platforms that provide the remote data processing necessary for a product to operate. Even components marketed separately — such as software libraries or firmware modules — may themselves constitute products with digital elements if they are made available on the market.
Concept of OSS Steward
Article 3.14 CRA formally defines the OSS Steward as:
Article 3.14 CRA: “open-source software steward”: a legal person, other than a manufacturer, that has the purpose or objective of systematically and sustainably providing support for the development of specific products with digital elements that qualify as free and open-source software and are intended for commercial activities, and that ensures the viability of those products.”*
In short, the OSS Steward is an organisation that, without directly marketing the software, plays an active and sustained role in its maintenance, evolution and stability, especially where that software is used in products or services with commercial use. In practice, this role is usually assumed by foundations and non-profit organisations
Requirements to be considered an OSS Steward
For an entity to be classified as an OSS Steward under the CRA, the following requirements must be met cumulatively. If any of them is missing, the entity cannot be considered an OSS Steward for the purposes of the CRA:
- Legal person: individuals are expressly excluded; foundations, associations, etc. are included.
- Separate from the manufacturer: the OSS Steward does not place products on the market and does not assume the obligations of the manufacturer, in particular those provided for in Articles 13 and 14 CRA.
- Systematic and sustained support: this must be interpreted broadly and includes code maintenance, contribution management and vulnerability management. It must be provided in an organised and structured manner (systematically) and with continuity over time (sustainably), excluding one-off or periodic interventions. The Draft Guidelines clarify that this support may take different forms: from non-technical support — brand management, governance, community events, fundraising — to support in technical infrastructure — repositories, version control, signing keys — and even engineering resources — employing developers, coordinating development, reviewing or merging code, managing releases or handling vulnerabilities and security patches. Mere passive code hosting is insufficient.
- Software intended for commercial activities: this excludes purely academic or personal projects with no connection to the market.
In practice, the role of OSS Steward is typically assumed by foundations and non-profit organisations. The most representative examples are: the Apache Software Foundation (ASF), which manages projects such as Apache HTTP Server, Kafka and Tomcat, widely used in commercial environments; the Eclipse Foundation, which coordinates hundreds of development-tool and framework projects; the Linux Foundation, which acts as steward for projects such as the Linux kernel, Kubernetes and the Sigstore project — the latter being managed specifically through the OpenSSF (Open Source Security Foundation), which is part of the Linux Foundation —; and foundations such as the Python Software Foundation, the PHP Foundation, the OpenSSL Software Foundation, the Rust Foundation and the Blender Foundation, all of which are actively involved in preparing for CRA compliance. In fact, in 2024 these seven foundations announced a joint collaboration, led from Brussels by the Eclipse Foundation, with the aim of developing common secure software development standards to facilitate CRA compliance.
Obligations of the OSS Steward (Article 24 CRA)
The regime of obligations applicable to the OSS Steward is more limited than that applicable to manufacturers, but it introduces a key element: a system of obligations scaled according to the level of control (Section 3.3.1 of the Guidelines). The greater the effective control over the project, the greater the responsibility; and vice versa. This approach reflects the principle that “you are only responsible for what you control”.
The three main obligations of the OSS Steward are:
- Cybersecurity policy appropriate to its size and structure, including measures for secure software development and vulnerability management (Art. 24.1 CRA).
- Facilitation of vulnerability reporting and participation in information sharing within the community (Art. 24.1 CRA).
- Cooperation with the competent authorities, providing them with clear information and collaborating in risk mitigation. Formal notification obligations are more limited and apply only in certain cases, such as the vulnerability notifications under Article 14.1 (Art. 24.2 CRA).
The Guidelines also clearly define what an OSS Steward is not (Section 3.3.2): it does not place the product on the market, does not carry out conformity assessments, does not issue EU declarations and does not affix the CE marking.
The main difference compared with the manufacturer lies in the fact that the latter is fully responsible for a product it places on the market, whereas the OSS Steward has a more limited responsibility, focused on the support and security of open-source software.
Accumulation of roles: manufacturer and OSS Steward within the same entity
Under the CRA, roles are not attributed to the company in the abstract, but according to each specific case. The same legal person may simultaneously act as manufacturer in respect of one FOSS and as OSS Steward in respect of another. Roles must be analysed project by project, or even version by version.
A common case is that of companies that manage the same FOSS project with two versions:
- Commercial version → manufacturer
- Free version → steward
The consequence is that the CRA requires a granular approach to compliance: the entity must identify its role for each piece of software or version, since the applicable obligations will depend on that classification in each case.
Conclusion: role and scope of the OSS Steward under the CRA
The OSS Steward is configured as an intermediate figure within the open-source software development ecosystem: it is not a manufacturer and does not market the software, but it assumes an active role in its maintenance, support and viability. Its responsibility under the CRA with regard to vulnerability management is delimited according to the degree of control it exercises over the project.
↳ Discover more content in the section Insight.
↳ Do you want to stay up today about the sector related news? Follow us on LinkedIn.
