Every Way to Push OTA Updates to IoT Devices in 2026

The most expensive firmware bug isn’t the one you ship. It’s the one you can’t patch.

A single missed vulnerability in a device with no update path means a recall, a field service visit, or a product line you quietly discontinue and hope nobody notices. The EU Cyber Resilience Act now mandates security updates for connected products sold in Europe. IETF’s SUIT manifest standard is gaining real traction. The question isn’t whether your IoT product needs OTA updates; it’s which of the dozen-plus approaches you should actually pick.

MCUboot, ESP-IDF native OTA, Golioth, Memfault, Mender, hawkBit, AWS IoT, roll-your-own… the list keeps growing, and each option comes with trade-offs that aren’t obvious until you’re 3 months deep. Here’s the full map, organized into tiers, with a decision framework at the end so you can stop researching and start building.

The Foundations Every OTA System Needs

Before you pick any tool, make sure it covers these pieces. If it doesn’t, you’re building the gap yourself.

OTA Foundations Checklist:

• Secure bootloader with image verification
• Asymmetric key image signing (not symmetric, not “we’ll add it later”)
• A/B partitioning or rollback mechanism
• Defined transport layer (MQTT, CoAP, HTTPS, BLE)
• Version reporting from devices in the field
• Rollback tested before first production deploy

Every tool in this article handles some of these pieces. None of them excuse you from verifying all six are covered, even if that means bolting on something extra.

Tier 1: DIY and Bootloader-Level Approaches

Maximum control, maximum responsibility.

MCUboot is the de facto open-source secure bootloader for constrained devices. It works with Zephyr RTOS and Apache Mynewt, gives you image swap, cryptographic signing, and rollback out of the box. What it doesn’t give you: a server, a transport layer, fleet management, or a dashboard. You get the bootloader. Everything above it is your problem.

MCUboot is the right starting point if your team has strong embedded chops and you need fine-grained control over the update flow. If you’re building on Zephyr, the Hubble Zephyr reference application shows how MCUboot fits into a real device integration.

ESP-IDF native OTA is surprisingly capable for teams in the ESP32 ecosystem. Espressif’s built-in OTA APIs give you a simple HTTPS pull model: your device checks a server, downloads a signed image, validates it, and swaps partitions. For a single-product fleet of a few hundred devices, the ESP32 OTA tools built into the SDK can get you to production faster than most people expect.

Custom bootloaders still exist, but rolling your own in 2026 is almost always the wrong call. If you’re on exotic hardware with no MCUboot port and extreme size constraints, maybe. For everyone else, the security risk alone rules it out. Bootloader bugs are the kind you can’t fix remotely, because the bootloader is the thing that does the fixing.

Tier 2: Open-Source Frameworks and Self-Hosted Platforms

This tier sits between “bare bootloader” and “fully managed SaaS.” You get real fleet management, but you run the servers.

Eclipse hawkBit is an open-source update server that handles rollout campaigns, device registration, and artifact management. It speaks DDI (Direct Device Integration) protocol and has a web UI for managing deployments. Solid if you want an OTA update platform without vendor lock-in.

Mender.io has an open-source core with a commercial hosted tier. Its strongest story is Linux/Yocto: if you’re shipping a gateway or Linux SBC, Mender’s client is mature and well-documented. MCU support is growing but still trails the Linux side.

RAUC and SWUpdate are both Linux-focused update frameworks. RAUC does clean A/B partition management with cryptographic verification. SWUpdate is flexible, supports multiple update sources, and integrates with hawkBit as a backend. Both are production-proven on embedded Linux.

Pick this tier when you want more than a bootloader but don’t want to pay per-device SaaS fees, and you have someone on the team who can run and maintain a server. Fair warning: these frameworks assume Linux on the target in most cases, or at least a gateway architecture where the gateway runs Linux and proxies updates to constrained nodes.

Tier 3: Managed OTA Update Platforms

If your team is small (or just wants to ship faster), this is probably where you should start. Managed platforms handle the server, the dashboard, the rollout logic, and usually adjacent features like logging and device configuration.

Golioth is purpose-built for constrained MCUs. It’s Zephyr-native, which means if you’re already on Zephyr + MCUboot, the integration is tight. OTA is one piece of a broader SDK that includes logging, settings management, and device metrics. Golioth OTA shines for small teams that don’t want to stitch together 4 different services. Free tier available with device-count limits.

Memfault started as an observability and crash analytics platform, then bolted OTA on top. The result is an unusually powerful “update and monitor” loop: push a firmware update, then immediately see crash rates, reboot reasons, and performance metrics from the new version. Memfault OTA is a strong pick if post-deployment visibility matters as much as the update itself. Also has a free tier.

