CRA Open Source Steward Obligations Explained

The EU’s Cyber Resilience Act (CRA) creates specific CRA open-source steward obligations, but here’s the crucial detail: these rules only apply to legal entities like foundations or companies that systematically support open-source software used in commercial products. Individual developers, hobbyists, and non-commercial projects are explicitly exempt.

What the CRA Means for Open-Source Projects

The central question for many developers is whether the Cyber Resilience Act imposes new rules on every open-source project. The answer is a clear no, but the details matter. To bridge the gap between community-driven development and the commercial world, the legislation introduces a specific role: the “open-source steward”.

This distinction is fundamental. It separates individual contributors from organised legal entities that provide structured, ongoing support to open-source software that ends up in products sold on the EU market.

Think of it this way: a hobbyist maintaining a personal garden shed isn’t subject to commercial building codes. A professional contractor managing the construction of public infrastructure, however, certainly is.

Who Is a Steward?

The CRA defines a steward as a legal person—such as a non-profit foundation or a company—that ensures the viability of an open-source project intended for commercial use. The focus isn’t on the person who writes the code, but the organisation that governs it.

• Practical Example (Steward): The Apache Software Foundation, which provides governance, infrastructure, and coordinated vulnerability management for projects like the Apache HTTP Server, would likely be considered a steward for its projects used in commercial applications.
• Practical Example (Not a Steward): An independent developer who creates and maintains a popular JavaScript library on GitHub in their free time is not a steward, even if that library is used by thousands of companies.

This guide walks through what defines an open-source steward and their specific duties under the law. We’ll cover the key CRA open-source steward obligations, which centre on security policies and vulnerability handling, and explain the steps manufacturers must take to work with them.

The introduction of the “steward” role acknowledges the unique position of open source. It applies formal responsibilities only where there is an organised, systematic effort supporting commercial activities, protecting the vast majority of individual contributors from regulatory burdens.

With key obligations taking effect throughout 2026 and 2027, understanding these roles is vital. This article maps out the timeline so you can prepare effectively for the new requirements. You can also explore our guide to understand how the CRA impacts different open-source licensing models.

Identifying an Open Source Steward

Knowing who the Cyber Resilience Act considers an “open-source software steward” is your first and most important job. This isn’t about targeting individual volunteers or hobbyist coders. Instead, the CRA is very specific: a steward is a legal person—think a company or a foundation—that provides systematic, ongoing support to an open-source project meant for commercial use.

This distinction is everything.

Picture a single developer maintaining a small GitHub library in their free time. Even if that library gets popular, they are not a steward. Their work is personal, not tied to a formal legal entity with a commercial support structure behind it.

In sharp contrast, you have the major foundations that govern critical projects used in thousands of commercial products. Organisations like the Linux Foundation or the Apache Software Foundation are prime examples. They provide the infrastructure, governance, and coordinated vulnerability management that allow businesses to rely on their software. Their support is systematic and enables commercial activity, which is exactly what the CRA is looking at.

The Three Core Criteria of a Steward

To figure out if an organisation is a steward, you can check it against three core criteria from the CRA. An entity has to meet all three to have CRA open-source steward obligations. This framework neatly separates informal community work from the structured, commercial-facing support the regulation is designed to cover.

1. Legal Person Status: The entity must be a registered legal person. This could be a non-profit foundation, a trade association, or a for-profit company. An informal group of developers without a legal structure simply doesn’t qualify.
2. Systematic and Sustained Support: The support can’t be a one-off contribution or sporadic help. It has to be an organised, ongoing effort to keep the project viable. This includes managing releases, coordinating development, or providing core infrastructure.
3. Intended for Commercial Activities: The open-source software must be developed with the clear intention of being integrated into commercial products. This is the key link that connects a steward’s activities directly to the EU market.

This clear separation protects individual contributors while placing responsibility squarely on the organisations that formally enable open source to be used in the commercial world. Understanding this is also vital for manufacturers, who need to pinpoint which of their software dependencies are managed by a steward to streamline their own compliance. You can learn more about how these duties compare to the responsibilities of a product lifecycle manager under the CRA.

To make this even clearer, the checklist below breaks down what it takes to be considered a steward under the CRA.

Identifying an Open Source Steward Criteria Checklist

