Mobile Device Management Is a Real Blind Spot

Mobile device management is one of the few areas of IT where almost everybody buys the software and a surprising number never switch it on.

A survey by IAITAM of the largest US counties found that very few required across-the-board installation of MDM software on the mobile devices they had issued to their own employees. The association’s position was blunt: plenty of organisations manage servers, desktops and laptops competently and then treat phones and tablets as somebody else’s problem. Those devices hold the same mail, the same documents and the same credentials as the laptop. They are simply easier to leave off the register.

That is the blind spot. Not a missing product — a missing policy.

What mobile device management actually covers

MDM deals with the deployment, security, monitoring, integration and ongoing management of mobile devices at work. The point is to make the devices useful while keeping them, and the network they connect to, defensible.

When you assess a tool, the questions that matter are narrower than the vendor pitch:

• Which platforms are genuinely supported? iOS and Android are the two that matter now. Support that amounts to a configuration profile and nothing else is not support.
• How does a device get enrolled? Enrolment and configuration have to be something a service desk can do at volume, not a per-device ritual.
• Can it tell corporate-owned from personally owned? The two need different policies. A tool that cannot distinguish them will either be too strict for BYOD or too loose for corporate kit.
• What happens when a device is lost or stolen? Lock, locate, wipe — and crucially, evidence that the wipe completed.
• Can you control devices in high-risk locations? Shared iPads in schools, hospitals and warehouses are the classic case: high value, high turnover, low individual accountability.
• Can it detect a jailbroken or rooted device? A device with its security model removed should not be holding company mail, and you need to know automatically rather than on inspection.

None of that is exotic. It is the baseline.

The failure mode is departmental discretion

The most instructive example remains San Bernardino County in 2016. The county had mobile device management software available. The device at the centre of the subsequent legal dispute between Apple and the US Department of Justice did not have it installed. There was no requirement across the organisation that it should be; individual departments decided for themselves.

That pattern repeats everywhere, and it is worth being honest about why. Local discretion is not laziness. It is what happens when MDM is procured as a security product, owned by one team, and rolled out department by department on the basis of persuasion. Every department that says no is a legitimate business decision at the time, and collectively they produce a fleet nobody can account for.

The fix is not a better MDM product. It is making enrolment a condition of issuing a device at all, and then being able to prove — continuously, not at audit — which devices are enrolled and which are not.

That proof is an asset management problem, not a mobility problem. If your mobile devices live in a separate console with a separate list of users, you can only ever compare two lists and argue about the difference.

What this looks like in CerteroX today

When this article was first written, mobile management was a product you bought next to your asset management tool. It is now part of it.

Mobile is an asset class, not an integration. CerteroX ITAM manages iOS and Android devices directly, including Apple Device Enrolment Program enrolment, and there is a Microsoft Intune connector for environments already standardised on it. The devices land in the same inventory schema as Windows, macOS, Linux, AIX, HP-UX and Solaris machines. There is no reconciliation step between “the MDM list” and “the asset list”, because there is one list.

The policy is enforced as code, not as a document. Governance Policies use a reusable filter builder to express a condition and then report continuously against it — the same mechanism that checks BitLocker is enabled or Defender is running on a laptop will tell you which issued devices are unenrolled, or jailbroken, or have not reported in. Policy definitions export and import as JSON, so the rule itself is reviewable and version-controllable rather than living in a slide deck.

Departmental discretion becomes departmental visibility. Zones segment data between entities, and Reporting Levels restrict what each part of the organisation can see by organisational unit or location. A department can be given its own view of its own devices without being given the ability to opt out of the standard. Role-based access control does the rest.

Enrolment can be part of the request, not an afterthought. The App-Centre self-service portal carries manager approval chains, so provisioning a device or an application runs through an approval path that the asset record then reflects.

The question worth asking

Ask how many mobile devices your organisation has issued. Then ask how many are enrolled in management. If those two numbers come from two different systems, you do not have an answer — you have an estimate, and the gap between the two figures is your actual exposure.

Mobility brings real benefits and they are worth having. But they are worth having under management, and management starts with a policy that applies everywhere and a register that can prove it.

To see what device numbers look like when they come from one system rather than three, book a demo.