What MDM Cannot Do

Device management applies and verifies configuration. Several adjacent problems are handed to it and are outside what it reaches.

The practical question in “What MDM Cannot Do” is how to make work visible without confusing visibility with certainty. For teams researching employee time tracking, the product page can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.

Stop data leaving

It can contain data within a work profile and restrict copying.

For an independent baseline relevant to “What MDM Cannot Do”, the CISA mobile-device security guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

It cannot stop somebody photographing a screen with another phone, reading a document aloud, or remembering.

Containment raises the effort; it does not close the channel, and a programme sold as preventing leakage will be judged against something it cannot do.

Detect or stop an attack

It reports device state and compliance.

It does not detect malicious software, inspect traffic or respond to an intrusion.

Those are different product categories, and bundling them in a procurement does not merge the capabilities.

Make an unsupported device safe

A device past its security update window is not made safe by a passcode policy.

Compliance can exclude it, which is the right action.

But compliance rules describe configuration, not security, and an estate at full compliance running three-year-old unsupported hardware is not protected.

Tell you whether somebody is working

Check-in logs show when a device contacted the server.

People read that as a presence record and it is not one: a device checks in when it is on and connected, which is not when its owner is working.

Using it that way is performance monitoring by accident, and in several jurisdictions unlawful.

Fix an unreasonable policy

If the passcode requirement makes the device unusable, people work around it.

The platform will enforce what you set and will not tell you it was a bad idea.

The compliance breakdown will, which is the argument for reading it by condition.

Substitute for the conversation

No configuration persuades somebody to enrol a device they own.

The work profile makes the ask reasonable; it does not make it.

Programmes that deploy without explaining meet resistance that administrators experience as irrational and that is entirely predictable.

Remove the ownership question

Who bought the device determines what is permissible, and no amount of configuration changes that.

A personal device managed as though it were corporate is the same mismatch regardless of how carefully it is done.

Using this before you start

For each thing somebody hopes this will fix, ask what setting would fix it.

Where the answer is a conversation, a different product, or a hardware refresh, the programme's job is to say so rather than to absorb the expectation.

What to check

Is your programme expected to prevent data escaping?

Is check-in data used, or read, as attendance?

Does compliance in your estate mean secure?

And has anybody said out loud what this cannot do?