Trusted device updates rest on three parties with clear jobs. The OEM holds the signing keys and decides what ships. The team that runs the update service delivers each release to devices in stages. Otukan prepares the embedded protection, expected values and rollback settings for every release, and tracks each security finding through to the image that fixes it, until the model’s agreed end of support. This page covers Android-based devices whose firmware an OEM or ODM builds and signs. Apple builds and signs iOS updates, so they sit outside this scope.
Key authority
An update is only as trustworthy as the key that signed it. Most Android device programmes involve several keys, and each needs a known holder and a known recovery path. Otukan records them in a key custody map before the first release.
| Key | What it authorises | Usually held by | Recovery question to settle |
|---|---|---|---|
| Boot and verified boot key | Which bootloader, kernel and vbmeta images a device will start | OEM, sometimes with the chipset vendor | Can it be rotated on devices already in the field, or only on new production? |
| Update package key | Which update packages a device accepts for install | OEM or the ODM running releases | Who can sign an emergency release if the usual signer is unavailable? |
| Platform and system app keys | Which system apps run with platform privileges | OEM | How are system apps re-signed if a key is exposed? |
| Attestation keys | Which devices can prove their state to your server | Provisioned at manufacture or remotely, per chipset | Which devices lose attestation if a batch is revoked? |
Custody and recovery
Keys belong in a hardware security module or an equivalent controlled store, with named people allowed to use them. Otukan agrees with you what happens if a key is lost, exposed or held by a supplier that leaves the programme. The plan names who signs the replacement, which devices can accept it, and which devices must be handled another way.
Update lifecycle
A secure update is checked more than once: by your release process, by the device before install, by verified boot at the next start, and by your server when the device reports back.
- Build. Otukan’s protection is built into the release alongside your security patches, and tested on the models in scope.
- Sign. You sign the image and the update package through your own process.
- Validate. The release is checked against the approved model, key and version. Otukan publishes the new expected values to your verification side.
- Roll out. A first group of devices installs the release. On devices with A/B system partitions, a failed install falls back to the previous slot.
- Confirm. Devices report their image version and patch level, and exceptions are listed for your operations team.
Staged rollout
The first group includes every model and hardware revision in scope, so a problem specific to one board appears early. Otukan reviews install results, boot success and reported versions from that group with your release team before the rollout widens. A release that fails review is paused, and devices already on the previous approved image stay there.
Rollback protection
Verified boot keeps a rollback index on the device and refuses images with a lower value. Raising it closes the door on older, vulnerable images, and also stops devices returning to them for recovery. Otukan plans each rise into your release calendar, so the decision is deliberate and recorded.
Maintenance
Updates are a promise that lasts as long as the model is supported. Otukan’s maintenance plan names who does what for each model.
| Task | Owner | What is recorded |
|---|---|---|
| Watch security bulletins and incoming reports | Otukan with your security team | Which findings affect which models |
| Triage each finding | Otukan, with the chipset vendor where the flaw sits in its layer | Severity for your devices, owner, target release |
| Build and test the fix | ODM or OEM build team, with Otukan for the protection | Test results on the physical models |
| Approve and release | OEM, and the institution where it approves updates | Release record and devices reached |
| End of support | OEM and institution, agreed at the start | Date, final state and what devices may still reach |
The five delivery stages for an OEM programme are covered on OEM device security integration. For the product overview, see mobile device security.