IllustrationA safe update needs a bootloader that recovers from a power cut mid-swap, a new image that must confirm itself before it is kept, and a version rule you can survive getting wrong. This guide compares what MCUboot, ESP-IDF and Zephyr document, as of October 31, 2026, and lists what to measure on your own board.
A bad over-the-air update is a fleet problem. One firmware image goes to every unit, so one mistake reaches every unit. This guide compares what the official MCUboot, ESP-IDF and Zephyr documentation says about power-cut recovery, confirming a new image, reverting, and downgrade protection. It then lists the pitfalls that follow from those documents and what to measure on your own board. For letting an AI agent drive bench instruments, see AI Hardware Debugging: Agents and Lab Instruments.
This is a design guide. We have not run tests for it, and no test result appears on this page. It contains no Duobay price. Everything below is based on the vendor pages linked in each row, as of October 31, 2026.
What do the three stacks document?
The table paraphrases each official page. Where a page does not cover a topic, the cell says so instead of filling the gap from memory.
| Question | MCUboot | ESP-IDF (ESP32 page) | Zephyr, using MCUboot |
|---|---|---|---|
| Recovery from a reset or power cut mid-update | The swap status region lets the bootloader recover if it restarts in the middle of an image swap. (MCUboot design page, as of October 31, 2026) | The otadata boot-selection data is kept in two flash sectors, to prevent problems if power fails while it is being written. (ESP-IDF OTA page, as of October 31, 2026) | The Zephyr page says its DFU support is directly compatible with MCUboot. It gives no swap detail, so read the MCUboot rows for the mechanism. (Zephyr DFU page, as of October 31, 2026) |
| Confirm step for a new image | If the new image is not confirmed, MCUboot performs a revert swap during the next boot. (MCUboot design page, as of October 31, 2026) | The new app must confirm its operability by calling esp_ota_mark_app_valid_cancel_rollback(). Otherwise it is rolled back on reboot. (ESP-IDF OTA page, as of October 31, 2026) | Not covered on the Zephyr page. The page defers to the MCUboot-with-Zephyr documentation, which we did not verify. (Zephyr DFU page, as of October 31, 2026) |
| Revert behavior | Reverts on the next boot when unconfirmed. The same page says a swap can also be made permanent directly, after which MCUboot never reverts. (MCUboot design page, as of October 31, 2026) | Rollback exists to keep the device working after the update. A new app gets a first-boot trial. (ESP-IDF OTA page, as of October 31, 2026) | Not covered on the Zephyr page. Check the MCUboot-with-Zephyr documentation. (Zephyr DFU page, as of October 31, 2026) |
| Downgrade protection | An optional step of image validation. The new image security counter is compared with the active security counter. (MCUboot design page, as of October 31, 2026) | Anti-rollback prevents rollback to an app with a security version lower than the one programmed in the chip eFuse. (ESP-IDF OTA page, as of October 31, 2026) | Not covered on the Zephyr page. Check the MCUboot-with-Zephyr documentation. (Zephyr DFU page, as of October 31, 2026) |
The MCUboot page calls the hardware-based downgrade check an optional step of image validation. It also describes a software-based variant, which this table does not cover. The ESP-IDF details come from the ESP32 page. Do not assume another chip family behaves the same way.
Which pitfalls follow from the documents?
These come from engineering reasoning about the facts in the table. None describes an incident at any company, and we do not cite specific recalls.
- An image that boots but is broken. Both stacks revert only when the new image is never confirmed. In ESP-IDF the app must call the confirm function. In MCUboot an unconfirmed image is reverted at the next boot. If your firmware confirms itself as soon as it starts, a build that boots and then fails to reach the network, the microphone or the model has already cancelled its own safety net. Put the confirm call behind a health check.
- Making a swap permanent at first install. The MCUboot page says a swap can be made permanent directly, after which MCUboot never reverts. That is a valid option for a factory image. Used for field updates, it removes the revert path for exactly the updates that need it.
- A security version that cannot be lowered. ESP-IDF anti-rollback compares against a security version programmed into the chip eFuse. The page notes that eFuse bits cannot go from 1 back to 0, and that on ESP32 the security version is limited to 32 bits, so it can be applied only 32 times. The page never says "irreversible", so this is our inference: a bad security-version bump shipped to the fleet could keep devices from ever running the older, working firmware.
- A counter that only moves one way, with no staged rollout. Combine the previous pitfall with an update that goes to every device at once, and a version mistake reaches the whole fleet before anyone sees it. A staged rollout limits how many devices can hit the problem before you stop it.
- Rollback that was never tested end to end. The docs describe the mechanism. They do not tell you that your partition layout, your confirm call and your power supply behave correctly together. The only evidence is a measurement on your own board, described below.
- Generalizing from one chip family. The ESP-IDF details above are from the ESP32 page. Another chip, or another bootloader configuration, can behave differently. Read the documentation for the exact part you ship.
- Large model or voice assets with no compatibility gate. If a model or voice file sits in its own partition and the application expects a matching version, an update that replaces one and not the other can produce a device that boots yet answers nothing. The sources above do not cover this case, so treat it as engineering reasoning. Give each asset a version, and have the health check verify that the pair matches before the image is confirmed.
How do you build a safe update path?
The documents suggest an order of defense. Each layer covers a different failure.
- Interrupted write. Use the bootloader's own recovery data (the swap status region in MCUboot, the two-sector otadata in ESP-IDF) and keep its partitions as the documentation lays them out.
- Image that boots but is wrong. Leave the new image unconfirmed until your health check passes. Decide what the check covers, for example network, storage, sensors and any model or voice asset.
- Image that never boots. Rely on the unconfirmed-image revert, and test that it triggers on a real reset.
- Old, vulnerable image coming back. Decide whether downgrade protection is worth its cost for your product. If you use a counter, treat each bump as a controlled release step.
- Everything at once. Stage the rollout so a problem stops at a small share of the fleet.
The first four items come directly from the vendor pages. The staging advice is our engineering judgment, and the sources do not specify how large a stage should be. Choose that from your own risk tolerance.
What should you measure on your own board?
The documents describe mechanisms. They do not tell you how your hardware, partition layout and power supply behave together. This is a measurement checklist. The pass line is yours to set from your product requirements, and you should record the basis for it. We have run none of these tests, and this page reports no results.
| What to measure | How to instrument or collect it | Raw data to record |
|---|---|---|
| Power cut during download | Switch board power with a controllable relay or bench supply. Trigger the cut at chosen points in the transfer. After each cut, restore power and watch the boot log. | Cut point and time, which image ran after restore, the boot-log lines seen, and the time to reach a working state. |
| Power cut during swap or slot switch | Toggle a spare GPIO at the start and end of the swap, and use it as the trigger for the power switch. Repeat around the boot-selection write. | Cut offset from the GPIO marker, which image the device ended on (old or new), and the full boot log. |
| Power cut during first boot of the new image | Cut power after the new image starts and before it confirms. Restore power and reset the board. | Cut time relative to first boot, whether the device reverted or recovered on the next reset, and which image it ended on. |
| Boots but fails the health check | Build a deliberately broken image that starts normally and then fails the check you chose, for example no network or no model asset found. Install it by the normal OTA path. | Whether the confirm call was withheld, whether the device reverted without a person touching it, and the elapsed time to revert. |
| Confirm timing | Log a timestamp at first boot of the new image and another at the confirm call. | Both timestamps for every boot, plus the watchdog and reset settings you rely on. |
| Security version or counter handling | Use sacrificial boards only, because eFuse writes cannot be undone. Install an image with a higher security version, then try to install the previous one. | Chip and bootloader configuration, security version before and after, the install result, and the boot log. |
| Asset and application mismatch | Install a model or voice asset of one version with an application of another, in both directions. | Both version identifiers, the health-check result, which set the device ended on, and the boot log. |
What should you settle before you choose an update design?
These are yes or no questions for your firmware team and for any partner who proposes an update design, including us. Any "no" marks something to resolve first. If an outside team writes your firmware, our buyer's guide to firmware development services covers the contract terms for source, signing keys and builds. For how firmware teams organize embedded programming, see Embedded Programming Workflow for Connected Device Firmware.
- Do we know which bootloader and version we ship, and where its documentation describes the confirm and revert behavior?
- Does the firmware confirm a new image only after a health check passes?
- Is there any code path that can make a swap permanent in the field?
- If we use an anti-rollback counter, does a named person approve each security-version bump?
- Do we know how many times the counter on our chip can be advanced?
- Have we cut power during download, swap and first boot on the real board and kept the logs?
- Have we installed a build that boots but fails its health check and watched it revert?
- Is the rollout staged, with a signal that stops it?
- Does a check confirm that each large asset in its own partition matches the application version?
- If we hire a development partner, do we know what firmware source, build instructions and software bill of materials they hand over?
Questions about OTA update safety
Does a bootloader with rollback make a bad update safe?
It gives you a mechanism, and your firmware has to use it correctly. Both documented examples revert only an image that was never confirmed, so a build that confirms itself too early defeats the protection. This page is a design guide with no test results.
Is anti-rollback a good idea for every product?
That is a product decision, and the sources do not decide it for you. The ESP-IDF page describes a security version programmed into the chip eFuse, and eFuse bits cannot go from 1 back to 0. Weigh the protection against the cost of a wrong bump, and try it on sacrificial boards first. ESP-IDF OTA page, as of October 31, 2026.
What does Zephyr add on top of MCUboot?
The Zephyr DFU page says it is directly compatible with MCUboot and points to the MCUboot-with-Zephyr documentation for detail. We did not verify confirm or swap behavior on the Zephyr page, so use the MCUboot design page for those. Zephyr DFU page, MCUboot design page, as of October 31, 2026.
Do you cite real recalls caused by bad updates?
No. We did not find a first-party public postmortem we could cite, and press reports are not primary sources. Every pitfall on this page is engineering reasoning drawn from the vendor documentation. It is not a description of an incident at any company.
Do you deliver firmware source on a Duobay project?
Firmware source and a software bill of materials are delivered to you, as described on our firmware page. Tell us about your device to discuss your update design.
If you want a second pair of eyes on your update design before it ships, tell us about your device. You can also read how we hand over firmware source and a software bill of materials on the firmware page.
Sources
All pages accessed October 31, 2026. Documentation changes, so re-read the pages before you rely on them. Quotes in our research notes came through a summarizing fetch, so confirm exact wording on the live pages.
- MCUboot, Design: https://docs.mcuboot.com/design.html (accessed 2026-10-31)
- Espressif, ESP-IDF OTA (stable, ESP32): https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/ota.html (accessed 2026-10-31)
- Zephyr Project, Device Firmware Upgrade: https://docs.zephyrproject.org/latest/services/device_mgmt/dfu.html (accessed 2026-10-31)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →