A valid integrity check proves that firmware is authentic and unchanged: signed by the owner’s key and not modified since. It does not prove the firmware is free of flaws. A vulnerable driver, an exposed debug interface or an outdated component is signed and verified just as faithfully as safe code. Integrity protection keeps the approved image in place on every device; security testing decides whether that image deserves approval. Device makers and institutions need both. This article covers Android-based devices, where scope is always agreed per model and chipset.
Three different questions
Firmware assurance is often discussed as one thing. It is three questions, each answered by a different method at a different moment in the life of an image.
| Question | Method | When it is answered | What it produces |
|---|---|---|---|
| Who produced this image? | Provenance through code signing | At build and signing | A signature tied to an authorised release |
| Is the device running it now? | State verification through verified boot and attestation | At every boot and on request | Signed evidence of device state |
| Is the approved image safe? | Vulnerability assessment | Before signing, and again as new flaws are disclosed | Findings for the version tested |
Provenance: who produced this image?
Provenance ties an image to a build and a signer. Code signing with keys held by the device maker establishes that the image came through the authorised release process. It says nothing about what the process let through.
State verification: is the device running it now?
On Android, verified boot checks each stage of the boot chain against the owner’s keys, and partition verification detects changes to protected partitions while the system runs. Rollback indexes stop an older signed image from booting once the device has accepted a newer one. Key attestation lets a server receive a signed statement of boot state, lock state and patch level from the device’s hardware-backed key store. Together they answer whether this device, today, is in the state you shipped.
- 2013
Android 4.4
dm-verity arrives, letting the system detect changes to protected partitions.
- 2016
Android 7.0
Verified boot is strictly enforced, and key attestation lets a server receive signed statements about a device's key store.
- 2017
Android 8.0
Android Verified Boot 2.0 introduces rollback protection, so older signed images can be refused.
Each step made the answer to the second question stronger. None of them changed the answer to the third: the platform verifies whatever image the owner signed.
Vulnerability assessment: is the approved image safe?
Assessment looks inside the image: component inventory and known flaws, configuration review of access control and services, privileged app review, debug interface checks, and targeted testing of drivers and update handling. It produces findings at a point in time, for the version tested.
Where the gap shows up
Consider a field device that reports a locked bootloader, a verified boot chain and the expected image version. Every integrity signal is green. Yet the image may still ship a vendor service that listens on a local port, a system app with more permissions than it needs, or a kernel component with a flaw disclosed after release.
An OEM workflow that uses both
Testing and integrity protection meet at the signing step. The workflow below keeps each method where it does its best work.
Assess before signing
Each release candidate is tested and reviewed; findings are fixed or accepted with an owner.
Sign
Only the approved build is signed, with keys that stay under the device maker's control.
Raise the rollback floor
When a release fixes a security flaw, older images stop booting.
Publish expected values
The verification server learns the new keys, patch level and version before devices update.
Verify in the field
Devices report signed state; services restrict any device outside policy.
Testing makes the image worth trusting; integrity protection makes a locked device refuse anything else at boot and reports what each unit booted, for the supported life of the model. A release checklist makes the hand-off explicit:
- Security testing and configuration review are complete for this release candidate.
- Every open finding has an owner and a decision.
- Debug interfaces and test services are disabled in the production build.
- The rollback floor is raised if this release fixes a security flaw.
- Expected values are published to the verification server before rollout.
- A sample of devices reports the new state after the update.
What each method can and cannot show
Integrity protection shows
- The image came from your build and signer
- The device runs that image now
- Nobody reinstalled an older release
- Security settings held after boot, where attested
Security testing shows
- Known flaws in the components shipped
- Debug interfaces left enabled
- Privileged apps with more access than they need
- How the update handler treats bad input
| Evidence | Integrity protection shows | Security testing shows |
|---|---|---|
| This image came from our build | Yes, through signature verification | Only if provenance is recorded alongside |
| This device runs the approved image now | Yes, through boot state and attestation | No, testing happens before shipment |
| Nobody reinstalled an older release | Yes, through rollback protection | No |
| The image contains no known serious flaw | No | Yes, for the version and scope tested |
| Debug interfaces are disabled in production | Only if the state is attested after boot | Yes, as a configuration finding |
| Privileged apps resist abuse | Partly, through hardening and access control | Yes, through targeted review |
How Otukan provides persistent protection
Otukan works inside your firmware build and signing process, per model and chipset, and your signing keys stay with you. It configures verified boot for your keys, protects the update path so devices accept only your signed releases and refuse rollback, hardens privileged system apps and services, and checks security settings after boot. Each device reports boot state, lock state, patch level and image version as evidence signed by the hardware-backed key store on chipsets that provide one, verified against approved values on your own server, where new expected values are published before each authorised update reaches devices. Your services then restrict any untrusted device under a policy you set. Otukan rebuilds and retests this protection on physical models with every firmware release.
The technical detail is covered on Android firmware integrity. The product is on mobile device security.