Devices That Refuse to Enrol

A proportion of devices will not enrol. The reasons differ and so do the responses, and treating them all as user error wastes time.

The boundary described in “Devices That Refuse to Enrol” should also govern any workforce system introduced alongside device management. When a team evaluates how to detect mouse jigglers for how to detect mouse jigglers, it should explain the purpose, choose only the necessary settings and give employees a clear account of what managers can review.

Operating system too old

The commonest technical cause.

For an independent baseline relevant to “Devices That Refuse to Enrol”, the ICO employment-practices guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

Your platform requires a minimum version; the device is below it and may not be upgradable.

This is a hardware refresh conversation rather than a support ticket, and on personal devices it is a difficult one because you are asking somebody to replace their own phone.

Jailbroken or rooted

Enrolment may succeed and compliance will fail, or the platform refuses outright.

The security concern is genuine: the operating system guarantees the whole arrangement depends on no longer hold.

Refuse work data on these, and say why in terms of what breaks rather than as a rule.

Still managed by somebody else

A device previously enrolled elsewhere and not released: a former employer, a reseller, a previous owner.

Visible as an enrolment failure that looks like a bug.

Resolution is with the previous organisation or the manufacturer, and it can take days, which should be known before somebody's first day.

Region or carrier variants

Some models differ by market in ways that affect management capability.

Rare, frustrating, and worth knowing when it appears rather than debugging from scratch.

Devices the user will not hand over

Not a technical failure.

A personal device whose owner has decided not to proceed, expressed as a technical problem.

Recognise it, and move to the alternative route rather than troubleshooting, which saves everybody's time and the relationship.

What to do about each

Too old: offer a loaned device or application-management access, and raise the refresh.

Jailbroken: refuse work data, explain, offer a loaner.

Previously managed: start the release process immediately, because it is slow.

Will not proceed: the alternative route.

Recording the exceptions

Who is not enrolled, why, and what they have instead.

With a review date.

Because the population outside the programme is the one nobody is watching, and it grows quietly if nobody counts it.

The minimum version decision

Setting it high excludes people; setting it low admits devices the platform cannot secure.

Choose it deliberately, write the reason, and review it annually as support windows move.

And give notice before raising it, because somebody will need to buy a phone.

What to check

Do you know how many people are outside the programme, and why?

Is there a documented minimum version with a reason?

What happens when a device is still managed by somebody else?

And is there an alternative route for each failure cause?