OTA firmware updates

In short: Reliable OTA firmware updates use dual (A/B) partitions so a new image is written to the inactive slot while the running one stays untouched, cryptographically sign and verify every image before boot, and automatically roll back to the known-good slot if the new firmware fails to confirm itself — which is what stops a failed update from bricking the device.

Over-the-air (OTA) updates are how a shipped embedded product keeps getting better — and how a security patch reaches a million units in the field without a technician touching any of them. But an update is also the single riskiest thing a device does: it rewrites the exact code that makes it bootable. Get the mechanism wrong and you convert a fleet into paperweights. This article walks through the architecture that production teams actually use — A/B partitions, image signing and verification, confirmation-based rollback, and the concrete failure modes that cause bricking.

Why naive "overwrite flash" bricks devices

The simplest update imaginable is: erase the application region, write the new binary, reboot. This works on the bench and fails in the field. If power drops after the erase but before the write completes, there is no valid application left — and no mechanism to get a new one, because the very code that talks to the network is the code you just destroyed. Field data from large IoT deployments routinely shows power loss, brown-outs, and radio dropouts during the multi-second flash window at rates far too high to ignore at fleet scale.

The fix is a principle borrowed from database design: never destroy the only good copy. Keep the running firmware intact, stage the new image somewhere else, and switch over atomically only after you are sure the new image is both authentic and bootable.

A/B partitions and the atomic switch

In an A/B scheme the flash is divided into two application slots plus a small, rarely-changed bootloader. Say slot A holds v1.4 and is running. The update agent downloads v1.5 straight into slot B while the device keeps operating normally. Only after the entire image is written and verified does the system flip a single "active slot" pointer and reboot. That pointer flip is a single-word write — the one genuinely atomic operation — so there is no in-between state where the device has half an image. This is exactly how Android (since the 2016 "seamless updates" design) and most automotive ECUs operate, and it is the model behind frameworks such as Mender, SWUpdate, and RAUC on Linux targets.

Cost: A/B roughly doubles the flash budget for application code. On a 2 MB-app device you need 4 MB-plus of program flash. On deeply cost-sensitive MCUs where that is impossible, teams fall back to a single-slot scheme with a compressed update staged in external SPI flash and a minimal recovery bootloader — slower and riskier, but it fits.

Signing and verification: trust before you boot

An update channel is an attack surface. If a device will flash and boot whatever arrives, a man-in-the-middle can push malicious firmware. The defence is a digital signature. At build time the vendor hashes the image (SHA-256) and signs that hash with a private key — commonly RSA-2048/3072 or ECDSA P-256. The device stores only the matching public key, usually burned into one-time-programmable (OTP) fuses or a secure element so it cannot be swapped.

On every boot, the bootloader recomputes the image hash and verifies the signature against that trusted key. If the signature fails, the image is rejected — it is either corrupt or forged. This is the foundation of secure boot, and when the chain extends through every stage it becomes a chain of trust rooted in immutable silicon. Standards bodies have converged here: the IETF SUIT manifest format and the Arm-backed MCUboot bootloader both bake signing and anti-rollback counters into the update metadata.

Rollback: confirming the new firmware actually works

A signed image can still be broken — a logic bug that crashes on boot or kills the network stack. Signature verification proves authenticity, not correctness. So A/B systems add a confirmation handshake. When the bootloader launches the new slot, it marks it pending/trial. The new firmware must, within a watchdog window, explicitly call something like boot_set_confirmed() to declare "I came up healthy." If it does, the slot becomes permanent. If the device reboots before confirming — because it hung, panicked, or the watchdog fired — the bootloader sees the unconfirmed flag and automatically reverts to the previous known-good slot.

This is why a bad OTA is a non-event on a well-built product: one reboot, and the old firmware is running again. An anti-rollback counter (a monotonic value in OTP) complements this by refusing to boot images older than a security baseline, so an attacker cannot force a downgrade to a patched-out vulnerability.

Rule of thumb: if a device is physically hard to reach (a sensor in a wall, an ECU in a car, a meter on a pole), treat A/B + signing + confirmed-rollback as mandatory, not optional. The recovery cost of a single brick dwarfs the flash cost of a second slot.

Where real designs still go wrong

Even with A/B, bricking creeps in at the edges. The classic one is a bootloader update — the bootloader is the thing that makes A/B safe, so it usually lives in a single slot and updating it is inherently risky; most teams freeze it or use a tiny immutable first-stage loader. Shared data-partition migrations are another trap: if v1.5 rewrites a config schema and then rolls back to v1.4, the old firmware may choke on the new data. Version your persistent data and keep migrations forward-and-backward tolerant. For deeper treatment of the loader itself, see our companion piece on the bootloader in embedded systems, and our guide to secure boot and the chain of trust.

Finally, test the update path as a first-class feature. Fault-inject power loss mid-write, corrupt the image, present an expired signature, and confirm the device always lands on a bootable slot. Teams building safety-critical silicon validate this alongside the RTL and firmware using the same verification discipline that firms like Avecas VLSI design services apply to tapeout flows.

Want to build OTA pipelines that never brick a device? CourseTron's Embedded Systems & Firmware track takes you from bootloaders to A/B OTA with hands-on labs. Explore the courses →

Frequently asked questions

Do I always need two application slots for OTA?

No, but it is the safest option. A/B guarantees a bootable fallback and power-fail safety. On flash-constrained MCUs you can use a single slot with an external staging area and a recovery bootloader, accepting a narrower safety window.

What is the difference between signing and secure boot?

Signing is the act of attaching a cryptographic signature to an image at build time. Secure boot is the device-side policy of verifying that signature against a trusted key on every boot and refusing to run anything that fails. Signing without enforced verification gives you no protection.

How does automatic rollback actually trigger?

The new firmware boots in a trial state and must confirm itself within a watchdog window. If it crashes or hangs before confirming, the next reboot sees the unconfirmed flag and the bootloader reverts to the previous good slot — no human action required.

Can an OTA update still brick an A/B device?

Rarely, and almost always through the edges: updating the bootloader itself, incompatible shared-data migrations after a rollback, or disabling the fallback. Keep the first-stage loader immutable and version your persistent data to stay safe.