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). That leaves weeks to months between confidential report and public disclosure. During that time the vulnerability is exploitable — it is simply not publicly known. And because the code is open, someone else can find it at any moment. Knowing early buys you exactly that time to act.

Where a project involves OTTRIA as a steward in these processes, we receive security reports upon receipt — not only at the time of public disclosure. This means we work on the fix while the vulnerability is not yet public.

For projects for which OTTRIA sponsors bug bounty programmes, an additional channel exists: we design those programmes so that security researchers also report their findings directly to us. We therefore finance the discovery of vulnerabilities and are among the first recipients of the results. This is a dual advantage: the projects become more secure, and our clients learn of new vulnerabilities at the earliest possible point.

Additionally, the CRA obliges manufacturers in Art. 13(6) who discover a vulnerability in an integrated component to inform the person or entity that manufactures or maintains it and, where appropriate, share any fix they developed.

As steward, OTTRIA receives reports from three sources:

• Responsible disclosure — as an embedded steward at the time of receipt
• Bug bounty programmes — under the agreed programme rules
• Manufacturers — under Art. 13(6) CRA, insofar as OTTRIA maintains the component concerned

The CRA obliges manufacturers in Art. 14(8) to inform affected users about actively exploited vulnerabilities and severe security incidents, and about the protective measures required. OTTRIA uses the confidential advance reports to warn affected clients early and prepare protective measures — and, where the agreed confidentiality rules permit, already before public disclosure.

This time advantage means in practice: fixes are prepared, tested, and provided before the vulnerability becomes public. You act while others are still waiting for the CVE disclosure.

Important: This time advantage is not a blanket promise for every component in your supply chain. It arises where OTTRIA is actively involved as steward in a project's responsible disclosure process — depending on the project and reporter, that is 28 to 90 days. Which of your components are covered, we tell you straight after the first SBOM evaluation.

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 — within the agreed disclosure rules, often weeks 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.