Guide · Security · ESP32
Lock the firmware down
By default, the code on an ESP32 is wide open: pop the flash and anyone can read your firmware, your Wi-Fi password, your API keys. Two hardware features close that door — Flash Encryption scrambles what’s stored, and Secure Boot refuses to run anything you didn’t sign. Here’s how they work, and the real price you pay for turning them on.
The threat: your flash is an open book
The external flash chip on an ESP32 stores everything unencrypted by default. Anyone with a few minutes and a cheap reader can dump it and pull out your credentials, keys and logic — no soldering skills required — see where an ESP32 keeps things. Worse, they can write a modified image back and the chip will happily boot it. For a hobby blinker that’s fine; for anything shipping to customers it isn’t.
Flash Encryption — scramble what’s stored
Flash Encryption transparently encrypts the flash contents with an AES key that lives in the chip’s eFuses — write-once memory the CPU can use but you can’t read back out. The chip decrypts on the fly at runtime, so your code doesn’t change, but a dumped flash is now useless ciphertext. That alone stops the “read the secrets off the chip” attack.
Secure Boot — only your code runs
Encryption hides the firmware; Secure Boot guarantees authenticity. You sign your image with a private key; the chip holds the matching public key hash in eFuse and verifies the signature before every boot. Swap in tampered or foreign firmware and it simply refuses to start. Together they cover both halves: encryption stops reading, Secure Boot stops replacing.
| Feature | Stops | Key lives in |
|---|---|---|
| Flash Encryption | reading firmware / secrets off the flash | eFuse (AES) |
| Secure Boot | running modified or foreign firmware | eFuse (public-key hash) |
| Both | clone, tamper and extract | — |
What it costs you
These are one-way, on-purpose. Once the eFuses are burned there’s no going back — a bricked unit can’t be un-secured. Plan for three things: debugging gets harder (no more reading flash or JTAG as before), OTA needs care (updates must be signed and encrypted the same way — the OTA flow still works, but the keys must match), and you must keep the signing key safe forever. The rule: develop with them off, burn them as a deliberate, tested final step before you ship.
Shipping a product? Pair signed firmware with a polished UI served from the device.