Search every question across sub-FAQs

No.

The Article 3(14) definition is limited to a legal person.

No.

Steward status is narrower. The legal person must systematically provide support on a sustained basis, the software must be intended for commercial activities, and the legal person must ensure the software's viability.

The CRA gives broad examples.

Recital 19 says that sustained support may include hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing free and open-source software products, and steering their development.

Yes.

The March 2026 draft guidance says this assessment is specific to each FOSS product. A legal person may be the manufacturer for a specific FOSS that it places on the market, while being the steward for another specific FOSS that it publishes without placing on the market. The same split can also arise between a monetised version and a free or community version of related software.

They have a lighter, tailored regime under Article 24.

Stewards must put in place and document, in a verifiable manner, a cybersecurity policy that fosters secure development, effective vulnerability handling, voluntary reporting of vulnerabilities, and sharing of vulnerability information within the open-source community. They must also cooperate with market-surveillance authorities and, on a reasoned request, provide the documented policy to the authority.

Yes, but only to the limited extent set out in Article 24(3).

Article 14(1) applies to stewards only to the extent that they are involved in development of the products. Article 14(3) and 14(8) apply only to the extent that severe incidents affect network and information systems provided by the steward for the development of those products.

No.

Recital 19 makes clear that open-source software stewards should not be permitted to affix the CE marking to the products whose development they support.

Yes.

The market-surveillance authorities designated under Article 52 are also responsible for activities relating to steward obligations under Article 24. If a steward does not comply, the authority must require appropriate corrective action.

Not to the administrative fines referred to in Article 64(2) to (9).

Article 64(10)(b) expressly says those administrative fines do not apply to infringements of the Regulation by open-source software stewards.

The manufacturer still has due-diligence obligations for its own product.

Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software components that have not been made available on the market in the course of a commercial activity, so those components do not compromise the cybersecurity of the final product.

It must report the vulnerability upstream and remediate it in its own product.

Article 13(6) says that where manufacturers identify a vulnerability in an integrated component, including an open-source component, they must report it to the person or entity manufacturing or maintaining the component, address and remediate it in accordance with the CRA vulnerability-handling requirements, and share the relevant fix or documentation where appropriate.

The integrating manufacturer remains responsible for user-facing security information for the finished product.

If a vulnerability in an integrated open-source component affects the product, the Commission FAQ says the manufacturer still has to fulfil its own vulnerability-handling duties, including keeping users informed, providing mitigating measures, and updating documentation. For software versions or products where support ends, the draft guidance also points to the CRA requirement to inform users when vulnerability remediation for earlier versions is discontinued and users need to upgrade.

No, not in general.

If a manufacturer places open-source software on the market in the course of a commercial activity, the ordinary CRA manufacturer regime applies to that product. The main special rule is Article 32(5), which preserves access to the Article 32(1) conformity-assessment procedures for Annex III products qualifying as free and open-source software if the technical documentation is made public at the time of placing on the market.

In one specific case, yes.

Article 32(5) allows manufacturers of Annex III products qualifying as free and open-source software to use one of the Article 32(1) procedures, including module A, provided the technical documentation referred to in Article 31 is made available to the public at the time of placing on the market.

The Commission FAQ explains this as preserving the possibility of module A for important class I and class II free and open-source software when that public-documentation condition is met.

Yes.

Article 25 empowers the Commission to establish voluntary security attestation programmes for free and open-source software, in particular to help manufacturers perform due diligence when integrating such components.