How Do You Enable ESP32 Secure Boot and Flash Encryption for Production?

Detailed Explanation

Every commercial ESP32 product eventually has to answer two related but distinct security questions: can someone run unauthorised firmware on a shipped unit, and can someone extract this unit's legitimate firmware to read or clone it? ESP-IDF answers these with two independent mechanisms — Secure Boot V2 and Flash Encryption — both configured through the project's build settings and both activated by burning eFuse bits that are permanent once set in production (Release) mode. This page covers what each mechanism actually protects against, how they're enabled, and the irreversible eFuse decisions that need to be finalised before first production flash. For the broader ESP-IDF vs Arduino framework decision this sits inside, see ESP-IDF vs Arduino for ESP32 — both security features require ESP-IDF; Arduino-ESP32 does not expose them.

Secure Boot V2: Verifying Firmware Authenticity

Secure Boot V2 cryptographically verifies that only firmware signed with an authorised private key can run on the device. The mechanism, at a high level:

1. An RSA key pair is generated (offline, kept secure — this is the single most important artefact in the whole scheme).
2. The public key's digest is burned into eFuse during the first secure-boot-enabled flash.
3. Every bootloader and application image is signed with the private key before being flashed or delivered as an OTA update.
4. On every boot, the ROM bootloader verifies the second-stage bootloader's signature against the eFuse-stored public key digest, and the second-stage bootloader in turn verifies the application image's signature before jumping to it.

If either signature check fails — a corrupted image, or one signed with the wrong key — the boot process halts rather than running unauthorised code. This closes the attack path where someone with physical or update-channel access tries to run modified or entirely different firmware on a unit that isn't theirs.

Flash Encryption: Protecting Firmware Confidentiality

Flash Encryption is a separate mechanism that solves a different problem: even with Secure Boot preventing unauthorised firmware from running, the legitimate firmware sitting in external flash is still readable in plaintext by anyone who desolders the flash chip (or the module, on some designs) and reads it on a programmer. Flash Encryption addresses this by encrypting flash contents with an AES key that is itself generated on-chip and burned into eFuse — a key that never leaves the chip and is not visible to any external programmer or debug interface once encryption is enabled. Reads and writes are transparently encrypted and decrypted by dedicated hardware, so application code does not need to handle encryption explicitly; a flash dump from an encryption-enabled chip yields ciphertext.

Development Mode vs Release Mode

Both features have a Development Mode and a Release Mode, and the distinction matters for how you actually bring a product through the design cycle:

• Development Mode allows the key digest (Secure Boot) or the flash encryption key (Flash Encryption) to be re-flashed, letting you iterate on firmware and debug the boot chain without burning yourself into a corner during bring-up.
• Release Mode burns additional eFuse bits that permanently disable further changes — the Secure Boot key digest can no longer be updated, and Flash Encryption's key-regeneration path is disabled. This is the mode a shipping product actually needs, but it is the point of no return: verify the entire signing pipeline, key storage process, and OTA update flow in Development Mode first, on units you're prepared to lose if something goes wrong.

Enabling Both Features

Both are configured through idf.py menuconfig, under Security features, before building the bootloader and application images for a production flash. Key generation, the signing step in the build/release pipeline, and eFuse burning are typically integrated into a factory provisioning script rather than performed manually per unit — see Espressif's Secure Boot V2 and Flash Encryption documentation for the exact idf.py commands and eFuse fields involved, which vary somewhat between the original ESP32 and the S2/S3/C3 and later variants.

Interaction with OTA Updates

Both mechanisms remain compatible with OTA firmware updates: Secure Boot requires every OTA image to be signed with the same private key the device was provisioned with (an unsigned or wrongly-signed OTA image is rejected at boot, the same as at initial flash), and Flash Encryption transparently encrypts an OTA image as it's written to its target partition — the update mechanism itself doesn't need to implement encryption or signature-checking logic beyond what ESP-IDF's OTA and bootloader components already provide.

Design Considerations

• Treat key generation and storage as the actual security-critical step, not the eFuse burning itself. Secure Boot's entire guarantee depends on the private signing key never leaking. A key generated on a shared build server without hardware-backed storage or access control undermines the protection regardless of how carefully the eFuse provisioning is executed.
• Always validate the full pipeline in Development Mode on scrap units first. Because Release Mode's eFuse changes are permanent, any mistake in the signing process, key digest, or provisioning script needs to be caught before it's run against real production hardware.
• Decide whether you need one feature or both, based on an actual threat model. Secure Boot alone stops unauthorised firmware from running; Flash Encryption alone stops firmware extraction. A product concerned about firmware IP theft needs Flash Encryption; a product concerned about field units being reflashed with malicious firmware needs Secure Boot; most commercial products with genuine IP or safety value benefit from both together. Zeus Design designs ESP32 production security provisioning — Secure Boot, Flash Encryption, and the signing-key management process — as part of a complete firmware engagement.
• Plan the OTA signing pipeline before enabling Secure Boot in the field, not after the first field update is needed. Every OTA image a product ever ships must be signed with the same key the units were provisioned with; losing or rotating that key without a planned migration path can leave already-shipped units unable to accept any future update.

Common Mistakes

• Enabling Release Mode directly on a development board or an early production sample, permanently locking out further changes before the signing and provisioning process is fully validated.
• Storing the Secure Boot private key insecurely (in a shared repository, on a build server without access control) — a leaked key defeats the entire mechanism, since anyone with it can sign firmware the device will accept as legitimate.
• Assuming Secure Boot alone prevents firmware extraction. Secure Boot only verifies what's allowed to run — it does nothing to stop someone from reading the (legitimate, correctly signed) firmware directly off the flash chip. That confidentiality guarantee is Flash Encryption's job specifically.
• Losing the signing key with field units already deployed, leaving no way to deliver a legitimate future OTA update to a fleet of Secure-Boot-enabled devices — a key-management and backup process needs to exist from the first production run, not be improvised after the fact.
• Treating security provisioning as a firmware feature bundled into the normal build, rather than a distinct, carefully gated production step — accidentally flashing a signed, encryption-enabled image (with production eFuse settings) onto a development or QA unit can brick that unit's ability to be reprogrammed normally.