Open Source and the EU Cyber Resilience Act: The Steward Regime Explained

When the European Commission first introduced the Cyber Resilience Act (EU Regulation 2024/2847), the open-source community expressed significant concerns. Initial drafts risked subjecting voluntary contributors to the same rigorous conformity assessments designed for large-scale commercial tech vendors.

The final regulation clarifies these boundaries by distinguishing between purely voluntary projects, dedicated open-source stewards, and commercial software suppliers. For entities managing open-source development, the CRA introduces a specialized, proportionate regulatory framework.

Commercial Activity vs. Purely Non-Commercial Open Source

Under Recital 18 and Article 2 of the CRA, software developed or supplied outside the scope of commercial activity is entirely exempt. If you contribute to hobby projects, publish libraries without monetization, or provide unpaid patches, the CRA imposes no legal obligations or financial penalties.

However, this exemption ceases when open source intersects with commercial operations. Commercial activity encompasses charging for software, selling proprietary add-ons, providing paid enterprise support, or monetizing user data.

Defining the Open-Source Software Steward

To bridge the gap between community-driven development and enterprise security, the CRA establishes a specific legal classification: the open-source software steward.

A steward is a legal entity—such as a non-profit foundation or consortium—that systematically supports the development of open-source software intended for commercial use, without acting as a commercial product manufacturer itself.

Core Requirements of the Steward Regime

Open-source stewards are exempt from the comprehensive product compliance requirements faced by commercial manufacturers. Instead, their obligations focus on governance, security transparency, and cooperation:

• Establishing a cybersecurity policy that promotes vulnerability handling and responsible disclosure practices.
• Implementing a coordinated vulnerability disclosure (CVD) mechanism to effectively receive and triage security reports.
• Sharing security information and collaborating with market surveillance authorities and ENISA regarding critical flaws.
• Facilitating vulnerability reporting without assuming the burden of CE marking, conformity assessments, or manufacturer-level liability.

Impact on Downstream Commercial Vendors

While maintainers and stewards benefit from simplified rules, downstream commercial vendors do not. If your organization integrates open-source components into a commercial product or SaaS platform, you retain full legal responsibility under the CRA.

Manufacturers must maintain a comprehensive Software Bill of Materials (SBOM), monitor third-party components for vulnerabilities, and patch security issues throughout the product lifecycle. Non-compliance penalties can reach up to €15 million or 2.5% of annual global turnover.

Navigating CRA Deadlines and Compliance

The CRA implementation follows two primary milestones: mandatory vulnerability reporting begins on 11 September 2026, followed by full technical compliance requirements on 11 December 2027.

Managing open-source risk does not require building compliance workflows from scratch. Platforms like CRAcheck provide self-assessment support, enabling developers to connect repositories, generate SBOMs across nine package ecosystems, monitor vulnerability alerts, and draft essential compliance documentation.