Take a fresh microcontroller out of the box, flash your firmware, and it just runs. Flash a completely different firmware and it runs that one just as happily; it has no particular loyalty to the code you consider yours. Connect an inexpensive adapter and read the flash back, and the bytes come off unencrypted. The firmware itself is compiled machine code, so it won’t read like source, but it’s the real binary. That’s enough to clone onto another board or feed to a disassembler, and any secrets you stored in the clear (keys, certificates, configuration) are right there for the reading.
On your workbench or during prototyping, that openness is wonderful. It’s part of why these chips are a joy to develop on. On the other hand, that same device sitting in a customer’s facility for the next ten years is a different story, and the openness that helped you move fast is now a door anyone can walk through. This post is about the two locks that close that door, what each one actually does.
Two locks: secure boot and flash encryption
It’s easy to file all of this under one heading, “device security,” and move on. On real hardware it is two separate mechanisms solving two separate problems, and most products want (or need!) both.
Secure boot is about authenticity
Secure boot is a hardware check that lets a device run only firmware signed with your key. Someone can try to load their own image, but it just won’t boot. That’s what stops counterfeit firmware, tampered updates, and the classic move of swapping your app for someone else’s. It answers one question: is this exactly the firmware we shipped?
Flash encryption is about confidentiality
Flash encryption stores the contents of flash as ciphertext only that specific chip can decrypt. Desolder the flash chip, read it in a programmer, and you get noise. That’s what protects the things baked into a device: credentials, provisioning certificates, the clever algorithm your team worked out. It answers a different question: if someone walks off with the hardware, what can they learn from it?
You might be wondering whether you really need both. Here’s the catch: they don’t cover for each other. Secure boot without encryption means nobody can run their own code, but your secrets are still sitting there readable. Encryption without secure boot means your secrets are safe, but the device will still happily boot a modified image. Turn on both and you’ve closed both doors: only your signed code runs, and the flash gives up nothing useful.
What are you actually defending against?
It’s worth being concrete, because the threat model drives how far you go.
- Cloning and counterfeits. If your firmware is readable, it’s copyable, and a gray-market shop can stamp out units that look and act just like yours. Encryption makes the image worthless off the chip, and secure boot ties a working device to your signature.
- Secret extraction. Connected devices now carry per-unit identity: certificates and keys that let them talk to a backend. A readable flash turns that into a harvesting opportunity. Encryption keeps those secrets on the one chip they belong to.
- Tampering. A device that will boot “anything” is a device that will boot an attacker’s “anything.” Secure boot means a modified image simply doesn’t run.
- Protecting your work. Sometimes the firmware is the product. Encryption moves reverse engineering from “an afternoon with a programmer” to “a serious lab effort.”
Not every device needs the full treatment. A battery-powered widget that stores nothing and talks to nothing is a very different risk conversation than a networked device holding credentials to your cloud. The moment a product goes on a network or carries secrets, the math changes quickly.
The one idea that changes how you think about it
Here’s the concept that trips up most teams the first time: these protections are one-way.
The enforcement doesn’t live in software you can toggle. It lives in hardware, in bits you can burn exactly once and never un-burn. You can take a device from “wide open” to “signed firmware only, flash encrypted,” but there is no reverse gear. No factory reset nor re-flash will undo it. This is one of the rare corners of computing where turning it off and on again offers no comfort whatsoever. A device’s security state only ever moves forward.
That permanence is exactly what makes the protection trustworthy, because an attacker can’t turn it off either. That being said, it also means the process demands respect. Every step that flips one of those bits is irreversible, so the sequence and the tooling around it matter as much as the feature itself. We’ll get into the sharp edges in the next post, including how a device can brick itself if you get the order wrong.
The first time I did this, I must have stared at the terminal command for a solid ten minutes, reading and rereading it to make sure I had it right. I’d also recommend keeping a healthy supply of ESP32 dev kits on hand, just in case. The good news is that you can take most of that pressure off yourself by building some tooling around the process for repeatable provisioning. Tooling allows you to stop worrying about getting any single command right, and that’s the subject of a later post in this series.
The practical upshot for your mental model: don’t think of secure boot and flash encryption as settings you toggle. Think of them as a provisioning process you run once per device, carefully, and then never take back.
Why this is landing on more roadmaps
For a long time, embedded security was something teams did if they had spare time and a security-minded lead. That’s changing, partly because attacks on connected devices are now routine, and partly because regulation is catching up.
In the EU, Radio Equipment Directive rules covering firmware integrity, data protection, and fraud prevention became mandatory for connected products on August 1, 2025. The broader Cyber Resilience Act is right behind it, with its own major obligations phasing in through 2027. You don’t need to read the legal text to see where it points: firmware integrity, confidentiality of stored data, authenticated updates. In other words, exactly the two locks above. We’ll devote a whole post later in this series to what those requirements actually ask for and how the technical pieces map onto them. For now, the takeaway is simpler: the features that used to be a differentiator are quietly becoming the baseline.
✨ AI Post Recap
ESP32 chips ship completely open: any firmware runs, and the flash reads back in the clear. Two hardware features close that gap. Secure boot makes the device run only firmware signed with your key, which protects authenticity. Flash encryption stores flash as ciphertext only that chip can decrypt, which protects confidentiality. Most connected products need both. The enforcement is burned into one-time hardware fuses, so it’s permanent and can’t be reversed, which is why the provisioning process matters as much as the features.
What is the difference between ESP32 secure boot and flash encryption? Secure boot checks authenticity, so the device only runs firmware signed with your key. Flash encryption protects confidentiality, storing flash as ciphertext only that chip can decrypt. Secure boot stops unauthorized code from running; flash encryption stops secrets from being read off the chip.
Do I need both secure boot and flash encryption? For most connected devices, yes. They don’t cover for each other. Secure boot alone leaves your secrets readable, and flash encryption alone still lets a modified image boot. Enabling both means only your signed code runs and the flash gives up nothing useful.
Is ESP32 secure boot and flash encryption reversible? No. Enforcement lives in one-time-programmable fuses that can be burned but never un-burned. A device can move from wide open to locked down, but no factory reset or re-flash undoes it. That permanence is what makes the protection trustworthy.
