Android bootloader integrity explained

Android bootloader integrity is the question of whether a device started from software its manufacturer signed, with the bootloader locked. A mobile security team should evaluate it as one signal among three: root artefacts, modified boot state and attested device trust. Read it from a hardware-backed attestation that your server verifies, not from properties the device reports about itself, because a rooted device can rewrite those. An unlocked bootloader is evidence, not a verdict: developers unlock on purpose. This article covers Android only. It explains the boot chain, the signal boundary, manufacturer differences and how to turn the signal into proportionate app behaviour.

Signal boundary: root artefacts, boot state and device trust

Every Android device boots in a chain. Each stage checks the signature of the next before handing over control. Android calls this verified boot, and its current form, Android Verified Boot (AVB), records the result so the operating system and the keystore can report it later.

The chain gives you four boot states. Their meaning is defined by Android, not by each manufacturer.

That state is different from the other two signals your app may already collect.

You can see the raw values on any device with developer tools. They are useful for testing and worthless as evidence, because root access can change them.

# Local properties: fine for a test bench, spoofable on a rooted device
adb shell getprop ro.boot.verifiedbootstate   # green | yellow | orange
adb shell getprop ro.boot.vbmeta.device_state # locked | unlocked
adb shell getprop ro.boot.flash.locked        # 1 = locked, 0 = unlocked

The trustworthy copy lives in the key attestation certificate. The Android keystore writes a RootOfTrust structure into it, signed by a key that never leaves the trusted environment.

RootOfTrust ::= SEQUENCE {
    verifiedBootKey    OCTET_STRING,
    deviceLocked       BOOLEAN,
    verifiedBootState  VerifiedBootState,
    verifiedBootHash   OCTET_STRING,
}
VerifiedBootState ::= ENUMERATED {
    Verified (0), SelfSigned (1), Unverified (2), Failed (3),
}

Compatibility: manufacturers, versions and development devices

Verified boot has evolved across Android releases, which is why older devices and newer ones report different levels of detail.

Beyond the platform version, manufacturers make choices that change what you will see in the field:

• Unlock policy. Some devices allow unlocking from developer options, some require a token from the manufacturer, and some carrier or enterprise models never allow it.
• Relocking. A few devices let owners relock the bootloader with their own key. That produces the yellow state, which is legitimate and should not be read as orange.
• Attestation strength. Attestation certificates carry a security level: software, trusted environment or a dedicated secure element (StrongBox). A software-level attestation says little about boot integrity.
• Unlock wipes data. Unlocking normally triggers a factory reset, so an unlocked device is rarely a user’s own device that was quietly tampered with overnight.

Build your test matrix before you write the policy. At minimum, cover one locked device per major manufacturer in your user base, one device relocked with a custom key, one unlocked device with stock software, one unlocked and rooted device with hiding tools active, and one older device whose attestation is software-level only. Record what each reports, locally and in the attestation, and keep the results dated.

Decision: connect signal confidence to proportionate behaviour

The strongest decisions use the attested value on your server and combine it with the other two signals. The table shows one way to structure a policy. The thresholds are yours to set per user flow.

Otukan reads boot state, root artefacts and attested device trust as separate signals on Android, so your team sees which one fired rather than a single opaque score. The signals travel to your backend with login, payee creation and payment requests, where your risk engine combines them with account history. You set the response per flow: observe, warn, restrict or terminate. Development and test devices can be marked so their unlocked state does not interrupt your own teams. For the wider picture of Android signals, see Android root detection and Android app security.

Before you set a boot-state policy

• Confirm that boot state is read from a key attestation verified on your server, not from system properties.
• Check the attestation security level and treat software-level results as weak evidence.
• Test green, yellow and orange devices from the manufacturers your users own.
• Allow-list your development and QA devices by identity, not by relaxing the rule.
• Start in observe mode and measure how often each state appears before restricting anything.
• Decide the response for each sensitive flow: login, payee creation and payment.