OTA Firmware Updates in IoT: Challenges, Realities & Best Practices
Updated: 14 hours ago
OTA updates are how a deployed device gets bug fixes, security patches and new features without a site visit. They are also one of the riskiest operations a device performs, because a failed update can leave it unable to boot. The design goal is simple to state and hard to meet: an update must never leave a device unrecoverable.
Anatomy of an OTA system
Component | Job |
Build and signing | Produces the image and signs it with a private key kept in an HSM or similarly protected store |
Update server | Hosts images and manifests and controls which devices get which version, and when |
Update agent | Runs on the device, checks for updates, then downloads and stores the image |
Bootloader | Verifies the signature, switches to the new image, and falls back if it fails |
Health check and rollback | Confirms the new image works after boot, and reverts if it does not |
| Component | Job | |---|---| | Build and signing | Produces the image and signs it with a private key kept in an HSM or similarly protected store | | Update server | Hosts images and manifests and controls which devices get which version, and when | | Update agent | Runs on the device, checks for updates, then downloads and stores the image | | Bootloader | Verifies the signature, switches to the new image, and falls back if it fails | | Health check and rollback | Confirms the new image works after boot, and reverts if it does not |
Choose an update layout early
Dual bank (A/B). Two image slots: the device runs one and writes the other. This is the safest layout, but it needs roughly twice the flash.
Single bank with external staging. The new image is downloaded to external flash, verified, then copied in by the bootloader. It needs an external flash part, and the copy step must survive power loss.
Swap with a scratch area. Used by bootloaders such as MCUboot, which can swap slots and revert if the new image is not confirmed.
Delta updates. Send only the difference between versions, for example with bsdiff. This saves bandwidth, but the device must hold exactly the base version the delta expects.
The layout decides how much flash you reserve, so settle it before the hardware design is frozen.
Security
An update channel is also an attack path, so treat it as one.
Sign every image (ECDSA P-256 and Ed25519 are common) and verify the signature in the bootloader before running anything. Keep the signing key off build servers.
Use an immutable first-stage verifier, so a bad update cannot disable the check.
Protect the transport with TLS or DTLS, and authenticate the device as well as the server.
Add an anti-rollback counter, so an attacker cannot install an older, vulnerable version.
Use a standard manifest where you can. The IETF SUIT architecture, described in RFC 9019, defines one for constrained devices.
Constrained and costly networks
LoRaWAN, NB-IoT and cellular links make large images slow or expensive. Practical measures:
Download in chunks with resume and retry. On constrained IP networks, CoAP block-wise transfer (RFC 7959) is designed for this.
Send deltas and compress them (for example with heatshrink or LZMA, depending on the RAM available).
Verify the hash of the whole image before applying it, not just each chunk.
Where the network supports it, use multicast or a gateway cache so one download serves many devices.
Battery-powered devices
Schedule update checks inside normal wake windows.
Refuse to start an update below a battery threshold. A flash write that loses power halfway is the classic way to brick a device.
Budget the energy cost of the download, the flash erase and write, and the reboot.
Where you store staging data, use a flash-friendly filesystem such as LittleFS to limit wear.
Validate like the field will
A faulty rollout can fail thousands of devices at once. Test at least:
Power loss at every stage of download, write and swap
A corrupted or truncated image
A wrong or missing signature
A downgrade attempt
Low battery at the start of an update
Every hardware variant and flash size you ship
Then roll out in stages, starting with a small percentage of devices. Watch telemetry, and halt automatically when failures appear. After the first boot, require the new firmware to confirm itself, and let the bootloader revert if it does not.
Checklist
Update layout chosen and the flash budget agreed with hardware
Images signed, and the signature verified before execution
Rollback and anti-rollback in place
Resumable, verified downloads
Battery and connectivity checks before updating
Failure tests run for every stage
Staged rollout with automatic halt
Written by Vijay Kumar Sanugondla, Embedded Engineer, Eurth Techtronics.
Need an OTA pipeline designed for your device? Write to connect@eurthtech.com or see www.eurthtech.com/solutions.
Comments