A rollback attack installs an old, validly signed firmware image that has a known bug. A signature alone does not stop it, because the old image really was signed. MCUboot offers two defences: a software version comparison and a hardware security counter checked against a trusted, non-volatile counter on the device.
Why signatures are not enough
Signature checks answer one question: did the vendor sign this? An image from two years ago passes that test. If it contains a flaw the vendor already fixed, an attacker who can deliver it gets the flaw back. ETSI EN 303 645 gives this as an example of a secure update measure: an anti-rollback policy based on version checking can be used to prevent downgrade attacks.
Option one: version comparison
MCUboot's software option compares version numbers, enabled with MCUBOOT_DOWNGRADE_PREVENTION. The design document says it applies only with the overwrite-only strategy. That is a real limit: if you want swap with test and revert, this option is not the one for you.
Because the version is stored with the image, this approach protects against accidental or casual downgrades more than against an attacker with deep access to flash.
Option two: hardware security counter
The image carries a security counter inside its protected TLVs, added at signing time with imgtool. At boot, the bootloader checks it against a counter held in non-volatile storage that the device trusts, enabled with MCUBOOT_HW_ROLLBACK_PROT.
Two details from the document are worth noting. The security counter is independent of the version number, so you can ship version 2.1.0 without bumping the counter. And an image with an equal counter value is accepted, so the counter blocks lower values only.
How to use the counter well
- Bump the counter only for security fixes that you never want to see undone. Bumping it on every release makes recovery harder.
- Test the failure path. An image with a lower counter should be refused and the device should stay in a bootable state.
- Plan for the one-way nature. A counter that has advanced cannot go back, so a bad release that raises it needs a fix-forward plan.
- Document the counter value per release so support can reason about which images a device will accept.
Where the counter lives
The counter is only as trustworthy as its storage. If an attacker can reset it, the protection is gone. Check what your silicon offers for monotonic counters or protected storage, since that differs by part.
Quick check
Is the version number the same as the security counter?
No. MCUboot treats them as independent. The counter lives in the image's protected data and is compared with a trusted counter on the device.
Does an equal counter value pass?
Yes. Per the design document, an image with an equal security counter value is accepted.
Where Safeguard fits
Safeguard works on the software supply chain around your firmware: SBOM and dependency scanning, policies and gates that can block a release, and compliance evidence. It does not sign images or run your bootloader. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
