MDM is not mobile security
Device management tells you a handset complies with your policy. It does not tell you the handset is being attacked. That gap matters.
Here is a conversation we have had more than once.
“Are the phones secured?” “Yes, they are all in the MDM.”
Those are answers to different questions. The second one is true and does not address the first.
What MDM actually tells you
Mobile device management is a configuration and compliance system. It is very good at what it does:
- The device is enrolled and supervised
- The passcode policy is applied
- The OS version is at or above the minimum you set
- The device is not jailbroken or rooted, by the checks the platform performs
- The approved applications are installed and the prohibited ones are not
Every one of those is a statement about configuration state. None of them is a statement about whether anything hostile is happening.
An enrolled, supervised, fully patched, policy-compliant handset connected to a malicious network, running a legitimate app that is exfiltrating data, with a user who has just tapped a link in an SMS, will report as green in every MDM console on the market.
The four things that are actually happening
Mobile attacks do not look like desktop attacks, and this is the reason the gap goes unnoticed.
Network. Rogue access points and interception on public and semi-public networks. Mobile devices roam onto untrusted networks constantly and by design — that is the point of them.
Device. Exploits against the OS itself, including chains that do not require the user to do anything. These are expensive and therefore targeted, which makes them a government and defence concern specifically.
Application. Not just malware. Legitimate applications with excessive permissions, embedded SDKs that transmit device and location data to third parties, and apps whose data handling would fail your own policy if anyone read it.
Phishing. The dominant vector, and the one where mobile is structurally weaker. On a handset the URL is truncated, the sender is harder to inspect, the message arrives through SMS or a messaging app rather than a filtered mail gateway, and the user is usually walking.
Why the mobile fleet is monitored least
Most organisations have endpoint detection on their laptops, a SIEM ingesting from their servers, and nothing at all reading from the devices that leave the building every day.
The reasons are consistent:
- The devices were procured as telephony, not as computing
- Privacy concerns — legitimate ones — made organisations cautious about monitoring
- The MDM console is green, and it is the only console anyone looks at
The privacy concern is the one worth taking seriously, and it is also the one that has an answer. On-device detection engines perform their analysis locally. They report risk to the organisation without shipping the user’s traffic, messages or browsing to a cloud service for inspection. That distinction is what makes mobile threat defence deployable on devices people also use personally.
What “closing the gap” looks like in practice
It is not another console for somebody to ignore. Three things have to be true:
Detection has to work offline. The moments that matter are frequently the moments with no reliable connectivity. An engine that phones home to make a decision is not useful in the field.
A detection has to change access. If a compromised device keeps its access until a human reads an email, you have bought telemetry, not protection. The signal has to reach conditional access and quarantine the device automatically.
Somebody has to tune it. Every detection platform is noisy on day one. If nobody suppresses the false positives, the alerts get muted within a month and the capability is dead. This is an operating commitment, not a deployment task.
The short version
MDM answers “is this device configured the way I said?”
Mobile threat defence answers “is this device under attack right now?”
You need the first one to run a fleet. You need the second one if the fleet holds anything worth taking.