OTA Firmware Updates: The Basics That Keep Devices Alive

A power cut at 60% of a firmware download should cost you a retry, not a truck roll. OTA firmware updates are how a connected product fixes bugs and vulnerabilities after it ships, and they’re also the riskiest code path in the device: an update is, as the IETF’s firmware update architecture puts it, essentially authorized remote code execution. This article explains the parts of an update system that keep devices working (image slots, signed manifests, rollback protection, test-and-confirm boots) and what the main standards and research ask for, with a flash budget you can adapt to your own part.

Key Takeaways

• An update must survive interruption. RFC 9019 says devices must not fail when a disruption such as a power failure occurs, which in practice means keeping a working image (two slots, or a recovery image) until the new one is proven.
• The device verifies a signature over a manifest before installing. The manifest describes the image and carries a sequence number so the device can reject an older image even if it’s validly signed.
• A “test” boot that reverts unless the new firmware confirms itself, as in MCUboot’s test and permanent swap modes, turns a bad release into a reboot instead of a bricked device.
• The update server is part of the security boundary. Research on The Update Framework (Samuel et al., CCS 2010) designed for signing-key compromise with separate roles, thresholds and expiring metadata.
• ETSI EN 303 645 requires consumer IoT manufacturers to publish a defined support period for security updates, so the update system has to last at least that long.

The problem: the riskiest code path ships last

Update support is often added late, after the application works, and tested on a bench with a good connection and a stable power supply. In the field, downloads stop halfway, batteries die during a flash write, devices sit offline for months and come back with three releases to catch up on, and an attacker who can reach the update channel tries to install something you didn’t build.

Each of those cases has a known answer, and the answers constrain the hardware: flash has to hold more than one image, the bootloader needs keys and a verifier, and the device needs some non-volatile state that records what it’s running and whether that image has been confirmed. These are decisions to make when the memory map is drawn, not after.

What the standards and research say

The IETF architecture: manifests, signatures and sequence numbers

RFC 9019, A Firmware Update Architecture for Internet of Things (Moran, Tschofenig, Brown and Meriac, 2021), describes the pieces for constrained devices. Each update is described and protected by a manifest, which can travel with the image or separately. The device verifies a digital signature (or a MAC, on very constrained devices) over the manifest before installing, using trust anchors provisioned before any update happens. Authorization can require more than one signer, such as both the firmware author and the device operator.

The manifest also carries a sequence number. The RFC is explicit that “a device presented with an old but valid manifest and firmware must not be tricked into installing such firmware,” because the older release may contain a vulnerability that the new one fixed. Signing alone doesn’t stop downgrades.

On reliability, it states that devices “must not fail when a disruption, such as a power failure” occurs, and describes the usual ways to achieve that: keep the previous image as a backup, store two or more images, or keep a recovery image that can rerun the update. It also notes that the bootloader itself should rarely be updated, because a failed bootloader update is the one that can’t be recovered.

NIST: protection, detection and recovery

NIST SP 800-193, Platform Firmware Resiliency Guidelines (Regenscheid, 2018), was written for platform firmware in computers and servers, but its structure applies to any device. It organizes the requirements into three principles: protection against unauthorized changes, detection of unauthorized changes when they happen, and recovery to a known good state. An embedded update system maps onto all three: signature verification protects, a boot-time integrity check detects, and a fallback image recovers.

MCUboot: slots, swaps and confirmation

MCUboot, an open-source secure bootloader for microcontrollers, is a concrete implementation of these ideas. Each image area has a primary slot, where the bootloader normally runs the firmware, and a secondary slot, where the new image is downloaded. At boot, the bootloader checks the new image’s SHA-256 hash and signature, then installs it by swapping or overwriting.

The key feature for reliability is the test swap. In test mode, the bootloader swaps the new image in and boots it, and if the firmware doesn’t mark itself as confirmed before the next reset, the bootloader swaps the old image back. Firmware typically confirms only after it has reached its server or passed a self-test. Swap progress is recorded in an image trailer at the end of the slot, so a swap interrupted by a reset resumes where it stopped.

MCUboot also offers downgrade prevention, either by comparing version numbers in software or by comparing a security counter stored in trusted, non-volatile hardware. Its documentation notes that software downgrade prevention is available only in overwrite-only mode, a detail that shows why these features need to be chosen with the memory layout.

Securing the server side

Signing keys and update servers are targets too. Samuel, Mathewson, Cappos and Dingledine presented The Update Framework (TUF) at ACM CCS 2010, with the goal of making software update systems survive the compromise of signing keys. Its design separates responsibilities into roles (which files are trusted, which versions are current, which metadata is fresh), lets critical roles require a threshold of several keys, and puts expiry times on metadata so that a device can detect when it’s being fed stale information. TUF was designed for general software repositories; the same ideas were later adapted for vehicles in Uptane. For a small product, the lessons are to keep the root signing key offline, separate it from day-to-day release keys, and give devices a way to notice an update channel that has stopped telling the truth.

Regulation: a promised support period

ETSI EN 303 645 (V2.1.1, 2020), the European baseline for consumer IoT security, requires non-constrained devices to have a mechanism for the secure installation of updates, requires best-practice cryptography for it, and requires that updates delivered over a network have their authenticity and integrity verified through a trust relationship. It also requires the manufacturer to publish a defined support period: the minimum time, as a duration or end date, for which security updates will be provided. Whatever you promise there, the update system and its keys have to work for that long.

