Microsoft says it plainly: these are not security features. They are a barrier for non-malicious users.
What they do is prevent the wrong device enrolling by accident, and a compromised device is perfectly capable of misrepresenting what it is to get past them. The error organizations make is treating a guardrail as a control. Understanding the difference changes two things: what you build on top of them, and what you can honestly write when a customer sends you a security questionnaire.
- 2 typesPlatform restrictions and device limit
- 1 to 15Configurable device limit per user
- 15 minutesTypical group and filter assignment delay
- Default onlyWhat applies to non user-driven enrollment
Enrollment restrictions are not security features. Microsoft says so on the page.
Quote that sentence in any document presenting these as a control, because overstating what they do is precisely how a gap survives unnoticed for two years and how a security questionnaire answer quietly becomes inaccurate.
- The published wording leaves no room for interpretation. These are not security features, a compromised device can misrepresent its character, and what you have is a best-effort barrier aimed at non-malicious users.
- None of which makes them useless, and we would push back on anyone who says so. Preventing the wrong platform, an unsupported release or an unexpected number of devices from enrolling has genuine value, and it stops a considerable amount of accidental mess reaching your estate in the first place.
- What it does mean is that they cannot be what stands between an attacker and your data. That boundary lives in compliance policy, in Conditional Access and in device-based access control. Enrollment restrictions sit in front of those things rather than in place of them.
- One further expectation worth setting is timing. Assignment processing between the directory and the service usually completes within fifteen minutes rather than instantly, so enroll a device several minutes after adding somebody to a group rather than immediately afterward.
Eight things that determine whether yours behave as intended.
They are a guardrail, not a security control
The documentation states outright that these are not security features, that a compromised device can misrepresent its character, and that what you have is a best-effort barrier against non-malicious users. Read that carefully. Any architecture treating these as a boundary between an attacker and your estate has been built on an assumption the vendor explicitly disclaims.
Non user-driven enrollments get the default policy
Your restrictions govern enrollments a person initiates. Everything else falls to the default policy instead, and look at what that list contains: self-deploying and pre-provisioned Autopilot, bulk enrollment, co-managed devices, userless Apple automated enrollment, virtual desktops, Cloud PCs and Android dedicated hardware. In a modern tenant that is a very large proportion of how devices actually arrive.
Ownership defaults differ from what people assume
Apple hardware arrives classified as personally owned unless something tells the service otherwise. Establishing corporate ownership requires registration by serial number, or by IMEI on iPhone and iPad, or enrollment through the automated route. Miss all three and you get a genuinely confusing outcome: blocking personal devices blocks equipment your company paid for.
Device limits, and where they do not apply
You can set anywhere from one to fifteen devices per person. What you cannot do is apply that to co-managed enrollments, Group Policy enrollments, directory joined enrollments including bulk, Autopilot, or anything going through a device enrollment manager account, all of which use shared device mode. Those are governed by a separate hard limit configured in the directory instead.
Assignment changes are not instant
Platform restrictions rely on assignment filters, and the synchronization between the directory and the service that processes user, group and filter assignments typically completes within fifteen minutes rather than the instant you click save. The published advice is to wait several minutes after adding somebody to a group before attempting an enrollment, which is exactly the sort of thing nobody reads until a test fails inexplicably.
Blocking personal Windows devices is an allow list
Block personally owned Windows devices and what actually happens is that every new enrollment request gets checked against a list of authorized corporate routes, with everything else refused. Those routes are Autopilot, automatic enrollment through Group Policy or Configuration Manager for co-management, a bulk provisioning package, and a device enrollment manager account. Nothing outside that list gets in, which is worth knowing before somebody tries.
Co-managed devices bypass your custom policies
Because a co-managed machine enrolls on the strength of its device token rather than a user token, only the default restriction is ever consulted. Whatever carefully scoped policy you assigned to a group of people plays no part whatsoever. It is not overridden or outranked, it is simply never looked at.
Version and manufacturer limits are narrower than expected
Version restrictions cover Android device administrator, Android Enterprise work profile, Apple mobile devices enrolled through the Company Portal specifically, and Windows. That is the whole list. The manufacturer restriction is narrower still, applying to Android and to absolutely nothing else, which catches out anybody hoping to filter Apple hardware that way.
Your scoped restriction policy does not apply to most automated enrollment scenarios.
Every one of these is listed explicitly in the documentation, and taken together they account for a very large share of how devices genuinely arrive in a modern tenant.
- Restrictions govern enrollments a person initiates. Everything else falls to the default policy, and the list is long: self-deploying and pre-provisioned Autopilot, bulk enrollment through Configuration Designer, co-managed enrollments, userless Apple automated enrollment, virtual desktops, Cloud PCs and corporate-owned dedicated Android devices.
- Follow that through and the consequence is uncomfortable. Your default policy is carrying far more weight than most administrators appreciate. A meticulously designed restriction assigned to one group has no bearing whatsoever on a Cloud PC or a self-deploying kiosk, both of which answer to whatever the default happens to contain.
- Co-managed machines deserve a specific mention. Enrolling on a device token rather than a user token means only the default restriction is consulted, and group-scoped policies never enter the picture at any point.
- Device limits carry their own exclusion list for the same underlying reason. They cannot reach co-managed, Group Policy, directory joined including bulk, Autopilot or device enrollment manager enrollments, since all of those use shared device mode. A hard limit configured in the directory covers that population instead.
Four things that make these settings behave predictably.
We design the default policy first
Anything not initiated by a person falls back to the default, and that covers self-deploying and pre-provisioned Autopilot, co-management, Cloud PCs, virtual desktops and userless Apple enrollment. Count those populations in a modern tenant and you generally find the default policy governing more machines than every assigned policy combined.
We fix ownership classification before blocking anything
Apple hardware defaults to personally owned in the eyes of the service. So blocking personal devices before registering your corporate equipment by serial number or IMEI, or bringing it in through automated enrollment, produces the opposite of what you intended: the fleet you paid for gets refused while nothing else changes.
We are explicit that this is not a security control
The documentation says these are not security features and that a compromised device can misrepresent its character. Where your actual requirement is keeping untrusted hardware away from company data, what delivers that is device compliance feeding Conditional Access. We say so in the first meeting, because a false sense of protection is worse than none at all.
We build the assignment delay into testing
Platform restrictions depend on assignment filters, and the processing behind user, group and filter assignments generally needs up to fifteen minutes rather than working instantly. Test immediately after changing a group and the result carries no information whatsoever. That single mistake accounts for most reports we receive of a restriction that supposedly does not work.
Four phases across roughly three weeks.
- 01Week 1
Establish which enrollment paths are actually used
We catalog every route in use: Company Portal enrollments, Autopilot in each of its modes, co-management, Apple automated enrollment both with and without user affinity, Cloud PCs and virtual desktops. Each one then gets marked as user-driven or not, since that single attribute decides which policy will govern it.
- Enrollment paths in use cataloged per platform
- User-driven and non user-driven paths separated
- Current default policy contents documented
- Assigned policies mapped to the groups they target
- 02Week 2
Design the default policy deliberately
Since the default governs every enrollment nobody initiated by hand, it deserves the most attention rather than the least, which inverts how most organizations have treated it. Only afterwards do we design the assigned policies covering user-driven paths, setting priority order so that the policy you intended is genuinely the one that wins.
- Default policy designed against the non user-driven paths
- Assigned policies designed for user-driven enrollment
- Priority ordering set and documented
- Device limit decided within the 1 to 15 range
- 03Week 2 to 3
Fix the ownership classification problem
A block on personal devices only produces the intended outcome if your own hardware is genuinely classified as corporate. On Apple platforms that means registration by serial number or IMEI, or coming through the automated enrollment route. Skip that groundwork and the block you configured catches the equipment your company bought rather than the equipment you were worried about.
- Corporate identifiers uploaded for Apple devices
- Automated device enrollment coverage confirmed
- Windows authorized enrollment routes verified
- Workplace Join and prior Entra join conflicts identified
- 04Week 3
Test each path, allowing for the delay
Each path gets tested against the restrictions properly, with explicit allowance made for assignment processing taking up to fifteen minutes rather than applying the moment you save. Run a test straight after a group change and whatever you observe means nothing at all, which is how people conclude a working restriction is broken.
- Each enrollment path tested end to end
- Assignment delay accounted for in test procedure
- Blocked and permitted outcomes verified per platform
- Service desk guidance for enrollment failures
Six situations where enrollment control needs designing properly.
A business trying to keep personal devices out
This brings more people to us than anything else, and ownership classification decides how it ends. Since Apple hardware defaults to personally owned, blocking personal enrollment before registering corporate serial numbers or adopting automated enrollment produces an outcome nobody wanted, which is your own fleet being turned away at the door.
An operator running shared and dedicated devices
Corporate-owned dedicated Android hardware, self-deploying kiosks and anything bulk enrolled all share one property: no person initiates them, so every one falls to the default. Where an estate is built predominantly from devices like these, your default policy is not merely important, it is effectively the only policy you have.
A firm asked how enrollment is controlled
A SOC 2 auditor, an examiner or a customer questionnaire wants to know how device onboarding is governed, and the strongest answer draws a clear line between what these do and what they cannot. They stop the wrong hardware enrolling by accident. Keeping genuinely untrusted equipment away from your data is compliance policy feeding access control. Blur those two together and you have weakened an answer that was otherwise perfectly good.
An organization limiting devices per person
Your limit can sit anywhere from one to fifteen, and it will not reach co-managed, Group Policy, directory joined including bulk, Autopilot or device enrollment manager enrollments, all of which use shared device mode. Covering that population requires a hard limit set in the directory, and it needs configuring separately by somebody who remembers it exists.
A school district or university with mixed ownership
Campuses run three populations side by side: hardware the institution bought, hardware students brought themselves, and shared equipment living in classrooms. Getting corporate identifiers and automated enrollment right is precisely what lets an ownership-based restriction describe that mixture accurately rather than blocking roughly half of it on the first morning of term.
A company where an enrollment keeps failing
This one has a specific and unobvious cause more often than you would expect: a workplace joined machine that had previously been directory joined to the same tenant, a state documented as capable of blocking enrollment. Fixing it means deregistering the device and removing the associated object from the directory before attempting the join a second time.
How organizations control what enrolls.
| Feature | Default and assigned both designed | Assigned policies only | Untouched defaults |
|---|---|---|---|
User-driven enrollment controlled | Yes | Yes | Default behavior |
Automated enrollment controlled | Yes, via default | No | Default behavior |
Co-managed enrollment governed | Yes, via default | No | Default behavior |
Apple devices classified correctly | Yes | Sometimes | Personal by default |
Personal device blocking works as intended | Yes | Partly | Not configured |
Device limit applied where possible | Yes, plus Entra limit | Intune only | Default |
Assignment delay understood | Yes | No | Not applicable |
Enrollment failures diagnosable | Yes | Difficult | Difficult |
Treated as a security boundary | No, correctly | Frequently yes | Frequently yes |
Tested per enrollment path | Yes | Rarely | No |
Ten scenarios and which policy actually governs them.
Enrollment scenario
A user enrolling through Company Portal
- Which restriction policy applies
- Assigned policy, or default if none applies
Enrollment scenario
Autopilot self-deploying mode
- Which restriction policy applies
- Default policy only
Enrollment scenario
Autopilot pre-provisioned deployment
- Which restriction policy applies
- Default policy only
Enrollment scenario
Bulk enrollment via Windows Configuration Designer
- Which restriction policy applies
- Default policy only
Enrollment scenario
Co-managed enrollment
- Which restriction policy applies
- Default policy only, enrolled by device token
Enrollment scenario
Userless Apple automated device enrollment
- Which restriction policy applies
- Default policy only
Enrollment scenario
Azure Virtual Desktop
- Which restriction policy applies
- Default policy only
Enrollment scenario
Windows 365
- Which restriction policy applies
- Default policy only
Enrollment scenario
Android Enterprise corporate-owned dedicated
- Which restriction policy applies
- Default policy only
Enrollment scenario
Device limit on shared device mode enrollments
- Which restriction policy applies
- Not applicable, use an Entra ID hard limit
Five steps, and the default policy leads.
- 1
Catalog the enrollment paths in use
Everything gets listed: the Company Portal, Autopilot across each of its modes, co-management, Apple automated enrollment both with and without user affinity, bulk provisioning, Cloud PCs and virtual desktops. Then each is classified as user-driven or not, because that one distinction settles which policy will govern it.
- 2
Design the default policy against the automated paths
Look at what the default is actually responsible for: self-deploying and pre-provisioned Autopilot, bulk enrollment, co-management, userless Apple enrollment, Cloud PCs, virtual desktops and dedicated Android hardware. In a contemporary estate that is a very large share of everything that enrolls, and it has earned some deliberate design attention.
- 3
Fix ownership classification
Apple hardware gets corporate identifiers uploaded by serial number or IMEI, or comes through automated enrollment instead, so that equipment your company owns stops being treated as somebody personal property. On Windows we confirm which authorized routes are genuinely in use before any block on personal devices goes anywhere near production.
- 4
Set assigned policies and priority for user-driven paths
Restrictions on platform, version, manufacturer and ownership get built for the paths a person initiates, with priority ordering configured so the policy you meant to win actually does. Device limits are chosen within the available range, and a hard limit goes into the directory to cover the enrollment types those limits cannot reach.
- 5
Test each path with the delay built in
Each path is exercised properly against the restrictions, allowing the fifteen minutes that assignment processing usually requires rather than testing immediately. Your service desk then receives written guidance on what a deliberately blocked enrollment looks like from the user side, and how to tell it apart from a genuine failure.
What organizations ask about enrollment restrictions.
Fifteen questions about your own enrollment controls.
Default policy
- What does our default policy actually allow?It governs all automated enrollment.
- Was it ever deliberately designed?Usually not.
- Do we use Autopilot self-deploying?Default policy only.
- Do we run Windows 365 or AVD?Also default policy only.
- Are any devices co-managed?They enroll by device token.
Ownership
- Are Apple devices registered by serial or IMEI?Otherwise they are personal by default.
- Are Macs registered or enrolled via ADE?Same default applies.
- Do we block personal devices anywhere?Check what that catches.
- Which Windows routes are authorized?Autopilot, GPO, bulk package, DEM.
- Any Workplace Join devices previously Entra joined?They can be blocked.
Limits and scope
- What device limit is set?The range is 1 to 15.
- Does it apply to our enrollment types?Shared device mode is excluded.
- Have we set an Entra ID hard limit?For the excluded types.
- Do we restrict by OS version?Company Portal only on some platforms.
- Do we restrict by manufacturer?Android only.
Open your default enrollment restriction policy and read what it allows.
It governs every automated enrollment path: Autopilot self-deploying, co-management, Windows 365, bulk provisioning and userless Apple enrollment. In most tenants nobody has looked at it since setup.
Related Services
Explore more solutions that work great with this service