Search every question across sub-FAQs

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.