Key takeaways
- The steward's role ensures the viability of the software (funding, governance, release management, security response coordination).
- A steward does not have to: meet the Annex I essential cybersecurity requirements itself, run a conformity assessment procedure, affix CE marking, or issue an EU declaration of conformity.
- Device makers already building a CRA 24-hour/72-hour reporting process for their own products should not assume every open-source foundation they depend on carries the same clock.
- Classify your own open-source dependencies' upstream organisations, not just the components.
The Cyber Resilience Act does not treat every organisation that touches open-source code as a "manufacturer." Regulation (EU) 2024/2847, Article 24 creates a separate, deliberately lighter category — the open-source software steward — for the foundations and similar bodies that keep widely used free and open-source components alive, as distinct from the companies that build and sell products with digital elements using that code. A device maker shipping firmware built on an open-source TLS library, RTOS or protocol stack needs to know which side of that line its own suppliers and its own open-source contributions sit on.
Who counts as a steward, and who doesn't
The CRA's own definition, as summarised by consistent secondary legal analysis, limits "open-source software steward" to a legal person other than a manufacturer that:
- Provides sustained, systematic support for the development of specific free and open-source software,
- Where that software is intended for commercial activities, and
- The steward's role ensures the viability of the software (funding, governance, release management, security response coordination).
This is a narrow category built around organisations such as software foundations, not a catch-all for anyone who uses or redistributes open-source code. Two groups fall outside the CRA entirely, not just outside Article 24:
- Individual maintainers and volunteer contributors acting outside a commercial activity.
- Free and open-source software developed or supplied purely outside a commercial context — the CRA's recitals carve this out so individual hobby and non-commercial projects are not swept into product-liability-style obligations never designed for them.
A manufacturer that happens to build its product on open-source components, or that itself publishes open-source software as part of a commercial product strategy, does not become a "steward" by doing so — it stays a manufacturer under Article 13, with the full Annex I obligations. Stewardship is about the organisation that sustains the underlying software project, not the company that integrates it into a shipped device.
What Article 24 actually asks for
Per secondary analysis of the regulation's text, a steward's obligations are structured around three things, each lighter than the equivalent manufacturer duty:
| Steward obligation | Manufacturer equivalent it is lighter than |
|---|---|
| Put in place and document a cybersecurity policy, proportionate to the steward's activity and the risk of the software it stewards | Full Annex I essential requirements and Article 31 technical documentation |
| Cooperate with manufacturers that integrate the steward's software, so those manufacturers can meet their own CRA obligations | N/A — this duty only exists for stewards, as the counterpart to a manufacturer's own due-diligence duty on components it integrates |
| Cooperate with market surveillance authorities on a reasoned request | Full inspection and corrective-action regime under Articles 52-55 |
A steward does not have to: meet the Annex I essential cybersecurity requirements itself, run a conformity assessment procedure, affix CE marking, or issue an EU declaration of conformity. It is also not subject to the administrative fines Article 64 sets for manufacturers, importers and distributors — enforcement against a non-compliant steward instead works through a market surveillance authority requiring corrective action, not a monetary penalty, per secondary analysis of the enforcement provisions.
Scoped vulnerability reporting, not the full Article 14 clock
Device makers already building a CRA 24-hour/72-hour reporting process for their own products should not assume every open-source foundation they depend on carries the same clock. Secondary analysis of Article 24 describes its reporting trigger as scoped to stewards that develop the product with digital elements, substantially contribute to its development, or provide the systems used to develop it — language that pulls in a foundation actively building the software, but not a foundation that merely hosts a package index or distributes releases it did not help write. A steward outside that description is not bound by the 24-hour/72-hour deadlines, though it can still choose to report voluntarily.
This distinction matters for supply-chain risk assessment: if a critical dependency's upstream steward has no CRA reporting duty of its own, a manufacturer's own vulnerability-monitoring plan — not an assumption that the foundation will report on the same schedule — is what actually closes the gap. See firmware SBOM for building the component inventory this kind of dependency risk assessment starts from.
What device makers and foundations should do now
Classify your own open-source dependencies' upstream organisations, not just the components. A library maintained by an individual volunteer, a company-backed open-source project, and a foundation-stewarded project each sit differently relative to the CRA — only the foundation case can be an Article 24 steward. Don't assume a steward's cybersecurity policy substitutes for your own technical documentationArticle 24 does not require a steward to meet Annex I; a manufacturer integrating stewarded software still owns its own Annex I compliance for the product it ships. If your company funds or governs an open-source foundation, work out separately whether that activity makes the foundation a steward under Article 24 and whether your own product-shipping activity keeps you a manufacturer under Article 13 — the two roles are not mutually exclusive across a group of companies. Build your own vulnerability-monitoring plan to not depend on upstream steward reporting, since most stewards fall outside Article 14's 24-hour/72-hour scope. See the CRA checklist for device makers for the manufacturer-side obligations this steward regime sits alongside, and CRA obligations for importers and distributors for how the same chain-of-responsibility logic works for resellers. Confirm current article-level text on EUR-Lex before a compliance decisionThis guide summarises secondary analysis of Article 24 because EUR-Lex's own page served an automated bot-protection challenge rather than article text during this guide's research; treat specific clause numbering as a starting point, not a final citation.
SoftWSP's firmware security work can help map which open-source components in your SBOM come from a steward-type organisation versus an individual maintainer, so your own CRA risk assessment reflects the real supply chain: see Device & Firmware Security.
This guide is general information, not legal advice, and summarises secondary analysis of Regulation (EU) 2024/2847 Article 24 where the official EUR-Lex text could not be directly retrieved during research; confirm against the current official text before relying on it.
Sources
Frequently asked questions
What is an 'open-source software steward' under the Cyber Resilience Act?
The CRA, Regulation (EU) 2024/2847, defines an open-source software steward as a legal person, other than a manufacturer, that provides sustained support for the development of specific free and open-source software intended for commercial activities and that ensures the viability of that software. Foundations such as the Apache Software Foundation, the Eclipse Foundation and the Python Software Foundation are the kind of organisation this category is built around; an individual volunteer maintainer or a purely non-commercial project is not caught by the CRA at all.
Does Article 24 impose the same duties as Article 13 on manufacturers?
No. Per widely corroborated secondary legal analysis of the regulation (EUR-Lex's own site served a bot-protection challenge page rather than article text when this guide was researched, so treat article-level wording as to be confirmed against the official text), Article 24 is explicitly described in the CRA's recitals as a 'light-touch and tailor-made regulatory regime.' Stewards are not required to meet the Annex I essential requirements, do not affix CE marking, do not run a conformity assessment, and are not subject to the administrative fines that apply to manufacturers under Article 64.
What does Article 24 actually require from a steward?
Based on consistent secondary-source summaries of the article, a steward must put in place and document a cybersecurity policy proportionate to its activity and the risks of the software it stewards, cooperate with manufacturers that integrate its software so those manufacturers can meet their own CRA obligations, and cooperate with market surveillance authorities on request. It does not have to produce the Article 31 technical documentation a manufacturer owes.
Do CRA vulnerability-reporting deadlines apply to open-source software stewards?
Only in a scoped way. Secondary analysis describes Article 24 as applying Article 14's reporting duties to a steward only where that steward develops the product with digital elements, substantially contributes to its development, or provides the systems used to develop it — not to every foundation that merely hosts or distributes code it did not help build. Confirm the exact trigger against the regulation's own Article 14 and Article 24 text before relying on it.
When do the open-source software steward obligations start applying?
The CRA's general application date for Chapter II obligations, which includes Article 24, is 11 December 2027, the same date manufacturers' Annex I essential requirements and most of their Article 13 duties start applying; see [the CRA vulnerability-reporting guide](/guides/cra-vulnerability-reporting-24h/) for the separate, earlier 11 September 2026 date that governs Article 14 reporting specifically. This guide's dates come from the Regulation's Article 71 staggered application schedule already used elsewhere on this site; confirm the current text on EUR-Lex before treating a specific date as final for a steward-specific question.
In this cluster
