CRA Art.24: Open Source Steward Obligations — Why GitHub's US Jurisdiction Complicates EU Vulnerability Disclosure

Post #15 in the sota.io EU Cyber Resilience Act (CRA) Series

The Cyber Resilience Act does not treat all software producers equally. Alongside manufacturers — who bear the full weight of conformity assessment and CE marking — the CRA creates a distinct, lighter-touch category: the open source steward. Article 24 defines what these organisations must do and, critically, what they are exempt from.

For thousands of European organisations that maintain open source projects used in commercial products, Article 24 is not optional reading. And for those who host their development infrastructure on GitHub — a Microsoft-owned platform subject to US CLOUD Act jurisdiction — Article 24 creates a structural compliance problem that no internal policy can fully resolve.

Who Qualifies as an Open Source Steward?

Article 4(17) of the CRA defines an open source steward as:

"any legal person, other than a manufacturer, that has the purpose or objective of systematically providing maintenance of products with digital elements qualifying as free and open source software that are intended for commercial activities."

Four elements are required simultaneously:

1. Legal person — not an individual developer acting alone
2. Systematic maintenance — not one-off contributions but ongoing stewardship
3. Free and open source software — the OSI or FSF definition applies
4. Intended for commercial activities — the defining threshold

That last criterion is doing significant work. The "commercial activities" intent requirement draws the line between hobbyist maintainers and institutional stewards.

The Hobbyist Exemption

Article 4(18) explicitly carves out individuals who develop or supply open source software "outside of a trade or profession, or in a non-commercial context." A developer maintaining a personal project on GitHub purely for learning or community contribution, with no expectation of commercial use, is not an open source steward and bears no CRA obligations.

The difficulty is that software does not declare its own commercial intent. A permissively licensed library that a solo developer posted five years ago may now be a dependency of multiple commercial products, generating revenue for manufacturers who have never contacted the original author. This does not retroactively make the individual developer a steward — but it does place obligations on the manufacturers who integrated that library.

What Makes an Organisation a Steward in Practice?

The following indicators push an organisation toward steward status:

• Dedicated foundation or legal entity maintains the project (Apache Software Foundation, Eclipse Foundation model)
• Commercial sponsors fund the project's development
• Explicit commercial adoption support in documentation ("enterprise users should contact...")
• Paid support contracts alongside the free tier
• Systematic release cycles and security response processes

If your open source project has any of these characteristics and is used in products placed on the EU market, your organisation is likely a CRA open source steward.

Article 24 Obligations: The Lighter Framework

Article 24 imposes four categories of obligation on open source stewards, intentionally reduced from the full manufacturer framework:

1. Coordinated Vulnerability Disclosure Policy

Article 24(1) requires stewards to "put in place and document a policy for the coordinated disclosure of vulnerabilities." This must be:

• Publicly accessible (commonly published as SECURITY.md)
• Covering how reports are received
• Describing the timeline for acknowledgement, triage, and disclosure
• Specifying conditions for coordinating with reporters before public release

This is the foundation. Without a formal CVD policy, stewards cannot satisfy any downstream manufacturer's verification requirement under Article 16 (importer obligations) or Article 13 (security by design documentation requirements).

See our earlier analysis: CRA Art.14: Coordinated Vulnerability Disclosure covers the full CVD framework that manufacturers must implement — the steward version under Art.24 is a subset of this.

2. Cooperation with Market Surveillance Authorities

Article 24(2) requires stewards to "cooperate with market surveillance authorities on their request" and "provide those authorities, on request, the technical documentation referred to in Article 31."

Article 31 documentation includes:

• A general description of the product and its intended use
• Design and development documentation
• Information on conformity assessment procedures applied (if any)
• The CVD policy

This cooperation obligation means market surveillance authorities — national bodies designated by each EU Member State — can request documentation directly from stewards. The steward is not merely a pass-through; they are a formal point of accountability in the regulatory chain.

3. ENISA Notification of Actively Exploited Vulnerabilities

This is where the compliance burden becomes most significant. Article 24(3) requires stewards to notify ENISA — and the relevant national CSIRT — when they become aware of:

• Actively exploited vulnerabilities in their product
• Severe incidents that could affect the security of their product

The 24-hour notification requirement under Art.11 that applies to manufacturers also applies to stewards for these categories. Within 24 hours of awareness, a preliminary notification must reach ENISA. Within 72 hours, a more detailed report. Within 14 days, a final report.

