No. A SHA256 hash shows that bytes arrived intact, but anyone who can change the file can recompute the hash. Only a digital signature, checked against a key the device already trusts, shows who approved the image. Production bootloaders should require the signature, not just the hash.
What a hash and a signature each give you
A hash is a fingerprint of data. If one bit changes, the fingerprint changes. That is useful for catching a bad download or a flash error.
A signature adds identity. The signer hashes the image and encrypts or signs that digest with a private key. The device checks it with the matching public key. An attacker without the private key cannot produce a valid signature for a changed image.
How the tools treat them
The MCUboot documentation describes a required SHA256 TLV and an optional signature TLV. A hash mismatch stops the image. The signature adds the key hash lookup and verification step. The U-Boot documentation says FIT hashes detect corruption but do not stop one signed image from being swapped for another, and it recommends signing configurations.
ETSI EN 303 645 provision 5.3-9 says the device should verify the authenticity and integrity of software updates, and 5.3-10 says that where updates arrive over a network, the device shall verify both via a trust relationship, with digital signature based verification listed as a valid one.
| Control | Integrity | Authenticity |
|---|---|---|
| Hash only | Yes | No |
| Signature over hash | Yes | Yes, if the key is protected |
| Encrypted channel only | In transit only | Depends on endpoint trust |
Common gaps
- The signature is optional in build configuration and a development build leaves it off.
- Release images are signed, but test images signed with a weak or shared key are still accepted by the same bootloader.
- The hash is stored next to the image and fetched from the same server, so an attacker replaces both.
- Verification happens only at install time, never at boot.
What to configure
- Reject images without a valid signature in production builds.
- Remove development keys from production bootloaders.
- Sign what ships, including metadata that affects behavior.
- Verify at boot as well as at install, unless you have a reasoned exception.
- Test with a tampered image and an image signed by the wrong key.
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
Can HTTPS replace image signing?
HTTPS protects the transfer. It does not protect against a compromised update server or a bad image stored upstream, so the device should still verify a signature.
Does a signature prove the firmware is safe?
No. It proves your key approved those bytes. Vulnerabilities in the code are a separate problem.
Sources
- MCUboot design documentation
- U-Boot documentation: FIT image signature verification
- ETSI EN 303 645 V2.1.1 (2020-06)
Last reviewed: 19 October 2026.
