The Cyber Resilience Act recognises open-source software as a category that does not fit comfortably into the manufacturer-led conformity model. After extensive consultation with the open-source community during 2023-2024, the final text introduces a separate category — open-source software stewards — with its own obligations under Article 24. Stewards are not manufacturers under the CRA. They do not produce EU Declarations of Conformity, do not affix CE markings, are not subject to conformity assessment under Article 32, and are not subject to administrative fines under Article 64. They do have three concrete obligations: a cybersecurity policy, vulnerability reporting cooperation, and information sharing with market surveillance authorities. The regime entered force with the rest of the CRA on 10 December 2024, with substantive application from 11 December 2027.
What is an "open-source software steward"?
Article 3(14) of the CRA defines an open-source software steward as a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software (FOSS) and intended for commercial activities, and that ensures the viability of those products. The definition has four operative elements. First, the steward is a legal person, not an individual contributor — this means foundations, non-profits, and commercial entities acting in a steward capacity but not natural-person maintainers. Second, the support is systematic and sustained, not occasional. Third, the FOSS being supported is intended for commercial activities — a hobbyist project with no commercial deployment is outside scope. Fourth, the steward ensures viability of the project, suggesting some level of governance or funding role.
Who counts as a steward in practice?
The European Commission's draft guidance — published for consultation in 2025 — identifies typical examples: the Eclipse Foundation, the Linux Foundation, the Apache Software Foundation, the Python Software Foundation, the Rust Foundation, OpenSSL Foundation, and similar organisations that host or otherwise systematically support FOSS used in commercial contexts. Companies that employ maintainers of strategic open-source projects on a sustained basis may also qualify as stewards in respect of those projects, even if the projects are governed through external foundations — for instance, a cloud vendor that employs the principal maintainers of a critical infrastructure library. The Commission has signalled that the test is functional rather than formal: does this entity provide systematic and sustained support that keeps a commercially-used FOSS project viable?
What does Article 24 require?
Article 24 imposes three substantive obligations on stewards:
# CRA Article 24 steward obligations
1. Cybersecurity policy
Put in place and document a cybersecurity policy to foster
the development of a secure product with digital elements as
well as an effective handling of vulnerabilities.
The policy should specifically address:
- secure development practices for the project
- vulnerability handling and disclosure
- coordination with downstream commercial users
- incident response coordination role of the steward
2. Cooperation with market surveillance authorities
Cooperate with market surveillance authorities at their request
to mitigate the cybersecurity risks of FOSS products that the
steward supports.
This is a passive cooperation duty, not active monitoring.
3. Reporting of vulnerabilities and incidents
Notify the relevant CSIRT (and ENISA via the single reporting
platform under Article 16) of actively exploited vulnerabilities
contained in supported products, and severe incidents having
an impact on the security of supported products.
Cadence aligned to Article 14: 24-hour early warning,
72-hour notification, 14-day or one-month final report.
That is the complete substantive duty. Article 24 does not impose Annex I essential cybersecurity requirements, does not require technical documentation under Annex VII, and explicitly excludes stewards from administrative fines under Article 64.
What does the steward NOT have to do?
The contrast with the manufacturer regime is significant. A steward does not produce an EU Declaration of Conformity, does not affix a CE marking, does not perform conformity assessment under Module A, B+C, or H, does not engage a Notified Body, does not maintain Annex VII technical documentation in the form required for manufacturers, and is not subject to product recall under Article 22. A steward is not required to provide updates for the project — although Article 13(7) imposes that obligation on manufacturers that integrate the FOSS into their products, the obligation does not flow upstream to the steward. The architecture is deliberate: the EU recognises that imposing manufacturer-grade obligations on foundations would force projects to shed European maintainers or restructure outside EU jurisdiction, harming the supply ecosystem the CRA seeks to protect.
How does a manufacturer's FOSS use interact with steward status?
The CRA distinguishes between the steward (the legal entity that supports the FOSS project) and the manufacturer (the entity that integrates the FOSS into a product with digital elements placed on the EU market). A manufacturer that includes a FOSS library in its product takes on full manufacturer obligations for that product, including conformity assessment, technical documentation, vulnerability handling, and CE marking. The fact that the FOSS comes from a steward-governed project does not transfer obligations upward. Manufacturers must continue to apply due diligence in the selection and use of integrated FOSS — typically through SBOM generation, vulnerability scanning, and component vetting — as part of their own Annex I essential requirements compliance.
What about the boundary between steward and contributor?
Individuals who contribute to FOSS projects on a non-commercial basis are not stewards. Article 2(2) excludes FOSS released outside the course of a commercial activity from the CRA's scope entirely. The steward category bridges the gap where a project is itself non-commercial in development but is widely used in commercial deployments — for example, OpenSSL or curl. The steward duties attach to the entity that systematically supports the project's viability, not to individual contributors. A natural-person maintainer who contributes code to a foundation-stewarded project bears no CRA obligation. A company that pays an employee to contribute upstream does not become a steward by virtue of that employee's contributions, but might become a steward if it takes on a systematic and sustained governance role.
What guidance is available?
The Commission's draft guidance for stewards was published for consultation in 2025 and runs to roughly 75 pages. Key clarifications include the boundary between stewardship and ad-hoc support, the form of the cybersecurity policy (the guidance suggests OpenSSF Scorecard practices and CNCF security baselines as reasonable starting templates), and the integration of steward vulnerability reporting with downstream manufacturer reporting under Article 14. Stewards that already participate in coordinated vulnerability disclosure programmes — for example, through the GitHub Security Advisory database or the CNA programme — are likely to find their existing processes substantially compliant with Article 24's reporting obligation.
How Safeguard Helps
Safeguard helps both stewards and manufacturers operate within the CRA's open-source dimension. For stewards, the platform provides the cybersecurity policy templates aligned to the Commission's draft guidance and OpenSSF practices, plus a vulnerability reporting workflow that interfaces with the ENISA single reporting platform under Article 16 alongside upstream CVE coordination. For manufacturers, Safeguard's SBOM module records FOSS provenance including steward identity where known, so that the Annex VII technical documentation reflects the upstream governance posture. Where a manufacturer's product depends on a steward-governed project, Safeguard tracks steward advisories alongside CVE feeds so that an Article 14 manufacturer notification can reference the upstream steward report consistently. The platform's policy gates flag components that lack steward governance or that come from projects with no documented cybersecurity policy, supporting due diligence at integration time.