This is not a reduced obligation — it is the same notification timeline as manufacturers, applied to the most urgent vulnerability class.

4. Facilitation of Manufacturer Compliance

Article 24(4) requires stewards to make documentation available that "enables manufacturers integrating their products... to comply with their obligations."

In practice this means:

• Publishing SBOM-compatible manifests
• Documenting known vulnerabilities and their status
• Making security assessment information available to downstream manufacturers
• Supporting the conformity assessment process manufacturers must complete

This creates a functional dependency chain: manufacturers cannot complete their Article 13 security-by-design obligations without steward-provided documentation.

What Stewards Are Exempt From

Article 24 explicitly states that open source stewards "shall not be subject to" the obligations applicable to manufacturers for the products they steward. Specifically exempt:

• Conformity assessment (Articles 32-34): No CE marking required
• EU Declaration of Conformity (Article 28): Stewards do not issue this
• Product registration (Article 30): No EUDAMED-equivalent for software
• Authorised representative requirement (Article 25): Not applicable
• Importer obligations (Article 16): Stewards are not importers of their own work

The exemptions make open source stewardship commercially viable. Requiring full conformity assessment for every open source project would impose costs that would effectively end European open source contribution.

The GitHub Problem: US Jurisdiction Meets EU Notification Requirements

Here is where the structural conflict emerges. The vast majority of open source development, including projects maintained by EU organisations, happens on GitHub. GitHub is owned by Microsoft, a Delaware corporation subject to:

• CLOUD Act (18 U.S.C. § 2523): US government can compel disclosure of stored data regardless of where it is stored
• FISA Section 702: Collection of communications from non-US persons for intelligence purposes
• National Security Letters: Compelled disclosure with gag orders

The Gag Order Scenario

A CRA open source steward using GitHub becomes aware of an actively exploited vulnerability in their project. The 24-hour ENISA notification clock starts. Before the steward can file that notification, a US government agency could issue a National Security Letter compelling Microsoft to preserve and disclose all communications about that vulnerability — with a gag order preventing the steward from telling ENISA what it has been required to disclose.

The steward is now in a position where:

1. EU law (CRA Art.24) requires 24-hour ENISA notification
2. US law prohibits disclosure of the compelled surveillance to ENISA
3. There is no mechanism within either legal system to resolve this conflict

This is not a theoretical edge case. The NSL gag order authority is exercised thousands of times per year. For any vulnerability involving US national security relevance — infrastructure attacks, state-sponsored exploits — the conflict is directly applicable.

Vulnerability Database Infrastructure

Even without a gag order, the practical infrastructure creates compliance friction:

• GitHub Security Advisories are hosted on US infrastructure; draft advisories are US-accessible
• GitHub's Advisory Database (GHSA) is operated by Microsoft and shares data under US jurisdiction
• Coordinated disclosure embargoes stored in GitHub private repositories are subject to CLOUD Act extraction before the embargo period ends

When an EU steward coordinates a 90-day disclosure embargo with a security researcher, that embargo is effectively US-accessible from day one if hosted on GitHub. This does not automatically violate Art.24, but it creates an inherent asymmetry between the EU regulatory intent (controlled, coordinated disclosure) and the technical reality (US-accessible coordination).

The 24-Hour Window Under CLOUD Act Pressure

The 24-hour ENISA notification requirement assumes an organisation in full control of its disclosure process. For a GitHub-hosted project, that assumption does not hold:

• Microsoft retains a copy of all repository data
• US law enforcement can access repository data faster than the 24-hour notification window
• If US disclosure precedes ENISA notification, the Art.24 obligation has been partially undermined by an external actor

Practical Infrastructure Options for EU Open Source Stewards

Given these constraints, EU open source stewards have three viable infrastructure strategies:

Option 1: EU-Native Git Infrastructure

Hosting the primary development repository on EU-jurisdiction infrastructure eliminates the CLOUD Act conflict:

