Firmware Update & OTA Security

Firmware is the low-level software that controls a device's hardware - it runs on microcontrollers, manages peripherals, and often implements core protocol stacks. A firmware update replaces or patches this software to address vulnerabilities, fix bugs, or add functionality. Over-the-air (OTA) update mechanisms allow firmware to be delivered and installed remotely without physical access to the device. OTA update security refers to the controls that ensure only authentic, integrity-verified firmware is accepted by a device: cryptographic signatures on update packages, TLS-secured delivery channels, rollback prevention, and integrity checks performed by a trusted bootloader before executing new code.

Annex I Part I(2)(j) of the CRA requires manufacturers to ensure that their products include the ability to receive security updates - and that the update mechanism is itself secure. Article 13(3) reinforces that manufacturers must make security updates available promptly and ensure they are easy to install. An insecure update mechanism is a high-value attack target: if an attacker can inject malicious firmware through the update channel, they gain persistent, privileged access to the device. A secure update mechanism is therefore not merely a feature - it is a prerequisite for the manufacturer's ability to fulfil its ongoing security obligations throughout the product support period.

A secure OTA update implementation requires controls at every stage of the update lifecycle. During build: firmware images must be signed with a private key held in a Hardware Security Module (HSM); version metadata and changelogs must be generated. During delivery: firmware must be transmitted over a TLS-authenticated channel; update servers must require device authentication before serving packages. On device: the bootloader or update agent must verify the cryptographic signature before staging; downgrade attacks must be prevented via a version counter; and a validated rollback-to-last-good mechanism should exist to recover from failed updates. Update delivery and installation outcomes should be logged for audit purposes.

A common firmware update error is signing update packages but not verifying the signature on device - the signature exists in the build pipeline but is never checked before execution. Another error is delivering updates over unencrypted HTTP, making the package susceptible to man-in-the-middle substitution. Manufacturers also frequently implement update mechanisms that lack downgrade protection, allowing an attacker who can intercept the update channel to force installation of an older, vulnerable firmware version. Finally, some manufacturers ship products where the update mechanism depends on a cloud service with no defined availability or continuity commitment, rendering the device unable to receive security updates if the service is discontinued.