A flash budget, worked through

Illustrative numbers for a device with 1 MB of internal flash:

• Bootloader: 32 KB.
• Primary slot: 448 KB for the application.
• Secondary slot: 448 KB for the incoming image (same size as the primary in a swap scheme).
• Scratch or swap overhead, trailer and a small settings area: the remaining space.

The application can therefore be at most about 448 KB, less than half the flash. If that’s too small, the options are external flash for the secondary slot (the image is then usually encrypted, since external flash is easier to read), compressed or delta images, or a single-slot design with a small recovery image, which accepts that the device is offline while it reinstalls.

Download time matters too. At an illustrative effective throughput of 20 kB/s over a short-range radio, a 400 KB image takes about 20 seconds; at 2 kB/s over a constrained cellular or sub-GHz link, more than three minutes, during which the battery, the connection and the user all have to cooperate. Resumable downloads (keeping track of which blocks have arrived) are worth the code.

Update designs compared

Design	Survives power loss	Survives a bad release	Flash cost	Notes
Single slot, overwrite in place	No	No	Lowest	Only acceptable with a physical recovery path
Single slot plus recovery image	Yes (reinstall from recovery)	Partly (device offline until reinstall)	Low	Recovery image must be able to download
Two slots, overwrite primary	Yes, if the copy can resume	No (old image is gone)	Two image sizes	Simple; allows software downgrade checks in MCUboot
Two slots, test swap with confirmation	Yes	Yes (reverts unless confirmed)	Two image sizes plus swap overhead	Common default for microcontrollers
Two equal slots, run from either (direct execute)	Yes	Yes, with trailer support	Two image sizes	Image must be built for each slot’s address

What to actually do

Reserve flash for two images on day one

Decide the slot layout when you choose the part. If the application won’t fit twice, plan external flash or a recovery image now, not after the application has grown into all the space.

Sign images and verify a manifest on the device

Use a maintained bootloader that verifies signatures, keep the private key off build servers that don’t need it, and include a version or sequence number that the device checks against what it’s running.

Use test-and-confirm boots

Boot the new image in a test mode and confirm it only after the firmware reaches its server or passes a self-test. A release that crashes on boot should revert by itself.

Block downgrades deliberately

Decide whether the device may ever install an older version (for example, a signed recovery release), and enforce the rule with a version check or a hardware security counter.

Roll out in stages

Release to a small fraction of devices first, watch confirmation and crash reports, and only then widen. Keep the ability to stop a rollout.

What not to do

Don’t update the bootloader routinely; it’s the one component without a fallback. And don’t test updates only on a bench: cut the power and the connection at every stage of an update, many times, before the first field release.

How to put it to work

If you have an hour

Draw your current flash map and mark where a second image would go. Write down what your device does today if power is lost halfway through an update.

If you have a sprint

Integrate a bootloader with signature verification and test swaps, and build a test that interrupts power at random points during an update a few hundred times and checks the device always boots a valid image.

If you want it to last the product’s lifetime

Document the signing-key hierarchy and who holds each key, set the support period you’ll publish, and add update success, revert and version data to the telemetry you review after each rollout.

The question to ask yourself: “If the next release crashes on boot on every device, what happens in the first five minutes, and does anyone need to touch the hardware?”

Frequently asked questions

What is an OTA firmware update?

It’s an update delivered to a device over its network connection (wireless or wired) instead of through a programming cable. The device downloads a new image, verifies it and installs it, usually through a bootloader that can fall back to the previous image if something goes wrong.

Why do OTA updates need two image slots?

So that a working image remains while the new one is downloaded and tested. If the download is interrupted or the new image fails, the device boots the old one. Single-slot designs need a separate recovery image to achieve the same.

What is rollback protection?

It’s a check that prevents the device from installing an older firmware version, even a validly signed one, because older versions may contain vulnerabilities that were fixed later. It’s typically a version or sequence number in the manifest, sometimes backed by a hardware counter.

What is a test swap in MCUboot?

It’s a mode in which the bootloader installs and boots the new image but swaps the old one back on the next reset unless the new firmware has marked itself as confirmed. It protects against releases that fail to boot or fail to reach the network.

Do small microcontrollers need signed updates?

Yes, if updates arrive over any channel an attacker could reach. RFC 9019 targets constrained devices explicitly and allows a MAC instead of a public-key signature on the most constrained ones. ETSI EN 303 645 requires authenticity and integrity checks for network-delivered updates on consumer IoT devices.

Related reading: RTOS vs bare-metal firmware, measuring microcontroller power consumption and from development board to product.

Sources

1. Moran, B., Tschofenig, H., Brown, D., & Meriac, M. (2021). A Firmware Update Architecture for Internet of Things. IETF RFC 9019. https://www.rfc-editor.org/rfc/rfc9019.html
2. Regenscheid, A. (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. https://csrc.nist.gov/pubs/sp/800/193/final
3. Samuel, J., Mathewson, N., Cappos, J., & Dingledine, R. (2010). “Survivable Key Compromise in Software Update Systems.” Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS ’10), 61–72. https://doi.org/10.1145/1866307.1866315
4. ETSI (2020). Cyber Security for Consumer Internet of Things: Baseline Requirements. ETSI EN 303 645 V2.1.1. https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf
5. MCUboot project. “MCUboot Design.” https://docs.mcuboot.com/design.html