CRA Open-Source Software Steward Obligations

The Cyber Resilience Act (CRA) creates a specific regulatory role for certain organisations that sustain free and open-source software: the open-source software steward. A steward is not simply any maintainer or contributor. Under the CRA definition, it is a legal person, other than a manufacturer, whose purpose or objective is to provide systematic and sustained support for the development of specific free and open-source software intended for commercial activities, while ensuring the viability of those products.

For organisations that meet that definition, Article 24 establishes a tailored regime. The core obligations are to put in place and verifiably document a cybersecurity policy, support effective vulnerability handling and voluntary vulnerability reporting, cooperate with market-surveillance authorities, and meet specified reporting duties where the statutory conditions apply.

The distinction matters because free and open-source software is not automatically treated like an ordinary commercial product under the CRA. The Commission describes the steward regime as light-touch and tailored to the role these organisations play in the open-source ecosystem.

First determine whether the organisation is actually a steward

Before building an Article 24 process, establish whether the legal entity meets the CRA definition.

A steward must be a legal person and must not be acting as the manufacturer for the relevant product. Its role involves systematic support on a sustained basis for the development of specific products with digital elements that qualify as free and open-source software, are intended for commercial activities, and whose viability the organisation helps ensure.

That can include certain foundations and organisations that support open-source projects over time. It does not mean that every individual contributor, occasional sponsor or project maintainer automatically becomes a steward.

The Commission also distinguishes stewards from manufacturers. If an organisation places a free and open-source product with digital elements on the market as a manufacturer, the manufacturer obligations apply instead. Teams should therefore document the legal entity, the supported projects, the nature and continuity of support, how viability is ensured, and whether the organisation places the software on the market under its own role.

A practical scope record can include:

the legal entity responsible for the activity;
the open-source products or projects receiving sustained support;
the nature of that support, such as infrastructure, governance, development resources or funding;
how the organisation contributes to the project's viability;
the relationship between the software and commercial activities; and
the rationale for treating the entity as a steward, manufacturer or neither for the relevant product.

This scope decision should be revisited when governance or commercial relationships change.

Article 24 requires a verifiable cybersecurity policy

Article 24(1) requires an open-source software steward to put in place and document, in a verifiable manner, a cybersecurity policy. The policy must foster the development of secure products with digital elements and effective vulnerability handling by the developers of those products.

The policy must also foster voluntary vulnerability reporting by developers under Article 15 and account for the steward's particular nature and legal and organisational arrangements.

The CRA specifically says the policy should address documenting, addressing and remediating vulnerabilities and promote information sharing about discovered vulnerabilities within the open-source community.

A policy that merely states broad security principles is therefore unlikely to be operationally useful. A steward should be able to show how the policy is implemented.

Useful policy areas can include:

how vulnerabilities are received and documented;
how reports are routed to the appropriate project or maintainer;
how severity and potential impact are assessed;
how remediation work is coordinated;
how security fixes and relevant information are communicated;
how voluntary vulnerability reporting by developers is supported;
how sensitive vulnerability information is handled before disclosure; and
how responsibilities are divided between the steward and project developers.

The exact process should reflect the steward's actual organisational model rather than copying a manufacturer process that does not fit an open-source community.

Make the policy verifiable

The word verifiable is operationally important. The steward should retain records that demonstrate the policy exists and is being used.

Depending on the organisation, evidence might include:

approved versions of the cybersecurity policy;
ownership and responsibility records;
vulnerability intake procedures;
issue or advisory records for security-relevant cases;
triage and remediation decisions;
communication records with affected maintainers;
disclosure or advisory history;
evidence of security guidance provided to projects;
records of policy reviews and material changes; and
examples showing how the process handled actual or simulated vulnerability cases.

The goal is not to create paperwork for every development action. It is to preserve enough evidence to show that the policy is more than an aspirational document and that the steward can explain how vulnerability handling works across the projects it supports.

Cooperation 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 posed by qualifying free and open-source products.

Following a reasoned request, a steward must provide the Article 24(1) policy documentation to the authority in a language the authority can easily understand, in paper or electronic form.

This means the policy should be retrievable and owned. Organisations should know who receives an authority request, who can assemble the requested documentation, who reviews the response and how the organisation records what was supplied.

The CRA's market-surveillance provisions also provide for authorities to require appropriate corrective action where a steward does not comply with Article 24. The Commission notes that stewards are not subject to the CRA's administrative fines, but that does not remove the underlying obligations or the authority's supervisory role.

Reporting obligations have a narrower scope

Article 24(3) applies parts of the CRA's Article 14 reporting regime to open-source software stewards, but only within defined boundaries.

For actively exploited vulnerabilities, the Article 14(1) obligations apply to the extent that the steward is involved in the development of the products with digital elements.

For severe incidents, Article 14(3) and (8) apply to the extent that the incident affects network and information systems provided by the steward for development of those products.

