TL;DR:

  • Over-the-air firmware updates are a security requirement, not just a convenience — unpatched IoT fleets are a primary attack vector in 2026
  • The main platforms (Mender, Balena, AWS IoT Jobs, Azure Device Update) each suit different scale and complexity profiles
  • Key patterns: staged rollouts, A/B partition updates, automatic rollback on failure, and delta updates for bandwidth-constrained devices

Here’s a scenario that’s become depressingly common: a company deploys 2,000 IoT devices across customer sites. Eighteen months later, a critical firmware vulnerability is discovered. The devices are running custom Linux builds with no automated update mechanism. Updating each one requires a field visit or a manual process that takes 45 minutes per device. The fleet never gets fully patched.

This is a real problem at scale, and it’s getting worse. The growth in deployed IoT devices, combined with increasingly capable threat actors targeting embedded systems, means that an IoT fleet without a reliable OTA update mechanism is an unmanaged liability. The question in 2026 isn’t whether you need OTA updates — it’s which approach fits your architecture.

Why OTA updates are harder than they sound

A few things make IoT firmware updates genuinely difficult compared to software updates on managed servers or endpoints:

Device heterogeneity. Real fleets have multiple hardware revisions, processor architectures, and storage configurations. An update that works on your newest hardware might brick your three-year-old units.

Unreliable connectivity. IoT devices often run on constrained networks — cellular with data caps, low-bandwidth LPWAN links, or intermittent Wi-Fi. Update payloads need to be small or restartable; full image transfers that can’t resume on connection drop are impractical.

No rollback by default. Unlike a web deployment, a bad firmware update on a field device might leave it unresponsive. Without explicit rollback mechanisms, a failed update means a brick — and a truck roll.

Security of the update channel itself. An OTA update mechanism that doesn’t verify cryptographic signatures is itself an attack surface. Your update pipeline needs to be at least as secure as the firmware it delivers.

The update strategies worth knowing

A/B partition updates are the most reliable approach for Linux-based devices. The device has two root filesystem partitions — A and B. Updates write to the inactive partition. When the update completes and verifies successfully, the bootloader switches to the new partition. If the device fails to boot or a watchdog fires, it falls back to the previous partition automatically. No successful update required before rollback is available.

This is the approach used by Android updates and most mature industrial IoT platforms. The cost is doubled storage requirements — viable on modern hardware, a constraint on older or very low-cost devices.

Delta updates address the bandwidth problem. Rather than sending a full firmware image, delta update tools compute a binary diff between the current and target firmware and transmit only the changed bytes. Tools like bsdiff, xdelta3, or Mender’s delta update feature can reduce update payload sizes by 70–90% for incremental releases. For cellular-connected devices with per-MB data costs, this makes the economics viable.

Staged rollouts are how you avoid bricking your entire fleet at once. Push updates to 1% of devices first. Monitor error rates, watchdog trips, and connectivity metrics. Expand to 10%, 50%, 100%. Most enterprise OTA platforms support configurable rollout stages and automatic pause on elevated error rates.

Comparing the main platforms

Mender (open-source, self-hosted or managed) is one of the most widely deployed OTA platforms for Linux-based IoT. Built around the A/B partition model, it handles the full update lifecycle from image creation through deployment and rollback. The managed (Mender.io hosted) tier is viable for smaller fleets; larger deployments typically self-host. Strong support for Raspberry Pi, Yocto, and Debian-based images. Delta updates available on professional tiers. If you’re running Linux devices and want a mature open-source foundation, Mender is the standard starting point.

Balena combines container-based deployment with device management. Devices run BalenaOS (a minimal Linux host) and your application runs in Docker containers. Update the container image, it gets pushed to devices over encrypted connections, and rollback is handled at the container level. Better developer experience than traditional firmware OTA; slightly more overhead per device. Good fit for devices with enough compute to run Docker comfortably (Raspberry Pi class and above).

AWS IoT Jobs provides OTA update orchestration for fleets already integrated with AWS IoT Core. Not an update mechanism in itself — it orchestrates the scheduling and tracking of updates that your device firmware downloads and applies. Works well as part of a broader AWS IoT architecture; requires more integration work to build a complete solution compared to Mender or Balena.

Azure Device Update for IoT Hub is Microsoft’s equivalent — orchestration and tracking for devices on the Azure IoT Hub platform. Import-compatible manifest system, decent integration with Azure Monitor for update status dashboards. Straightforward if you’re already committed to Azure IoT.

What a reliable update architecture looks like

The combination that survives contact with production is: A/B partition updates + cryptographically signed payloads + staged rollout with automatic pause + delta updates where bandwidth matters.

Add to this: a monitoring system that tracks boot partition state, update completion rates, and watchdog resets across your fleet. An update that silently fails on 5% of devices is easy to miss without explicit tracking.

The governance piece that’s often skipped: a defined process for who approves update releases, how test devices are selected, and what success criteria look like before expanding a staged rollout. This doesn’t need to be bureaucratic — even a simple checklist and a sign-off from two engineers catches most disasters before they affect the full fleet.

As IoT security requirements tighten (ETSI EN 303 645 in Europe, the UK Product Security and Telecommunications Infrastructure Act coming into full force), demonstrable patch management capabilities are becoming a compliance requirement as well as a practical necessity. Building a capable OTA infrastructure now is less painful than retrofitting one under regulatory pressure.