Secure Boot on STM32: What Actually Protects You
STM32 microcontrollers ship with genuine secure boot and isolation features, but most of them do nothing until you configure them. The gap between the datasheet’s promises and a default device is where trouble lives, and closing it takes deliberate setup and a verification step on real hardware.
The Features Are Real but Inert
STM32 parts advertise a serious security feature set: readout protection, a hardware root of trust, a secure boot loader, and memory isolation. Every one of those is genuine and capable. The catch that catches teams is that they are almost all opt-in, and a chip in its default state enforces almost none of them.
That means the datasheet’s feature list describes what the chip can do, not what your device does. The distance between those two is set entirely by configuration, and a single missed option byte can leave a protection enabled in name while a misconfiguration quietly defeats it. The only way to know is to verify on a finished unit.
Readout Protection Is the Floor
Readout protection, RDP, controls whether the debug interface can read flash. At Level 0 the chip is wide open and a debugger dumps firmware in seconds. Level 1 blocks debug read of flash and triggers a mass erase if someone tries to drop the protection. Level 2 disables debug entirely and locks the setting permanently.
RDP is the floor because without it nothing else matters: an attacker who can read flash over SWD has your firmware regardless of how secure the boot chain is. Many devices ship at Level 0 because that is the default and nobody changed it, which is the single most common STM32 finding there is.
Check the Protection Level First
Before anything else, read the current RDP level off the unit. It is one command and it tells you immediately whether the most basic protection is even on.
STM32_Programmer_CLI -c port=SWD -ob displ
RDP : 0xAA (Level 0) <- no protection, flash readable over SWD nBOOT0 : 1 PCROP : disabled Secure Area : not configured
An RDP Level 0 on a production unit means the firmware is exposed and the rest of the security configuration is probably untouched too. That single line frequently sets the tone for the whole assessment, because it tells you the team shipped the chip in its development state.
The Secure Boot Path
Newer STM32 families provide a hardware root of trust and a secure boot loader, often through the Secure Boot and Secure Firmware Update framework, that verifies the firmware’s signature before running it. It is powerful and it is exactly what you want, but it does not engage on its own.
Turning it on means provisioning keys, configuring the secure boot loader to occupy the start of flash, and setting the option bytes that hand control to it at reset. Each step has to be right, and the framework is unforgiving of a half-configured state, which is why so many devices have the capability present but not actually verifying anything.
Provisioning Is the Hard Part
The secure boot is not a single switch, it is a small provisioning project. You generate a key pair, install the public key or its hash into the device, sign the firmware with the private key, and configure the loader and option bytes so the chip runs the loader first and the loader checks the signature.
# sign firmware with the provisioned key, then program the signed image
STM32_SigningTool_CLI -bin app.bin -nk -of 0x0 -t fw -o app_signed.bin
STM32_Programmer_CLI -c port=SWD -d app_signed.bin 0x08010000Signing with ECDSA-P256... done Image header + signature appended File programmed; secure boot loader will verify on next reset
Every one of those steps is easy to get subtly wrong, and a mistake usually fails open rather than closed: the device boots fine because the loader did not actually verify, and nothing looks broken from the outside. That silent failure mode is exactly why verification on real hardware is not optional.
Isolation Features
Beyond boot, STM32 parts offer hardware isolation, secure-memory areas, the firewall or the secure area feature depending on family, and PCROP to make a code region execute-only. These wall off secret-handling code and keys from the rest of the firmware, so a bug in the application cannot read the keys.
Like everything else here, isolation is opt-in and configured through option bytes and linker placement. Used well, it means a memory-corruption bug in the application does not automatically hand over the cryptographic material. Left unconfigured, the keys sit in the same readable address space as everything else.
Verify Secure Boot Actually Engages
The decisive test is empirical: program an unsigned or tampered image and confirm the device refuses to run it. A unit with secure boot truly enabled will reject it; a misconfigured one will run it and reveal that verification never happened.
# flash a deliberately unsigned image and watch the boot result STM32_Programmer_CLI -c port=SWD -d unsigned_app.bin 0x08010000 # then reset and watch the console / debug status
secure boot: signature check FAILED secure boot: halting, not executing application <- GOOD # vs. a misconfigured unit: # application started normally <- BAD: verification not engaged
A device that halts on the unsigned image is verifying. A device that runs it has its secure boot disabled in practice no matter what the configuration appears to say. This one test separates a real chain of trust from a checkbox someone believed they had ticked.
Confirm Readout Protection Holds Too
Pair the boot test with a flash-read test, because the two protect different things. Secure boot stops modified code from running. Readout protection stops the firmware from being read in the first place. A device needs both, and each has to be verified on its own.
# attempt a flash read; should fail at RDP Level 1 or 2
STM32_Programmer_CLI -c port=SWD -r32 0x08000000 0x40 head.binError: Read operation failed (protection active) <- GOOD # a successful read here means RDP never advanced past Level 0
A failed read confirms RDP is doing its job. If the read succeeds while you believed protection was on, an option byte did not take, and the firmware is exposed even though secure boot might be working. Both tests together give the full picture.
Why Defaults Bite
The recurring theme is that STM32 security fails open. The default state is permissive, the configuration is spread across option bytes and tooling, and a partial setup usually still boots, so nothing forces the team to notice the gap. A device can pass every functional test while protecting nothing.
That is why I never accept the datasheet’s feature list, or the build configuration, as evidence. The chip is capable, but capability is not protection. Only a tested production unit, where the read fails and the unsigned image is refused, proves the configuration actually engaged.
A Verification Checklist
Before shipping, a short empirical checklist settles it. Confirm RDP is at Level 1 or 2 and a flash read fails, confirm a signed image runs and an unsigned one is refused, confirm any isolated key region is not readable from the application, and run all of it on a finished production unit rather than a development board.
Each item is a concrete test with a clear pass and fail. A device that passes all of them has security that is real and verified. A device that was only configured, and never tested this way, is one missed option byte away from shipping wide open while looking fine.
Verify, Do Not Assume
The throughline with STM32 security is that the capability is real but inert until configured, and a single missed option byte leaves a gap that looks closed. Readout protection, the secure boot loader, and hardware isolation each require deliberate setup, and each can be enabled in name while a misconfiguration quietly defeats it.
Treating the datasheet’s feature list as proof of protection is the mistake. Treating a tested production device as proof is the discipline. The features give you the tools, and the verification step is what turns those tools into actual security you can rely on.
Where This Fits
Auditing whether an STM32 product’s security features were configured correctly, and proving it on shipped hardware, is a core part of a product security assessment. If you want your STM32 configuration verified the way an attacker would test it, that is the kind of work we do at Berkner Tech.