Concept renderPublic documentation splits secure boot into several controls. MCUboot checks that an image was signed with a key matching the embedded KEYHASH TLV and calls one validation step optional. ESP-IDF says read-protected keys must be burned before Secure Boot is enabled. NIST SP 800-193 calls for mechanisms that detect corrupted platform firmware.
Secure boot is several controls, and some of them are optional or order-dependent. This guide compares what three public sources say, then lists what to measure and what to ask. It summarizes documentation and reports no test results.
Fuse and option-byte writes can be permanent. For any register or fuse, follow the vendor document for your exact part.
What do the sources actually say?
Six facts carry this article. Each row gives the statement, the quoted line from the source and the link. All pages were read on October 31, 2026. The ESP-IDF page is the versioned "stable" documentation, so re-read it for your release.
| Topic | What it means for a schedule | Quoted line | Source |
|---|---|---|---|
| Signature check against the KEYHASH TLV | MCUboot checks that the image was signed with a private key that corresponds to the embedded KEYHASH TLV. | MCUboot design page: "the bootloader verifies that an image was signed with a private key that corresponds to the embedded KEYHASH TLV." | MCUboot design documentation, as of October 31, 2026 |
| An image validation step is optional | MCUboot describes one step of its image validation process as optional. Check which validation steps your build enables. | MCUboot design page: "It is an optional step of the image validation process." | MCUboot design documentation, as of October 31, 2026 |
| Key digest in eFuse, later images must match | ESP-IDF Secure Boot v2 stores a key digest in eFuse. Later bootloaders and apps must be signed with a matching key. | ESP-IDF page: "Any updated bootloader or app will need to be signed with a key matching the digest already stored in eFuse." | ESP-IDF Secure Boot v2 (stable), as of October 31, 2026 |
| Order of operations for read-protected keys | ESP-IDF says read-protected keys must be burned before Secure Boot is enabled. | ESP-IDF page: "After Secure Boot is enabled, further read-protection of eFuse keys is not possible." | ESP-IDF Secure Boot v2 (stable), as of October 31, 2026 |
| Detecting corrupted firmware | NIST SP 800-193 calls for mechanisms that detect when platform firmware code and critical data have been corrupted. | NIST SP 800-193: "Detection: Mechanisms for detecting when Platform Firmware code and critical data have been corrupted." | NIST SP 800-193, as of October 31, 2026 |
| Rollback can restore a vulnerable image | NIST SP 800-193 names unauthorized rollback as a risk, so a device that supports rollback needs controls. | NIST SP 800-193: "unauthorized rollback could allow an attacker to restore a vulnerable firmware image" | NIST SP 800-193, as of October 31, 2026 |
Which controls does a secure boot plan have to cover?
The table lists each control with what the sources say and the question to answer for your part. One ordering rule quoted here comes from ESP-IDF: read-protection of eFuse keys is not possible after Secure Boot is enabled, so set it first. For the full order on your part, use the vendor document.
| Control | What the sources say | Question to answer |
|---|---|---|
| Signing key and key hash | MCUboot: the image must be signed with a private key that corresponds to the embedded KEYHASH TLV. ESP-IDF: later bootloaders and apps must match the digest already in eFuse. | Who holds the signing key, and where is the hash stored? |
| Read-protected eFuse keys | ESP-IDF: read-protected keys must be burned before Secure Boot is enabled, because afterwards read-protection is not possible. | Which keys are read-protected, and are they all written before the Secure Boot enable write? |
| Enabling Secure Boot | ESP-IDF: once enabled, later images must match the stored digest, and further read-protection of eFuse keys is not possible. | What must already be written before this step? |
| Flash encryption and debug port | This article does not quote guidance on flash encryption or the debug port. Settle both against the vendor document for your part. | Which flash-encryption and debug-port settings does the vendor document require, and in what order relative to the Secure Boot enable write? |
| Rollback protection | MCUboot: one step of image validation is optional. NIST SP 800-193: unauthorized rollback could restore a vulnerable image. | Is the rollback check switched on in our build? |
| Detecting corruption | NIST SP 800-193: platform firmware needs mechanisms that detect corrupted code and critical data. | What detects a corrupted image on our device? |
Quoted source statements are as of October 31, 2026. Sources: MCUboot design, ESP-IDF Secure Boot v2, NIST SP 800-193. Fuse and option-byte writes can be permanent, so follow the vendor document for your exact part.
What should you test on your own board?
The sources do not describe how your board behaves with your bootloader and your fuse settings. This list says what to measure, how to capture it and what to record. Use a board configured like production.
| What to test | How to instrument or capture | Raw data to record |
|---|---|---|
| Unsigned image is refused | Build an image without a valid signature and try to boot it on a locked board. Capture the boot log and the serial output. | Board identifier, image hash, signing state, full boot log, the result you observed |
| Wrong-key image is refused | Sign an image with a key whose hash was not provisioned, then try to boot it. Capture the boot log. | Key identifiers used for signing and provisioning, image hash, boot log, result |
| Older signed image is refused | After an update raises the version, try to load the older signed image. Read the counter value before and after. | Counter value before and after, version of each image, boot log, result |
| Debug access is closed | On a locked production-configuration board, try to attach a debugger with the tools you use in development. Record the tool and the reply. | Debugger model and software version, connection log, state of each debug-related setting read back |
| Flash contents are protected | Dump the external or internal flash from a locked board and inspect the dump for readable strings and known code patterns. | Dump method, dump size, what you searched for, what you found |
| Recovery after a failed update | Cut power at several points during an update and during first boot. Capture what the device boots into afterward. | Point of interruption, number of runs, boot log after each run, whether the device ran a valid image |
| Provisioning record matches the unit | Read back the programmed key hash and counter settings from finished units and compare them with the record. | Unit serial, value read, value in the record, who ran the check and with which script version |
What should you ask before you commit?
Take this list to your firmware team, and to any supplier who offers to set up secure boot for you.
- Who holds the signing key today, and what happens to updates if that person or system is unavailable?
- Is the signing key in an HSM or behind a remote signing service, or is it a file on a laptop?
- Which of our fuse or option-byte writes are permanent, and where does the vendor document say so?
- Do we burn read-protected keys before we enable Secure Boot, in the order the vendor document requires?
- Is the rollback counter scheduled, and what version scheme feeds it?
- How will we recover a field unit after a failed update, and have we tested that path on a locked board?
- Which MCU families are we shipping, and has someone fetched the vendor document for each one?
- Where is the provisioning record kept, and who may change it?
- Does the vendor document describe how to replace a signing key, and where?
Questions about secure boot and signed firmware
Does signed firmware protect against rollback?
Only if your build includes a rollback check. MCUboot's design page calls one step of image validation optional, so confirm which steps your build enables. NIST SP 800-193 says unauthorized rollback could let an attacker restore a vulnerable firmware image. MCUboot design, NIST SP 800-193, as of October 31, 2026.
Why does the order of fuse steps matter?
On ESP-IDF, read-protection of eFuse keys is not possible after Secure Boot is enabled, so read-protected keys must be burned first. That is one documented ordering constraint. Other MCU families may differ, so read the vendor document for yours. ESP-IDF Secure Boot v2, as of October 31, 2026.
Can Duobay set this up for my product?
Tell us about your device, or read about our firmware approach.
To discuss your device, tell us about it. You can also read how our engineering gates run.
Sources
All pages accessed October 31, 2026. Documentation changes between releases, so re-read the version that matches your toolchain.
- MCUboot, Design: https://docs.mcuboot.com/design.html (accessed 2026-10-31)
- Espressif, ESP-IDF Secure Boot v2 (stable): https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html (accessed 2026-10-31)
- NIST, SP 800-193 Platform Firmware Resiliency Guidelines: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf (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 →