OTA Updates for IoT: The Safe Way to Ship Firmware

Quickstart

If you only implement a few things, implement these. They’re the highest-leverage choices that separate “OTA demo” from “OTA you can trust in the field”.

Overview

“OTA Updates for IoT: The Safe Way to Ship Firmware” is really about one thing: making firmware upgrades boring—predictable, reversible, and auditable. The hard part isn’t downloading a file over HTTP. The hard part is the edge cases: dead batteries, flaky LTE, flash wear, partial writes, incompatible config migrations, and attackers trying to install modified firmware.

Core concepts

1) OTA architecture (the three actors)

A reliable OTA system has three moving parts. Each has a clear job, and none should “trust” the others blindly:

2) Atomic updates: “don’t destroy the last good thing”

“Atomic” means the device is always in one of two states: old firmware fully intact or new firmware fully installed. Anything in-between must be recoverable after power loss.

3) Versioning: device reality beats semantic purity

Firmware versions exist for three practical reasons: targeting, debugging, and rollback/compatibility. You can use semantic versioning for human readability, but devices also need a monotonic number to compare versions safely.

4) Rollback: “trial boot” + confirmation

Rollback isn’t “install old firmware manually.” It’s a boot policy: new firmware boots in trial mode; it must confirm itself; otherwise the bootloader reverts automatically.

5) Security chain: TLS is not the whole story

You need two layers: transport security (protect data in flight) and update authenticity (prove the firmware is yours). Authenticity is typically done by signing a manifest (or the image) with a private key; the device verifies using a public key stored in a protected location (ideally in ROM, secure element, or the bootloader region).

Step-by-step

This is a practical, production-minded path you can adapt to almost any MCU/SoC and RTOS. The goal is not to copy a “one true OTA implementation”, but to adopt the invariants that make OTA safe.

Step 1 — Define constraints and failure modes

Step 2 — Choose flash layout (A/B is the safest default)

If you can afford it, use a dual-bank layout: keep two application images (slot A and slot B), plus a small bootloader region that never changes (or changes rarely and very carefully).

Step 3 — Implement boot policy (trial boot + auto-rollback)

The bootloader should be able to answer: “Which slot do I boot now, and when do I revert?” Below is a minimal slot-selection state machine. It assumes the application calls boot_confirm() only after health checks pass.

<!-- Minimal A/B boot policy (illustrative). Keep real bootloaders tiny + audited. -->
typedef enum { SLOT_A = 0, SLOT_B = 1 } slot_t;

typedef struct {
  slot_t active;            // currently preferred slot
  slot_t pending;           // slot requested for trial boot
  uint8_t trial_remaining;  // allowed trial boots before rollback
  uint32_t active_crc;      // integrity for this struct
} boot_state_t;

boot_state_t st = load_boot_state_with_crc();

/* Called by update agent after writing/validating the new image in the inactive slot. */
void request_trial(slot_t new_slot) {
  st.pending = new_slot;
  st.trial_remaining = 2;  // e.g., allow 2 attempts
  st.active_crc = crc32(&st, sizeof(st) - sizeof(st.active_crc));
  save_boot_state(st);
  reboot();
}

/* Bootloader entry: decide which slot to boot. */
slot_t select_slot(void) {
  if (!crc_ok(st)) {
    // If state is corrupted, fail safe: boot the default known-good (choose a policy that fits your device).
    return SLOT_A;
  }

  if (st.trial_remaining > 0) {
    st.trial_remaining--;
    save_boot_state(st);
    return st.pending; // trial boot
  }

  return st.active; // confirmed slot
}

/* Called by application after successful boot + health checks. */
void boot_confirm(slot_t running) {
  st.active = running;
  st.pending = running;
  st.trial_remaining = 0;
  st.active_crc = crc32(&st, sizeof(st) - sizeof(st.active_crc));
  save_boot_state(st);
}

/* Optional: application can explicitly fail to force rollback on next boot. */
void boot_fail(void) {
  st.trial_remaining = 0;  // stop trial attempts
  st.active_crc = crc32(&st, sizeof(st) - sizeof(st.active_crc));
  save_boot_state(st);
  reboot();
}

Step 4 — Define a signed manifest (device verifies before install)

The manifest is the “contract” between server and device: what version this is, which hardware it targets, where to download it, and how to verify it. Keep it explicit so the device can refuse unsafe installs.

version: "1.8.2"
build: "2026-01-09+sha.abc123"
product: "unilab-sensor-node"
hw_compat:
  - "revA"
  - "revB"
channel: "stable"
rollback_index: 10802         # monotonic, used for comparisons/anti-rollback policies
min_bootloader: 3             # refuse if bootloader is too old for this image
payload:
  url: "https://updates.example.com/unilab-sensor-node/1.8.2/firmware.bin"
  size: 524288
  sha256: "2f2c0d2a3b8f0b4a7c1e8a5c0a2d9e6e1b4a8d0d2b7e8c4f9a0b1c2d3e4f5a6b"
  slot: "inactive"            # A/B devices write to the inactive slot
policy:
  canary_percent: 5
  install_window_utc: ["01:00", "05:00"]
  battery_min_percent: 30
  require_mains_power: false
signature:
  alg: "ed25519"
  key_id: "prod-2026-01"
  sig_b64: "BASE64_SIGNATURE_OVER_CANONICAL_MANIFEST"

Two practical tips that prevent nasty surprises:

• Canonicalization: define exactly how the manifest is serialized for signing (field order, whitespace, encoding).
• Key rotation: include a key_id so devices know which public key to use; plan how you’ll rotate keys safely.

