What is an Open Source Steward?

A new role in European law #

With the Cyber Resilience Act (CRA), the European Union has created a role that did not previously exist: the open source software steward.

This role recognises that open source software works differently from commercial products. It is not "placed on the market" by manufacturers but developed by communities and freely used by everyone. The steward closes the gap between this reality and the requirements of the new cybersecurity legislation.

The legal definition #

Art. 3 No. 14 of the Cyber Resilience Act defines the open source software steward as a legal person that:

• is not a manufacturer
• has the purpose of systematically and sustainably supporting the development of specific products with digital elements that qualify as free and open source software and are intended for commercial activities
• ensures the viability of these products

The definition is deliberately narrow. Individuals cannot be a steward — only legal persons. And the support must be systematic and sustained, not merely occasional.

Steward obligations under Art. 24 CRA #

The CRA imposes on the steward a range of obligations that are significantly less extensive than those of a manufacturer but nonetheless substantial:

• Develop and document a cybersecurity strategy — in a verifiable manner, with a focus on secure development and effective vulnerability handling (Art. 24(1))
• Vulnerability management — promote the documentation, remediation, and elimination of vulnerabilities (Art. 24(1))
• Information exchange — support the exchange on vulnerabilities within the open source community (Art. 24(1))
• Voluntary reporting of vulnerabilities, in accordance with Art. 15 CRA (Art. 24(1))
• Cooperation with authorities — submit strategy documentation upon request of market surveillance authorities (Art. 24(2))
• Reporting obligations — report actively exploited vulnerabilities and severe security incidents insofar as the steward is involved in development (Art. 24(3))

Security attestation under Art. 25 CRA #

The CRA provides that the European Commission may introduce voluntary security attestation programmes by delegated act. These programmes are intended to:

• Facilitate manufacturers' due diligence when integrating open source components (Art. 13(5) CRA)
• Take account of the particularities of open source development models
• Be initiated by developers, users, manufacturers, or public administrations

For projects under steward support, such an attestation could be a concrete advantage: manufacturers deploying attested components more easily fulfil their due diligence obligation.

Steward vs. manufacturer — the differences #

The distinction is central, as it determines the scope of obligations and possible consequences:

Legal form: A manufacturer can be a natural or legal person. A steward can only be a legal person.

Role: The manufacturer develops, produces, or markets a product. The steward systematically supports development without itself being a manufacturer.

CE marking: The manufacturer must affix the CE marking. The steward expressly may not (Recital 19).

Obligations: The manufacturer is subject to the full manufacturer obligations under Art. 13 and 14 CRA. The steward has only the reduced obligations under Art. 24 CRA.

Market surveillance: For the manufacturer, a full conformity assessment takes place. For the steward, the assessment is limited to compliance with the Art. 24 obligations (Art. 52(3) CRA).

Enforcement: Manufacturers can be sanctioned with up to EUR 15 million or 2.5% of worldwide annual turnover. For stewards, the legislator relies on corrective measures rather than fines (Art. 52(3), Art. 64(10b) CRA) — a different enforcement path but no lesser expectation.

The obligations are real #

Market surveillance authorities can request the steward to take appropriate corrective measures (Art. 52(3) CRA). The obligations under Art. 24 CRA — cybersecurity strategy, vulnerability management, reporting obligations, authority cooperation — require professional processes and permanent capacity.

Additionally, there is indirect pressure: DORA-regulated financial institutions must conduct open source analyses (Art. 25(1) DORA). NIS2 operators must assess the security processes of all suppliers (Art. 21(2)(d) NIS2). The new Product Liability Directive makes software a product (Art. 4 Directive 2024/2853). This demand- side regulatory pressure directly affects the steward — as the point of contact for companies, auditors, and authorities.

For OTTRIA, this means: we take on the steward role not because it is convenient but because it provides the right structure for our work — and because the projects need a professional partner to absorb this pressure.

The time advantage through responsible disclosure #

The advantage arises from the responsible disclosure process of the open source world: when a security researcher discovers a vulnerability in a project, they report it confidentially to the maintainers. The maintainers then have an agreed period to fix the vulnerability before it is made public. The specific timeframes differ depending on the project and reporter — common are 28 days (e.g. DGC AG), 30 days (CERT NRW), or 90 days (Google Project Zero). In each case, weeks to months lie between confidential report and public disclosure.

As a steward, OTTRIA is directly embedded in these project processes. We receive security reports upon receipt — not only at the time of public disclosure. This means: while the world does not yet know, we are already working on the fix.

For projects for which OTTRIA sponsors bug bounty programmes, an additional channel exists: security researchers report their findings directly to us as sponsor. We actively finance the discovery of vulnerabilities and are the first recipient of the results. This is a dual advantage: the projects become more secure, and our clients benefit from the earliest possible knowledge of new vulnerabilities.

Additionally, the CRA obliges manufacturers in Art. 13(6) who discover a vulnerability in an open source component to inform the responsible person or entity and, where appropriate, share the security patch.

As steward, OTTRIA therefore receives reports from three sources:

• Responsible disclosure — as an embedded steward at the time of receipt
• Bug bounty programmes — as sponsor directly from the security researcher
• Manufacturers — obliged under Art. 13(6) CRA to inform us

The CRA further requires in Art. 14(8) that users be informed about vulnerabilities. OTTRIA can and must therefore warn its clients before public disclosure — and actively does so.

This time advantage means in practice: fixes are prepared, tested, and provided before attackers learn about the vulnerability. Your systems are protected while others are still waiting for the CVE disclosure.

Important: This time advantage — depending on the project and reporter between 28 and 90 days — applies only to projects where OTTRIA is actively involved as steward. It is not a blanket promise but a direct consequence of the steward's involvement in the responsible disclosure process.

What this means for open source projects #

When OTTRIA takes over the steward role for your project, you receive:

• A documented cybersecurity strategy that meets the CRA requirements
• Professional vulnerability management — from detection through remediation to coordinated disclosure
• A point of contact for European market surveillance authorities
• Relief from regulatory obligations that are difficult to reconcile with community development
• Concrete operational support: code reviews, security audits, test infrastructure

What this means for companies #

When you use open source components under OTTRIA stewardship, you benefit from:

• Early warning for vulnerabilities — weeks to months before public disclosure
• Prepared fixes at the time of publication
• Documentation for your due diligence obligation under Art. 13(5) CRA
• A concrete partner in the supply chain that your auditors can speak to
• Evidence of appropriateness of your supply chain security measures

Transition periods #

The CRA entered into force on 10 December 2024. The obligations take effect in stages:

• From 11 September 2026: Reporting obligations for vulnerabilities and security incidents (Art. 14 CRA)
• From 11 December 2027: Full application of all provisions

For projects and companies, this means: the time to act is now. The reporting obligations take effect in a few months, and full application follows at the end of 2027.

Want to know whether the steward role is relevant for your project? Or whether the open source components you use are under steward support? Talk to us.