Evaluate deployment options for device security on two axes: how Otukan’s protection reaches the device, and where the services that verify and maintain it run. Protection enters either through the production firmware image on new devices or through a signed firmware update on devices already in service. Verification and update services run in your environment, on an isolated network or with Otukan. Each combination moves work between the OEM, ODM, chipset vendor, institution and Otukan, so Otukan agrees the combination per device model before rollout. This applies to Android-based devices whose firmware an OEM or ODM builds.
Integration boundary
The deployment path decides who does what. The same protection can reach a device three ways, and each path gives the parties different jobs.
| Party | Factory integration | In-service update | Institution specification |
|---|---|---|---|
| OEM | Approves the protected image for production and signs it | Builds, signs and publishes the update for devices in the field | Commits to deliver models built to the institution’s requirements |
| ODM | Integrates the protection into the production build | Rebuilds the release that carries the protection | Builds the specified models |
| Chipset vendor | Supplies the boot chain and hardware security features the protection uses | Confirms which hardware features remain available on devices already provisioned | Confirms the hardware features the specification relies on |
| Institution | Receives protected devices and runs verification | Approves the update for its devices and confirms they installed it | Writes the requirement and accepts delivered devices against it |
| Otukan | Delivers and tests the protection in the production image | Delivers and tests the protection in the update release | Supplies the technical requirement text and acceptance tests |
Choosing a path
Factory integration suits new models and new production runs. In-service update suits fleets already deployed, where the device maker can still build and deliver firmware for the model. Institution specification suits buyers who procure devices rather than build them, and want protection written into the purchase itself.
Mixed fleets
Most programmes combine paths. An institution may receive a new model with factory integration while an older model in the same fleet takes protection through an update, and a third model is procured under a specification. Otukan keeps each model on its own record, so the fleet’s protection status is readable model by model rather than averaged across devices that differ.
Control scope
Every control depends on something outside itself. The deployment path changes which of those dependencies are available.
| Dependency | Factory integration | In-service update |
|---|---|---|
| Firmware build access | Part of the production build | Needs the device maker’s release process for that model |
| Hardware-backed keys and attestation | Provisioned during manufacture, on hardware that supports it | Limited to what was provisioned before the device shipped |
| Device reporting to your verification server | Configured before first boot | Configured by the update, then confirmed per device |
| Future updates | Planned from the first release | Depends on the model’s remaining update support |
Where the services run
Otukan’s verification and update services can run in your own environment, on a network with no external connection, or hosted by Otukan. The choice affects reporting paths and update transfer, so Otukan settles it together with the device path, not after it. Data, key custody and support access for each hosting arrangement are covered on sovereign mobile device security.
Qualification
Qualification turns the chosen path into a commitment that every party can check. It happens on physical devices of each model, not on specifications alone, and it covers the paths a device takes after delivery as well as the first boot: installing an update, returning from repair and resetting to factory state.
A deployment is ready when every model has a signed record. Otukan confirms build access, hardware security features and a reporting path for each model before rollout, and writes the result into one deployment record per model.
What the deployment record contains
- Supported models. Each model, its firmware baseline and the deployment path it follows.
- Update authority. Who builds, who signs and who approves each release for that model.
- Service placement. Where verification and update services run, and who operates them.
- Maintenance period. How long the model will be maintained, agreed in writing before the first device ships.
- Exceptions. Any control the chosen path cannot deliver on that model, stated plainly.
Operators whose field devices have limited connectivity should read critical infrastructure device security. How protection is maintained after rollout is covered on lifecycle and maintenance. For the wider collection, return to deployment and control.