Intune enrollment restrictions: what they block, and what enrols anyway

Intune enrollment restrictions look like a gate and behave like a filter. They stop the ordinary user who opens Settings on a personal laptop and tries to attach it to the tenant. They are ignored, in the specific sense of falling back to a policy you probably never edited, by several of the enrolment paths a large organisation is most likely to be running in parallel. Microsoft says so in its own documentation, in a list most people never scroll to. What follows is what the restrictions cover, the paths that bypass the targeted policy, the two separate device limits that are routinely confused with one another, and the error code the service desk sees first.

Blocking enrolment is only half of the control. The other half is what happens to a device once it has been admitted, which is the job of the Intune enrollment status page. The two are configured in different places by different people often enough that the gap between them goes unnoticed until something enrols that should not have.

One disclosure before the detail. My tenant is a lab with no enrolled devices, so nothing below is a measurement. Every factual claim is taken from Microsoft’s current documentation and verified on 15 September 2026, and the judgement section at the end is labelled as judgement rather than experience.

What Intune enrollment restrictions control

There are two types and they are unrelated to each other despite sharing a blade. Device platform restrictions filter on platform, operating system version, manufacturer and ownership type. Device limit restrictions cap how many devices a single user may enrol. Each type ships with one default policy that you can edit, and Microsoft’s overview of enrollment restrictions states that Intune applies that default policy to all user and userless enrolments until a higher priority policy is assigned.

Microsoft is also unusually blunt about what these controls are worth. The same page states that they are not security features, because a compromised device can misrepresent its character, and describes them as a best effort barrier for non malicious users. That sentence is worth reading twice before anyone builds a compliance story on top of enrolment blocking. The control that survives a determined adversary is a Conditional Access policy evaluated at sign in, not a filter evaluated once at enrolment, and the design considerations for that sit in the Conditional Access policy guide.

Ownership is not a field somebody sets. It is derived, and the derivation differs per platform.

The Windows row is the one that produces support calls in both directions. A device that nobody registered is personal, and personal Windows enrolment is blocked out of the box, so the first BYOD pilot fails before anyone has configured anything. The mirror image is worse: an organisation that unblocked personal Windows during a pilot and never put it back.

What Intune enrollment restrictions do not reach

This is the section the documentation buries. Platform restrictions are applied to enrolments that are user driven. For enrolment scenarios that are not user driven, Intune enforces the default policy instead of the one you targeted at a group.

1# Enrolment scenarios that are not user driven.
2# For these, Intune enforces the DEFAULT platform restriction policy,
3# not the higher priority policy you assigned to a group.
4Windows Autopilot self-deploying mode
5Windows Autopilot for pre-provisioned deployment
6Bulk enrolment via Windows Configuration Designer
7Co-managed enrolments
8Userless Apple automated device enrollment (without user-device affinity)
9Azure Virtual Desktop
10Windows 365
11Android Enterprise corporate-owned dedicated devices

Read that as a fallback rather than an exemption, because the distinction decides whether you have a problem. If your default policy is permissive and your real rules live in a targeted policy, every path on that list is governed by the permissive one. Nothing in the admin centre tells you this while you are editing the targeted policy, and the targeted policy will look correct in every screenshot you take of it.

Device limit restrictions have their own list, and the reasoning is different. Microsoft documents that the limit cannot be applied to co-managed enrolments, group policy enrolments, Microsoft Entra joined enrolments including bulk enrolment, Windows Autopilot enrolments, or device enrollment manager enrolments, because those scenarios use shared device mode. A per user cap has no meaning where there is no single user to count against.

The two device limits, and why they disagree

There are two numbers, in two portals, owned by two different teams, and they are not the same control. Microsoft’s page on Intune and Microsoft Entra device limit restrictions sets them side by side. The Intune device limit restriction caps how many devices a user can enrol in Intune, allows a user to enrol up to 15 devices, and is configured under Devices then Enrollment. The Microsoft Entra device limit, labelled Maximum number of devices per user, caps how many devices can join or register with Entra and is configured in the Entra admin centre under Identity, Devices, Device settings.

The failure they produce together is a device that enrols in Intune and then fails to complete, or the reverse, with an error that names neither limit. The exclusion lists do not match either. The Intune limit does not apply to Autopilot, co-management with Configuration Manager, automatic enrolment with group policy, automatic enrolment with a device enrollment manager, automatic enrolment with bulk device enrolment, automatic enrolment initiated by the user from the desktop, Android device administrator with a device enrollment manager, or Android Enterprise dedicated devices. The Entra limit does not apply to Microsoft Entra hybrid joined devices, Android Enterprise dedicated devices, Windows automatic enrolment with bulk device enrolment, or Windows automatic enrolment with group policy.

