Otukan lets authorised administrators lock, restart, reset the passcode of, or wipe a managed phone or tablet from the console. Which of these a device accepts depends on its platform and enrolment mode: corporate-owned devices take the full set, while personally owned devices only ever lose their work data. Your roles decide who may run each action and on which device groups, and a full wipe can require a second approver. Each command is tracked until the device confirms it, queued if the device is offline, and recorded against the people who asked for it.
Action matrix
The platforms set what a management service may do in each mode. Otukan maps those rules for your fleet and shows administrators only the actions a given device accepts.
| Action | Android, corporate-owned | Android, work profile on personal device | Apple, supervised | Apple, User Enrollment |
|---|---|---|---|---|
| Lock | Yes | Work profile locked | Yes | Not available |
| Passcode reset or clear | Where the Android version allows | Work profile challenge, where supported | Clear passcode | Not available |
| Restart | Fully managed and dedicated devices | Not available | Yes | Not available |
| Wipe | Full device wipe | Work profile removed | Full device erase | Managed apps, data and account removed |
| Lost-device handling | Lock with a contact message | Not available | Managed Lost Mode | Not available |
| Refresh inventory | Yes | Yes | Yes | Yes |
The columns are separate on purpose. An Android work profile and Apple User Enrollment both protect personal data, but they permit different actions, and Otukan does not treat one as the other. Dedicated Android devices follow the corporate-owned column.
For kiosk-specific recovery, see Android kiosk management.
Authorisation
Remote actions reach devices people depend on. Otukan keeps the power to act and the effect on the user in plain view.
Administrator permissions
- By action. Lock and passcode reset can sit with the help desk; restart and wipe with fleet administrators.
- By device group. A regional team acts only on its own region’s devices.
- By approval. A full wipe can require a second administrator to approve it before the command is sent.
- By record. Every request and approval carries a named person, never a shared account.
What the user sees
A lock takes effect when the device receives the command and, on corporate devices, can show a message with a number to call. Managed Lost Mode on a supervised Apple device displays your message until an administrator lifts it. On personal devices, staff can see in the platform’s own settings which organisation manages the work side and what it can do. Telling users in advance which actions exist, and why, keeps trust intact when one is used.
Reissuing a device
A wipe is often the start of a device’s next life rather than the end. After a corporate device is wiped, Otukan keeps its record, marks it as awaiting reissue and, when it is set up again through the bulk-enrolment channel, places it back under management in the group of its new user. The history of who held it, and what was done to it, stays attached to the record.
Failure handling
A command is not finished until the device confirms it. Otukan tracks each one through clear states.
| State | Meaning | What happens next |
|---|---|---|
| Sent | Command issued from the console | Delivered at the device’s next contact |
| Queued | Device offline or unreachable | Held until reconnection; can be cancelled by an authorised administrator |
| Acknowledged | Device has received the command | Otukan waits for the result |
| Completed | Device reports success | Inventory refreshes and the log closes the entry |
| Failed | Device reports an error or the mode rejects the action | Reason shown; the administrator chooses the next step |
A wipe is usually the last message a device sends, so Otukan records its acknowledgement before the erase begins and marks the device as retired afterwards. Each entry in the audit log holds requester, approver, device, time and result, which gives security and audit teams the evidence they need without piecing it together from several screens. Repeated failures on one model or group are visible in the command history, so a configuration problem is fixed once instead of worked around device by device.
Remote actions sit alongside enrolment, policy and inventory; the full product is covered on mobile device management.