Open Source Software Under the Cyber Resilience Act

Open Source Is Not a Single CRA Legal Category

The CRA recognises the distinctive development model of free and open-source software, but it does not create one universal rule for every project, maintainer, foundation, contributor and commercial vendor. The legal result depends on what software is being supplied, who has responsibility for it, whether an entity acts as a manufacturer, whether the relevant activity is commercial, whether a legal person systematically supports the project as an open-source software steward, and whether a downstream manufacturer integrates the software into another product. The same source code can therefore appear in several different CRA relationships. An unpaid contributor can occupy a very different position from a company commercialising a product under its own name, while a foundation providing sustained support can have the separate steward role.

• Open-source licensing does not by itself determine CRA obligations.
• Regulatory role matters.
• Commercial activity matters.
• Product responsibility matters.
• Downstream use can create separate manufacturer obligations.

The CRA Defines Free and Open-Source Software

Article 3 defines free and open-source software by reference to both source availability and licensing rights. The source code must be openly shared, and the software must be made available under a free and open-source licence providing the rights necessary to make it freely accessible, usable, modifiable and redistributable. This means the CRA does not use open source merely as an informal description for source-visible software. The licensing model is part of the legal definition. A manufacturer, foundation or maintainer analysing the CRA should therefore identify the actual licence and distribution model before relying on the Regulation's open-source provisions.

• Source code must be openly shared.
• A free and open-source licence is required.
• The licence must permit access and use.
• Modification and redistribution rights are part of the definition.

Commercial Activity Is a Central Dividing Line

The CRA's recitals distinguish open-source development from commercial supply. Recital 18 explains that, in relation to economic operators, free and open-source software should fall within the manufacturer-facing market regime when it is made available on the market in the course of a commercial activity. The Regulation also warns against deciding commercial status merely from how development was financed. Financial support, company contributions and regular releases do not automatically make an upstream project commercial. Conversely, using an open-source licence does not prevent a manufacturer from acting commercially when it monetises and markets the resulting product. The commercial-activity analysis should therefore examine the actual supply and monetisation relationship rather than rely on project labels.

• Open source does not automatically mean non-commercial.
• Funding alone does not automatically establish commercial activity.
• Regular releases alone do not establish commercial activity.
• Commercialisation under an open-source licence can still create manufacturer obligations.

A Commercial Open-Source Vendor Can Be a Manufacturer

Article 3 defines a manufacturer as a natural or legal person that develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark, whether for payment, monetisation or free of charge. The open-source rules do not erase that role. A business can therefore distribute software under an open-source licence while still acting as the CRA manufacturer when the product is marketed under its responsibility in the relevant commercial context. The manufacturer analysis should focus on responsibility for the product and how it is brought to market, not on whether customers can inspect or modify the source code.

Open-Source Software Stewards Have a Separate Legal Role

The CRA creates the open-source software steward role specifically so that certain organisations supporting important open-source projects are not forced into the full manufacturer model when that model does not fit their position. A steward must be a legal person other than a manufacturer. Its purpose or objective is to provide systematic and sustained support for the development of specific free and open-source products intended for commercial activities, while ensuring the viability of those products. Recital 19 describes this as a light-touch and tailor-made regulatory regime. Certain foundations and organisations operating in a business context can qualify, including some not-for-profit entities.

• A steward must be a legal person.
• A steward is legally distinct from the manufacturer role.
• Support must be systematic and sustained.
• The supported products are intended for commercial activities.
• The steward helps ensure product viability.

Stewardship Can Include Governance, Hosting and Development Support

Recital 19 gives a broad picture of sustained support. It can include hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing free and open-source products and steering their development. No single activity automatically creates steward status. The legal definition still requires the complete combination of sustained systematic support, specific free and open-source products intended for commercial activities, legal-person status and a role in ensuring project viability. This makes organisational reality more important than the title an entity gives itself. A foundation can potentially be a steward, but foundation status alone is not enough.

• Project governance can be relevant.
• Development-platform management can be relevant.
• Source-code or software hosting can contribute to sustained support.
• Steering development can be relevant.
• The complete statutory definition still needs to be met.

Stewards Have Tailored Article 24 Obligations

Article 24 requires open-source software stewards to put in place and document in a verifiable manner a cybersecurity policy that fosters secure development and effective vulnerability handling. The policy must promote voluntary vulnerability reporting by developers and cover the documenting, addressing and remediation of vulnerabilities, while encouraging information sharing within the open-source community. Stewards must also cooperate with market surveillance authorities when requested in order to mitigate cybersecurity risks associated with qualifying free and open-source software and provide the required policy documentation following a reasoned request.