Particle couples hardware, cloud, and OTA into one tightly integrated stack. If you’re already using Particle hardware, the onramp is the easiest of any option here. If you’re not, the lock-in is real.

Arduino Cloud works for prototyping and small fleets. Limited, but improving. Don’t plan a 10,000-device deployment on it.

Foundries.io targets the Linux microPlatform space with secure OTA for more complex devices, managed Mender with extra security layers.

AWS IoT Device Management and Azure IoT Hub are enterprise-grade. They handle OTA as part of a much larger device management story. Powerful, but the complexity tax is steep. Better for large organizations with existing AWS/Azure commitments and a dedicated platform team.

Free tier with device-count limits

Picking the Right Approach: A Decision Framework

Walk through this tree based on your actual project constraints, not aspirational ones.

START: How many devices in your fleet?
  |
  +--< 10 (prototyping)
  |     --> ESP-IDF native OTA or Arduino Cloud
  |
  +-- 10 to 1,000
  |     --> Do you have DevOps capacity?
  |           |
  |           +-- Yes --> hawkBit / Mender self-hosted
  |           +-- No  --> Golioth / Memfault / Particle
  |
  +-- 1,000+
        --> What's your hardware?
              |
              +-- Constrained MCU --> Golioth or Memfault
              +-- Linux-based    --> Mender / Foundries.io / AWS IoT
              +-- Mixed fleet    --> AWS IoT / Azure IoT Hub

The tree is a starting point. Four variables refine the decision:

Fleet size. Under 10 devices? Keep it simple. Under 1,000? You can probably get away with a managed platform’s free tier. Over 1,000? Per-device pricing starts to matter, and you’ll want a real firmware update service with staged rollouts and automatic rollback triggers. Over 100,000? You need dedicated infrastructure, whether self-hosted or enterprise cloud.

Hardware target. Bare-metal MCUs (nRF52, STM32, ESP32) point you toward MCUboot + a managed platform like Golioth or Memfault. Linux SBCs and gateways open up Mender, RAUC, SWUpdate. Mixed fleets (gateways talking to constrained nodes) often land on AWS or Azure because they handle heterogeneous device types.

Team bandwidth. Solo dev or team of 2? A managed platform will save you months. Team of 5+ with someone who enjoys running Kubernetes? Self-hosted options become viable. Most teams overestimate their capacity to maintain OTA infrastructure.

Compliance needs. Hobby project? Image signing is still smart but nobody’s auditing you. Commercial product? You need signing, and the EU CRA means you need a documented update process. Medical or automotive? You probably need a platform with audit trails, staged rollouts, and compliance documentation. Managed platforms tend to handle this better out of the box.

If you’re a small team shipping your first product, start with a managed platform. You can always migrate to self-hosted later. You can’t un-brick devices in the field. For BLE-connected devices specifically, the Hubble device SDK handles the transport layer so you can focus on your application firmware.

Pitfalls That Brick Devices (and Careers)

Not testing rollback before shipping. If you haven’t deliberately pushed a bad image to a test device and watched it recover, you don’t have rollback. You have an untested assumption.

Who updates the updater? If your bootloader has a vulnerability and you can’t update it remotely, you’ve got a permanent hole. Plan the bootloader upgrade path before you ship.

Ignoring bandwidth constraints. Delta updates (sending only the diff, not the whole image) matter enormously on cellular or satellite connections. A 200KB full image costs roughly $0.02 to transmit. A 12KB delta patch costs a fraction of a cent. Across a fleet of 50,000 devices, that difference adds up to thousands of dollars per update cycle.

Skipping code-signing because “we’ll add it later.” You won’t. And when you finally do, migrating devices already in the field to a signed update chain is painful.

30 days after a deploy, do you know what’s running? Pushing firmware into the void and assuming it worked is how you end up with 15% of your fleet running a version you deprecated 6 months ago. Pair your OTA pipeline with observability. Even something as simple as version reporting through your cloud integration closes this gap.

What to Build Into Your Requirements Doc Today

The IoT OTA update space in 2026 breaks into three tiers: DIY bootloaders for maximum control, open-source frameworks for self-hosted fleet management, and managed platforms for speed.

Pick based on your real constraints: fleet size, hardware, team bandwidth, compliance requirements.

If you’re unsure, start managed. The switching cost to self-hosted later is real but manageable. A half-baked update system compounds its cost every day those devices sit in the field.

Hubble Network connects your devices from anywhere on Earth via Bluetooth—no gateways, no extra infrastructure. See how it works →