Over-the-Air Updates for Connected Products

Why updates belong in the first design

ETSI EN 303 645 (V3.1.3), the European baseline standard for consumer IoT security, opens its section 5.3 "Keep software updated" with a plain statement: "Developing and deploying security updates in a timely manner is one of the most important actions a manufacturer can take to protect its customers". The standard says the device "shall have a secure update mechanism" unless a real resource constraint of the use case prevents it, and it rules out cost alone as a reason.

The IETF's RFC 9019, an architecture for firmware updates on small IoT devices, calls an update mechanism "a fundamental requirement for fixing vulnerabilities". In the US, NIST's IR 8259A core baseline for IoT devices lists software update as one of six core capabilities, including:

• updating the software remotely or locally;
• verifying and authenticating any update before installing it;
• letting authorised parties roll back to a previous version;
• enabling or disabling updates and update notifications.

The practical point is that updates depend on choices made before the first device is built: enough flash memory to hold a second image, a bootloader that can verify signatures, keys stored safely, and a server and app that can deliver and track releases. Our guide to IoT companion apps covers how the phone app fits in.

Signed updates the device checks itself

An update mechanism is also a way to put code on the device, so it is a target. ETSI explains that "if an attacker compromises this mechanism, it allows for a malicious version of the software to be installed". Its provision 5.3-10 says that where updates arrive over a network, the device "shall verify the authenticity and integrity of each update via a trust relationship", and lists digital signature verification as one valid way.

In practice, the manufacturer signs each firmware image with a private key that never leaves a secure build or signing system, and the device holds only the matching public key. RFC 9019 says the device must prevent "attempts to flash a maliciously modified firmware image or an image from an unknown, untrusted source". Its companion, RFC 9124, describes the manifest that travels with the image. Among other things it carries a vendor ID and a class ID, so a device can reject firmware built for a different product.

Signing protects the image however it travels, from a server, a phone app or a USB stick. ETSI notes that a device too constrained to check signatures can rely on a trusted hub to verify the update and pass it on over a secure channel.

A way back when an update fails

ETSI warns that if an automatic update fails, a user "can, in some circumstances, no longer be able to use a device". It suggests "watchdogs and the use of dual-bank flash or recovery partitions" so the device returns to a known good version or the factory state. RFC 9019 says an IoT device "needs a recovery strategy", such as storing two or more firmware images. It also notes that the bootloader itself, or a minimal part of it, is usually not updated, "since a failed update of the bootloader poses a reliability risk".

The MCUboot open-source bootloader shows how this works on small microcontrollers. MCUboot performs a "test" swap to boot the new image, which must then mark itself "OK". If it does not, MCUboot "will perform a 'revert' swap during the next boot" and runs the old image again. Decide what "works" means for your product: it connects to your server and passes a self-test, not just that it boots.

Blocking downgrades

Being able to go back after a failed update is different from letting anyone install an old version. An older signed image may contain a flaw you have since fixed. ETSI gives "an anti-rollback policy based on version checking" as one way to "prevent downgrade attacks". RFC 9124 makes a "monotonic sequence number" a required manifest element "to prevent malicious actors from reverting a firmware update against the policies of the relevant authority".

The two fit together. The device falls back automatically only to the image it was running before a failed update. Any deliberate rollback to an older release is a decision for authorised parties, as NIST IR 8259A puts it, not something any update file can trigger.

Rolling out to a fleet

RFC 9019 describes a "status tracker" that tells devices a new version is available, learns which hardware and firmware each device has, and can trigger the update. Its example flow ends with the device reporting "the successful boot of the new firmware version". That reporting is what makes a careful rollout possible:

• Release first to your own test devices, then to a small share of the fleet.
• Watch the reports: how many installed, how many reverted, how many went silent.
• Widen the rollout only when the numbers look normal, and be able to pause it.
• Keep a dashboard of every device and its firmware version.

ETSI also notes that if an update "is subsequently found to cause issues, manufacturers can ask users to not upgrade".

What the user sees

An update people never install fixes nothing. ETSI provision 5.3-3 says an update "shall be simple for the user to apply". Its other recommendations:

• Offer automatic updates, switched on during setup with the user's consent.
• Let the user turn automatic updates on and off, and postpone an installation.
• Tell the user clearly when a security update is required, and what risk it fixes.
• Warn when an update will interrupt the device.
• Keep essential functions running where safety depends on them: "a home thermostat will continue to maintain a reasonable temperature and a Smart Lock will continue to lock and unlock a door".

ETSI also advises that it is "often advisable not to bundle security updates with more complex software updates, such as feature updates", so a fix is not delayed by a new feature. For battery devices, RFC 9019 notes that radio use and writing to flash make updating "an energy-intensive task", so schedule updates when the battery can cope.

Publishing a support period

Updates need an owner for as long as you promise them. ETSI provision 5.3-13 says the manufacturer "shall publish, in an accessible way that is clear and transparent to the user, the defined support period". In the UK, the PSTI product security regime requires manufacturers of consumer connectable products to publish "the minimum length of time security updates will be provided along with an end date". The EU's Cyber Resilience Act summary says the end date of the support period, "including month and year", must be clearly specified at the time of purchase. For what each law covers and when it applies, see our guide to IoT device security rules.

If a device cannot be updated at all, ETSI asks the manufacturer to publish why, along with the period and method of hardware replacement,. Either way, budget for the people, keys, servers and testing the support period needs.

A checklist

• Flash, bootloader and key storage are chosen with updates in mind before hardware is final.
• Every image is signed, and the device verifies the signature and the product it is for.
• A failed update falls back automatically to the previous working image.
• A sequence number blocks unauthorised downgrades to older releases.
• Devices report their version and update result; rollouts start small and can be paused.
• Updates are simple and automatic with consent, and the user can postpone them.
• The support period and its end date are published in plain words.

Frequently asked questions

Does every connected device need OTA updates?

ETSI EN 303 645 says a consumer IoT device shall have a secure update mechanism unless a resource constraint of its use case prevents it, and cost alone does not count.

What does it mean for an update to be signed?

The manufacturer signs each firmware image with a private key kept in a secure signing system. The device holds the matching public key and installs only images whose signature checks out, so a modified or unofficial image is rejected.

What happens if an update fails halfway?

With a recovery design, nothing permanent. The device keeps the previous image, tries the new one, and reverts if the new firmware does not confirm that it works. ETSI suggests dual-bank flash or recovery partitions for this.

Is rollback the same as a downgrade?

No. Falling back to the last working image after a failed update is a safety feature. Letting anyone install an older release is a risk, because it can bring back fixed vulnerabilities. ETSI and RFC 9124 describe version checks and a monotonic sequence number to block unauthorised downgrades.

How long do we have to provide updates?

You set the period, but you must publish it. ETSI requires a published support period, the UK PSTI regime requires a minimum security update period with an end date, and the EU Cyber Resilience Act requires the end date, including month and year, at the time of purchase.

Building a connected product? We design the device, cloud and apps as one system, with signed OTA updates verified on the device, rolled out to a small group first, with the previous version kept to fall back to, and a dashboard that shows every device's firmware version. See our IoT development service and all our services, or email [email protected].