CRA and Open Source: What the Steward Role Means for Foundations and Maintainers

The EU Cyber Resilience Act does not treat all open source software the same. While non-commercial open source projects maintained by hobbyists are largely exempt, the regulation introduces a new legal category — the open source steward — that applies to foundations and organizations that systematically support open source development used in commercial products.

This article explains who qualifies as an open source steward, what obligations come with the role, and what individual maintainers and companies using open source need to know.

The CRA's Approach to Open Source

The CRA applies to products with digital elements placed on the EU market. The key distinction for open source is whether there is a commercial activity associated with the software.

If you are an individual maintaining a personal project on GitHub with no revenue, no corporate sponsor, and no commercial intent, the CRA's manufacturer obligations do not apply to you. Recital 18 of Regulation 2024/2847 makes this explicit.

However, the moment open source software is integrated into a commercial product, the CRA kicks in — but the obligations fall on the manufacturer of the commercial product, not on the upstream open source maintainer. The company shipping the product is responsible for the security of all its components, including open source dependencies.

What Is an Open Source Steward?

An open source steward is defined in Article 3(14) as a legal person — other than a manufacturer — that has the purpose or objective of systematically providing support on a sustained basis for the development of products with digital elements qualifying as free and open source software, intended for commercial activities.

In practical terms, this means:

• Foundations like the Apache Software Foundation, the Linux Foundation, the Eclipse Foundation, or the Python Software Foundation
• Corporate open source program offices that systematically maintain open source projects used commercially
• Non-profit organizations that coordinate development of widely-used open source infrastructure

The key phrase is systematically providing support on a sustained basis. A company that occasionally contributes to an open source project is not a steward. A foundation that governs, maintains, and coordinates the development of open source projects used in thousands of commercial products likely is.

Steward Obligations vs. Manufacturer Obligations

Open source stewards have significantly lighter obligations than full manufacturers. Here is how they compare:

What Stewards Must Do

• Cybersecurity policy: Put in place and document a cybersecurity policy to foster secure development of the projects they support (Article 24)
• Vulnerability handling: Facilitate the identification and handling of vulnerabilities, including providing a contact address for reporting (Article 24)
• Cooperation: Cooperate with market surveillance authorities when requested (Article 25)
• ENISA reporting: Report actively exploited vulnerabilities discovered in products they steward, following the same 24h/72h/14d timeline as manufacturers (Article 24)
• Documentation: Document their cybersecurity practices and make them available

What Stewards Do NOT Need to Do

• No CE marking or conformity assessment
• No EU Declaration of Conformity
• No technical documentation package as required for manufacturers
• No obligation to ensure products ship without known exploitable vulnerabilities
• No security update obligations

The intent is clear: stewards should foster good security practices and coordinate vulnerability handling, but they are not liable for the security of every product that uses the open source software they support.

What Individual Maintainers Need to Know

If you are an individual contributor or maintainer — not part of a foundation or company — the CRA's obligations almost certainly do not apply to you directly. Recitals 18 through 20 carve out non-commercial open source development from the manufacturer definition.

Indicators that the CRA does not apply to you:

• You maintain the project in your personal capacity
• You do not charge for the software or provide paid support
• You do not have a corporate entity behind the project
• Donations or sponsorships alone do not make it commercial

Indicators that it might apply:

• You provide the software as part of a commercial service
• Your company employs you specifically to maintain the project for commercial purposes
• You monetize the project through dual licensing, paid features, or hosted versions

If your open source project has a commercial dimension, you may be considered a manufacturer rather than just a contributor.

What Companies Using Open Source Need to Know

This is the critical point that many teams miss: if your commercial product includes open source dependencies, you are the manufacturer and the CRA obligations fall on you.

You cannot point upstream and say the open source project is not compliant. Under the CRA, you must:

• Include open source components in your SBOM
• Monitor those components for vulnerabilities
• Patch or mitigate vulnerabilities in your product, even if the fix has to come from upstream
• Report actively exploited vulnerabilities in your dependencies to ENISA within 24 hours

This is why tools like cra-scanner exist — to help you assess the CRA readiness of your project, including its open source dependencies.

Practical Steps

For foundations and steward organizations:

1. Determine if you meet the steward definition (systematic, sustained support for commercially-used OSS)
2. Draft and publish a cybersecurity policy for the projects you govern
3. Establish a vulnerability reporting and handling process
4. Set up monitoring for actively exploited vulnerabilities in your projects
5. Prepare for ENISA reporting (see our ENISA reporting guide)

For companies using open source:

1. Generate SBOMs that include all open source dependencies
2. Set up continuous vulnerability monitoring for your full dependency tree
3. Establish processes to patch or mitigate upstream vulnerabilities
4. Do not assume upstream projects will handle CRA compliance for you

Complaro helps engineering teams monitor vulnerabilities across all dependencies — including open source — and automates ENISA reporting when actively exploited vulnerabilities are discovered. Get started free.