ESP32 Flash Encryption and Secure Boot: A Production Guide

If you are about to ship a product on an ESP32, ESP32 flash encryption and secure boot are the two features that decide whether someone with a screwdriver and a USB cable can read your firmware, clone your device or run their own code on it. Both are off by default. Both have a development setting and a production setting, and picking the wrong one is the most common way to ship a device that is only pretending to be locked down.

This guide is based on Espressif's ESP-IDF Programming Guide for the ESP32: the pages on Flash Encryption, Secure Boot v2 and NVS Encryption (we read the stable documentation, version 6.1). We have not built or fused a production device for this article, so treat it as a reading of the docs, not field experience. Other ESP32 family chips differ in details, and Espressif keeps a separate page for each, so check the one for your exact chip. Source

The two features do different jobs

Flash encryption protects confidentiality. Espressif describes it as encrypting the contents of the off-chip flash memory. You flash plaintext firmware, and on the first boot the data is encrypted in place, so a physical readout of the flash chip is not enough to recover most of its contents. Source

Secure boot protects integrity. It stops the device from running any code that is not signed, by checking each piece of software that boots. On the ESP32 that means the second stage bootloader and every application image. The first stage ROM bootloader is not signed because it is ROM code and cannot be changed. Source

Espressif says Secure Boot is a separate feature that can be used with flash encryption to create an even more secure environment. Its flash encryption best practices say to enable Secure Boot as an extra layer, to stop an attacker from selectively corrupting any part of the flash before boot. ESP-IDF Docs Put simply: encryption keeps people from reading, signing keeps people from replacing. A product that handles customer data or can be cloned usually wants both.

What flash encryption covers

With flash encryption on, these are encrypted by default: the second stage bootloader, the partition table, the NVS key partition, otadata, and all partitions of the app type. Other data is encrypted only if its partition is marked with the encrypted flag in the partition table. Source

That second sentence is a trap. If you store certificates, a model file or a config blob in a custom data partition and forget the flag, it stays readable. List every partition in your table and decide on purpose which ones need it.

The key is generated on the chip. If no valid key is already in the eFuse, the second stage bootloader uses the random number generator to make an AES-256 key and writes it to the eFuse, with read and write protection set so software cannot access it. The encryption happens in hardware. Source

Development mode and release mode

This is the part that matters most for shipping. Espressif defines two modes. Source

Development mode is recommended only for development. You can still flash new plaintext firmware, and the bootloader will encrypt it with the hardware key. Espressif notes that this allows, indirectly, reading the plaintext of the firmware in flash. In this mode the bootloader sets only the eFuse bits DISABLE_DL_DECRYPT and DISABLE_DL_CACHE, and the FLASH_CRYPT_CNT bits are not write-protected. Source

Release mode is recommended for manufacturing and production. Flashing plaintext firmware without knowing the key is no longer possible. The bootloader sets DISABLE_DL_ENCRYPT, DISABLE_DL_DECRYPT and DISABLE_DL_CACHE, which stops the UART bootloader from decrypting flash contents, and it write-protects the FLASH_CRYPT_CNT bits. Source

The guide states it twice in plain terms: for production use, flash encryption should be enabled in release mode only. It also warns that enabling flash encryption limits your options for further updates, so read the whole document and understand the consequences first. Source

Our reading: a device shipped in development mode has encryption you can switch on in a demo, and not much more. Check the eFuse state of a sample unit from your production line before you call it done.

Best practices from the flash encryption guide

Espressif's production list is short. Source

1. Do not reuse the same flash encryption key across devices. That way, an attacker who copies encrypted data from one device cannot move it to another.

2. On ESP32 chip revision v3, disable the UART ROM download mode if the production device does not need it. You can call esp_efuse_disable_rom_download_mode() at startup, or set the minimum revision to v3 and choose the option to permanently disable ROM download mode, which Espressif marks as recommended.

3. Enable Secure Boot as an extra layer.

The per-device key point has a cost. A unique key per device means your factory process has to generate and burn keys one unit at a time, and you need a plan for where those keys live. That is a manufacturing problem, and it is better to find it before the first production run.

