InteopleA connected product is never finished. There will be bugs to fix, security patches to push, and features to add — across devices already installed in homes, clinics, factories and fields. Over-the-air updates are how you do that without sending a technician. They're also, done wrong, the single most dangerous code path in the whole system: a remote channel that replaces the software running on hardware you can't physically reach.
We build embedded systems on platforms like
ESP32 and STM32, running
FreeRTOS, talking to the cloud over
MQTT. OTA is where we spend a disproportionate
amount of our engineering care, because everything else depends
on it.
Why OTA is the highest-stakes feature
Think about what an update mechanism actually is: a way to make a device download and execute new code. If an attacker can impersonate your update server, or slip a modified image past your checks, they don't compromise one device — they compromise every device that trusts that channel. And if a legitimate-but-buggy update bricks the device before it can receive the fix, you've turned a software defect into a hardware loss.
The two failure modes of OTA are equally fatal: an update an attacker can forge, and an update you can't take back.
Sign everything, trust nothing
Every firmware image is cryptographically signed before it leaves our build pipeline. The device holds the corresponding public key — provisioned at manufacture, stored where it can't be rewritten — and refuses to install any image whose signature doesn't verify. The transport is encrypted (TLS), but transport security is not enough on its own: we verify the image itself, so a compromised CDN or a man-in-the-middle still can't get malicious code to run.
- Image signing with a private key that never leaves a hardware security module.
- Secure boot so the device only executes verified code, all the way from the bootloader.
- Anti-rollback counters so an attacker can't force a downgrade to an old, vulnerable version.
- Per-device identity so the backend authenticates which device is asking, not just that someone is.
A/B partitions and atomic flips
The cardinal rule: never overwrite the running firmware in place. We use dual (A/B) partitions. The device runs from slot A while the new image is written and verified into slot B. Only once the image is fully downloaded and its signature checked does the bootloader flip to slot B on the next reboot. The update is atomic — the device is always running a complete, valid image, never a half-written one.
If power drops mid-download — which, in the field, it will — the device simply keeps running slot A. Nothing is lost. The interrupted download resumes later.
Staged rollouts and rollback
Even a signed, atomic update can contain a bug that only shows up on real hardware. So we never ship to the whole fleet at once. Updates roll out in waves — a small canary group first, then widening cohorts — with health telemetry watched at each stage.
- Canary first — a fraction of devices take the update while we watch crash rates, connectivity and key metrics.
- Health-gated promotion — the rollout only widens if the canary stays healthy.
- Automatic rollback — a device that fails to boot or check in after an update falls back to the last known-good slot on its own.
- A kill switch — we can halt a rollout instantly the moment telemetry turns bad.
Key takeaways
- OTA is the highest-stakes path in any connected product — engineer it first.
- Verify the image, not just the connection: sign firmware and use secure boot.
- A/B partitions make updates atomic and power-loss safe.
- Roll out in waves, gate on health telemetry, and make rollback automatic.
- Anti-rollback protection stops forced downgrades to vulnerable versions.
Surviving the field
Devices live in hostile conditions: flaky networks, metered bandwidth, unreliable power, and years of uptime between human visits. That shapes every OTA decision. Images are delta-compressed so an update is kilobytes, not megabytes. Downloads resume rather than restart. Devices report their firmware version and update status back to a fleet dashboard, so we always know exactly what's running where — and can prove it.
Get this right and a connected product gets better after it ships: patched against new threats, improved with new features, and recoverable when something goes wrong — all without anyone driving out to touch it. That's the difference between an IoT product and an IoT liability.
