MCUboot checks that an image starts with the expected magic number, that a TLV information block follows the payload, that the computed SHA256 matches the stored hash, and, when a signature is present, that it verifies against a key the bootloader trusts. Each check proves something different.
The checks in order
The MCUboot design documentation describes validation just before an image is copied into the primary slot.
- Header magic. The image must start with a defined magic value.
- TLV block. A type-length-value info block must sit right after the header and image.
- Hash. A SHA256 value is required, and the computed hash must match it. SHA384 and SHA512 types are also defined.
- Signature. If a signature TLV is present, a key hash TLV must be present too. The bootloader walks its embedded keys to find the match, then verifies. Defined types include RSA2048-PSS, ECDSA, RSA3072-PSS and Ed25519.
When protected TLVs exist, the hash covers the header, payload, protected TLVs and the TLV info header, so metadata you protect cannot be altered without detection.
What each check proves
| Check | Proves | Does not prove |
|---|---|---|
| Header and TLV structure | The file is shaped like an image | Anything about origin |
| SHA256 | The bytes were not corrupted | That the right party made them |
| Signature | The holder of a trusted private key approved the bytes | That the code is free of bugs |
A hash alone cannot defend against a malicious replacement, because anyone can compute a hash. The signature is what ties the image to your key.
Where the public key comes from
MCUboot offers three styles. By default the hash of the public key is embedded in the bootloader and compared to the key hash TLV. With the hardware key option the key hash is provisioned on the device and the full key travels in the image. With the built-in key option, keys live in the crypto backend and are referenced by ID, currently only with the PSA Crypto backend for ECDSA.
Choose based on how you plan to rotate keys. A key baked into bootloader code can only change with a bootloader update, so decide that before you ship.
Questions to ask your own build
- Is the signature mandatory in your configuration, or is hash-only allowed?
- Which key signs release images, and who can use it?
- Can a development key ever boot on production hardware?
- What happens on validation failure: does the device hang, fall back, or report?
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
Is the signature really optional in MCUboot?
The design documentation describes the signature as optional at the format level. A production device should be configured so an unsigned image is rejected.
Does the hash cover the whole image?
It covers the header, payload, protected TLVs and the TLV info header when protected TLVs are present.
Sources
Last reviewed: 19 October 2026.