Criterion	What It Means	Example of a Steward	Example of NOT a Steward
Legal Person	The project is managed by a registered legal entity (e.g., foundation, company).	The Eclipse Foundation, a non-profit corporation.	A group of unaffiliated developers on GitHub.
Systematic Support	Provides structured, ongoing support like governance, infrastructure, or release management.	The Apache Software Foundation, providing coordinated processes.	A company making a one-time code contribution to a project.
Commercial Intent	The project is explicitly intended for use in commercial products.	The Linux Foundation, supporting an OS for enterprise servers.	A personal blog engine built by a developer for their own use.

An organisation must meet all three of these criteria to be classified as a steward. This ensures the regulation focuses only on entities that have a formal, structured role in the commercial open-source ecosystem.

Practical Examples: Steward vs. Non-Steward

Let’s apply these criteria to a couple of real-world scenarios to make the distinction crystal clear.

Example of a Steward:

• Organisation: The Eclipse Foundation.
• Why it qualifies: It’s a legal non-profit entity that provides strict governance, intellectual property management, and a formal development process for huge projects like Jakarta EE. This systematic support is precisely designed to make these projects stable and reliable enough for businesses to build commercial products on top of them.

Example of NOT a Steward:

• Organisation: A group of five friends collaborating on a new open-source game engine.
• Why it doesn’t qualify: While they work together, they are not a registered legal entity. Their support, however valuable, lacks the formal, systematic structure and clear commercial intention required to be considered a steward under the CRA.

Open-source software stewards under the EU CRA are defined as legal persons—not individuals—systematically supporting specific OSS development for commercial use. Research shows that while many potential stewards demonstrate high readiness in security practices (74-79% adoption of key measures), a significant gap exists, as only 32% currently produce SBOMs, a core element for supply chain transparency. You can explore more about what the CRA means for open source on berthub.eu.

Implementing Secure by Design Policies

The Cyber Resilience Act is forcing a big change for open-source stewards. It’s taking security from a community handshake to a set of formalised, documented processes. The principle of “secure by design” is at the very core of these new CRA open-source steward obligations. This isn’t about starting from scratch; it’s about making your security practices predictable, reliable, and transparent.

Instead of relying on gut feelings or one-off decisions, stewards now need a documented cybersecurity policy. Think of it as the project’s security playbook, explaining how you handle security from the first line of code to the last patch. It’s all about consistency and accountability.

From Informal Norms to Formal Policies

For ages, security in open-source projects has been part of the culture, just not always written down. The CRA changes that by requiring this culture to be codified. You’re essentially translating those unwritten rules into documented procedures that anyone—from a first-time contributor to a downstream manufacturer—can follow.

A huge part of this is having a documented policy for finding and managing vulnerabilities. This policy becomes the foundation for how your project builds and maintains secure software. It’s less about checking a box for regulators and more about building a system that people can trust.

Practical Example:
Imagine an open-source project that traditionally relied on a single, trusted maintainer to manually review all security-sensitive code. To comply with the CRA, the steward formalizes this by creating a SECURITY.md file. This file publicly documents the security policy, names a security team, defines the review process, and provides a dedicated email for reporting vulnerabilities. The informal process is now a documented, transparent one.

The real goal of a secure-by-design policy is to make security a non-negotiable part of the development lifecycle. It embeds security thinking into every stage, from the initial concept to the final release, instead of treating it like an afterthought.

The good news is that many projects are already well on their way. A Linux Foundation report from early 2025 found that an impressive 74% of surveyed stewards already had security policies in place to manage cybersecurity issues. This high adoption rate in the ES region and beyond gives many stewards a head start as the CRA rolls out. You can dive into the data in the Linux Foundation’s CRA Readiness & Awareness Report.

Actionable Steps for Secure by Design

So, what does a “secure by design” policy look like in the real world? It boils down to a few concrete actions that weave security directly into your development workflow. As a steward, you’ll need to set up clear, repeatable processes for your most important security activities.

Here are a few practical steps you could take:

• Establish a Threat Modelling Routine: Before you build any major new features, create a process to identify potential security threats. For instance, your policy might demand a simple threat model for any pull request that touches authentication logic.
• Adopt Secure Coding Standards: Formally adopt and document a set of secure coding guidelines, like the OWASP Top 10. Make it clear that all contributors are expected to follow them.
• Mandate Security Reviews: Ensure all new code gets a security check before it’s merged. To make this work, Mastering Security Code Reviews: Your Practical Guide is an essential read for identifying and fixing risks before they become problems.

