EU Cyber Resilience Act FAQ Over-the-Air Updates

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.

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.

ETSI update-security standards make this more concrete for OTA implementations by pointing to secure channels, authenticated communication partners, and authenticity and integrity checks for updates.

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.

Sometimes, but not usually.

Draft Commission 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.

No.

For legacy products, the question is whether the later update amounts to a substantial modification. Draft Commission 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.

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.

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.

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.

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.

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.

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.

Not necessarily.

Draft Commission 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.

Potentially, yes.

The CRA requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute updates. It does not say that every compliant update path has to be wireless, cloud-delivered, or continuously remote.

ETSI consumer IoT guidance makes that practical point explicit: update mechanisms can range from direct download from a remote server to delivery through a mobile application or transfer over USB or another physical interface. ETSI examples also describe signed updates delivered from a manufacturer-prepared USB stick and constrained devices accepting firmware uploaded through a user interface after signature verification. So OTA is one compliant implementation pattern, not the only one. This is an inference from the CRA's functional wording together with the ETSI examples.

Potentially, yes.

The CRA does not say that each individual device must itself poll update servers or personally validate every update package. What it requires is that vulnerabilities can be addressed through security updates and that update-distribution mechanisms are secure.

ETSI EN 303 645 says that, for some products, it can be more appropriate for an associated service rather than the device itself to check whether security updates are available. The same ETSI material also explains that, where updates are delivered over a network interface, authenticity and integrity can be verified through a trust relationship, and that for constrained devices verification can be performed by another trusted device. ETSI TR 103 621 gives a concrete example of a smart home controller that validates update signatures and then transmits the trusted update to sensors and actuators over a trustworthy channel. Gateway- or app-mediated update handling can therefore fit the CRA if the trust model and security controls are strong enough. This is an inference from the CRA's functional wording together with the ETSI examples.

No.

The CRA's default-enable, opt-out, notification, and postponement rule is about automatic security updates where applicable. Separately, Annex I Part II point (2) says new security updates should, where technically feasible, be provided separately from functionality updates.

So the CRA does not create a general rule that feature or functionality changes must be installed automatically by default. If a functionality change is itself necessary to deliver the security fix, bundling may still be allowed, but that does not turn functionality updates as a category into mandatory default automatic updates.

Yes.

Annex I Part I point (2)(c) expressly requires the option to temporarily postpone automatic security updates where automatic security updates are applicable. The CRA therefore does not require every automatic update to install at the first possible moment regardless of operational context.

ETSI implementation examples include user-defined installation times and postponing download or installation until the product is connected to an unmetered network, while still allowing an override for security updates. That does not remove the CRA's requirement that updates be disseminated without delay and that vulnerabilities be fixed or mitigated in a timely manner. It means the update flow can accommodate controlled postponement.

Yes.

The CRA technical-documentation rules do not treat secure update distribution as just an operational detail. Annex VII requires the technical documentation to include the necessary information and specifications of the manufacturer's vulnerability-handling processes, including a description of the technical solutions chosen for the secure distribution of updates.

So the manufacturer needs more than a working update channel. It also needs documentation showing what secure update-distribution approach it chose for the product.

Not automatically.

The CRA itself speaks at a higher level and requires mechanisms to securely distribute updates. ETSI update-security guidance makes clear that protected transport can be one valid part of the trust model, but that secure update handling is about the overall mechanism resisting misuse and ensuring appropriate authenticity and integrity for the use case.

ETSI EN 303 645 explains that valid trust relationships can include authenticated communication channels, but it also points to verifying authenticity and integrity of updates and to anti-rollback measures. ETSI TS 103 701 says secure update mechanisms need security guarantees appropriate to the use case and that at least integrity and authenticity are required. ETSI TR 103 621 gives an example using TLS plus mutual authentication and digitally signed, versioned firmware packages. So a protected channel may be part of a compliant design, but it is not a shortcut that removes the need to ensure the update itself is trusted and protected against misuse.

Potentially, yes.

The CRA does not say that a product must be permanently online. It requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute those updates.

ETSI examples show several models that fit that basic pattern: a smart kitchen appliance that can be initialized and used offline and checks for updates when first connected; a limited-bandwidth device that is securely updated via a manufacturer-prepared USB stick; and a smart tracker that only downloads updates when in range of a paired mobile device. Intermittent connectivity does not by itself make a product non-compliant, provided the manufacturer still ensures an update path that is secure and suitable to timely remediation. This is an inference from the CRA's functional wording together with the ETSI examples.

Keep evidence that connects the update mechanism to the CRA cybersecurity risk assessment, vulnerability-handling process, and technical documentation.

For an OTA or other update path, the useful record is usually a short architecture description of the update channel, package-signing and verification model, rollback protection, user-notification and postponement flow, support-period statement, release availability policy, and exception rationale for products where automatic updates are not applicable.

For each security update, keep the vulnerability or issue being remediated, severity and exploitability assessment, affected versions, separation analysis for any bundled functionality change, release and advisory text, rollout controls, user-notification evidence, and the reason for any withdrawal, recall, or latest-version-only remediation decision.