Blogs

The OTA Update: How to Ship Firmware to Production

Over-the-air firmware updates are non-trivial. The architecture for delivering bits to a fleet of devices safely.

Dec 09, 2025 4 min

Shipping software once is easy. Shipping firmware to a hundred thousand devices in the field is a discipline.

Every IoT product needs OTA updates. Few teams understand how much engineering goes into doing it safely. A bad OTA can brick a device permanently — and unlike a phone app, you cannot ask the user to plug it into their laptop and reflash.

The dual-bank architecture

The fundamental pattern: two firmware slots in flash. Update writes to the inactive slot, validates it, then atomically swaps active and inactive on next boot. If the new firmware fails to start, the bootloader rolls back to the previous slot. This requires the chip to have ~2x the flash you need for one firmware image.

Cryptographic signing is mandatory

Every firmware image is signed with your factory-issued private key. Every device verifies the signature before flashing. Without this, an attacker who obtains an OTA endpoint can flash arbitrary firmware. The signing infrastructure (HSM, signing service, audit log) is its own project.

Delta updates save bandwidth

For devices on cellular or constrained networks, sending the full firmware image (typically 256KB-2MB) is expensive. Delta updates compute a binary patch from the device's current version to the target. Done right, the patch is 10-50x smaller than the full image.

Phased rollout

Never push a new firmware to 100% of the fleet at once. Roll to 1%, then 5%, then 25%, then 100% over hours or days. Monitor crash rates and connectivity loss. If anything regresses, stop the rollout and investigate. This is feature flags, applied to firmware.

The recovery path

What happens when a device's update fails? The bootloader rolls back. What if both slots are corrupted? You need a recovery partition or a USB / serial reflash path. What if the user is in a remote area without WiFi? Schedule retries with exponential backoff.

Backend infrastructure

The OTA service has its own architecture: artifact storage (S3 or similar), versioning service, device-to-version mapping, rollout policies, telemetry ingestion. Memfault, Mender, and AWS IoT Device Management each productize this; building it yourself is a sprint of work.

What we ship

For client IoT projects, we install MCUboot as the bootloader, signed images via the project's HSM, delta updates via Mender, and a phased rollout policy. Every project goes through a "deliberately fail an OTA" test before launch. The discipline pays for itself the first time it does.