• A documented cybersecurity policy is required.
• The policy should foster secure development.
• Effective vulnerability handling must be supported.
• Voluntary reporting by developers should be encouraged.
• Stewards must cooperate with market surveillance authorities.

Steward Reporting Starts on 11 December 2027

Article 24(3) applies specified Article 14 reporting obligations to open-source software stewards within defined limits. Article 14(1), concerning actively exploited vulnerabilities, applies to stewards to the extent that they are involved in development of the relevant products. Article 14(3) and Article 14(8) apply in the circumstances specified by Article 24(3) where severe incidents affect network and information systems provided by the steward for development of the products. Although Article 14 began applying to manufacturers on 11 September 2026, the European Commission's CRA reporting guidance confirms that the Article 24(3) reporting obligations for open-source software stewards apply from 11 December 2027.

• Manufacturer Article 14 reporting started on 11 September 2026.
• The steward reporting regime is linked through Article 24(3).
• Steward Article 24(3) reporting begins on 11 December 2027.
• The scope of the steward duties is narrower than the manufacturer regime.

Ordinary Contributors Are Not Automatically Manufacturers or Stewards

The CRA recitals recognise that people and organisations can contribute code without taking responsibility for the product. Recital 18 states that the Regulation does not apply to natural or legal persons who contribute source code to qualifying free and open-source products that are not under their responsibility. This distinction protects ordinary collaborative development from being equated automatically with manufacturing. A contributor can still have another role in a different factual situation, but contribution by itself is not sufficient. Projects should therefore distinguish code contribution, maintainership, governance, sustained organisational support and actual responsibility for marketing a product.

• Code contribution alone does not establish manufacturer status.
• Product responsibility is important.
• A contributor is not automatically a steward.
• Governance and commercialisation should be analysed separately.

Hosting an Open Repository Does Not Automatically Make the Host a Distributor

Recital 20 addresses repository and platform infrastructure. The sole act of hosting products with digital elements on open repositories, including through package managers or collaboration platforms, does not by itself constitute making a product available on the market. A service provider becomes relevant as a distributor only where it actually makes the software available on the Union market in the course of a commercial activity. This is separate from the steward analysis. Hosting infrastructure can form part of sustained support in a wider steward relationship, but merely operating or using an open repository should not be treated as automatic distribution of every project hosted there.

• Open repository hosting alone is not market supply.
• Package-manager hosting alone does not automatically create distributor status.
• Commercial market supply must be analysed separately.
• Hosting can still be one factor in a broader stewardship relationship.

Downstream Manufacturers Still Carry Their Own CRA Responsibilities

A commercial manufacturer can integrate upstream free and open-source components into its own product with digital elements. The upstream project's open-source status does not transfer the downstream manufacturer's responsibilities back to unpaid maintainers or automatically exempt the resulting commercial product. Article 13 requires manufacturers to exercise due diligence when integrating components sourced from third parties so that those components do not compromise the product's cybersecurity. The CRA also creates the possibility of voluntary open-source security attestation programmes under Article 25 to support downstream due diligence. Manufacturers should therefore maintain component inventories, supplier and project information, vulnerability intelligence and evidence showing how open-source dependencies were evaluated.

• Downstream manufacturers remain responsible for their commercial products.
• Open-source dependencies require due diligence.
• Upstream non-commercial status does not eliminate downstream obligations.
• Article 25 can support future voluntary security attestation.

Use a Role-Based CRA Analysis for Every Open-Source Project

A practical CRA assessment should identify the specific software product, confirm that it qualifies as free and open-source software, identify the person or organisation responsible for the product, analyse the commercial context and determine whether the entity acts as a manufacturer, an open-source software steward, an ordinary contributor or another actor. The assessment should then map the appropriate obligations rather than starting with the assumption that all open-source software is exempt or fully regulated. Projects with foundations, corporate sponsors, paid services, downstream commercial integrations or complex governance should document these roles explicitly because different organisations can have different CRA responsibilities around the same codebase.

• Confirm the software meets the CRA FOSS definition.
• Identify product responsibility.
• Analyse commercial activity.
• Determine manufacturer or steward status.
• Separate ordinary contributors from responsible entities.
• Document downstream manufacturer relationships.