OTA Firmware Updates: Architecture, Security, and Safe Rollback

Ship 10,000 connected devices, then wait. Somewhere between month three and month eighteen, a CVE lands in the BLE stack, the TLS library, or the Wi-Fi driver you shipped — and now you have a fleet in the field running exploitable firmware with no way to fix it. Without over-the-air (OTA) updates, your only options are a recall, a truck roll at $150 to $400 per visit, or telling customers to live with it. That is the moment founders discover that OTA is not a feature you add in v2. It is load-bearing infrastructure you should have designed on day one, and retrofitting it into a locked-down flash layout after the board is frozen is one of the most expensive mistakes in embedded product development.

Why OTA Is Not Optional

A connected product is a product you are on the hook to maintain for its entire service life. For a consumer wearable that might be three years; for an industrial sensor it can be a decade. The security posture that shipped is guaranteed to rot: mbedTLS gets a CVE, the Nordic SoftDevice gets a patch, a regulator changes a requirement. If you cannot push signed firmware remotely, every one of those events becomes a business problem instead of an engineering task.

• The first exploitable CVE in a shipped fleet converts every unit into a liability — and your legal exposure scales with the number of devices you cannot patch.
• OTA is what lets you ship a 'good enough' v1 and fix the long tail of field bugs, rather than holding launch for six months chasing a mythical bug-free build.
• For anything with a long service life, plan the update path against the whole lifecycle — see how this plays out for a 10-year industrial IoT device where the MCU you chose may be end-of-life before the product is.
• OTA is where hardware meets software; if you have not settled your embedded vs. IoT architecture — where firmware ends and the cloud begins — you cannot reason about how updates are delivered and gated.

The Bootloader Does the Real Work

OTA is not about the application downloading a new binary. That is the easy 20 percent. The hard, safety-critical 80 percent lives in a small, rarely-touched piece of code that runs before your application: the bootloader. Its job is to decide which firmware image is valid, verify its signature, swap it into place atomically, and — critically — recover the device if the new image is broken. The application never trusts itself to be the final authority on whether an update is legitimate; the bootloader is the root of that decision, and it must be small enough to audit and stable enough that you almost never change it.

• Verify the cryptographic signature of a candidate image before ever jumping to it.
• Enforce the anti-rollback counter so a signed-but-old vulnerable image cannot be replayed.
• Perform the atomic swap between the running image and the new one, tolerating power loss at any instant.
• Detect a failed boot and roll back to the last known-good image without human intervention.

A/B Dual-Bank vs. Single-Bank — Pick Your Flash Budget

There are two fundamental layouts, and the choice dictates your flash budget before you place a single component. In A/B (dual-bank) partitioning, flash is split into two application slots. The device runs from slot A while downloading the new image into slot B; the bootloader validates B and marks it primary; if B fails, it falls back to A. This is the gold standard because the old image is always intact. The cost is real: you need roughly 2x your application size in flash. On an STM32L4 with 1 MB of internal flash, two ~480 KB banks plus a ~32 KB bootloader is tight but workable. On an nRF52840 (also 1 MB), the SoftDevice eats space and you feel the squeeze fast.

• A/B dual-bank: safest, always has a working fallback, but demands ~2x app flash. Budget it at schematic time, not after.
• Single-bank with a bootloader: the new image overwrites the running one after verification. Uses far less flash but has a vulnerable window — a power loss mid-write can brick the device unless you stage the image elsewhere first.
• If internal flash is the constraint, add external SPI/QSPI flash — a W25Q128 gives you 16 MB of staging area for a few tens of cents, and lets even a small MCU run a clean A/B scheme.
• This is one more input to the ESP32 vs. STM32 vs. Arduino production decision: the ESP32-S3 already boots from external SPI flash, so A/B partitioning across a 4–16 MB part is cheap and native, while a bare STM32 forces the trade-off into your internal flash budget.

Delta Updates Save Bandwidth and Battery

A full firmware image can be 500 KB to several megabytes. Pushing that to a cellular NB-IoT device on a metered plan, or to a coin-cell BLE sensor that has to keep its radio on for the whole transfer, is expensive in both dollars and joules. Differential (delta) updates ship only the binary diff between the installed version and the target — often a 5–20x reduction. The device reconstructs the full image locally from the old image plus the patch. It adds complexity (you must track exactly which version each device runs, and generate per-version patches), so many teams ship full images for v1 and add delta support once the fleet grows and bandwidth cost becomes real.

Sign Every Image, Verify Before Boot

