Firmware updates for IoT devices: OTA, signing and rollback explained

A device that cannot be updated is a device whose next security hole is permanent. A device that updates badly can be bricked by a power cut or hijacked by a fake update. The mechanism between those two outcomes is a small set of ideas that every well-designed connected product shares, and once you know them you can judge a product’s update story from its documentation.

Why firmware updates matter for IoT devices

Firmware is the software that runs on the device itself. Unlike an app on a phone, it usually includes everything: the operating system, the network stack, the drivers, the application. A vulnerability in any of those is fixed by replacing the firmware image.

Vulnerabilities are found continuously in the components these devices are built from, including the open-source libraries and the chip vendor’s software that most manufacturers reuse. A device with no way to receive a new image cannot be fixed, and it will sit on a network for years. That is why the update path is one of the first things to check on any product, and why the device security basics article puts updates second only to passwords.

The update path is also an attack surface of its own. A process that fetches and installs code from the network is exactly what an attacker would like to control. So the design has to solve two problems at once: getting fixes onto the device reliably, and making sure only the manufacturer’s fixes get on.

How an OTA update is delivered

Over-the-air means the device downloads and installs a new image over its normal network connection, with no cable and no person holding a file. The steps are broadly the same on every platform; the IETF describes the general architecture in RFC 9019, which is a readable summary of what a good design contains.

The device learns that an update exists, either by checking a server periodically, by being told through the cloud service it is already connected to, or in some ecosystems (such as Matter) by a controller offering the image over the local network. It downloads the image, or in constrained designs a set of chunks, into storage that is not the currently running firmware. It verifies the image. It marks the new image as the one to boot next, and reboots. On the first boot of the new firmware, it confirms the update was successful, or if something is wrong, it falls back.

Each step has failure modes that a good design handles. The download can be interrupted, so images are stored separately from running code and resumed or restarted. Storage can run out, so the device has enough for two images. Power can fail mid-write, so the write never touches the image currently running. The server can be impersonated, which is what signing addresses. And the new firmware can turn out to be broken, which is what rollback addresses.

What signing protects against

Signing is how the device knows an image came from the manufacturer and has not been altered. The manufacturer holds a private key. Before publishing an image, they compute a cryptographic hash of it and sign that hash with the private key. The device holds the matching public key, typically in the bootloader or in protected storage. Before installing, it computes the hash of what it downloaded and checks the signature against its public key. If the check fails, the image is discarded.

What this defeats: an attacker who intercepts the download and substitutes their own image; an attacker who compromises the download server and replaces the file; a corrupted download. What it does not defeat: an attacker who steals the manufacturer’s private key, which is why serious manufacturers keep that key in a hardware security module and use it only through a controlled process.

Two details separate a solid implementation from a weak one. The public key must be protected from replacement, or an attacker who gets one image onto the device can swap the key and sign everything after; hardware that locks the bootloader and its key is the usual answer. And the check must happen on the device, at install and ideally at every boot (secure boot), rather than only on the server side.

Signing is not the same as encrypting the transport. Downloading over HTTPS protects the file in transit; signing protects the file whatever path it took. Good designs do both, and a device that relies on transport security alone can be fed a bad image by anyone who can get in the middle.

How rollback keeps a device alive

A verified image can still be bad. It can have a bug that crashes on this hardware revision, or a network setting that stops the device reconnecting, or simply fail to boot. Rollback is the mechanism that gets the device back to the previous, working firmware without a person visiting it.

The common design is dual-slot storage, as in the diagram: two copies of the firmware live in flash, one active and one spare. The update is written to the spare slot. The bootloader is told to try the new slot on the next boot, with a condition attached: the new firmware must report that it started successfully, usually by writing a confirmation flag once it has connected to the network or passed a self-check. If the bootloader sees the device restart without that confirmation, or restart more than a few times, it switches back to the old slot. The failed update becomes the spare, and the device is running the firmware it had before.

Some constrained devices cannot afford two full slots. They use a smaller recovery image instead: a minimal firmware whose only job is to download a working image, kept in a protected area. That is weaker, because the device has to reach the network to recover, but it still beats a brick.

A related idea is anti-rollback protection, which sounds like the opposite and is a different thing. It stops an attacker from installing an older, signed, vulnerable image on purpose. The device keeps a version counter that only goes up, and refuses to boot a signed image whose version is below the counter. Manufacturers use this to make sure a fixed hole stays fixed.

Questions to ask a vendor

Product pages rarely say any of this, but documentation, support pages and a direct question usually get answers. What to ask:

• How are updates delivered? Automatically, through the app, or by manual file upload. Automatic is best for a device you will forget about.
• Are images signed and verified on the device? The answer should be yes without hesitation. Ask whether the bootloader is locked and whether secure boot is used.
• What happens if an update fails? Listen for “dual bank”, “A/B”, “rollback” or “recovery”. A vendor who has not thought about it will describe a support ticket.
• How long will updates be provided? A stated support period, in years from a date, is the honest form. “Ongoing” means nothing.
• Where is the changelog? A public list of past updates with dates is the best evidence that updates actually happen.
• Can the device be updated without the cloud? For a device you intend to run locally, a local update path matters.

A vendor that answers all six clearly is one you can trust with a device that will be on your network for a decade.

When a device stops getting updates

Every device reaches this point. The manufacturer moves on, or the product line ends, or the company closes. What to do depends on what the device is.

For anything that must reach the internet to work, and that holds something sensitive (a camera, a microphone, a lock, an alarm), plan its replacement. An internet-facing device with no more fixes is a liability that grows each year.

For devices that work on the local network, contain them. Put them on the IoT VLAN, block their internet access, and let them carry on doing their local job. A bulb or a plug that cannot reach out and cannot be reached from outside has very little attack surface left.

For some devices there is a third option: community firmware. Several popular chips, the ESP32 family above all, have open-source firmware projects that keep receiving updates long after the original manufacturer stopped. Installing it usually voids the warranty and takes some skill, but it turns an abandoned device into a maintained one.

Whichever route, write the end-of-support date on your device list when you learn it. The devices that quietly age out of support are the ones that end up in a botnet, and a list you review once a year is all it takes to notice.