Does a foundation or collaboration platform become a steward for every FOSS project it hosts?
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.
Do all stewards have the same CRA reporting duties regardless of the kind of support they provide?
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.
Does the CRA use or define the term "over-the-air update"?
No.
The CRA speaks about security updates, automatic security updates where applicable, and mechanisms to securely distribute updates. It does not create a separate legal definition of "over-the-air" or "OTA".
The ETSI smart-device standards in the local CRA corpus do use the term OTA for updates delivered over a network interface. So, in CRA practice, OTA is best understood as one possible way to implement the CRA's update obligations, not as a separate legal category.
Does the CRA require OTA update capability for every product with digital elements?
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.
Is an OTA update the same thing as an automatic security update?
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.
If a product uses automatic OTA security updates, must they be enabled by default and user-controllable?
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.
Does the CRA require completely silent OTA installation with no final user approval step?
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.
Are automatic OTA updates expected for all product categories?
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.
If a product has no screen, can CRA update notices or approval be handled through a paired app or companion device?
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.
If a product uses OTA updates, what does the CRA require from the security of that mechanism?
The CRA requires the OTA path to be secure enough to distribute updates so vulnerabilities are fixed or mitigated in a timely manner.
It does not prescribe one single technical architecture, but it does require secure update-distribution mechanisms. Read together with the CRA's requirements to protect commands, programs and configuration against unauthorised manipulation, the OTA channel and package handling cannot be left unsecured.
The ETSI standards in the local corpus make this more concrete for OTA implementations by pointing to secure channels and authenticity and integrity verification of updates.
Does the CRA allow an OTA release to bundle a security fix with a feature change?
Only where separation is not technically feasible.
The CRA's rule does not change just because the update is delivered OTA. Where technically feasible, new security updates must be provided separately from functionality updates. The Commission FAQ explains that bundling can still be acceptable where the security fix itself necessarily changes functionality.
Can an OTA security update itself amount to a substantial modification?
Sometimes, but not usually.
The March 2026 draft guidance says security updates are generally not substantial modifications where their purpose is to reduce cybersecurity risk and they do not change the product's intended purpose or introduce new cybersecurity risks. But a security-driven update can still become a substantial modification if it changes the intended purpose beyond what was foreseen or introduces new dependencies, new interfaces, or other new risks not covered by the original risk assessment.
For products placed on the market before 11 December 2027, do later OTA updates automatically bring those products into the full CRA regime?
No.
For legacy products, the question is whether the later update amounts to a substantial modification. The March 2026 draft guidance says security updates are generally not substantial modifications, and Article 69(2) makes substantial modification the trigger for bringing pre-11 December 2027 products into the CRA's full product regime.
The same draft guidance also says manufacturers should be able to demonstrate, if asked, that later updates do not amount to substantial modifications.
Is the manufacturer responsible under the CRA if a user refuses an OTA update or leaves the device unupdated?
No, not for the user's refusal or opt-out.
The manufacturer must design the product and its processes so that security updates can be notified, distributed, and installed as required. But the Commission FAQ says the manufacturer is not responsible under the CRA if the user does not install the update, including where the user opts out of automatic updates.
Must OTA security updates be free of charge and accompanied by user-facing messages?
Yes, unless the tailor-made exception applies.
The CRA requires security updates addressing identified security issues to be disseminated without delay and free of charge, unless otherwise agreed for a tailor-made product with a business user. It also requires advisory messages with the relevant information, including on potential action users should take.
Once an OTA security update has been released, must it remain available later?
Yes.
Article 13(9) applies to each security update made available during the support period. It must remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer.
Can a manufacturer stop patching older OTA software branches once users can move to the latest version?
Sometimes.
Article 13(10) allows the manufacturer, under strict conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of earlier versions can access the latest version free of charge and without additional costs to adjust their hardware or software environment.
So an OTA upgrade path can support that approach, but only if those Article 13(10) conditions are actually met.
If an OTA update cannot adequately fix the vulnerability or restore conformity, can the CRA require withdrawal or recall?
Yes, in exceptional cases.
The CRA does not assume that every vulnerability can always be solved through an OTA patch. If the product or the manufacturer's processes are not in conformity and the necessary corrective measures cannot adequately bring the product back into conformity, Article 13(21) allows the consequence to be withdrawal or recall, as appropriate.
The Commission FAQ makes the same point expressly: in exceptional cases, particularly for hardware products, a vulnerability may present such a significant risk of compromise that it cannot be adequately addressed and remediated, in which case withdrawal or recall may be required.
Can compromise of the OTA release channel itself trigger CRA reporting obligations?
Yes.
Recital 68 gives a direct example of a severe incident having an impact on the security of the product: an attacker successfully introducing malicious code into the release channel via which the manufacturer releases security updates to users. Once the manufacturer becomes aware of such an incident, Article 14 reporting and user-information duties become relevant.
Are OTA backends, CI/CD pipelines, or update-distribution systems automatically part of the CRA product or its remote data processing solution?
Not necessarily.
The March 2026 draft guidance says the CRA is not intended to treat the manufacturer's whole IT infrastructure as part of the product. It gives examples including CI/CD pipelines and the distribution of security updates to edge locations as systems that should not be considered RDPS.
But that does not make them irrelevant, and it does not transfer the manufacturer's CRA responsibilities away from the manufacturer. The same draft guidance says manufacturers must apply risk-based security measures and due diligence when relying on third-party cloud service providers. The draft guidance and the CRA's incident rules also show that compromise of those systems can still matter for the product's cybersecurity risk profile and can amount to a reportable severe incident where the security of the product is affected.