Search every question across sub-FAQs

The timing is split.

Article 24(3), because it links to Article 14 reporting obligations, becomes relevant from 11 September 2026 when Article 14 starts to apply. The rest of the Regulation, including the main Article 24 obligations, applies from 11 December 2027.

No.

Article 3(48) requires both a qualifying free and open-source licence and that the source code be openly shared. The March 2026 draft guidance says "openly shared" means publicly available, not merely shared on a restricted or conditional basis. So software whose source code is available only to paying customers or a limited user group is not FOSS within the CRA's definition.

Responsibility lies with those who publish the FOSS and exercise primary control over its development, releases, and distribution decisions.

The March 2026 draft guidance says contributors who merely submit code are not responsible on that basis alone, even if they have technical permissions such as commit access. Responsibility is tied to publishing and control over releases, roadmaps, or governance decisions.

No.

The March 2026 draft guidance says that a monetised version and a free or community version should be treated as different products for CRA purposes. The paid version is placed on the market if it is monetised. The free or community version is not placed on the market on that basis alone.

If the publisher is a legal person, that same entity may still be the steward for the free or community version if the steward conditions are met. If the publisher is a natural person, the free or community version may instead fall outside the CRA.

Yes, potentially.

The March 2026 draft guidance says that, particularly for natural persons publishing FOSS, bundled support does not by itself amount to commercial activity where the price serves only to recover actual costs. It adds that those actual costs can include design, development, and maintenance costs, including reasonable living expenses and fair remuneration for the person.

No, not on that basis alone.

The March 2026 draft guidance says a person offering technical support services for a FOSS that is not under its responsibility is not deemed to be placing that FOSS on the market, unless it substantially modifies the FOSS as part of delivering those services.

No.

The March 2026 draft guidance says steward status is assessed project by project. A foundation can be a steward for specific FOSS intended for commercial activities where it provides sustained support and ensures viability. But merely hosting other FOSS projects, without systematic support, a viability role, or software intended for commercial activities, does not make it the steward for those other projects.

No.

All stewards must comply with the policy and cooperation duties in Article 24(1) and (2). But the March 2026 draft guidance explains that the Article 24(3) reporting duties vary with the kind of support provided.

A steward that only provides non-technical support is not, on that basis alone, required to report actively exploited vulnerabilities or severe incidents. A steward that provides development infrastructure may need to notify severe incidents affecting those systems. A steward that also provides engineering resources may need to notify actively exploited vulnerabilities that it becomes aware of and, where appropriate, inform users.

No. The CRA does not use or define over-the-air update as a legal term.

The CRA speaks about security updates, automatic security updates where applicable, and mechanisms to securely distribute updates. It does not create a separate legal category for "over-the-air" or "OTA" delivery.

ETSI smart-device standards use OTA as a technical term for updates delivered over a network interface. In CRA practice, treat OTA as one implementation pattern for update obligations, not as a separate legal category.

No express OTA mandate appears in the CRA.

What the CRA requires is that vulnerabilities can be addressed through security updates and that the manufacturer provides mechanisms to securely distribute updates. It also requires automatic security updates only where applicable.

That means OTA is one potentially compliant implementation route, rather than a universally mandated delivery channel. This is an inference from the CRA's functional wording.

No.

OTA describes how the update is delivered, typically over a network. Automatic update describes how the update is installed or applied. A product can receive updates OTA but still require user approval before installation. Conversely, the CRA's legal trigger for default enablement is not "OTA" but "automatic security updates" where applicable.

Yes, where automatic security updates are applicable.

Annex I Part I point (2)(c) requires automatic security updates, where applicable, to be enabled as a default setting, with a clear and easy-to-use opt-out mechanism, notification of available updates to users, and the option to temporarily postpone them.

No.

Recital 56 says manufacturers should also provide the possibility to approve the download and installation of security updates as a final step. So even where automatic updates are used, the CRA materials do not point toward an unconditional "silent install only" model.

No.

Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products used in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations.

Potentially, yes.

The CRA requires notification of available updates to users and clear user information, but it does not prescribe one specific interface. ETSI TS 103 927 gives a concrete example for a screenless smart voice-controlled device: a paired phone or app can be used to notify the user about security updates, obtain consent, and display update-related information.

That means a paired app is one potentially compliant implementation pattern for screenless products. This is an inference from the CRA's interface-neutral wording together with the ETSI example.