CRA Responsibilities for Open Source Foundations

A Foundation Is Not Automatically an Open-Source Software Steward

Recital 19 states that open-source software stewards include certain foundations, not all foundations. The distinction matters because Article 3(14) contains a functional definition rather than an organisational-label test. A foundation needs to be a legal person other than the manufacturer, systematically provide sustained support for development of specific qualifying free and open-source products intended for commercial activities and ensure the viability of those products. A foundation that only promotes open-source values, provides occasional grants or hosts unrelated community activities does not automatically satisfy that test.

• Only certain foundations qualify as stewards.
• Foundation status alone is insufficient.
• The full Article 3(14) definition must be tested.
• Project-specific analysis can be necessary.

Start by Checking Whether the Foundation Is Actually the Manufacturer

The steward definition expressly excludes manufacturers. A foundation should therefore first determine whether it develops or has developed a product with digital elements and markets that product under its own name or trademark in a way that gives it manufacturer responsibility. If it is the manufacturer, the lighter Article 24 steward regime cannot be used as a replacement for the manufacturer obligations. A separate foundation supporting projects developed and commercialised downstream by others is more likely to require steward analysis instead.

• Manufacturer status should be checked first.
• A steward must be other than the manufacturer.
• Article 24 is not an alternative manufacturer regime.
• Downstream commercial manufacturers can coexist with an upstream foundation.

Non-Profit Status Does Not by Itself Decide Steward Status

Recital 18 gives specific non-commercial treatment to qualifying FOSS development by not-for-profit organisations where all earnings after costs are used to achieve not-for-profit objectives. Recital 19 separately states that open-source software stewards can include not-for-profit entities. These two rules serve different purposes. A foundation can therefore conduct non-commercial upstream development and still satisfy the steward definition because the supported products are ultimately intended for commercial activities. Non-profit status should not be used as a shortcut either for excluding steward obligations or for assuming them.

• Non-profit development can be non-commercial under Recital 18.
• Not-for-profit entities can still be stewards.
• The two legal tests are separate.
• Document both commercial-activity and steward analyses.

Systematic Sustained Support Is Central

A steward foundation must systematically support development on a sustained basis. Recital 19 lists examples such as hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing qualifying open-source products and steering their development. Foundations often perform several of these activities across multiple projects. The role assessment should identify which specific projects receive that sustained organisational support and how long-term continuity is provided.

• Support must be systematic.
• Support must be sustained.
• Governance can be relevant.
• Development infrastructure can be relevant.
• Steering project development can be relevant.

The Foundation Must Support Specific Products Intended for Commercial Activities

Steward status does not cover every open-source project a foundation might touch. Article 3(14) refers to specific products intended for commercial activities. Recital 19 explains that this can include products ultimately intended for integration into commercial services or monetised products. Regular contributions or financial assistance from manufacturers that integrate the component can also demonstrate the intended commercial ecosystem for the steward regime. A foundation should therefore maintain a project-level view rather than assume that all projects under its umbrella have identical CRA status.

• Specific products must be identified.
• Ultimate commercial integration can be relevant.
• Commercial services can be relevant.
• Monetised downstream products can be relevant.
• Different foundation projects can have different CRA positions.

Ensuring Project Viability Is Part of Steward Status

The steward definition requires the organisation to ensure the viability of the supported products. A foundation should identify what it actually does to sustain those projects. Examples can include governance continuity, development infrastructure, release coordination, security processes, maintainer support, funding administration or other mechanisms that help the project continue. The CRA does not reduce viability to financial support alone. Evidence of organisational continuity and project stewardship can therefore be important when documenting why a foundation qualifies as a steward.

A Steward Foundation Needs a Verifiably Documented Cybersecurity Policy

Article 24(1) requires qualifying open-source software stewards to put in place and document in a verifiable manner a cybersecurity policy. The policy should foster development of secure products and effective vulnerability handling by the developers of those products. It must account for the specific nature of the steward and its legal and organisational arrangements. A foundation should therefore avoid adopting a generic corporate security policy that does not describe how its project governance, infrastructure and community processes actually support security.