Practical Example:

Imagine you steward a popular data-processing library. You could update your contribution policy to say: “All pull requests must pass an automated static analysis security testing (SAST) scan and receive at least one manual code review from a designated security lead before being considered for a merge.” This one simple rule makes security an explicit, mandatory step.

A Safe Harbour for Good Faith Efforts

While these new policy obligations are mandatory, the CRA contains a critical provision known as a “safe harbour.” Article 64(10) specifically exempts stewards from administrative fines for non-compliance with these particular policy-related duties. This is a big deal. It encourages good-faith efforts without the fear of massive financial penalties for an imperfect process.

This exemption is designed to foster a culture of improvement, not punishment. The focus is on making progress, not achieving immediate perfection, which is a nod to the unique, community-driven nature of open-source development. You can get more details on building these practices in our guide to creating a secure software development life cycle.

Mastering Vulnerability Reporting and Disclosure

Of all the obligations the CRA places on open-source stewards, vulnerability management is where the stakes are highest. It’s the only area where stewards can face significant fines, making a clear, documented process completely non-negotiable. This is all about having a predictable system for handling security issues, from the initial report right through to the public fix.

The process demands several mandatory steps. If a steward finds out a vulnerability in their project is being actively exploited, they have to move fast. The clock starts ticking immediately, and the response must be both quick and well-coordinated.

The 24-Hour Reporting Mandate

The most urgent duty is the 24-hour reporting rule. Once a steward is aware that a vulnerability in their software is being actively exploited, they must notify the relevant authorities within 24 hours. This initial report goes to two key bodies:

• ENISA (The European Union Agency for Cybersecurity): The central EU body responsible for coordinating cybersecurity responses.
• The National CSIRT: The Computer Security Incident Response Team in the relevant EU member state. For a steward based in Spain, this would be INCIBE-CERT.

This first notification isn’t a deep technical analysis. Think of it as an immediate heads-up, giving authorities an early warning of a threat that could spread. This allows them to prepare for the wider impact across the ecosystem.

The core principle here is speed. The 24-hour window for reporting actively exploited vulnerabilities is strict. Stewards must have a pre-defined internal process to identify such incidents and escalate them to the correct channels without any delay.

After this initial alert, stewards have a follow-up duty. They must promptly inform their downstream users—the manufacturers putting the software into their products—and the wider community about the vulnerability and any fixes or workarounds. This ensures everyone in the supply chain can act to protect their own systems. A foundational step in mastering this is to perform a thorough vulnerability assessment to proactively find security weak points.

A Log4j-Style Incident Under the CRA

To make this real, let’s walk through a hypothetical incident similar to the Log4j crisis, but looking at it from the perspective of a CRA-compliant open-source steward.

1. Private Disclosure (Day 1): A security researcher privately reports a critical remote code execution (RCE) vulnerability to your project’s security team, using the contact info in your SECURITY.md file. Your team gets to work and validates the vulnerability.
2. Evidence of Exploitation (Day 5): While your team is developing a patch, you find credible online evidence that the vulnerability is now being actively exploited in the wild. The 24-hour clock starts now.
3. Mandatory Reporting (Day 6): Within 24 hours of discovering the active exploitation, you send an initial notification to ENISA and the relevant national CSIRT. The report briefly describes the vulnerability and confirms it’s being exploited.
4. Coordinated Disclosure (Day 10): After working with key downstream manufacturers under an embargo, you publicly release a patched version of the software. At the same time, you publish a security advisory with a CVE identifier, explaining the impact and giving clear instructions for upgrading.
5. Ongoing Cooperation: In the weeks that follow, you cooperate with market surveillance authorities, giving them the information they need to assess the market-wide risk. The focus is on technical details to help with mitigation, not on revealing sensitive internal data.

This structured response is a world away from the ad-hoc scramble many projects faced in the past. It turns incident response from a chaotic reaction into a defined, predictable workflow.

Vulnerability management is a cornerstone of the CRA for open-source software stewards. Stewards must report actively exploited vulnerabilities to ENISA and relevant CSIRTs, as laid out in Articles 11.3 and 11.8. A 2025 report shows that 68% of stewards already proactively identify and fix vulnerabilities, with 79% operating voluntary reporting channels. This is vital, as only vulnerability-handling obligations carry fines up to €15 million or 2.5% of global turnover. For IoT vendors in Spain facing 2027 deadlines, this high readiness from stewards is a huge help but requires tight integration for post-market surveillance.

