What a safe update system needs
- An OTA system must survive power loss at any moment. Dual-bank or swap-based layouts with a confirmed-boot step make an interrupted update recoverable.
- Images must be signed and verified before they run. Without it, anyone who can reach the update channel controls your device.
- Rollback protection stops downgrade attacks that reinstall a known-vulnerable version.
- Regulation is moving this way. Many markets now expect devices to be updatable and to ship without default passwords, so an update path is becoming a compliance feature.
The building blocks
- Immutable first-stage bootloader that verifies the application before jumping to it.
- Digital signatures (for example ECDSA P-256 or Ed25519) so only your signing key can authorise firmware.
- Encryption of the image in transit and, where needed, at rest, to protect your intellectual property.
- Slot layout: primary and secondary slots, with swap or direct-execute from either bank.
- Confirmed boot: the new image must mark itself good after startup, or the bootloader reverts.
- Anti-rollback counters in protected storage.
We frequently build on MCUboot, an open-source bootloader supported on many Cortex-M parts, or on vendor equivalents, instead of writing a bootloader from scratch.
Delivery channels
| Channel | Notes |
|---|---|
| Wi-Fi / Ethernet over HTTPS or MQTT | Most common; pair with cloud device management |
| Cellular (LTE-M, NB-IoT) | Plan for data cost; use delta updates where possible |
| Bluetooth LE | Phone acts as the transport; slower, needs resumable transfer |
| LoRaWAN | Very low bandwidth; firmware-update-over-the-air (FUOTA) multicast support varies |
| Wired (UART, USB, CAN) | Factory and service updates |
Key management
Security rests on protecting the private signing key. We recommend keeping it in an HSM or a managed key service, separating development and production keys, and documenting how a key would be rotated or revoked. The device side stores only the public key, ideally in immutable memory or a secure element.
Testing an update system
We test by cutting power at random points during update, corrupting images, sending images signed with the wrong key, and replaying older versions. An update system that has only been tested on the happy path has not been tested. See also our firmware development service.
Sources and further reading
- MCUboot documentation — Open-source secure bootloader design and image format.
- PSA Certified — Platform security guidance for IoT devices.
- ESP-IDF Programming Guide — Secure boot, flash encryption and OTA on ESP32.
Last reviewed: October 2026. Regulations and product availability change; confirm current rules with the issuing authority before you commit to a design.