OTA firmware updates and the Cyber Resilience Act: patching as a service obligation
OTA updates are no longer just a convenience—they are a legal duty
When a Chinese robotics manufacturer ships a manipulator arm or an autonomous mobile robot into the European Union, the firmware on that device is now subject to the Cyber Resilience Act (CRA). The regulation, published in the Official Journal of the EU as Regulation (EU) 2024/2847, transforms over-the-air (OTA) updates from a feature that delights customers into a compliance obligation that can determine market access. For a service network being set up in Europe, the practical consequence is clear: patching is not an occasional fix but a continuous service that must be planned, documented, and executed with security in mind.
The CRA does not merely require that vulnerabilities be fixed; it requires that the update mechanism itself be secure. Annex I, Part I, point 2(d) of the regulation mandates that digital elements be designed to “limit attack surfaces” and to “minimise the impact of an incident”. More specifically, point 2(f) requires that security updates are delivered in a timely manner and that the update mechanism is secure. This means that an OTA system that allows unsigned firmware or that can be interrupted by a man-in-the-middle attack is not compliant, even if the update content is correct.
What the CRA demands from update mechanisms
The regulation sets out several concrete security requirements for OTA updates. Under Annex I, Part I, point 2(f), manufacturers must ensure that updates are “supported by secure mechanisms” that prevent the installation of unauthorised firmware. This implies cryptographic signing of update packages, verification of the update source, and integrity checks before installation. Additionally, the update process must not introduce new vulnerabilities—for example, it must not allow rollback to a version with known critical vulnerabilities unless explicitly authorised and logged.
Article 13(8) of the CRA adds another layer: manufacturers must ensure that vulnerabilities that can be exploited are “effectively mitigated” through security updates that are made available free of charge. The regulation does not specify a fixed time window, but it requires that updates be provided “without undue delay” after a vulnerability is discovered. For a service network, this creates a logistical challenge: how do you push a critical patch to hundreds of robots across multiple EU member states, each with different connectivity and maintenance schedules?
Furthermore, Article 13(9) requires that manufacturers document and inform users about updates, including their security impact. This means that every OTA update must be accompanied by release notes that explain what was fixed and why. For a third-party service provider, this documentation becomes part of the service record, which can be audited by national market surveillance authorities.
Shipping vulnerable firmware: who is liable?
The CRA shifts liability significantly. Under Article 13(1), manufacturers must ensure that products are placed on the market without known exploitable vulnerabilities. This is a strict obligation: if a robot ships with a firmware version that has a known critical vulnerability, the manufacturer is in breach, even if the vulnerability was disclosed after the product was designed. The only defence is that the vulnerability was unknown at the time of placing on the market, but the burden of proof lies with the manufacturer.
For a service network, this liability has a ripple effect. If a manufacturer relies on a local partner to perform updates, the manufacturer remains responsible for the security of the product. However, the service provider can be held liable under general contract law if it fails to perform an update correctly, or if it installs an update that introduces a new vulnerability. The CRA does not directly regulate service providers, but it does require manufacturers to ensure that “the product is accompanied by the information and instructions” needed for secure installation and use (Annex I, Part I, point 2(i)). This means that a service network must have access to detailed technical documentation and must follow the manufacturer’s update procedures to the letter.
In practice, this means that a service contract should clearly define who is responsible for monitoring vulnerability disclosures, who decides when to push an update, and who bears the cost of a failed update. The CRA does not mandate a specific division of labour, but it does require that the manufacturer has a process for “coordinated disclosure” of vulnerabilities (Article 13(5)). A service network can act as the manufacturer’s eyes and ears on the ground, reporting incidents and verifying that patches are applied correctly.
OTA versus physical service update: a comparison
While OTA updates are often the most efficient way to patch firmware, they are not always possible. Some robots operate in isolated networks, some have safety-critical functions that require physical intervention, and some have hardware that does not support secure OTA. The following table compares the two approaches from a service and compliance perspective.
| Aspect | OTA update | Physical service update |
|---|---|---|
| Speed of deployment | Can be pushed to many devices simultaneously, often within hours | Requires scheduling a technician visit; can take days or weeks for large fleets |
| Security of update mechanism | Must implement cryptographic signing, secure channels, and integrity checks (CRA Annex I Part I 2(f)) | Physical access reduces risk of remote interception, but requires secure handling of update media and verification of technician identity |
| Documentation and audit trail | Automatic logging of update attempts, success/failure, and device state; easier to provide evidence of compliance | Requires manual logging; risk of human error or incomplete records |
| Cost per update | Low marginal cost after initial infrastructure investment | High: travel time, labour, and potential downtime |
| Suitability for safety-critical systems | May require additional validation; some safety functions may need physical presence to verify | Preferred when a technician must visually inspect the robot or when a fail-safe is needed |
| Compliance with CRA free update requirement | Easier to provide updates free of charge, as no travel costs | Can be free of charge, but the cost of labour must be absorbed by the manufacturer or service contract |
The choice between OTA and physical updates is not binary. Many manufacturers use a hybrid approach: OTA for non-critical firmware, and physical visits for major upgrades or safety-related patches. For a service network, this means building capabilities in both areas, but with a clear understanding that OTA is the default for compliance because it is faster and more auditable.
Practical implications for a service network
For a local service network being set up in Europe, the CRA creates a new revenue stream: patching as a service. Manufacturers may outsource the monitoring of vulnerability databases, the preparation of update packages, and the verification of successful installation. However, this requires a level of technical expertise and legal awareness that goes beyond traditional repair.
First, the network must have access to the manufacturer’s vulnerability disclosure process. The CRA requires manufacturers to maintain a “single point of contact” for vulnerability reporting (Article 13(5)), but it does not require them to share this with third parties. A service contract should therefore include provisions for the manufacturer to notify the service provider of relevant vulnerabilities and to provide the necessary patches.
Second, the network must be able to verify that an update is authentic and has not been tampered with. This means that technicians need to understand cryptographic signatures and be able to check them before installation. In practice, this may involve using a secure bootloader that only accepts signed firmware, but the technician must still confirm that the update package matches the manufacturer’s release notes.
Third, the network must keep meticulous records. Under Article 13(9), manufacturers must inform users about updates, but a service provider may need to document that an update was applied to a specific device, at what time, and with what result. This is not only for compliance but also for liability protection: if a robot fails after an update, the service provider must be able to prove that the update was performed correctly.
Finally, the network must be prepared for the possibility that a manufacturer goes out of business or stops supporting a product. The CRA requires manufacturers to provide security updates for the “expected lifetime” of the product (Article 13(8)), but if the manufacturer disappears, the responsibility may fall on importers or distributors. A service network can step in to provide updates, but it must have the legal right to do so, which again points to the need for clear contracts.
Sources
- EUR-Lex — Regulation (EU) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj (accessed 2026-03-14)
- European Commission — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/ (accessed 2026-03-14)