For a deeper dive into what these reporting duties entail, you might be interested in our guide on CRA reporting obligations under Article 14.

Fulfilling Downstream Information Duties

Stewards sit at a critical junction in the software supply chain. The Cyber Resilience Act (CRA) makes it official: they have a responsibility to pass key security information down to the manufacturers who build products on top of their open-source projects. This information flow is the backbone of the transparent, secure ecosystem the CRA aims to build.

Think of it this way. While stewards are not on the hook for the full conformity assessments that manufacturers face, they must provide the raw data those manufacturers need to complete their own. A steward is like a supplier of a specialised flour; they don’t bake the final cake, but they absolutely must provide a detailed list of what’s in their flour so the baker can create an accurate ingredients label.

This formalises a process that ensures security information travels all the way from an open-source project to the end user.

Providing a Software Bill of Materials (SBOM)

A huge part of this transparency duty revolves around providing information for a Software Bill of Materials (SBOM). An SBOM is simply a formal, machine-readable inventory of every single component that makes up a piece of software, much like a list of ingredients for a recipe.

Under the CRA, manufacturers are mandated to create and maintain an SBOM for their products. To get this right, they need precise data from all their suppliers, and that absolutely includes open-source stewards. This is a central pillar of the CRA open source steward obligations.

The steward’s job is to supply this dependency information in a clean, usable format.

• What Stewards Must Provide: You should be ready to generate a machine-readable file listing your project’s direct dependencies, their exact versions, and any known security issues tied to them. Formats like SPDX or CycloneDX are the industry standard here.
• What Manufacturers Do With It: The manufacturer then pulls in this file, merges it with data from their other software components, and builds the complete SBOM for their final product.

Practical Example:
Imagine you’re the steward for a popular data visualisation library. A company making a business intelligence tool uses your library. To stay compliant, you provide a CycloneDX file with each release detailing that your library depends on “Parser v1.2” and “Connector v3.4.” The manufacturer’s build system automatically ingests that file, instantly updating their product’s master SBOM. If you later release a security patch for “Connector v3.4,” the updated SBOM file signals the manufacturer to take action.

This kind of seamless data exchange is what’s needed for real supply chain integrity. Unfortunately, the industry has a long way to go. Very few open-source projects currently produce comprehensive, machine-readable SBOMs consistently. This leaves manufacturers stuck with the painful and error-prone job of manually digging through code to identify dependencies. The CRA is designed to close this exact gap by making the steward’s role explicit.

Cooperating with Market Surveillance Authorities

Beyond just providing SBOM data, stewards also have a duty to cooperate with market surveillance authorities, like a national competent authority or a national CSIRT. This might sound intimidating, but the CRA frames it as a collaborative effort, not an adversarial audit. The shared goal is to work together to secure the entire digital market.

This cooperation usually kicks in when an authority makes a reasoned request for information. It’s not a blank cheque for them to demand all your project’s internal data. The request must be focused and necessary to assess or mitigate a specific, identified risk.

The duty to cooperate is about shared responsibility. Stewards hold crucial technical knowledge about their projects, and sharing that knowledge with authorities helps protect the entire ecosystem from widespread threats.

Practical Example:
If a major vulnerability is found in a widely used open-source networking protocol you manage, a market surveillance authority might ask for technical details on the flaw and which versions are affected. Your cooperation could involve providing a list of affected release hashes and technical guidance on how to detect exploitation attempts. This allows them to push out targeted alerts to critical infrastructure operators across the EU. Your cooperation is what makes that kind of rapid, coordinated response possible.

The flow from initial reporting to notification and finally to cooperation creates a structured response that puts the security of the ecosystem first.

Your Compliance Roadmap for 2026 and Beyond

With the Cyber Resilience Act’s main deadlines arriving in 2026 and 2027, compliance is becoming a strategic topic for everyone in the software supply chain. Both open-source stewards and the manufacturers who build on their work have clear, though different, paths to follow.

This roadmap connects the CRA’s expectations into a coherent plan for each role. For open-source stewards, this means formalising the security practices many already follow. For manufacturers, it’s about building the processes to consume, verify, and act on security information from your open-source dependencies.

A Three-Step Plan for Open-Source Stewards