How secure boot v2 works

On the ESP32, Secure Boot v2 uses RSA-PSS signatures and is available from chip revision v3.0 onward. Older revisions use the first version of Secure Boot, which Espressif calls less safe and less flexible. Source

The boot sequence has two checks. The ROM bootloader verifies the second stage bootloader's signature, and only runs it if that passes. The bootloader then verifies each application image's signature before running it. Each image carries a signature block holding a signature and an RSA-3072 public key, and a digest of that public key is stored in the eFuse. Source

Two properties are worth knowing. The private key is kept somewhere secret and never touched by the device, and no secrets are stored on the device, which Espressif says makes it immune to passive side-channel attacks such as timing or power analysis. And the app is checked on every boot and on each over-the-air update. If the selected OTA image fails verification, the bootloader falls back and looks for another correctly signed image. Source

Signing keys are the real asset

The guide's build flow offers a convenient command, idf.py secure-generate-signing-key. Espressif then points out that this key uses the best random source the operating system and Python provide, and that if that source is weak, the private key will be weak. For production it recommends generating the key pair with OpenSSL or another industry-standard tool. Source

There is a lock-in effect too. Once Secure Boot is on, any updated bootloader or app must be signed with a key matching the digest already in the eFuse. ESP-IDF Docs If the signing key is lost, you cannot ship updates to those devices. If it leaks, someone else can. This is our reading of that requirement, but it is why we would treat the signing key like a production database password: stored in a protected system, with named owners and a documented backup.

Restrictions to plan for

The Secure Boot v2 page lists consequences of turning it on. Source

• Enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, so you lose serial emulation and DFU updates on that port.

• After Secure Boot is enabled, further read-protection of eFuse keys is not possible by default. Espressif explains this prevents an attacker from read-protecting the block that holds the public key digest, which could cause denial of service and might enable a fault injection attack.

• So burn every key that needs read protection, such as the flash encryption key, before you enable Secure Boot. There is a config option to keep the ability to read-protect later, and the docs say to burn the matching eFuse once all keys are programmed.

• UART ROM download mode is left on by default so you do not lock yourself out during development. Espressif calls it a potentially insecure option and recommends disabling it.

NVS encryption: where Wi-Fi credentials live

Wi-Fi credentials, device tokens and similar values usually sit in NVS. Espressif's NVS encryption uses XTS-AES, and in the flash-encryption-based scheme the NVS keys live in a separate key partition protected by flash encryption. That makes flash encryption a prerequisite. Source

The docs say NVS encryption is on by default when flash encryption is enabled, because the Wi-Fi driver stores the SSID and passphrase in the default NVS partition. Your partition table needs an NVS key partition, of type data and subtype nvs_keys, marked encrypted and 4 KB in size. Source

If you write to the key partition yourself, note Espressif's warning: it must be completely erased before the app starts and generates keys, or the app may report a corrupt key partition error. Source

Why this matters for agent-connected devices

If your device talks to an AI agent, the firmware holds pairing tokens and Wi-Fi details, and accepts commands from software that can change. We wrote about this in our look at Meta's Muse Gadgets SDK, where Meta's own docs say builds use a development signing key and never turn on Secure Boot. That is fine for a hobby board. This guide covers what changes when it becomes a product.

A pre-ship checklist

This list is our summary of Espressif's guidance. The wording and order are ours.

1. Is flash encryption in release mode on a unit from the real production process?

2. Is every partition that holds sensitive data either encrypted by default or marked encrypted?

3. Does each device get its own flash encryption key?

4. Is Secure Boot v2 on, with a production signing key made by an industry-standard tool?

5. Where is the signing key stored, who can use it, and what is the backup?

6. Was every read-protected key burned before Secure Boot was enabled?

7. Is UART ROM download mode permanently disabled, if you do not need it?

8. Have you tested an over-the-air update of a signed image on a unit with these features on, and a rollback to a signed fallback?

9. Is NVS encryption on, and is the key partition in the partition table?

If you are building an embedded product and want a second set of eyes on this before the first production run, you can reach us through the contact page.