An APAC industrial gateway maker ships embedded Linux devices across the EU under its own brand. The Linux distribution it uses is OpenHarmony — the OS Huawei donated to the OpenAtom Foundation in Beijing, and which is brought to Europe through Oniro, governed by the Eclipse Foundation AISBL in Brussels. The company's compliance lead reads CRA Article 13 (manufacturer obligations), confirms what already seems obvious — the company is the manufacturer of its own gateway, with full Article 13 obligations attached — and starts planning the Article 14 reporting capability for September 2026. Standard work.
Then a question lands from the engineering team: "are we also a steward?" The team contributes patches upstream to Oniro on a regular basis, runs a small group of Brussels-based engineers paid by the APAC parent to maintain a downstream module, and lists itself as an Oniro Strategic Member. The compliance lead reads Article 24, then Article 3(14), then Recital 19. Two hours later he is not certain about the answer.
That uncertainty is what Article 24 is for. The CRA invented a legal category that did not exist in any prior EU regulation — open-source software steward — and dropped it in front of every legal entity that systematically supports an open-source project intended for commercial use. The category catches some organisations cleanly, releases others cleanly, and leaves a gap in the middle that APAC sponsors of open-source projects need to read carefully because it is exactly where many of them sit.
§ 01The category Article 24 invented, and the problem it was solving
Before the CRA, EU product safety law had two relevant categories for software in commerce: manufacturers, who place products on the market and bear full conformity obligations, and nobody else. Open-source contributors as a class did not appear. A volunteer maintaining a popular library out of personal interest, a foundation systematically funding a critical project, a company sponsoring an OSS distribution it then sells products on top of — all three sat in the same legal void.
The CRA had to decide what to do about that void. Treating every OSS contributor as a manufacturer would crush volunteer maintainers and large foundations alike under conformity assessment costs designed for commercial product makers. Treating none of them as anything would leave foundations that systematically support critical commercial software completely outside the regulatory framework — which is politically untenable when those foundations underpin EU industry's software supply chain.
Article 24 is the compromise. It invents a new category — open-source software steward — with a regulatory regime described in Recital 19 as "light-touch and tailor-made". The category catches legal persons that systematically and sustainably support OSS projects intended for commercial use, but it carries a fraction of the manufacturer obligation set, and it carries them with the explicit recognition that OSS governance is structurally different from product governance.
Three structural design choices in Article 24 are worth seeing on their own, because each one is a deliberate signal:
Stewards cannot affix CE marking. Recital 19 is explicit: "they should not be permitted to affix the CE marking to the products with digital elements whose development they support." The CE mark is reserved for entities that did the conformity assessment work — manufacturers. Stewards do not do that work, do not claim that bar, and the mark is not theirs to apply.
Stewards do not pay administrative fines. Article 64(10) exempts stewards from administrative fines for any infringement of the CRA. This is the single largest indicator that the EU intended the steward regime to be cooperative rather than punitive. Manufacturers face penalties up to €15M or 2.5% of global turnover. Stewards face zero.
Stewards' core obligation is one document, made verifiable. Article 24(1) requires a written cybersecurity policy promoting secure development and effective vulnerability handling, kept "in a verifiable manner". That is the substantive ask. There is no SBOM obligation, no support period declaration, no technical documentation file, no Annex VII, no conformity assessment route to choose, no notified body queue to wait in. The asymmetry is enormous, and it is enormous on purpose.
§ 02Article 3(14): the four words that decide everything
The steward category is gated by Article 3(14). Reading the definition slowly is the difference between knowing whether you are inside or outside the regime.
The definition reads: an open-source software steward is "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 and intended for commercial activities, and that ensures the viability of those products."
Five elements have to be present together. Each one is a gate.
Element 1 — "legal person". A natural person — an individual maintainer, a volunteer, a hobbyist contributor — cannot be a steward. The definition is not ambiguous on this point, and the Open Regulatory Compliance Working Group's CRA FAQ confirms it: "the obligations of open-source software stewards described in Article 24 therefore do not apply to solo maintainers acting in their personal capacity." A legal person means a company, a foundation, an association, a registered non-profit. An unincorporated developer collective is not a legal person, and is not a steward.
Element 2 — "other than a manufacturer". The same legal entity cannot be both manufacturer and steward for the same product. But Commission Draft Guidance (March 2026, draft, non-binding) confirms a single legal entity can be steward for one project and manufacturer for another. A foundation that hosts a community version while a separate paid enterprise version is sold on top — common in the OSS world — could see the foundation as steward for the community version and the company selling the enterprise version as manufacturer for it.
Element 3 — "purpose or objective of systematically providing support on a sustained basis". Two cumulative requirements: systematic (organised, not ad hoc) and sustained (over time, not one-off). A foundation that exists to fund a project ongoingly is in. A company that contributed a feature once and walked away is not. The Commission Draft Guidance lists examples of "support on a sustained basis": hosting collaboration platforms, maintaining governance, steering development direction.
Element 4 — "intended for commercial activities". The OSS itself must be aimed at commercial use somewhere downstream. Recital 18 is the key instrument here: "the mere circumstances under which the product with digital elements has been developed, or how the development has been financed, should not be taken into account when determining the commercial or non-commercial nature of that activity." Recital 19 sharpens it: software "ultimately intended for commercial activities, such as for integration into commercial services or into monetised products with digital elements". A library that is only ever used in academic research, with no commercial integration anywhere, falls outside. A library widely integrated into commercial IoT products falls inside — even if every contributor is a volunteer and the library itself is given away.
Element 5 — "ensures the viability". The legal person plays a primary role in keeping the project alive. A minor contributor among many is not a steward. The party that the project would not exist without — or would not survive without — is.
All five gates have to open. Miss one and you are not a steward in the legal sense, regardless of how OSS-adjacent the activity is in everyday speech.
§ 03Three scenarios where the regime bites
The cleanest way to feel where Article 24 lands is to walk through three structural archetypes that fall inside.
Scenario A — Foundation-hosted OSS with industrial integration. The Eclipse Foundation AISBL, Brussels-incorporated since January 2021, hosts hundreds of OSS projects including the Eclipse IDE family, Jakarta EE, and Oniro. Each project is integrated into commercial products by EU manufacturers. Eclipse AISBL is a legal person, has systematic and sustained support as its core purpose, the projects target commercial use, and the foundation ensures their viability. All five gates open. Eclipse AISBL is a steward for those projects. The Apache Software Foundation, despite being Delaware-incorporated, falls into the same analysis to the extent it has European exposure — its projects are everywhere in EU industrial software stacks.
Scenario B — Sub-foundation under a parent, parent absorbs the obligation. The Cloud Native Computing Foundation and the OpenJS Foundation are not independent legal persons — they are projects of the Linux Foundation (US 501(c)(6), EIN 46-0503801, registered in Delaware). The CNCF cannot be a steward in its own right because it is not a legal person. If steward obligations apply, they apply to the Linux Foundation as the parent legal entity. APAC contributors to CNCF projects need to look at the parent for the regulatory consequence, not the sub-foundation.
Scenario C — Corporate-stewarded project with EU commercial nexus. Huawei donated OpenHarmony source code to the OpenAtom Foundation in Beijing in 2021. OpenAtom itself is a Chinese NGO under MIIT supervision and lacks an EU legal person. The pan-European version, Oniro, is governed by Eclipse Foundation AISBL — and that is the entity in EU jurisdiction. Eclipse AISBL is the steward for Oniro. Huawei is the manufacturer of any EU-market product (gateways, automotive head units, IoT devices) it ships running OpenHarmony, which means full Article 13 manufacturer obligations on its own products plus a sponsor relationship to a steward (Eclipse). Two roles, two obligation sets, on the same software stack — but cleanly separated by which legal person did what.
The pattern across all three is the same: stewardship attaches to the legal person systematically and sustainably keeping the project alive, with EU jurisdictional reach. APAC organisations sponsoring OSS via a EU-incorporated foundation effectively channel their stewardship through that foundation — the foundation is the steward in EU eyes, not the APAC sponsor.
§ 04Three scenarios where it does not
The mirror image is more important to read carefully, because the noise around the CRA tends to over-include.
Scenario D — Solo maintainer, regardless of project popularity. An individual developer in Taipei maintaining a popular Rust crate, downloaded weekly by EU industrial software vendors, is not a steward. Article 3(14) requires a legal person; a natural person does not qualify. Recital 18 reinforces it: contributing source code to a project not under one's responsibility puts the contributor outside the regulation entirely. The maintainer is not a steward, not a manufacturer, not anything CRA-defined. This holds regardless of how widely the crate is integrated commercially. The risk shifts to the manufacturers that integrate it — they have to handle vulnerabilities in their own SBOMs — but it does not shift to the maintainer.
Scenario E — Unincorporated developer collective. A small group of developers in Tokyo collaborating informally on a shared project, no legal entity, no foundation, no incorporation — falls outside Article 3(14) for the same reason. There is no legal person to attach steward obligations to. If the group later forms a foundation or non-profit (whether in Japan, the EU, or elsewhere) and that entity systematically supports the project, the analysis changes. Until then, the collective is invisible to the CRA.
Scenario F — Project where commercial use is downstream, not the steward's. A Korean academic group maintains a research-oriented OSS toolkit. The toolkit is freely available; its primary use is in academic publications and graduate research. A subset of EU manufacturers happens to integrate parts of the toolkit into commercial IoT products. The academic group does not "intend" the software for commercial activities — its purpose is research. The integration was downstream, performed by the manufacturers themselves. Recital 19's phrasing — "intended for commercial activities" — keys on intent, not coincidental downstream use. The academic group is not a steward.
The thread connecting D, E, and F is that not every OSS contribution carries steward consequences. The category is narrow on purpose. APAC contributors who assume they fall in tend to overcommit; APAC contributors who actually fall in tend to underprepare. Reading Article 3(14) closely is how you know which bucket you are in.
§ 05Article 52(3) and Article 64(10): why the regime has teeth and where it does not
It is tempting to read the asymmetry between manufacturer and steward obligations as meaning the steward regime is performative — light obligations, no fines, no real enforcement. That reading misses Article 52(3).
Article 52(3) makes market surveillance authorities "responsible for carrying out market surveillance activities in relation to the obligations for open-source software stewards laid down in Article 24". Where an MSA finds non-compliance, it "shall require the open-source software steward to ensure that all appropriate corrective actions are taken". The MSA can enter a steward's processes, demand documentation in a language it understands, and order corrective action. The Article 24(1) cybersecurity policy is not a private internal document — it is auditable.
What the MSA cannot do is the part that distinguishes the regime. Manufacturers face the full Article 54–58 toolkit: corrective measures, mandated recall, market withdrawal, prohibition on placing on the market, administrative fines. Stewards face only the corrective-action requirement. No recall (because there is no product to recall — the steward is not a manufacturer). No withdrawal. No fines (Article 64(10)). The MSA can require the steward to fix its policy and processes; it cannot impose the financial pain that manufacturers face.
This calibration is structural rather than accidental. The regime says: "we recognise you keep critical software alive, we want a verifiable cybersecurity policy from you, we will inspect it, but we will not financially destroy you for getting it wrong because the OSS commons depends on you continuing to exist." The policy is a real obligation. The penalties are deliberately not.
The practical consequence for steward-eligible APAC organisations is that the cost of getting the policy wrong is reputational and operational (the MSA can disrupt your operations and require remediation work) rather than financial. The cost of being mistakenly classified as a manufacturer when you are actually a steward, however, is enormous — €15M-class fines plus full Article 13 burden. Reading Article 3(14) carefully matters not because the steward regime is heavy, but because the manufacturer regime next door is.
§ 06What APAC OSS contributors should actually do
Five concrete moves, in order of priority.
Move 1 — Map your legal person against Article 3(14). If you are an individual, you are out. If you are an unincorporated group, you are out. If you are a company, foundation, or association, walk through the five elements: legal person ✓, not the manufacturer of the same product ✓, systematic and sustained ✓, intended for commercial activities ✓, ensures viability ✓. Five tickmarks means you are in. Less than five means you are out (or you are something else, like a manufacturer).
Move 2 — If the answer is "out but adjacent", document the analysis. APAC sponsors of OSS that route stewardship through a EU foundation (Eclipse AISBL, etc.) are typically not stewards themselves — the foundation is. But MSAs may ask. Having a one-page analysis showing why the foundation is the steward and you are the sponsor (with the legal-person, systematic-and-sustained, viability arguments worked out) is much cheaper to produce in advance than to reconstruct under an MSA reasoned request.
Move 3 — If the answer is "in", start with the cybersecurity policy. Article 24(1) requires it documented "in a verifiable manner". That means a real document, version-controlled, dated, with a named responsible individual, that is actually applied in practice. It must address vulnerability handling, secure development promotion, and explicit encouragement of voluntary vulnerability reporting per Article 15. The 2026 March Draft Guidance gives examples of policy elements. Use those, plus your own governance documents (charter, contribution guidelines, security.txt), as the building blocks. The policy is the central artefact MSAs will read first.
Move 4 — Consider whether EU legal-person status is operationally helpful. Eclipse moved its primary legal seat to Brussels (AISBL) before the CRA was even adopted. The move turned out to be strategically advantageous: Eclipse is now the home-jurisdiction defendant for EU MSA matters, sits on the CRA Expert Group, and hosts the Open Regulatory Compliance Working Group. APAC-sponsored foundations without an EU legal person face MSA contact friction — not regulatory invisibility (the obligation still exists), but practical difficulty in cooperation. For foundations whose primary commercial users are in the EU, an AISBL or comparable EU entity is worth costing out. For foundations whose commercial users are dominantly elsewhere, it is not.
Move 5 — Distinguish between your steward role and your manufacturer role on the same software. If your organisation contributes to an OSS project (steward exposure) and sells products integrating that OSS in the EU (manufacturer exposure), the two regulatory tracks run in parallel. Steward role: Article 24, cybersecurity policy, no fines. Manufacturer role: Article 13, full conformity assessment, CE marking, SBOM, support period, Annex VII, full fines. Don't conflate them. The Commission Draft Guidance explicitly confirms a single legal entity can hold both roles for different projects or different versions. Documenting which role applies to which project is part of getting both right.
§ 07The asymmetry that makes the puzzle worth solving
Return to the APAC gateway maker. The compliance lead reads Article 24, then Article 3(14), then Recital 19, and the analysis resolves.
The company is the manufacturer of its own gateway — full Article 13 obligations, full Article 14 reporting clock, full conformity assessment route. That part was never in question.
The company is also a sponsor of Oniro through its Strategic Member contribution. But the steward of Oniro is Eclipse Foundation AISBL — the legal person systematically and sustainably supporting the project, with EU jurisdictional reach. The APAC company is not the steward. It is a contributor and a sponsor. Recital 18 confirms that contributing source code to a project not under one's responsibility puts the contributor outside the regulation entirely.
So the company has one regulatory role (manufacturer of its gateway) and one supporting relationship (sponsor of a project whose steward is Eclipse). Two pieces, both well-defined. The puzzle was not in the answer; it was in figuring out that there were two pieces and not three.
That is what Article 24 added to EU regulatory architecture: a piece of the puzzle that did not exist before. It catches some legal entities cleanly, releases others cleanly, and asks the rest to read five lines of Article 3(14) carefully. The reading is not difficult once the gates are visible. But until the gates are visible, the gap looks deeper than it is.
The light-touch regulatory regime in Recital 19 is doing a real job. It says: foundations and corporate-sponsored OSS bodies that keep critical commercial software alive get a regulatory regime calibrated to OSS realities — verifiable policy, MSA cooperation, no fines. It also says: individuals, informal groups, and projects without commercial intent stay outside. The category is narrow, the obligations inside are limited, the penalties are zero. The only thing required is reading the five gates closely.
For APAC OSS contributors, that reading is the work. Once it is done, most are outside. A few are inside. Almost none are in the bucket they assumed they were in on first read.