Evaluate managed app integration by first drawing the line between three jobs: protecting the app itself, managing the app on a device and administering the whole device. Then list the dependencies each option brings, such as policy source, tenant and distribution channel, and test how the app behaves when a device is enrolled, unenrolled or handed to a new owner. This guide is for enterprise mobility and security teams deploying internal or partner apps on Android and iOS, each scoped separately. Otukan offers application security and device management as separate products that work together, so you set the boundary that fits your fleet.
The capability is covered on managed app integration.
Boundary
Many evaluations stall because app protection, app management and device administration are bought as one blurred requirement. Separate them and each question gets a clear owner.
| Job | What it controls | Usual owner |
|---|---|---|
| App protection | The app’s code, its runtime behaviour and the signals it sends | App owner with the security team |
| App management | Installation, configuration and data rules for managed apps | Enterprise mobility team |
| Device administration | Enrolment, device-wide restrictions, updates and wipe | IT operations |
Which jobs you need
- Are the devices company-owned, personally owned with a work profile on Android or user enrolment on iOS, or not managed at all?
- Must the app also run on devices you will never manage, such as those of partners, contractors or customers?
- Which rules must hold inside the app whatever the device state: runtime protection, integrity checks, the response to a compromised device?
- Which rules belong to the device: passcode, encryption, operating system update policy?
How Otukan answers. Otukan Application Security protects the app wherever it runs, managed or not. Otukan MDM enrols company devices, applies policy and distributes apps. Use either product alone, or both when one team wants to see the app and the device side by side.
Integration
Every managed app setup leans on something outside the app. Write those dependencies down before you compare options, because they decide the effort and the risk.
Dependencies to confirm
- Policy: where are app settings defined, and how do they reach the app? Android uses managed configurations; iOS uses managed app configuration delivered by the device management service.
- Tenant: which management tenant owns the app, and what happens when subsidiaries or partners run their own?
- Distribution: managed Google Play on Android, Apple’s custom app distribution on iOS, or a private channel?
- Code: what, if anything, must be added to the app, and who keeps it current through each OS release?
- Signing: who signs the final build, and does any step expect access to your signing keys?
Policy ownership map
| Setting | Lives in | Owner | Approver |
|---|---|---|---|
| Response to a compromised device | App protection policy | Security team | Application owner |
| Server endpoints and feature flags | Managed configuration | Mobility team | Application owner |
| Copy, share and screenshot rules | Device or work profile policy | Mobility team | Data protection lead |
| Install and remove the app | Device management | IT operations | Mobility team |
How Otukan answers. Otukan protection fits your existing build and release pipeline, and your signing keys stay with your team. Protected apps travel through the channel you already use, including Otukan MDM when you run it. Protected apps read the settings you deliver through Android managed configurations and iOS managed app configuration, while integrity and runtime checks stay part of the build and cannot be switched off from there. We work through the ownership map with you, so every setting has a single home and a named owner.
Operations
A managed app is judged on its worst day: a lost phone, a leaver, a compromised device that is still enrolled. Test those days before rollout.
Enrolment-related behaviour
- What does the app do when it starts on a device that is not enrolled, or whose enrolment was removed?
- How does it behave on a rooted or jailbroken device that still reports as enrolled?
- What happens if managed configuration has not arrived by first launch?
Data separation
- Is corporate data confined to the managed app or work profile, and have you tried to move it out through copy, share and screenshot paths?
- On Android, have you tested inside and outside a work profile? On iOS, with managed open-in restrictions switched on?
Offboarding
- When a device is retired or an employee leaves, what is removed: the app, its data or the whole device?
- Does your backend revoke sessions at the same moment, so a copied token stops working?
| Test | Managed device | Unmanaged device |
|---|---|---|
| First launch | Configuration applied, app opens | Expected fallback, documented |
| Compromised device | Signal received, response applied | Signal received, response applied |
| Data leaves the app | Restricted by work profile or managed app policy | Handled by app-level rules |
| Offboarding | App and data removed, session revoked | Session revoked by the backend |
How Otukan answers. At start-up, the protected app checks its installation source and its managed configuration, and keeps corporate functions locked until the expected policy is in place. If that configuration is removed, the app applies your offboarding rule, such as clearing cached corporate data and asking for sign-in again. Otukan runtime threat signals reach your backend whether or not the device is managed, so a compromised device that is still enrolled stays visible. With Otukan MDM, retiring a device removes managed apps and their data from the same console that enrolled it.
Device-side distribution is covered on MDM app management.