Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
IoT & Embedded

Signed, Staged OTA Updates with Automatic Rollback for ESP32 Device Fleets

Build a self-hostable update system for small fleets of ESP32 devices that signs every firmware image, rolls updates out in stages, checks device health after each update and rolls back automatically when something goes wrong. Small IoT companies in Pakistan and elsewhere ship devices with no safe way to fix bugs in the field, or with update schemes that a single bad build can brick. The project applies the security ideas behind automotive update frameworks at a scale a startup can run.

Topics
Difficulty

Advanced

Needs a team, real planning, and a supervisor who knows the area.
Effort

2 semesters · 2 students

Deliverables

7 to ship

4 optional extras

Suggested stack

ESP-IDFESP32 secure boot and app rollbackECDSA signingGo or Python update serverMQTTPostgreSQLReact dashboard
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Firmware using dual app partitions so a new image is tried and confirmed before the old one is discarded
  • Signed images and signed update metadata, verified on the device before installation
  • A health check after boot (connectivity, sensors, watchdog) that confirms the update or triggers rollback
  • Staged rollouts: a canary group, then percentages of the fleet, paused automatically if failures exceed a threshold
  • An update server with device groups, release history and per-device status
  • Protection against downgrade and replay of old update metadata
  • A test bench of at least ten devices with deliberate bad builds, power cuts during updates and network drops

If you have time left

  • Delta updates to reduce download size over slow mobile connections
  • Threshold signing so no single compromised key can publish a release
  • Support for a second chip family using MCUboot
  • A command line tool for CI pipelines to publish releases

The problem: devices in the field that cannot be fixed safely

Many small companies now build connected devices: energy meters, tracking units, farm sensors, vending machines. Every one of them ships bugs. Without over-the-air (OTA) updates, fixing a bug means visiting every device. With a careless OTA scheme, one bad build can brick the whole fleet at once, or an attacker who reaches the update server can install their own firmware on every device.

Good update systems exist, but they are often tied to a particular cloud, priced per device, or aimed at Linux devices rather than microcontrollers. Small teams end up writing their own: an HTTP download and a reboot, with no signing, no staging and no way back.

What already exists and the gap

  • Espressif's ESP-IDF provides the building blocks: OTA partitions, app rollback and secure boot.
  • ESP RainMaker from Espressif, AWS IoT jobs and Memfault offer managed OTA with fleet management, tied to their own platforms.
  • Mender is an open source OTA system focused mainly on embedded Linux devices.
  • MCUboot is an open source secure bootloader for many microcontrollers.

The gap is a small, self-hostable system that combines signed metadata, staged rollouts and health-based rollback for microcontroller fleets, documented well enough for a small team to adopt and audit.

Inspiration

Kuppusamy and colleagues' paper "Uptane: Securing Software Updates for Automobiles" (escar Europe, 2016) adapted The Update Framework to vehicles, defending against compromised servers, freeze attacks that hide new updates, and rollback to vulnerable versions, through separate signing roles and signed metadata. Uptane is now a published standard. Your project applies a simplified version of those ideas to ESP32 fleets.

What you build

  • A developer builds firmware, signs it with an offline key and publishes a release to the server with a rollout plan.
  • The server offers the update first to canary devices, watches their health reports, then widens the rollout or pauses it.
  • Each device checks signed metadata, downloads and verifies the image, installs it to the spare partition, reboots, runs its health check and either confirms or rolls back.
  • The operator sees which devices run which version and why any rolled back.

The technically interesting part

  • Two layers of trust. Signing the image proves who built it; signing the metadata (which version, for which devices, valid until when) stops an attacker from replaying an old vulnerable release or hiding a new one. Implement both, with expiry and version counters.
  • Rollback that really works. Use ESP-IDF's pending verification state: the new image must confirm itself after passing health checks, or the bootloader returns to the old one. Test what happens when power fails at every stage.
  • Health checks. Decide what "healthy" means: connected to the broker, sensors reading sensible values, no watchdog resets for some minutes. A check that is too strict causes needless rollbacks; too loose lets bad builds through.
  • Staged rollout logic. Automatic pause on failure rate, with statistics that make sense for small groups.
  • Key management. Keep the root key offline, use a separate online key for metadata timestamps, and document how to rotate keys.

How to evaluate it

  • Fault injection: for bad builds (crash on boot, broken Wi-Fi, broken sensor), power cuts mid-update and network drops, how many devices end up on working firmware.
  • Security tests: attempt unsigned images, replayed old metadata, downgrade attempts and a modified image; all must be rejected.
  • Rollout behaviour: time to detect a bad build in the canary group and stop the rollout.
  • Overhead: flash and RAM use, update time and data usage per device.

Suggested plan

  • Weeks 1 to 4: ESP-IDF OTA basics, partition layout, first unsigned update.
  • Weeks 5 to 9: image signing, secure boot on a test device, rollback with health checks.
  • Weeks 10 to 14: server, signed metadata, device groups.
  • Second semester: staged rollouts, fault injection bench with ten devices, security tests, documentation and report.

Path to a product

Every IoT company needs safe updates, and many smaller ones prefer self-hosting for cost and data control. An open source core with paid hosting and support is a proven model in developer tools. The project shows a rare combination of embedded, security and DevOps skills, which IoT companies find hard to hire for.

Scope warning

Secure boot and flash encryption on the ESP32 can permanently lock a development board if misconfigured; practise on spare boards and read the documentation carefully. Do not write your own cryptography; use ESP-IDF and well-known libraries. Keep the first version to one chip family.

Learn what you need on Sefism

Get help with this idea

The hard parts are rollback that survives power cuts and a threat model you can defend. Tauseef can help you plan the fault injection bench and the security tests, and scope the system for two semesters. If you are new here, create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.