Management authority and threat detection are different capabilities. Mobile device management (MDM) holds the right to enrol a device, set its policy, install its apps and lock or wipe it. Mobile device security looks for what is wrong: a tampered system, a malicious app, an unsafe network, an outdated patch level. An MDM can confirm that a device follows the rules you set; it cannot, on its own, see an attack that breaks none of them. A strong fleet programme uses both and wires them together. Scope differs between Android and Apple devices and is agreed per platform.
Device management
- Enrols the device into your organisation
- Applies passcode, network and app policy
- Reports whether the device matches that policy
- Locks, restricts or wipes when told to
Device and app security
- Checks the system and firmware for tampering
- Watches apps for hooking, tampering and abuse
- Reports what is happening on the device now
- Informs a decision rather than enforcing one
Provisioning, policy and protection
Provisioning
Provisioning puts a device under management. On Android this runs through Android Enterprise, with zero-touch or QR enrolment for company-owned devices and a work profile for personal ones. On iPhone and iPad it runs through Apple’s device management framework, with automated enrolment for devices the organisation buys. Whoever holds this channel holds authority over the device, which is why the channel is granted by the platform to a registered management service and not claimed by any app that asks.
Policy
Policy is what the management service enforces through that channel: passcode rules, restrictions, network and certificate settings, required apps, kiosk mode. It also produces compliance status, a statement that the device matches its configuration.
Protection
Protection looks for threats the configuration does not describe. On the device side that means integrity of the operating system and firmware, boot and patch state, and hardened system components. Inside apps it means runtime checks for hooking, tampering, rooting or jailbreaking and malicious behaviour. Mobile threat defense products sit in this category, usually as an app that reports risk to other systems.
| Role | Main question | Typical output | Holds authority to act? |
|---|---|---|---|
| Provisioning | Is this device ours and set up? | Enrolled device in the right group | Yes |
| Policy | Does it follow our rules? | Compliance status per device | Yes |
| Device protection | Has the system been tampered with? | Integrity and state evidence | No, it informs |
| App protection | Is this app under attack right now? | Runtime threat signals | Within the app only |
Why compliant does not mean safe
A compliance dashboard can show every device green while an incident is under way. A field tablet with a strong passcode, encryption on and the required OS version can still carry an app that abuses accessibility to read the screen. A phone running a modified system image can still report settings that match policy perfectly, because the settings are exactly what the attacker left alone.
How signals and management actions connect
The strongest setups treat security findings as inputs to management policy. The loop below is the shape to aim for, whichever suppliers you use.
Detect
Device or app protection raises a signal, such as an unlocked bootloader.
Report
The signal reaches the management service and, where relevant, your backend.
Decide
A policy you own maps the signal to an action per device group.
Act
The device moves to a restricted group, loses sensitive apps or is locked.
Recover
Once the condition clears, the device returns and the event stays logged.
Each step has an owner. Without the policy in the decide step, a detection is only a report, and a management action is only a guess. A written mapping keeps the decision explicit and reviewable. The table below is an example policy to adapt, not a default.
| Signal | Source | Example action | How the device recovers |
|---|---|---|---|
| Bootloader unlocked or boot chain not verified | Device protection | Move to a restricted group, remove access to sensitive apps | Reflash an approved image and re-verify |
| Patch level below your minimum | Device protection or management inventory | Require the update within a set window | Update installs and the new patch level is reported |
| Hooking framework in a line-of-business app | App protection | Block that app’s sensitive actions for the session | A clean session is observed |
| Device reported lost | User or support desk | Lock the device remotely | Identity is confirmed and the device is unlocked |
| Device not seen for a long period | Management service | Flag for review, then retire | The device checks in, or is wiped and re-enrolled |
Buying without false assumptions
Procurement goes wrong when a buyer assumes one product brings the other along. A management platform with a compliance dashboard is not a threat detector, and a threat detector without the management channel cannot move a device into a restricted group. Ask these questions for each workflow before you compare offers:
- Which party holds the management channel on Android, and which on Apple devices?
- Which threats does the offer detect, on which platforms, and where does the evidence come from?
- Which signals can trigger which management actions, and who writes that policy?
- How does a restricted device return to normal, and who approves it?
- Where does management data and security evidence live, and who can access it?
- Which parts does the supplier build and operate itself, and which depend on platform services?
Where Otukan fits
Otukan offers the three pieces as products that work together. Otukan device management enrols Android devices through Android Enterprise, including zero-touch and QR provisioning, and iPhone and iPad through Apple’s framework with Automated Device Enrollment, applies policy per group, keeps an inventory and logs every remote action against the administrator who ran it. Otukan device security reports boot state, patch level and security settings from Android-based devices, and Otukan application security reports runtime threats from inside your apps. Device management acts on those signals under a policy you set, Otukan states per workflow what it builds and operates and which platform services it relies on, and you decide where management data is hosted.
For the product, see mobile device management.