A mobile security team evaluates supported platforms for device security by asking for the exact combinations that have been qualified: model, hardware revision, chipset and firmware build, not a general list of operating systems. Otukan treats each such combination as a platform in its own right. It is supported once Otukan’s protection is built for it, tested on the physical device and given an owner for updates until an agreed end of support. Otukan device security runs on Android-based devices whose firmware an OEM or ODM builds. iPhone and iPad sit outside its scope because Apple builds their firmware.
Integration boundary
A platform entry depends on pieces supplied by different parties. Before a platform is qualified, Otukan confirms who supplies each piece and whether it can be relied on for the life of the model.
| Platform element | Supplied by | What Otukan confirms |
|---|---|---|
| Chipset and board support package | Chipset vendor, usually through the ODM | Which hardware security features exist and how they are enabled |
| Hardware revision | ODM | That the revision in production matches the revision tested |
| Android version and security patch level | OEM build | The exact build qualified, and the owner of later builds |
| Deployment context | Institution | Whether the devices are shared, personal or dedicated, which changes the controls that matter |
Why the name is not enough
A product name is a marketing label. A mid-life hardware revision with a different chipset, memory part or secure element becomes a new platform entry, even when the name on the box stays the same. The matrix follows what is inside the device, so a support statement always refers to hardware you can identify.
Control scope
Not every control depends on the same thing. Otukan states per platform which controls it qualifies and what each one relies on.
| Control area | Relies on | When the platform lacks it |
|---|---|---|
| Boot chain verification | Verified boot with a locked bootloader on production devices | The entry records the limit, and device reports show the boot state as unverified |
| Hardware-backed keys and attestation | A trusted execution environment or secure element | Keys are software-backed, and reports are labelled so your server can weigh them |
| Privileged component hardening | Build access to the system image | The control is left out of the entry rather than half-applied |
| Integrity telemetry | A path from the device to your verification server | The device keeps its last verified state with a timestamp until it reconnects |
| Update and rollback defence | The OEM’s release process and rollback settings | The entry names the update owner who must confirm each release |
Platform statuses
Each entry carries one status, so a buyer can read the matrix at a glance.
- Qualified. Every control listed for the platform has passed its tests on the physical device.
- Qualified with stated limits. The platform is supported, and the entry names each control that behaves differently and why.
- Retired. The platform has passed its agreed end of support, and the entry records its final state.
Qualification
A support statement is worth as much as the process behind it. Otukan attaches three records to every platform entry.
- Qualified combination. The combination qualified, the controls tested on it and the test results kept with the entry.
- Release authority. The party that approves and signs releases for the platform, and the retest each release receives before rollout.
- Maintenance horizon. The end-of-support date and what happens to the platform’s devices after it.
Reading the matrix as a buyer
Each reader takes something different from the same row. Engineering checks that the firmware build and hardware revision match what the factory produces. Security checks which controls are qualified and whether any stated limit matters for the threats it cares about. Procurement checks the update owner and the end-of-support date against the years the devices must stay in service. When all three agree, the platform is ready to buy or ship.
When the platform changes
Platforms move during their life. A new Android version, a new security patch baseline, a changed hardware revision or a replacement chipset each triggers requalification before the changed build ships. The matrix keeps the history, so your team can see which builds carry which qualified protection on devices already in the field.
The steps for checking your own hardware before a programme are listed on the hardware compatibility evaluation implementation guide. Hardware-rooted features are covered on hardware-backed mobile security. For the parent topic, see OEM device security integration.