Mobile devices in critical operations can be governed like any other operational asset: with a clear boundary, rules that fit field conditions and named owners for every duty. Otukan hardens the firmware of the Android-based handhelds, tablets and rugged devices that crews in energy, water, transport and utilities carry. Each device proves it runs approved firmware, receives updates inside your maintenance windows and follows an agreed recovery path when something goes wrong. Otukan works at the mobile device boundary. Control systems, plant networks and supervisory software stay with the programmes that already protect them.
Scope boundary
Critical operations mix two very different kinds of technology, and a security programme needs to say which one it covers.
| Mobile device protection (Otukan) | Industrial control-system security | |
|---|---|---|
| Assets | Handhelds, tablets and rugged devices carried by people | Controllers, plant networks and supervisory systems |
| Main question | Is this device running the firmware we approved, and can it be trusted with operational data? | Are control commands and plant networks protected from misuse? |
| Evidence | Signed boot state, patch level and firmware version per device | Network monitoring and asset inventory on the plant side |
| Owner of the decision | Operator’s mobile or IT security team | Operator’s operational technology team |
The two meet where a field device connects to an operational service, such as a work order system or a maintenance app. At that point Otukan hands over device evidence, and the service owner decides what the device may reach. Otukan does not sit inside the control network and does not replace the controls that protect it.
This boundary helps both teams. The operational technology team gains a reliable answer about every mobile device that touches its services, without installing anything on the plant side. The mobile security team gains a programme it can run to its own schedule, with evidence it can show auditors and incident reviewers. Neither team has to take on the other’s tools to get there.
Operational constraints
Field conditions shape every design choice. Otukan plans around three of them from the start.
Connectivity
Crews work in substations, tunnels, pumping stations and remote sites with weak or no coverage. Devices keep their last verified state and the time it was produced. You decide how long that state is accepted for each kind of access, so a crew can finish a task offline without leaving an untrusted device connected indefinitely.
Maintenance windows
An update must not interrupt a live operation. Otukan assigns each site or device group a window agreed with your operations team. Updates are offered only inside it, a supervisor can hold one back, and a device that misses its window catches up on its next approved connection.
Recovery
Devices fail, get lost and fall out of trust. Before deployment, Otukan agrees a recovery path for each case: the spare pool at each site, who may re-provision a device, how a device returns to trust after repair, and who is informed. Recovery is tested at a pilot site, not written only on paper. A device that has been repaired, reflashed or left in a drawer for a season goes through the same return-to-trust check before it rejoins operational work.
OEM and operator responsibilities
A secure field fleet depends on the device maker, the operator and Otukan each doing a defined part. Otukan writes the split into one table and reviews it with every release.
| Responsibility | Device maker | Operator | Otukan |
|---|---|---|---|
| Firmware build and signing | Owns | Approves releases for its fleet | Engineers integrity controls into the build |
| Expected values per model | Supplies release details | Approves the values its verification server applies | Publishes values before each release |
| Update timing | Supplies the update | Sets windows and approvals | Enforces the agreed windows |
| Access decisions | – | Owns, per service | Supplies evidence and verdicts |
| Recovery and spares | Supplies repair images | Runs the spare pool and site process | Defines the return-to-trust steps |
| Incident review | Fixes firmware issues | Leads the review | Supplies device evidence and timelines |
Where the operator also runs device management, fleet policy and remote lock sit with that team. How management and device security work together is covered on MDM security integration. Data location and key custody are covered on sovereign mobile device security. Other device security programmes are covered on device security use cases. For the full device programme, see mobile device security.