Step 5 — Implement the device update agent (resume, verify, switch)

The update agent runs in the application (or a privileged service). Its job is to make updates resilient and measurable: resume downloads, verify integrity, write to staging, and request a trial boot.

Here’s a simple “check + download + verify” flow you can adapt for test rigs or CI devices. The important part isn’t the tooling— it’s that verification happens before you switch slots.

#!/usr/bin/env bash
set -euo pipefail

MANIFEST_URL="https://updates.example.com/unilab-sensor-node/latest/manifest.json"
WORKDIR="/var/lib/ota"
mkdir -p "$WORKDIR"

echo "[ota] Fetching manifest..."
curl -fsSL "$MANIFEST_URL" -o "$WORKDIR/manifest.json"

# Example: verify signature using a pinned public key (details depend on your crypto tooling).
# In production, this should run on-device and reject unsigned/unknown keys.
echo "[ota] Verifying manifest signature..."
python3 - <<'PY'
import json, base64, sys, hashlib
# Placeholder: in real life you verify Ed25519/ECDSA signature with a pinned public key.
# This script demonstrates the *shape* of the workflow.
m = json.load(open("/var/lib/ota/manifest.json"))
assert "payload" in m and "sha256" in m["payload"]
print("[ota] manifest has required fields")
PY

PAYLOAD_URL=$(python3 -c 'import json; print(json.load(open("/var/lib/ota/manifest.json"))["payload"]["url"])')
EXPECTED_SHA=$(python3 -c 'import json; print(json.load(open("/var/lib/ota/manifest.json"))["payload"]["sha256"])')

echo "[ota] Downloading payload..."
curl -fSL "$PAYLOAD_URL" -o "$WORKDIR/firmware.bin"

echo "[ota] Verifying SHA-256..."
ACTUAL_SHA=$(python3 -c 'import hashlib; d=open("/var/lib/ota/firmware.bin","rb").read(); print(hashlib.sha256(d).hexdigest())')

if [[ "$ACTUAL_SHA" != "$EXPECTED_SHA" ]]; then
  echo "[ota] ERROR: hash mismatch (expected $EXPECTED_SHA, got $ACTUAL_SHA)" >&2
  exit 2
fi

echo "[ota] OK: payload verified. Next step: write to inactive slot + request trial boot."

Step 6 — Rollout controls and telemetry (the “fleet safety net”)

OTA problems rarely show up in the first device you test. They show up when you deploy to thousands of devices across networks, temperatures, and hardware tolerances. Rollout control is how you keep a bug from becoming a disaster.

Common mistakes

These are the patterns behind “we bricked a few devices” and “we can’t reproduce what happened.” The fixes are usually architectural, not cosmetic.

FAQ

Do I really need A/B slots for OTA updates?

Not always—but if you can afford the flash, A/B is the simplest way to make OTA updates power-loss safe. Without A/B, you must build a rock-solid recovery mode (and ensure it can recover from interrupted installs), which is harder than it sounds.

What’s the minimum security I should implement?

At minimum: a signed manifest (or signed image) verified on the device using a pinned public key, plus a hash verification of the downloaded payload. TLS is strongly recommended for transport, but authenticity should not depend on TLS alone.

How do I prevent installing the wrong firmware (wrong model / wrong hardware rev)?

Include explicit compatibility fields in the manifest (product ID, hardware revisions, minimum bootloader version), and make the device refuse anything that doesn’t match. Don’t rely on filenames or directory paths as “targeting”.

What should trigger “confirm” after a trial boot?

Confirm only after the device proves it is healthy: successful boot, critical peripherals initialized, watchdog stable, and (if applicable) network connectivity established. If your device can operate offline, define offline health checks too.

Are delta updates worth it for IoT?

Delta updates can be worth it when bandwidth is expensive (cellular) or updates are frequent, but they increase complexity. If you adopt deltas, keep a “full image” escape hatch and verify the reconstructed image exactly like a normal payload.

How do I test OTA safely before shipping to customers?

Run an OTA failure matrix: power-cut during download, power-cut during write, corrupted payload, wrong target manifest, and forced reboot loops after install. If you can’t reliably recover in the lab, you won’t recover in the field.

How do I handle fleet rollout without babysitting it?

Use staged rollout: canary to a small percentage, automatically ramp when health metrics look good, and pause automatically when failure rates exceed a threshold. The server should be able to blocklist a build without shipping a new one.

Cheatsheet

A scan-fast checklist for brick-proof OTA updates you can tape to your monitor.

Wrap-up

Safe OTA updates aren’t about fancy infrastructure—they’re about invariants: don’t destroy the last known-good image, verify what you install, treat new firmware as trial until proven healthy, and roll out slowly. If you implement A/B slots with trial/confirm/rollback, add signed manifests and hash verification, and ship with canary rollouts, you’re already ahead of most “first OTA” implementations.

Want to go deeper? Pair OTA with the messaging and power fundamentals that make IoT systems reliable: MQTT for fleet communication, BLE/Wi-Fi realities, and power optimization for devices that can’t always stay awake.

Related posts

• ESP32 Starter Guide: GPIO, Wi-Fi, and Real Projects
• MQTT Explained: The Message Bus Behind Many IoT Systems
• Bluetooth Low Energy Basics: Advertising, GATT, and Power
• Power Optimization in IoT: Sleep Modes and Battery Math
• Sensors 101: Noise, Calibration, and Real Signal Reading
• Home Automation Architecture: Local-First vs Cloud