Firmware integrity is the assurance that the low-level software a device boots, from the bootloader through the kernel to the system partitions, is the build its maker approved and has not been altered or rolled back. It is established during boot, checked while the device runs and reported as signed evidence a server can verify. The task belongs mainly to device makers and to institutions that commission devices: an app can read the result but cannot repair compromised firmware. On iOS, Apple controls the whole chain. On Android, each maker configures it for every model and chipset.
The threat and the trust boundary
Firmware sits beneath the operating system’s protections. Code planted there sees data before any app encrypts it and can hide from every check above it. For a fleet used in government, public safety or critical operations, the affected flows are the ones everything else depends on: enrolling a device, signing in to institutional services, handling regulated data and installing updates.
Typical attacks include flashing a modified system image, unlocking the bootloader to run unsigned code, downgrading to an older image with a known flaw and planting an implant in a privileged system app. The trust boundary is the point where the device proves its state to a server that the attacker does not control.
Responsibilities by layer
| Layer | What it does for firmware integrity |
|---|---|
| Boot chain | Android Verified Boot checks each stage against the maker’s keys; rollback indexes refuse older images |
| System partitions | dm-verity checks blocks as they are read, so offline changes are caught |
| Operating system | Reports boot state and lock state; hardware-backed key attestation carries verified boot state and patch level on devices that support it |
| App | Reads platform evidence and passes it on; cannot fix what it finds |
| Backend | Verifies signed evidence against approved values per model and decides access |
On iOS, a secure boot chain beginning in the Boot ROM verifies each stage against Apple’s signatures, and neither device makers nor app makers can change it. Apps see the outcome only indirectly, through App Attest results and jailbreak indicators.
How to evaluate firmware integrity
- Platform scope. Which models and chipsets are covered, and which of them provide a hardware-backed key store.
- Evidence format. A signed record per device showing boot state, lock state, patch level and image version, verified on your server rather than on the device.
- Negative tests. An unlocked bootloader, a downgraded image and a modified system partition, each flagged by the verifier.
- Update path. How new expected values reach the verifier before an update reaches devices.
- User and service impact. Boot time, update behaviour, re-flashing at service centres and the end-of-support plan.
- Key custody. Who holds the signing keys, and how they are rotated.
How Otukan applies firmware integrity
Otukan Device Security configures verified boot, partition verification, key attestation and post-boot checks inside the device maker’s firmware build, scoped per model and chipset. Boot state, lock state and patch level become signed evidence that your own server verifies against approved values per model, and your services restrict untrusted devices under your policy. Before each authorised update reaches devices, Otukan publishes the new expected values to your verifier, so an authorised update is not mistaken for tampering.
The Android implementation is covered on Android firmware integrity. For update signing, see Android secure firmware updates. The product is covered on mobile device security.