Those limitations should be reflected in the steward's reporting procedure. A useful decision record should establish:

which product is affected;
whether the organisation is acting as a steward for that product;
whether it is involved in the relevant development for an actively exploited vulnerability;
for a severe incident, whether the affected systems are systems the steward provides for development;
when awareness was established; and
who owns the reporting decision and supporting evidence.

Do not assume that every vulnerability in every project associated with an organisation automatically creates an Article 24 reporting obligation.

When do steward reporting duties start?

The CRA's general manufacturer reporting obligations began applying on 11 September 2026. The timing for open-source software stewards is different.

The European Commission states that, under Article 71(2), the reporting obligations referred to in Article 24(3) apply to open-source software stewards from 11 December 2027.

That distinction is important for current planning. Steward organisations can use the implementation period to establish scope, awareness records, escalation routes and reporting ownership before their Article 24(3) duties begin.

The OpenSSF steward resource guide similarly recommends preparing the organisation to identify potentially reportable events, determine whether they fall within the steward-specific scope and preserve the information needed for the applicable reporting process.

Connect vulnerability handling to awareness and escalation

A reporting procedure cannot work if vulnerability intake and incident handling are disconnected from legal escalation.

For each supported project, identify how security information can enter the organisation. Sources might include maintainer reports, private vulnerability channels, public advisories, security researchers, dependency notifications, infrastructure alerts or reports from downstream users.

Then define an escalation path for information that may indicate an actively exploited vulnerability or a severe incident affecting steward-provided development systems.

Operational records should make it possible to reconstruct:

what information was received;
when the organisation became aware of it;
which project and product were affected;
who assessed the event;
which Article 24 scope conditions were considered;
what decision was made; and
what evidence supported that decision.

This does not require the steward to centralise every development decision. It does require a reliable route from security-relevant information to the people responsible for the steward's CRA obligations.

Preserve the open-source collaboration model

Article 24 explicitly requires the cybersecurity policy to take account of the steward's specific nature and organisational arrangements. It also calls for promoting information sharing about discovered vulnerabilities within the open-source community.

That supports a process designed around the actual project structure. A foundation supporting multiple independent projects may need common intake and escalation rules while leaving technical remediation with project maintainers. Another steward may provide shared infrastructure, security expertise and coordinated disclosure support.

The important point is to document where the steward's responsibility sits and how it supports developers rather than assuming that a central corporate product-security model is the only valid implementation.

Evidence should stay scoped to the right project and decision

Stewards may support multiple projects with different maintainers, release practices and security processes. Evidence can become difficult to interpret if vulnerability records, policy decisions and reporting assessments are not tied to the relevant project and lifecycle context.

A practical evidence model should connect the applicable policy, the affected project, the vulnerability or incident record, the people responsible for the decision, and any remediation or reporting evidence. That makes later authority cooperation and internal review more reliable without requiring the steward to replace the project's normal development systems.

AA-sec is focused on secure product development and lifecycle evidence and is designed around traceability between requirements, evidence, vulnerability work and decisions. For organisations that need structured CRA evidence, that model can help keep policy and vulnerability records connected to the relevant product context; it does not determine whether an organisation legally qualifies as a steward or make the CRA compliance decision for it.

Practical Article 24 readiness checklist

A steward preparing for Article 24 should be able to answer:

Which legal entity may qualify as the open-source software steward?
Which specific open-source products are within that role?
Why are those products considered intended for commercial activities?
How does the organisation provide systematic and sustained support?
Where is the required cybersecurity policy documented and approved?
How does the policy support secure development and effective vulnerability handling?
How are vulnerability documentation, remediation and community information sharing addressed?
How does the organisation foster voluntary vulnerability reporting?
Who owns requests from market-surveillance authorities?
Can the policy documentation be retrieved promptly for a reasoned authority request?
Which development activities can bring an actively exploited vulnerability within Article 24(3)?
Which steward-provided development systems can bring a severe incident within Article 24(3)?
How is awareness time recorded for potentially reportable events?
Who makes and documents the reporting decision?
Can records be tied to the correct project, event and decision?

Gaps in those answers are useful implementation targets before the steward-specific reporting duties apply.

Key takeaway

The CRA does not treat open-source software stewards as ordinary manufacturers. It creates a tailored role for legal persons that systematically and sustainably support specific free and open-source products intended for commercial activities and ensure their viability.

Article 24 centres on a verifiable cybersecurity policy, effective vulnerability handling, cooperation with market-surveillance authorities and carefully scoped reporting obligations. For stewards, the practical preparation work is to define which projects fall within the role, make vulnerability-handling policy demonstrable, establish authority-response ownership and build a reporting escalation path that preserves project-specific evidence.

Official and supporting sources

Official sources

Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
Cyber Resilience Act - Open source — European Commission
Cyber Resilience Act - Reporting obligations — European Commission
CRA Reporting Obligations for Stewards - Resource Guide — OpenSSF Global Cyber Policy Working Group