Evaluate lifecycle and maintenance by following one device model from qualification to retirement and asking, at each stage, who can still change the firmware, what the protection relies on, and who acts when something breaks. Otukan maintains its embedded protection across that whole life: rebuilt with every firmware release, re-qualified when the Android version or chipset package changes, carried through repair and reassignment, and closed with a recorded retirement. The maintenance period for each model is agreed in writing before the first device ships. This page covers Android-based devices built by an OEM or ODM; Apple maintains iOS firmware.
Integration boundary over time
Responsibilities that are clear at launch drift over the years. Suppliers change, contracts end and devices move between owners. Mapping each stage in advance keeps authority clear when that happens.
| Stage | Who can change the firmware | Otukan’s role | The institution’s role |
|---|---|---|---|
| Production | OEM and ODM, under the release process | Protection built and tested into the image | Accepts delivered devices against the specification |
| In service | OEM, through signed releases | Protection rebuilt and retested with every release | Approves releases and watches device reporting |
| Platform uplift | OEM, with the chipset vendor’s new package | Model re-qualified before the upgrade ships | Decides when the fleet moves |
| Repair and refurbishment | Service centres authorised by the OEM | Repaired devices checked against approved values | Decides whether the device returns to service |
| Reassignment | No firmware change expected | Approved firmware confirmed before reuse | Wipes and re-enrols per its own policy |
| Retirement | None | Device marked retired on the verification side | Wipes and disposes of the device |
Control scope over time
Some dependencies weaken with age. A useful evaluation asks, for each one, how long it will hold and what happens when it stops.
Firmware build access
Protection can only be updated by someone who can still build the model’s firmware. If the ODM leaves the programme, that ability must pass to another party. Otukan works with the OEM to move it to a party that can still produce protected releases.
Chipset support
Security fixes for the lowest layers come from the chipset vendor. When its support for a chipset ends, those layers stop receiving fixes, whatever the maintenance period says. Otukan tracks that date per model and records any gap against the agreed maintenance period, so the decision is made before devices are exposed.
Hardware trust
Hardware-backed keys and attestation depend on material provisioned during manufacture. If that material is revoked or expires, affected devices lose part of their evidence. Otukan records which devices depend on which provisioning, so the impact of a revocation is known in advance.
Platform uplift
A major Android version changes interfaces the protection relies on, and a new chipset package can change the boot chain beneath it. Otukan re-runs the qualification tests for the model on the new baseline, including update, factory reset and repair paths, and updates the maintenance record before the upgrade reaches devices. The institution then decides when its fleet moves, knowing what has been tested.
Device reporting
Integrity evidence only helps while devices keep reporting to your verification server. Otukan’s verification side shows which devices stopped reporting and applies the rule you set for them. Signing and update mechanics for each release are covered on Android secure firmware updates.
Qualification for the long term
Maintenance is decided at qualification, not at the end. For each model, Otukan and the parties in the programme agree a maintenance record before the first device ships.
What the maintenance record contains
- Supported models. Each model and hardware revision, and its firmware baseline.
- Update authority over time. Who builds, signs and approves releases, and who takes over if a party leaves.
- Maintenance period. The agreed period, and the chipset support date it relies on.
- Re-qualification triggers. Android version upgrades, chipset packages, hardware revisions and changes of firmware builder.
- Retirement procedure. How devices are wiped, marked retired and closed in the record.
Questions to settle before signing
A maintenance record is only as good as the questions it answers. These are the ones most often left open until they become urgent:
- Which party carries the model if the device maker stops releasing firmware for it?
- What happens to devices still in service when the maintenance period ends?
- Who decides whether a repaired device returns to institutional use?
Field fleets that work within maintenance windows and connectivity limits are covered on critical infrastructure mobile device security. Where each model is deployed and hosted is covered on deployment options. For the wider collection, return to deployment and control.