• Forgejo (https://forgejo.org): Federated, self-hostable git platform, European community governance
• Gitea (self-hosted on EU VPS): Lightweight, no US dependency
• Codeberg (https://codeberg.org): German non-profit, Forgejo-based, explicitly GDPR-compliant

With EU-native infrastructure:

• Vulnerability draft advisories stored under EU jurisdiction
• No US government CLOUD Act access to pre-disclosure embargoes
• Coordination with ENISA not subject to parallel US disclosure obligations

The tradeoff: reduced contributor reach (most open source contributors use GitHub), reduced tooling ecosystem integration.

Option 2: Dual-Platform Strategy

Maintain EU-native infrastructure as the canonical repository for security-sensitive content, with a GitHub mirror for contributor accessibility:

• Security advisories drafted and stored on EU infrastructure only
• CVD coordination happens via EU-hosted ticket system
• GitHub mirror is read-only for code, never for security coordination
• ENISA notification sent from EU infrastructure before GitHub advisory is published

This preserves contributor reach while maintaining jurisdictional control over the security-critical disclosure process.

Option 3: EU-Jurisdiction Coordination Point

Use a PaaS provider with EU jurisdiction and no US parent as the coordination layer for security disclosures, even if development remains on GitHub:

• Encrypted vulnerability reports received at EU-hosted endpoint
• Embargo coordination via EU-hosted private channels
• ENISA notification originating from EU infrastructure
• GitHub advisory published only after the notification window has closed

This option does not eliminate CLOUD Act exposure for repository content, but it ensures the notification chain itself is EU-controlled.

The Certification Cascade: From Steward to Manufacturer

Article 24(4) creates a compliance dependency that propagates through the software supply chain. When a manufacturer integrates an open source component into a product they place on the EU market, that manufacturer must:

1. Verify that the steward has a CVD policy (Art.24(1))
2. Document their verification in their conformity assessment
3. Monitor the steward's vulnerability notifications to maintain post-market monitoring obligations (Art.9)
4. React within their own 24-hour window if a steward notification reveals active exploitation

This cascade means that even a small EU open source library, if integrated into commercial products, connects the steward directly into the EU regulatory infrastructure. Stewards who fail to publish adequate CVD policies effectively break their downstream manufacturers' ability to comply with CRA.

The parallel with importer obligations under Art.16 is direct: just as importers must verify manufacturer compliance before placing products on the market, manufacturers must verify steward compliance before integrating open source components.

Timeline: When Do Art.24 Obligations Apply?

The CRA's phased implementation schedule applies to stewards as follows:

The September 2026 deadline — now fewer than 120 days away — is the critical threshold. After that date, EU open source stewards without a published CVD policy are in formal non-compliance.

What Happens When a Steward Fails Art.24?

The CRA does not directly impose financial penalties on open source stewards — the full penalty framework (up to €15 million or 2.5% of global annual turnover) applies to manufacturers.

However, steward non-compliance has downstream consequences:

• Manufacturers cannot use the product in conformity-assessed products without assuming additional compliance burden
• Market surveillance authorities can order corrective action against the steward
• Reputational impact on projects marketed to enterprise users who require CRA compliance evidence
• Procurement exclusion: EU public procurement is increasingly conditioning awards on CRA compliance evidence from the entire supply chain

For commercial open source projects — where "commercial activities" is the threshold for steward status — the practical incentive to comply is strong.

The EU-Native Infrastructure Advantage

Open source stewards who build on EU-jurisdiction infrastructure from the outset avoid a structural compliance problem rather than patch it:

• No CLOUD Act exposure on vulnerability coordination channels
• Single jurisdiction for ENISA notification
• No gag-order risk on pre-disclosure embargoes
• Audit trail entirely within EU legal framework

For stewards using a EU-native PaaS like sota.io as their coordination infrastructure, the compliance chain from vulnerability report through embargo through ENISA notification remains entirely within the scope of EU law — no parallel US disclosure obligation can interrupt it.

Conclusion

CRA Article 24 creates a thoughtfully calibrated obligation set for open source stewards — lighter than full manufacturer requirements, but real and enforceable. The CVD policy requirement, ENISA notification obligation, and documentation facilitation duties are not bureaucratic overhead; they are the minimum infrastructure for responsible open source stewardship in a regulated market.

The complication is not Article 24 itself. It is that the dominant infrastructure for open source development — GitHub, operated by Microsoft under US jurisdiction — creates a structural conflict with the notification requirements that EU law cannot resolve by itself. The only complete solution is jurisdictional: EU infrastructure for EU compliance obligations.

With September 2026 now fewer than 120 days away, EU open source stewards have a defined window to publish their CVD policy, establish their ENISA notification processes, and — for those who choose it — migrate their security-critical coordination to EU-native infrastructure.

Missed an earlier post in this series? Start with the CRA September 2026 countdown for the timeline overview, or CRA Essential Requirements (Annex I) for the foundational security obligations all manufacturers and stewards must understand.