Some entries appear on both lists and some appear on only one, which is why troubleshooting by analogy fails here. Check both numbers, in both portals, every time.

The failure modes

Pre-provisioning quietly uses the default policy

Windows Autopilot for pre-provisioned deployment and self-deploying mode are on the not user driven list, so they take the default platform restriction. An organisation that blocks a platform or an ownership type in a targeted policy, and leaves the default policy as it shipped, has built a control that the two most automated Windows enrolment paths walk straight past. The devices appear in the console, correctly enrolled, with no error anywhere to investigate.

The fix is not clever. Set the default platform restriction policy to the most restrictive position the organisation can live with, and express every exception as a higher priority policy targeted at a group. That is the opposite of how most tenants are built, because the default is usually left alone on the reasonable assumption that a targeted policy overrides it. It does override it, for user driven enrolment only.

Error 80180014 at the out of box experience

This is the code that reaches the service desk. Microsoft’s troubleshooting page for work or school enrolment gives the cause directly: the device is recognised as a personal device, and personal device enrolment is blocked for the tenant.

1# Seen during out of box experience or when adding a work or school account.
280180014
3# Microsoft documented cause: the device is recognised as a personal device
4# and personal device enrolment is blocked for the tenant.
5# Documented fix: allow personally owned devices in a Windows platform
6# restriction, assigned to the specific group that needs it.

The documented resolution is to create a Windows restriction with Personally owned devices set to Allow, and Microsoft explicitly recommends assigning it only to the users who need it rather than to all users. Before you do that, check whether the device should have been corporate in the first place. A Windows device that was never registered through Autopilot, a provisioning package, co-management or a device enrollment manager account is personal by definition, no matter who bought it, and the correct fix in that case is registration rather than a hole in the restriction.

Lowering a limit does nothing to devices already enrolled

Microsoft’s page on creating device limit restrictions, updated 5 May 2026, states that edits are applied to new enrolments and do not affect devices that are already enrolled. So reducing a limit from ten to three does not remove anything. It changes what happens the next time somebody enrols, and it leaves every over quota user exactly as they are, indefinitely, until they retire a device themselves.

The practical consequence is that a limit is a shaping tool, not a clean up tool. Cleaning up needs a separate action against the existing estate, and the ordering matters if the devices still hold data, which is the argument set out in wipe versus retire.

Priority is a drag and drop list, and scope tags hide the rest of it

When a group is assigned more than one restriction, the policy at position 1 wins and the others are disregarded. New restrictions are inserted just above the default policy, and non default restrictions are reordered by dragging in the Priority column. Two things follow. A restriction created last sits above the default but below everything created before it, which is rarely what the author intended. And where scope tags are in use, an administrator may be looking at a filtered list and reordering a policy against neighbours they cannot see, which is the same class of problem described in Intune scope tags.

Microsoft’s own pages give three different portal paths

Across the three pages cited here, the navigation is given as Devices then Device onboarding then Enrollment then Device platform restriction, as Devices then Enrollment then the platform tab, and as Devices then Enroll devices then Enrollment device platform restrictions. All three appear in current documentation. That is not a criticism worth dwelling on, but it is a useful signal: when the first party documentation disagrees with itself about where a blade lives, the blade has moved recently and any third party walkthrough older than a few months will send you to the wrong place. Navigate by searching the admin centre for the restriction name rather than by following a path from any article, including this one.

What I would do differently

This section is judgement and I have flagged it as such, because I have not run an enrolment estate at scale.

I would invert the default. Most tenants treat the default platform restriction as scenery and put the real rules in targeted policies, which is exactly backwards given that the automated enrolment paths fall back to the default. Making the default the restrictive one costs a single edit and removes the entire class of failure where a control looks configured and is not.

I would stop using enrolment blocking as the answer to BYOD. It is a filter that Microsoft itself declines to call a security feature, and it forces a binary choice between an unmanaged device and a fully enrolled personal one. Application level management is the better shape for that problem, and the way it fails is documented separately in MAM without enrollment.

I would also write down the two device limits and where they are set, in the same document, on the day they are configured. Both numbers are invisible from the other portal, neither appears in the error a user sees, and the cost of rediscovering them is an afternoon every time somebody hits one.

The thing I would not do is lower a device limit and consider the estate tidied. It changes nothing that already exists, and an organisation that believes otherwise will carry a quiet gap between the number in the policy and the number in the console for as long as nobody checks.

Last verified: 15 September 2026.