Android Verified Boot checks that the code a phone runs comes from a trusted source, usually the maker, and has not been altered. Each stage verifies the next before handing over control, starting at a hardware-protected root of trust and extending to the bootloader, boot partition and other verified partitions.
The chain
Google's documentation describes the chain starting at a hardware root of trust, then the bootloader, then the boot partition, then partitions such as system and vendor, and optionally oem. At each hop the current stage checks the integrity and authenticity of the next one. If a stage fails the check, it does not get control.
This is the same design idea behind PC secure boot and embedded secure boot. The details differ by platform, but the structure is a chain with a fixed first link.
Rollback protection
Verified Boot also checks that the device runs the correct Android version. Google explains the purpose: an exploit should not become persistent, so devices are only able to update to newer versions. Without that, an attacker could reinstall an old build with a known flaw.
Reporting integrity
The same system lets a device communicate its integrity state to the user. That is useful to a person holding a phone, and useful to an app deciding whether to trust it, though how apps use that signal is a separate topic.
Where dm-verity fits
Verifying a whole partition up front would be slow, so Linux uses dm-verity for block devices. It organises hashes in a tree and checks blocks on demand as they are read, with the root hash supplied at setup. Our dm-verity post goes through the corruption modes.
A short history
Google's page notes that Android 4.4 introduced Verified Boot 1, combining it with dm-verity. Android 7.0 began strictly enforcing it, so compromised devices cannot boot, and added forward error correction for non-malicious corruption. Android 8.0 and higher use Android Verified Boot, which works with Project Treble and adds rollback protection features.
What device makers can copy
You do not need Android to use the lessons. Put a verification step at every stage. Anchor the first one in something that cannot be rewritten. Add rollback protection. And decide what the device does when a check fails, instead of finding out in the field.
Quick check
Does Verified Boot stop all malware on a phone?
No. It protects the integrity of the boot chain and verified partitions, not apps that run later.
What does rollback protection prevent?
It stops a device from being moved back to an older, vulnerable version, so an exploit cannot become persistent.
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.
