Mobile device management is a protocol. Your employer runs a server that sends commands to a client built into iOS or Android, and the operating system decides which commands it will honour. That decision is not made by the MDM vendor and cannot be bought around. It is made by the enrollment type, which is fixed at the moment you enrolled.
So the useful question is never "what can our MDM do." It is "which enrollment am I under," and there are four common answers with very different consequences.
Android: the boundary is a separate profile
On a personal Android phone, work enrollment normally creates a work profile. This is a second user profile on the same device with its own storage encryption, its own copies of apps (the ones with the small briefcase badge), and its own accounts. The management agent holds profile owner rights, which are scoped to that profile.
Inside the boundary, the administrator can install and remove work apps, set a passcode requirement for the profile, block copy and paste between profiles, read work app inventory, and remotely wipe the work profile without touching the rest of the phone. Outside it, the operating system does not offer them a way in. They cannot enumerate your personal apps, read your personal accounts, see your photos, read SMS or call logs, or see what you do in your personal browser.
They do see device-level facts that are not profile-scoped: manufacturer and model, operating system version and security patch level, whether the bootloader is unlocked or the device fails an integrity check, and network usage attributable to work apps. On a personal device those are inventory and compliance facts, not content.
Fully managed enrollment is the other Android mode, where the agent holds device owner rights over the whole phone. This is meant for company-owned hardware and it changes the answer entirely: the full app inventory is visible, the whole device can be wiped or restricted, and hardware identifiers are readable. A device owner agent that has been granted location permission can query location.
iOS: the boundary is a separate volume
Apple's equivalent for personal devices is User Enrollment, and it works differently in a way that is worth knowing. Instead of a second profile, it creates a cryptographically separated data volume for managed apps and accounts, tied to a work account rather than to your Apple Account.
In this mode, MDM deliberately cannot read hardware identifiers such as the serial number or IMEI, cannot list your personal apps, cannot erase the device, and cannot access personal data. When you leave, unenrolling destroys the managed volume's key and the work data becomes unreadable, and your own data is untouched.
Device Enrollment on supervised hardware is the company-owned path, and it is considerably broader. A supervised device can be wiped remotely, can have apps installed silently, exposes its full app inventory and its serial number, and can be locked into a restricted configuration. Location can be queried when the device is placed in Lost Mode.
| Capability | Android work profile | iOS User Enrollment | Company-owned, either platform |
|---|---|---|---|
| List personal apps | No | No | Yes |
| Read personal email, SMS, photos | No | No | Not directly by MDM |
| Wipe the whole device | No, work data only | No, managed data only | Yes |
| Read serial number or IMEI | Model and OS level | No | Yes |
| Query device location | No | No | Yes, via Lost Mode or a permitted agent |
| Install a trusted root certificate | Into the work profile | Scoped to managed apps | Device-wide |
The certificate is the escalation that matters
Every row above is about what the management channel can query. The more consequential capability is one that reads as routine on a compliance checklist: an MDM can install a certificate authority into the device's trust store, and pair it with a VPN or proxy configuration.
Once your device trusts a certificate authority the employer controls, a proxy on the path can present a certificate for any site, and the connection will validate. That is TLS interception, and it turns encrypted browsing into readable text at the gateway. The MDM never had to read anything off your phone; it changed which certificate authorities your phone accepts.
On a company-owned device the certificate goes in device-wide, so a full-tunnel VPN routes personal traffic through the same inspection. Under Android work profile and iOS User Enrollment the trust is scoped to the managed side, which is precisely the reason those enrollment types exist. On a personal device, a device-wide certificate install is the thing to question.
Two things survive interception. Traffic to an app that uses certificate pinning will fail rather than be silently decrypted, because the app checks for a specific key rather than for any trusted authority. And content that is end-to-end encrypted at the application layer stays encrypted through a decrypting proxy, because the proxy only ever gets the transport layer. What the proxy does get either way is the destination, the timing and the volume.
The agent app is a separate question from MDM
Some deployments add a vendor agent app on top of the operating system's management channel, and an app can request permissions the MDM protocol does not grant. On Android, an app running as an accessibility service can read screen contents across the device. On either platform, an app with screen recording or usage-statistics access can report far more than an inventory.
This is worth separating in your head, because "MDM cannot see your personal apps" can be entirely accurate while an agent app you also installed reports your app usage. The permission screens are the source of truth, not the enrollment type.
How to check yours
On iOS, open Settings, then General, then VPN & Device Management. Select the management profile and read the details. It lists what the profile installs: certificates, VPN configurations, restrictions, accounts. A User Enrollment profile and a supervised device look different here, and a supervised device also says so on the Settings home screen.
On Android, the work profile appears as a separate tab in the launcher and in Settings. Android also exposes a screen describing what the administrator can and cannot see and do on your device; on most builds it is reachable from the work profile section of Settings or from the management app's own information page. Check Settings, Security, for device admin apps, and check installed CA certificates under the encryption and credentials section.
If the phone is yours, the two questions worth asking IT in writing are which enrollment type is in use, and whether a device-wide certificate authority is being installed. Both have short, factual answers, and both are visible on the device regardless of the answer you get.
What this changes in practice
For most people on a work profile or User Enrollment, the accurate picture is narrower than the anxiety and wider than the reassurance. Your employer sees an inventory, a compliance state, and everything you do inside work apps. They do not see your personal side. They may see the destinations of your traffic while on the corporate network, and if a certificate went in device-wide, potentially its contents.
The answer that does not depend on a policy staying as it was written when you enrolled is a second device, or at least a personal profile the employer does not manage. That is the same principle as browser compartmentalization, applied one layer down.
Haven runs as an ordinary app with its own encrypted local storage, and messages are encrypted before they leave the device, so a network path that inspects traffic gets the same ciphertext everyone else gets. Where an app performs its encryption determines what survives an inspecting proxy, and it is a question with a checkable answer for any app you rely on.