Usually yes. Re-validating the image on every boot catches tampering that happens after installation. MCUboot documents an option that caches a successful check to speed slow microcontrollers, and it states the trade-off plainly: a modified primary slot would boot without re-validation.
What the documentation says
In MCUboot, the integrity check runs immediately before an image is copied into the primary slot. Without a swap, the primary slot is only checked if the MCUBOOT_VALIDATE_PRIMARY_SLOT option is set. A further option, MCUBOOT_VALIDATE_PRIMARY_SLOT_ONCE, caches a successful validation so later boots skip it. The documentation describes this as speeding up slow MCUs while weakening security, because a modified primary slot would boot without re-validation.
ETSI EN 303 645 provision 5.7-1 says a consumer IoT device should verify its software using secure boot mechanisms, and 5.7-2 says that when an unauthorized change is detected the device should alert the user or administrator and not connect to wider networks than those needed to alert.
The trade-off
| Choice | Benefit | Cost |
|---|---|---|
| Validate every boot | Detects later flash tampering | Longer boot time, more power |
| Validate once, cache the result | Faster boots | Later modification goes unnoticed |
When caching may be reasonable
It is a risk decision, not a default. Ask:
- Can an attacker write to flash after installation, by physical access, a debug port or a software flaw?
- Is there another control that detects modification, such as hardware protection of the flash region?
- What is the actual boot time penalty on your part, measured rather than assumed?
- What does your threat model say about physical attackers?
If a debug port is open or the flash can be written in the field, validating each boot is the safer choice.
If validation fails
Decide the behavior in advance. MCUboot swap types include FAIL and PANIC, which cause the bootloader to hang rather than boot an invalid or compromised image. Hanging avoids running bad code, but it can brick a unit, so pair it with a recovery path and, where appropriate, a notification.
Record the decision
Write the choice and the reasoning in your design file. An auditor or customer asking about secure boot will want to know whether the check runs each time.
Where Safeguard fits
Safeguard supports compliance and evidence automation alongside SBOM and dependency scanning, so a record like this can be kept with your other evidence. Try the free scan at gold.safeguard.sh/scan on a repository you already own.
Quick check
Does validating each boot slow my device a lot?
It depends on image size and hardware. Measure it on your part before deciding to skip it.
What happens if validation fails?
The behavior is yours to define. MCUboot describes states in which the bootloader hangs rather than run a compromised image, so plan recovery.
Sources
Last reviewed: 19 October 2026.
