Over-the-Air (OTA) Update

An Over-the-Air (OTA) update is a mechanism that allows a device manufacturer to remotely deliver software or firmware updates to deployed devices over a network connection — Wi-Fi, cellular, or ethernet. OTA updates can deliver security patches, bug fixes, feature additions, or configuration changes without requiring users to physically connect the device to a computer or send it for servicing. For consumer IoT devices, wearables, smart appliances, and connected industrial equipment, OTA is the primary mechanism for keeping deployed devices secure. Without OTA capability, a manufacturer's ability to provide timely security patches is severely constrained — users may never apply updates requiring physical access, creating a permanently growing vulnerability exposure.

The CRA's Annex I requires manufacturers to ensure that products can receive security updates and to provide a mechanism for doing so. For connected products, this effectively mandates a secure OTA update capability. Key CRA-relevant requirements for the OTA mechanism:

• Authenticated updates: Updates must be cryptographically signed and verified by the device before installation — unsigned OTA updates can be weaponised by attackers to push malicious firmware.
• Integrity verification: The full update package must be integrity-checked (hash verification) before and after download.
• Rollback protection: Devices should prevent downgrade attacks — rolling back to a known-vulnerable earlier version after a security patch has been applied.
• Resilient delivery: Update failures (power loss mid-update, corrupted download) must not brick the device — A/B partition schemes and atomic update mechanisms prevent partial update corruption.

A secure OTA system requires several architectural components:

• Update server: Authenticates devices, authorises update delivery, and provides signed update packages. Must be secured against compromise — a hijacked update server can push malicious firmware to the entire device fleet.
• Signing infrastructure: Update packages signed with HSM-protected keys. The update server should not hold the signing key — signing should be a separate offline process.
• Device authentication: The device must prove its identity to the update server (mutual TLS or certificate-based authentication) to prevent unauthorised parties from pulling updates or injecting fake update responses.
• A/B partition scheme: Two firmware partitions allow atomic updates — the new firmware is written to the inactive partition and activated only after verification. On failure, the device boots from the stable previous partition.
• Delta updates: For bandwidth-constrained devices, delta (differential) updates deliver only the changed portions of firmware, reducing download size while maintaining full signature verification over the final assembled image.

The CRA requires manufacturers to provide security updates throughout the product's declared support period — and the CRA's end-of-life provisions require that the support period be communicated to users via Annex II documentation. This means the OTA infrastructure is not a launch-time feature that can be deprecated — it must operate reliably for the entire duration of the product's market life plus the declared support period.

• Infrastructure longevity: The update server and signing infrastructure must remain operational throughout the support period.
• Certificate lifetime management: TLS certificates and code signing certificates have expiry dates that must be renewed before expiry — a lapsed certificate can silently break OTA delivery.
• User notification: When security updates are available, users should be notified proactively rather than relying on them to check manually.
• Update uptake monitoring: Tracking what percentage of the device fleet has applied each security update helps assess risk exposure and informs communication decisions.