An unsigned OTA channel is a remote-code-execution vulnerability you built on purpose. If anyone who can reach your update endpoint — or spoof it — can push a binary the device will run, you have handed attackers root on your fleet. Every image must be cryptographically signed, and the bootloader must verify that signature against a public key baked into the device before it hands over control.

• Use ECDSA (P-256) or Ed25519 for signatures — both are compact, fast on Cortex-M, and well-supported by MCUboot and vendor bootloaders. RSA-2048 works but the signatures and verification cost are heavier on a constrained MCU.
• The private signing key never leaves your build/HSM environment; only the public key ships on the device. Treat the private key like the master key to your entire fleet, because it is.
• Verify in the bootloader, before the jump — not in the application. An application that verifies its own successor is trusting code that may already be compromised.
• Bind the signature to a version and device-class identifier so a valid image for product A cannot be flashed onto product B.

Hardware Root of Trust and Secure Key Storage

Signature verification is only as trustworthy as the key it checks against and the boot chain that runs the check. If an attacker with physical access can rewrite the public key or replace the bootloader, the whole scheme collapses. A hardware root of trust anchors the first link so the chain is verifiable from immutable silicon upward.

• Secure boot: the ESP32-S3 verifies the bootloader with an eFuse-burned key (Secure Boot v2, RSA-3072 or ECDSA); STM32 devices use RDP level 2 and option bytes to lock the boot path. Once burned, these are one-way — you cannot un-brick a misconfigured part, so validate on sacrificial units first.
• Secure key storage: an ATECC608B secure element holds private keys in tamper-resistant hardware over I2C, so keys never sit in readable MCU flash. Many MCUs also expose an on-die secure enclave or key store for the same purpose.
• eFuse / OTP: burn the public key hash and secure-boot enable bits into one-time-programmable fuses so they cannot be rewritten in the field.
• Encrypt flash at rest so a physical attacker cannot dump firmware and extract IP or secrets — ESP32 flash encryption and STM32 on-the-fly decryption both cover this.

Anti-Rollback: Stop Attackers Replaying Old Firmware

A signed image is not automatically a safe image. Version 1.2 was signed by you, and it also contains the exact CVE you patched in 1.3. An attacker who captures the old signed binary can replay it — a valid signature, a vulnerable payload. Anti-rollback defeats this with a monotonic security counter: each release carries a counter value, the device stores the highest value it has ever run in OTP or a secure counter, and the bootloader refuses any image whose counter is lower than what is stored. The trade-off is discipline — you can no longer casually downgrade a device in the field, so bump the counter only for security-relevant releases, not every point build.

Atomic Swap and Power-Fail Safety

The single most common way to brick a device during OTA is a power loss halfway through writing the new image. If the update is not atomic, the device wakes up with a half-written binary in the boot slot and nowhere to go. The defense is that the swap must be a transaction: either the whole new image is in place and marked valid, or the old one still is — never a torn state. MCUboot's swap-move and swap-scratch algorithms are built precisely for this, using a scratch area and status writes so that an interrupted swap can be resumed or reversed on the next boot. Test it the brutal way: pull power at randomized offsets during the swap, across hundreds of cycles, and confirm the device always comes up on a valid image.

Watchdog, Health Check, and Automatic Rollback

Sometimes the new image installs perfectly, is validly signed, swaps atomically — and then crashes on boot because of a bug you did not catch. Without a recovery path, you have just bricked the fleet with a signed update, which is the worst possible outcome because it looks legitimate. The device must be able to decide, on its own, that the new firmware is bad and revert.

1. After a swap, the bootloader marks the new image as 'test' rather than 'permanent', and starts a hardware watchdog before jumping to it.
2. The new application must reach a health check — connect to the network, pass a self-test, confirm core peripherals — and then explicitly confirm itself, which marks the image permanent and pets the watchdog.
3. If the application boot-loops or hangs before confirming, the watchdog fires, and on the next boot the bootloader sees an unconfirmed image and rolls back to the previous known-good slot automatically.

Staged Rollout, Canary Fleet, and a Kill Switch

Never push a new image to 100 percent of the fleet at once. That turns a bad build into a fleet-wide outage in minutes. Roll out in stages and watch the numbers before you widen the blast radius.

• Canary first: push to 1 percent of devices, watch crash rate, boot-success rate, battery drain, and connectivity for 24–72 hours before expanding.
• Ramp in tranches — 1 percent, then 10, then 50, then 100 — with automated health gates between stages so a regression halts the rollout instead of completing it.
• Keep a kill switch: the ability to immediately stop an in-flight rollout and, ideally, push the previous version as a forward-fix to any device that already took the bad build.
• Instrument the fleet so 'boot success rate dropped 4 percent in the canary cohort' is a dashboard alert, not a wave of support tickets.

