To evaluate deployment and control, ask three questions for every device model: who is allowed to change each layer, what each security control depends on to work, and who keeps it working after the first release. Otukan answers all three in writing before deployment, so an OEM or institution knows where control sits on day one and on the last day of support. The pages in this collection cover the deployment choices and the long-term maintenance of an Otukan device programme on Android-based devices.
Integration boundary
A deployment touches layers owned by different parties. The OEM decides what ships, the ODM often runs the build, the chipset vendor owns the boot chain and hardware security, and the institution operates the devices. Otukan records who integrates, signs, operates and updates each layer, per model.
Control scope
Each control rests on something else: the firmware image, the chipset’s hardware security features, telemetry reaching a server you trust, or an update path that stays open. Otukan names that dependency for every control and labels its evidence as hardware-backed or software-level, so your reviewers know exactly what each model can prove.
Qualification
Before any rollout, Otukan confirms the supported models, who holds update authority and how long each model will be maintained, and puts all three in writing. Otukan’s verification and update services run in your environment, on an isolated network or with Otukan, chosen per programme. Where Otukan’s services run and who operates them is covered on deployment options. Patching, key rotation and end of support are covered on lifecycle and maintenance. Keeping data, keys and administration in your hands is covered on sovereign mobile device security.