Otukan device management takes security findings as structured input and turns each one into a management response your teams approved in advance. Findings come from three sources: integrity signals from devices carrying Otukan device security, runtime findings from work apps protected by Otukan application security, and the posture reports every managed device already sends. Your security team decides what each finding means and how severe it is. Your fleet administrators decide which management response each severity may trigger. Reversible responses run as agreed; a wipe always waits for a person. Missing signals are treated as a state of their own.
Interface
Otukan brings security evidence to the place where management decisions are made: the device record.
Event sources
| Source | What it reports | Where it applies |
|---|---|---|
| Otukan device security | Boot state, patch level, security settings, verified against expected values for the model | Devices built with Otukan firmware-level protection |
| Otukan application security | Root or jailbreak indicators, hooking, tampering, observed at runtime in a protected app | Managed work apps protected with Otukan, reported per platform |
| Management posture | Passcode status, OS version, policy status | Every enrolled Android and Apple device |
The sources are complementary, not interchangeable. A firmware integrity signal describes the device beneath the operating system; an in-app finding describes the environment one app runs in; a posture report describes what the management framework can see. Otukan keeps each labelled with its source so nobody reads more into it than it says. How integrity signals are produced and verified is covered on device integrity signals.
Transport
Signals reach Otukan device management through a documented, authenticated interface, and arrive on the device record alongside inventory and policy status. Findings and the responses taken can also be forwarded to your security monitoring system, so analysts see management’s side of the story without logging into the console.
What a finding carries
Each finding arrives with the device it concerns, the source that raised it, what was observed, when it was observed, and the severity your security team assigned to that finding type. Otukan adds the device’s group, owner and current policy status from the inventory, so the person reviewing it sees the whole situation on one screen rather than cross-checking two tools.
Decision authority
A security signal is evidence. A management action is a use of administrative power. Otukan keeps them apart.
- The security role defines which findings count, sets their severity and reviews outcomes. It cannot change policy or run remote actions.
- The fleet administrator role approves which management response each severity may trigger, for which device groups. It cannot reclassify a finding.
- The person on duty handles anything outside the agreed map, and any destructive step.
This split protects both sides. A new detection rule cannot quietly gain the power to wipe devices, and an administrator cannot silence a finding by editing policy. Every change to the map is logged against the person who made it. Reviews of the map are scheduled, too: your security and fleet leads look at which findings fired, which responses ran and which releases followed, and adjust severities or responses together.
Response
Each finding type and severity leads to one approved response, and each response has a defined failure path.
| Finding | Approved response | If the response cannot run |
|---|---|---|
| Firmware integrity failure | Move to restricted group; notify security | Device offline: response queued, finding stays open |
| Root or jailbreak indicator in a work app | Withdraw sensitive work apps | App cannot report: device listed as silent |
| Tampered managed app | Reinstall the genuine app through managed distribution | Reinstall fails: escalated to the person on duty |
| Posture drift | Flag non-compliant; set a recovery period | Period expires: restricted group applied |
| No signal from an expected source | List as silent; ask the device to report | Still silent: handled by the person on duty |
A restricted group is the workhorse. It withdraws work apps and network profiles while leaving the device managed, which contains the risk and keeps the evidence intact for review. When the device checks out, an authorised person releases it and the reason is recorded next to the finding. Group placement and remote actions are covered on MDM remote device management.
For how this fits the wider product, see mobile device management and mobile device security.