Press play to start listening
Allowing employees to use their own phones for work sounds simple. Deciding how much control IT should have over those devices is where it gets complicated.
Personally owned smartphones are now a routine part of the corporate environment. The UK government’s 2025/26 Cyber Security Breaches Survey found that, among businesses with cybersecurity policies, 58% said those policies covered the use of personally owned devices for business activities.
Mobile device management (MDM) is one way companies bring some order to a mix of corporate and personal devices. The same platform may be able to register devices, install certificates, push applications, change network settings, and remotely lock or wipe hardware when needed.
With that much authority in one system, risk is no longer limited to individual devices. The MDM server, administrator identities, APIs, onboarding paths, certificates, and integrations create attack paths of their own. That is why MDM needs its own threat model, not just a role as an endpoint control.
Centralized Control Creates a Larger Blast Radius
Mobile device management gives IT a central place to configure company phones, tablets, and laptops. Some deployments also apply selected controls to personal devices. A threat model should start with what the platform is allowed to do.
List the privileges, as opposed to just the product features, to assess true compatibility with zero trust principles. Can an administrator install a certificate without user action? Can a policy send traffic through a different VPN? Can an app be pushed to an entire device group? Can someone reset a passcode or erase company data remotely?
Create a document with those permissions, and the scale of the risk becomes easier to see. One compromised employee account may stay fairly contained. In contrast, an MDM role that controls device onboarding, configuration, and remote actions can reach many devices.
Include the MDM service itself. Record where administrator credentials are stored, how enrollment tokens are issued, which certificates it can install, and which integrations can change policy.
Administrative Access Creates Its Own Attack Paths
An administrator login is an obvious entry point, but MDM platforms also connect to identity providers and services for support, automation, certificates, or application delivery. APIs and service accounts connect many of those pieces.
Permissions can spread through those connections. An inventory token may be able to change policy. A help desk role may retain rights it no longer needs. An old integration may still have access without regular review.
MFA protects interactive console access, but it cannot cover a vulnerable API or a leaked service credential. Threat modeling needs to follow each route that can acquire administrative authority and record where its credentials live.
The logs should make unusual use obvious. A new administrator appearing overnight is worth investigating, for instance. The same goes for a read-only inventory account suddenly changing policy for hundreds of devices.
Enrollment and Policy Changes Extend Trust
During enrollment, the organization decides which device is allowed into the managed environment. That device may then receive configuration, applications, certificates, or access to company resources. Weak identity checks or reusable registration credentials give attackers another way in.
A policy edit can have just as much reach. A configuration profile may alter a VPN, install a certificate, change password requirements, or control which apps can reach company data. An attacker with administrative access can use those functions without placing malware on every device.
Audit trails should make high-impact changes easy to reconstruct. Investigators need to know which account made the change, what was changed, which devices received it, and whether there was an approved request behind it.
Recovery planning should cover MDM-specific credentials, too. A compromised signing certificate or enrollment secret creates a different cleanup job from a stolen user password. Teams need a tested way to revoke the credential, reissue what is necessary, and identify devices that require another check.
BYOD Changes the Security Boundary
Personally owned devices change the boundary. IT may control a work profile or selected apps while the employee controls the rest of the device. A threat model should reflect those limits rather than assume every enrolled device is fully managed.
Start with the company data that can reach the device. Record which apps can open it and what happens when the device falls out of compliance. Then check what telemetry the MDM platform really provides. Information available on a corporate-owned phone may be unavailable, or inappropriate to collect, on a personal device.
During an incident, the company may be able to remove corporate data from a work container while seeing very little of what happened elsewhere on the device. Identity controls, application restrictions, and data isolation may have to carry more of the load.
Privacy also affects whether people cooperate with the scheme. Excessive collection can encourage workarounds or or push employees to opt out. The UK National Cyber Security Centre notes that BYOD can limit the device-wide controls an organization is able to enforce and may require a mix of mobile device management and application-level controls. A narrower, clearly explained scope gives users and responders a better idea of where company control begins and ends.
The Management Layer Can Fail Independently
A tabletop exercise is a good place to find assumptions that never made it into the documentation. Start with a compromised MDM administrator identity, a leaked API token, or an internet-facing management service and follow the access from there.
Ask how quickly the account can be disabled and whether recent policy changes can be found. Can the team trace remote commands back to a specific administrator or service account? How would it rotate secrets or certificates without disrupting the whole workforce?
Then verify the technical side. Check what is exposed to the internet, whether the platform is patched, and which roles or service accounts can make changes. Review API access and logs too. Remote wipe and similar destructive functions deserve tighter controls. If the platform supports granular roles or secondary approval, use them for actions that can affect a large group of devices.
Check the management service itself, not only the enrolled endpoints. Patch it promptly, limit unnecessary internet exposure, and review old integrations and service accounts. A well-managed device fleet can still be put at risk if the MDM system itself is neglected.
Secure the System That Manages the Devices
MDM is useful because it gives IT one place to enforce policy across a scattered device fleet. That reach also means a compromised administrator, API token, certificate, or integration can affect far more than one phone or laptop.
Looking at the MDM system separately during threat modeling makes those paths easier to see. Teams can tighten access, watch for unusual changes, and plan recovery around the parts of the platform that could otherwise spread an incident across the fleet.