• The Article 24 policy must be documented.
• The documentation must be verifiable.
• Secure development should be fostered.
• Vulnerability handling should be supported.
• Foundation governance should be reflected in the policy.

The Foundation Policy Should Cover Vulnerability Handling

Article 24 requires the steward policy to address documenting, addressing and remediating vulnerabilities and to foster voluntary vulnerability reporting by developers under Article 15. For a foundation, this can require coordination across projects that each have different maintainers and release practices. The foundation should establish a governance model that makes clear where vulnerabilities can be reported, who routes reports to the appropriate project, how security-sensitive information is handled and how remediation support is coordinated without taking away project-level technical responsibility.

• Provide a vulnerability intake path.
• Define routing and triage responsibilities.
• Support documentation of vulnerabilities.
• Support remediation processes.
• Encourage voluntary reporting.

Steward Foundations Must Be Ready to Cooperate With Market Surveillance Authorities

Article 24(2) requires stewards to cooperate with market surveillance authorities at their request with a view to mitigating cybersecurity risks associated with qualifying FOSS products. Following a reasoned request, the steward must provide its cybersecurity-policy documentation in a form and language that can be understood by the authority. Foundations should therefore know which entity owns the relevant policy, where the evidence is maintained and who is authorised to coordinate responses with authorities.

• Authority cooperation is an Article 24 duty.
• Policy documentation can be requested.
• Documentation should be retrievable.
• Foundation response ownership should be assigned.

Foundation Reporting Duties Begin on 11 December 2027 Where Article 24(3) Applies

A foundation qualifying as an open-source software steward must also prepare for the limited reporting regime in Article 24(3). The European Commission confirms that these steward reporting obligations apply from 11 December 2027. Article 14(1) applies to stewards to the extent they are involved in development of the relevant products, while the severe-incident obligations incorporated through Article 24(3) apply within the specific conditions relating to network and information systems provided by the steward for product development. This regime should not be described as identical to the reporting duties of a manufacturer.

• Steward reporting begins on 11 December 2027.
• The regime is linked through Article 24(3).
• The steward duties are narrower than full manufacturer reporting.
• Foundations should establish reporting ownership before the application date.

A Steward Foundation Does Not Take Over Downstream Manufacturer Responsibility

Commercial manufacturers can integrate foundation-supported software into their own products. Steward status does not transfer responsibility for those commercial products to the foundation. The downstream manufacturer remains responsible for its own CRA compliance and for due diligence concerning third-party components. The foundation can support the ecosystem by publishing vulnerability information, maintaining secure development processes and cooperating with users, but it should not be treated as the manufacturer of every downstream product containing its software.

• Downstream manufacturers keep their own responsibilities.
• Stewardship does not transfer manufacturer responsibility upstream.
• Foundations can support vulnerability information sharing.
• Component users should maintain their own due diligence.

Steward Foundations Do Not Affix CE Marking in Their Steward Capacity

Recital 19 reinforces the separation between stewardship and manufacture by explaining that open-source software stewards should not be permitted to affix CE marking to the products whose development they support merely by virtue of acting as stewards. CE-marking responsibility belongs within the applicable manufacturer and conformity-assessment framework. If a foundation separately becomes the manufacturer of a particular product, that role must be analysed independently rather than derived from stewardship.

• Stewardship does not itself create CE-marking authority.
• Manufacturer and steward roles remain distinct.
• A separate manufacturer role requires a separate analysis.
• Downstream manufacturers handle their own conformity process.

Create a Project-by-Project Foundation CRA Register

A practical foundation can maintain a CRA role register for major projects. For each project, the register should identify the licence, legal entity, governance relationship, sustained support activities, commercial intention, downstream manufacturer ecosystem, viability activities, security-policy coverage, vulnerability process and reporting ownership. It should state whether the foundation is manufacturer, steward or neither for that product. This is more reliable than assigning one CRA status to the foundation globally, especially where a foundation supports projects with different commercial ecosystems and governance models.

• Assess projects individually.
• Record manufacturer or steward status.
• Document sustained support and viability.
• Record commercial-intention evidence.
• Map each project to cybersecurity-policy coverage.
• Assign authority and reporting responsibilities.