OTA Is Your Biggest Single Battery Drain — Schedule It

On a battery device, the update itself is often the most expensive thing the product ever does. Keeping the radio powered to download hundreds of kilobytes, then writing flash page by page, can consume more energy than days of normal operation. An unscheduled update that fires during a low-battery window can leave a device unable to complete the write. Treat OTA as a power event you plan for, the same way you plan sleep-current and duty cycle in the rest of your low-power battery device design.

• Gate updates on a battery threshold — refuse to start a download below, say, 40 percent so you never strand a device mid-write.
• Schedule transfers for when the device is likely charging or mains-powered, or when the radio is already awake for other reasons, rather than waking it solely to update.
• Prefer delta images specifically to cut radio-on time, which is the dominant energy cost of the whole operation.

Platform Options — Roll Your Own or Buy

You do not need to invent a bootloader from scratch, and you probably should not. Mature, audited options exist at every level, and the right pick depends on your MCU class and how much fleet-management tooling you want to own versus rent.

• MCUboot: the de-facto open-source secure bootloader for Cortex-M. Handles signing, A/B swap, anti-rollback, and power-fail-safe swaps. This is the sane default for bare-metal and RTOS MCU products.
• ESP-IDF OTA: Espressif's built-in A/B OTA with rollback and Secure Boot v2, tightly integrated with ESP32 flash encryption. Excellent if you are already on the ESP32 family.
• SWUpdate and Mender: for embedded Linux (i.MX, higher-end products), these handle full root-filesystem A/B updates and fleet orchestration.
• Managed services — Golioth, Memfault, and Particle — provide the cloud side: image hosting, cohort/staged rollout, device fleet state, and crash/observability telemetry, so you do not build a deployment dashboard from zero. Memfault in particular pairs OTA with the crash reporting you need to run a safe canary.

The Failure Modes That Brick Fleets

Almost every OTA disaster traces to one of a short list of omissions. If your design has all of these covered before you ship, you have done the hard part.

• No rollback path: a bad-but-signed image boot-loops and there is no known-good slot to fall back to.
• Unsigned or improperly verified images: the update channel becomes remote code execution.
• Bricking on power loss: a non-atomic write leaves a torn image and no recovery.
• No fleet staging: a regression ships to 100 percent instantly instead of being caught in a 1 percent canary.
• Forgetting OTA in the flash budget: A/B needs ~2x app space, and discovering that after board layout means external flash respins or a painful single-bank compromise.

Frequently Asked Questions

Do I really need A/B partitioning, or can I get away with single-bank to save flash?

You can ship single-bank if flash is genuinely scarce, but only if you stage the incoming image somewhere safe first — external SPI flash or a reserved region — and verify it fully before overwriting the running image, so a power loss during download does not touch the working firmware. Overwriting the live application in place with no staged copy is the pattern that bricks fleets. If you can afford the ~2x flash or add an external part, A/B is worth it every time.

How much does it cost to add OTA to a product?

If it is designed in from the start — bootloader, A/B layout, signing keys, and staged rollout — it is a few engineer-weeks of embedded work plus your cloud/management choice, and adopting MCUboot or ESP-IDF OTA removes most of the bootloader risk. Retrofitting it into a product that shipped without it is dramatically more expensive, because you may be fighting a flash layout, a locked bootloader, or fuses that were never provisioned for secure boot.

Can I add OTA security later and just ship the update mechanism now?

No. Signing and secure boot depend on keys and fuses being provisioned during manufacturing. If devices ship without a public key baked in and secure boot enabled, you cannot add a hardware root of trust in the field — an attacker can simply flash whatever they like. Signing must be there on the first unit off the line, even if delta updates and fancy staged rollout come later.

Building a Connected Product? Get OTA Right the First Time

OTA touches your flash budget, your MCU choice, your security architecture, your battery life, and your entire post-launch operations story — which is exactly why it has to be designed at the start, not bolted on. At inteRFace R&D we architect the full update path — bootloader, A/B partitioning, image signing and secure boot, power-fail-safe swap, and staged fleet rollout — as part of the hardware and firmware, so your first CVE is a routine push instead of a recall. If you are planning a connected product and want the update path designed in from day one, talk to an engineer at https://interfacernd.com/#contact.