The CRA asks stewards to move from informal community norms to documented, reliable processes. The aim isn’t to force a new workflow on you, but to structure your existing security efforts so that downstream manufacturers can depend on them. Your focus should be on creating transparent policies and predictable information channels.

1. Formalise Your Security Policies: First, create and publish a clear cybersecurity policy. This document is where you explain how your project handles security, from accepting code contributions to managing vulnerability reports. It sets expectations for everyone.
2. Establish a Clear Intake Process: You need a public, structured way to receive security reports. A SECURITY.md file in your repository is the perfect place to start. It should include contact details and a general idea of your response times.
3. Prepare to Provide Dependency Information: Get ready to supply manufacturers with the data they need for their Software Bill of Materials (SBOM). Start exploring tools that generate SBOMs in standard formats like CycloneDX or SPDX.

Practical Example for a Steward:
An open-source steward for a popular JavaScript library can start by drafting a simple markdown document for their vulnerability disclosure policy. They can then set up a dedicated email like security@project.org and list it in a SECURITY.md file in their main repository. This single action meets a core CRA expectation.

A Three-Step Plan for Manufacturers

As a manufacturer, you carry the final responsibility for any product you place on the EU market. Your compliance hinges on your ability to understand, document, and manage your entire software supply chain—especially its open-source parts.

• Inventory Your Open-Source Components: Your first job is to create a full and accurate inventory of all open-source software inside your products. You can’t secure what you don’t know you’re using.
• Identify Which Components Have a Steward: For each component on your list, figure out if it is managed by a recognised open-source steward. This tells you where you can expect to find structured security information and who to contact.
• Build an Ingestion Process: Set up a formal workflow to receive, process, and act on the security data that stewards provide. This means integrating their SBOM fragments into your product’s main SBOM and having a plan ready to deploy patches when they announce a vulnerability.

Practical Example for a Manufacturer:
A company that builds an IoT device could use an automated scanning tool to generate an initial SBOM for its firmware. By reviewing that list, they identify that their device’s operating system is managed by a major foundation (a steward). They would then set up an automated feed to monitor that foundation’s security advisories for any relevant patches.

Early and open communication between manufacturers and stewards is the most effective compliance strategy. It will significantly reduce last-minute costs, streamline your documentation efforts, and build a more secure software ecosystem for everyone involved.

Open Source and the CRA: Answering Your Top Questions

This section tackles some of the most common questions we hear about the Cyber Resilience Act’s impact on open-source projects, stewards, and individual developers.

Are Individual Open-Source Developers Liable Under the CRA?

No. If you’re an individual contributing code to an open-source project in your spare time, without any commercial intent, the CRA’s obligations don’t apply to you. The regulation makes a clear distinction to protect the non-commercial open-source community.

The rules for “stewards” kick in only for legal entities—like foundations or companies—that provide structured, ongoing support to open-source software that finds its way into commercial products on the EU market.

What Happens If a Steward Fails to Report a Vulnerability?

This is where the CRA has real teeth. A steward’s failure to report an actively exploited vulnerability within the mandatory 24-hour window is the one obligation that carries massive financial penalties.

If a steward fails to meet this reporting deadline, they could face a fine of up to €15 million or 2.5% of their total worldwide annual turnover, whichever is higher. Other duties, like maintaining a security policy, are still mandatory but don’t come with this specific penalty structure.

Do Stewards Need to Get a CE Mark for Their Software?

No, they don’t. Under the CRA, open-source stewards are not considered “manufacturers.” This means they are completely exempt from the conformity assessment process, creating an EU Declaration of Conformity, and applying a CE mark.

A steward’s job is to provide the security foundation and critical information. The actual manufacturer who integrates that software into a final product is the one responsible for the full conformity process and the CE mark.

How Does the CRA Affect Non-EU Open-Source Projects?

The CRA’s jurisdiction is tied to where a product is sold, not where the code is written. It’s all about access to the EU market.

If an open-source project is managed by a steward—regardless of their physical location—and is then integrated into a commercial product placed on the EU market, the steward’s obligations are triggered. For example, a US-based foundation that stewards a popular library used in a smart thermostat sold in Germany must comply with its CRA duties.

---

At Regulus, we provide a dedicated software platform to help you navigate the complexities of the Cyber Resilience Act. Our solution helps you assess applicability, map requirements, and generate the documentation needed to confidently place compliant products on the EU market. Gain clarity and reduce compliance costs by visiting https://goregulus.com.