We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Intune and endpoint management
  3. Enrolment restrictions
Intune enrolment restrictions, UAE

Microsoft says it plainly: these are not security features. They are a barrier for non-malicious users.

Enrolment restrictions stop the wrong device enrolling by accident, and a compromised device can misrepresent its character to get past them. Treating them as a control rather than a guardrail is the mistake, and knowing that changes what you build on top.

Book an enrolment restriction reviewSee what they cover
Intune enrolment restrictions for UAE organisations
  • 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 enrolment
Set the expectation correctly

Enrollment restrictions are not security features. Microsoft says so on the page.

This sentence should be quoted in any document that presents enrollment restrictions as a control, because presenting them as more than they are is how a gap goes unnoticed.

  • The published wording is unambiguous: enrollment restrictions are not security features, compromised devices can misrepresent their character, and these restrictions are a best effort barrier for non malicious users.
  • That does not make them useless. Stopping the wrong platform, the wrong OS version or an unexpected number of devices from enrolling is genuinely valuable, and it prevents a large amount of accidental mess before it reaches the estate.
  • It does mean they cannot be the thing standing between an attacker and your data. Compliance policy, Conditional Access and device based access control are where that boundary lives, and enrollment restrictions sit in front of them rather than instead of them.
  • The other expectation to set is timing. Assignment processing between Microsoft Entra and Intune typically happens within 15 minutes rather than instantly, so enrol devices several minutes after adding users to a group rather than immediately.
What enrolment restrictions do

Eight things that determine whether yours behave as intended.

These are among the most misunderstood settings in Intune, largely because several documented behaviours are counterintuitive. Three of them mean a restriction you configured will not apply in circumstances you probably assumed it would.

They are a guardrail, not a security control

Microsoft states directly that enrolment restrictions are not security features, that compromised devices can misrepresent their character, and that these restrictions are a best-effort barrier for non-malicious users. Any design that treats them as a boundary against an attacker is built on the wrong assumption.

Non user-driven enrolments get the default policy

Restrictions apply to user-driven enrolments. For anything not user-driven, Intune enforces the default policy instead, which covers Autopilot self-deploying and pre-provisioned deployment, bulk enrolment, co-managed enrolments, userless Apple automated device enrolment, Azure Virtual Desktop, Windows 365 and Android dedicated devices.

Ownership defaults differ from what people assume

Intune classifies iOS, iPadOS and macOS devices as personally owned by default. Corporate ownership requires registration with a serial number, or IMEI for iOS and iPadOS, or enrolment through Apple Automated Device Enrollment. Without one of those, blocking personal devices blocks devices you actually own.

Device limits, and where they do not apply

The device limit is configurable from 1 to 15 per user. It cannot be applied to co-managed enrolments, Group Policy enrolments, Entra joined enrolments including bulk, Autopilot enrolments or device enrollment manager enrolments, because those use shared device mode. Entra ID carries a hard limit for those.

Assignment changes are not instant

Device platform restrictions use assignment filters, and the update between Entra and Intune that processes user, group and filter assignments typically happens within 15 minutes rather than immediately. Microsoft advises enrolling several minutes after adding users to a group, not straight away.

Blocking personal Windows devices is an allow list

When you block personally owned Windows devices, Intune checks each new enrolment request has been authorised for corporate enrolment and blocks the rest. Authorised routes are Autopilot, GPO or Configuration Manager automatic enrolment for co-management, a bulk provisioning package, and a device enrollment manager account.

Co-managed devices bypass your custom policies

A co-managed device enrols based on its Entra device token rather than a user token, so only the default Intune enrolment restriction applies to it. Any carefully scoped policy you assigned to a group of users will simply not be consulted for that device.

Version and manufacturer limits are narrower than expected

Operating system version restrictions work on Android device administrator, Android Enterprise work profile and iOS or iPadOS only for devices enrolled through the Intune Company Portal, plus Windows. The manufacturer restriction applies to Android devices only, and to nothing else.

The gap between what you configured and what applies

Your scoped restriction policy does not apply to most automated enrolment scenarios.

Microsoft lists these explicitly, and together they cover a large share of how devices actually reach a modern tenant.

  • Enrolment restrictions apply to user-driven enrolments. For scenarios that are not user-driven, Intune enforces the default policy. That list includes Autopilot self-deploying mode and pre-provisioned deployment, bulk enrolment via Windows Configuration Designer, co-managed enrolments, userless Apple automated device enrolment, Azure Virtual Desktop, Windows 365 and Android Enterprise corporate-owned dedicated devices.
  • The practical consequence is that the default policy is doing more work than most administrators realise. A carefully designed restriction assigned to a specific group is irrelevant to a Windows 365 Cloud PC or an Autopilot self-deploying kiosk, both of which are governed by whatever the default policy happens to say.
  • Co-managed devices are a specific case worth calling out. Because a co-managed device enrols based on its Entra device token rather than a user token, only the default Intune enrolment restriction applies. Group-scoped policies never enter into it.
  • Device limit restrictions have their own exclusion list for the same underlying reason. They cannot apply to co-managed, Group Policy, Entra joined including bulk, Autopilot or device enrollment manager enrolments, because those use shared device mode. For those, a hard limit is configured in Entra ID instead.
Ask us to review your default policy
How we approach it

Four things that make these settings behave predictably.

Enrolment restrictions generate a specific kind of confusion: they work exactly as documented, and the documentation contradicts what most people assume. The fix is reading the behaviour into the design.

We design the default policy first

Every non user-driven enrolment falls back to the default policy, and that list includes Autopilot self-deploying, pre-provisioned deployment, co-management, Windows 365, Azure Virtual Desktop and userless Apple enrolment. In most modern tenants the default policy governs more devices than any assigned one.

We fix ownership classification before blocking anything

Intune classifies iOS, iPadOS and macOS devices as personally owned by default. Blocking personal devices without first registering corporate hardware by serial number or IMEI, or enrolling it through Automated Device Enrollment, blocks the devices you bought.

We are explicit that this is not a security control

Microsoft states enrolment restrictions are not security features and that compromised devices can misrepresent their character. Where the requirement is genuinely to keep untrusted devices out, that needs device compliance and Conditional Access, and saying so early prevents a false sense of protection.

We build the assignment delay into testing

Device platform restrictions use assignment filters, and the update processing user, group and filter assignments typically takes up to 15 minutes rather than being instant. A test run immediately after a group change tells you nothing, and it is the usual reason a restriction appears not to work.

How a review runs

Four phases across roughly three weeks.

Short, and unusually high value, because most tenants have restriction policies that were configured once and never tested against the enrolment paths actually in use.
  1. 01
    Week 1

    Establish which enrolment paths are actually used

    Company Portal enrolments, Autopilot in each mode, co-management, Apple automated device enrolment with and without user affinity, Windows 365 and Azure Virtual Desktop. Each mapped against whether it is user-driven, because that determines which policy governs it.

    • Enrolment paths in use catalogued per platform
    • User-driven and non user-driven paths separated
    • Current default policy contents documented
    • Assigned policies mapped to the groups they target
  2. 02
    Week 2

    Design the default policy deliberately

    The default policy is what governs every non user-driven enrolment, so it deserves the most attention rather than the least. Then the assigned policies for the user-driven paths, with priority ordering set so the intended policy wins.

    • Default policy designed against the non user-driven paths
    • Assigned policies designed for user-driven enrolment
    • Priority ordering set and documented
    • Device limit decided within the 1 to 15 range
  3. 03
    Week 2 to 3

    Fix the ownership classification problem

    Blocking personal devices only works if your corporate devices are actually classified as corporate. For iOS, iPadOS and macOS that means serial number or IMEI registration, or Apple Automated Device Enrollment. Without it, blocking personal devices blocks your own hardware.

    • Corporate identifiers uploaded for Apple devices
    • Automated device enrolment coverage confirmed
    • Windows authorised enrolment routes verified
    • Workplace Join and prior Entra join conflicts identified
  4. 04
    Week 3

    Test each path, allowing for the delay

    Every enrolment path tested against the restrictions, remembering that group and filter assignment processing typically takes up to 15 minutes rather than applying instantly. Testing immediately after a group change produces results that mean nothing.

    • Each enrolment path tested end to end
    • Assignment delay accounted for in test procedure
    • Blocked and permitted outcomes verified per platform
    • Service desk guidance for enrolment failures
Where this matters

Six situations where enrolment control needs designing properly.

The common thread is an organisation that configured a restriction, saw it work in one test, and assumed it applied everywhere.

A business trying to keep personal devices out

The most common driver, and the one where ownership classification decides the outcome. Because iOS, iPadOS and macOS devices default to personally owned, blocking personal enrolment without registering corporate serial numbers or using Automated Device Enrollment blocks your own fleet.

An operator running shared and dedicated devices

Android Enterprise corporate-owned dedicated devices, Autopilot self-deploying kiosks and bulk enrolled machines are all non user-driven, so all of them are governed by the default policy. For estates built largely from these, the default policy is effectively the only policy.

A regulated firm asked how enrolment is controlled

The honest answer distinguishes between what enrolment restrictions do and what they cannot do. They stop the wrong device enrolling by accident. Keeping an untrusted device away from data is compliance policy and Conditional Access, and conflating the two weakens the answer.

An organisation limiting devices per person

The device limit runs from 1 to 15 and does not apply to co-managed, Group Policy, Entra joined including bulk, Autopilot or device enrollment manager enrolments, because those use shared device mode. A hard limit in Entra ID covers those, and needs setting separately.

A school or university with mixed ownership

Education estates mix institution owned devices, student owned devices and shared classroom hardware. Getting corporate identifiers and Automated Device Enrollment right is what allows ownership-based restrictions to express that mix rather than blocking half of it.

A company where an enrolment keeps failing

Frequently a Workplace Join device that was previously Entra joined to the tenant, which Microsoft notes can be blocked from enrolling. The remedy is deregistering and removing the associated object in Entra ID before attempting the join again.

Three positions

How UAE organisations control what enrols.

The middle column is the most common and the most misleading, because a carefully assigned policy creates confidence that does not extend to the enrolment paths it never governs.
User-driven enrolment controlled
Default and assigned both designedYes
Assigned policies onlyYes
Untouched defaultsDefault behaviour
Automated enrolment controlled
Default and assigned both designedYes, via default
Assigned policies onlyNo
Untouched defaultsDefault behaviour
Co-managed enrolment governed
Default and assigned both designedYes, via default
Assigned policies onlyNo
Untouched defaultsDefault behaviour
Apple devices classified correctly
Default and assigned both designedYes
Assigned policies onlySometimes
Untouched defaultsPersonal by default
Personal device blocking works as intended
Default and assigned both designedYes
Assigned policies onlyPartly
Untouched defaultsNot configured
Device limit applied where possible
Default and assigned both designedYes, plus Entra limit
Assigned policies onlyIntune only
Untouched defaultsDefault
Assignment delay understood
Default and assigned both designedYes
Assigned policies onlyNo
Untouched defaultsNot applicable
Enrolment failures diagnosable
Default and assigned both designedYes
Assigned policies onlyDifficult
Untouched defaultsDifficult
Treated as a security boundary
Default and assigned both designedNo, correctly
Assigned policies onlyFrequently yes
Untouched defaultsFrequently yes
Tested per enrolment path
Default and assigned both designedYes
Assigned policies onlyRarely
Untouched defaultsNo
Feature
Default and assigned both designed
Assigned policies only
Untouched defaults
User-driven enrolment controlled
YesYesDefault behaviour
Automated enrolment controlled
Yes, via defaultNoDefault behaviour
Co-managed enrolment governed
Yes, via defaultNoDefault behaviour
Apple devices classified correctly
YesSometimesPersonal by default
Personal device blocking works as intended
YesPartlyNot configured
Device limit applied where possible
Yes, plus Entra limitIntune onlyDefault
Assignment delay understood
YesNoNot applicable
Enrolment failures diagnosable
YesDifficultDifficult
Treated as a security boundary
No, correctlyFrequently yesFrequently yes
Tested per enrolment path
YesRarelyNo
What applies where

Ten scenarios and which policy actually governs them.

The default policy column is the one to read carefully, because in most tenants that policy was never deliberately designed.
Enrolment scenarioWhich restriction policy applies
A user enrolling through Company PortalAssigned policy, or default if none applies
Autopilot self-deploying modeDefault policy only
Autopilot pre-provisioned deploymentDefault policy only
Bulk enrolment via Windows Configuration DesignerDefault policy only
Co-managed enrolmentDefault policy only, enrolled by device token
Userless Apple automated device enrolmentDefault policy only
Azure Virtual DesktopDefault policy only
Windows 365Default policy only
Android Enterprise corporate-owned dedicatedDefault policy only
Device limit on shared device mode enrolmentsNot applicable, use an Entra ID hard limit
How an engagement runs

Five steps, and the default policy leads.

Working out which policy actually governs each enrolment path is most of the exercise, and it usually reorders what people thought mattered.
  1. 1

    Catalogue the enrolment paths in use

    Company Portal, Autopilot in each mode, co-management, Apple automated device enrolment with and without user affinity, bulk provisioning, Windows 365 and Azure Virtual Desktop. Each classified as user-driven or not, because that single distinction determines which policy governs it.

  2. 2

    Design the default policy against the automated paths

    The default policy governs Autopilot self-deploying and pre-provisioned deployment, bulk enrolment, co-management, userless Apple enrolment, Windows 365, Azure Virtual Desktop and Android dedicated devices. In a modern estate that is a large share of enrolments and it deserves deliberate design.

  3. 3

    Fix ownership classification

    Corporate identifiers uploaded for Apple devices by serial number or IMEI, or Automated Device Enrollment used, so that corporate hardware is not treated as personally owned. For Windows, confirming which authorised enrolment routes are in use before blocking personal devices.

  4. 4

    Set assigned policies and priority for user-driven paths

    Platform, version, manufacturer and ownership restrictions for the enrolments that are user-driven, with priority ordering set so the intended policy wins. Device limits chosen within the 1 to 15 range, with an Entra ID hard limit configured for the enrolment types Intune limits cannot reach.

  5. 5

    Test each path with the delay built in

    Every enrolment path exercised against the restrictions, waiting for group and filter assignment processing which typically takes up to 15 minutes. Then service desk guidance covering what a blocked enrolment looks like and how to distinguish it from a genuine failure.

Straight answers

What organisations ask about enrolment restrictions.

No, and Microsoft says so directly. Enrolment restrictions are not security features, compromised devices can misrepresent their character, and the restrictions are a best-effort barrier for non-malicious users. Keeping untrusted devices away from data is compliance policy and Conditional Access.

Most likely because that enrolment was not user-driven. Restrictions apply to user-driven enrolments, and for anything else Intune enforces the default policy. Autopilot self-deploying, pre-provisioned deployment, bulk enrolment, co-management, Windows 365 and Azure Virtual Desktop are all in that category.

Only the default Intune enrolment restriction. Because a co-managed device enrols based on its Entra device token rather than a user token, group-scoped policies are never consulted for it. That surprises people who scoped a restriction carefully to a user group.

Because Intune classifies iOS and iPadOS devices as personally owned by default. To be treated as corporate-owned, a device must be registered with a serial number or IMEI, or enrolled using Automated Device Enrollment. Without one of those, a personal device block catches your own hardware.

Yes. Intune classifies macOS devices as personally owned by default, and corporate ownership requires registration with a serial number or enrolment through Apple Automated Device Enrollment. It is the same trap with the same remedy, and it catches organisations that solved it for iPhones and forgot Macs.

Windows Autopilot, GPO or automatic enrolment from Configuration Manager for co-management, a bulk provisioning package, and enrolment by a device enrollment manager account. If you block personally owned Windows devices, anything outside those routes is treated as unauthorised and blocked.

The device limit is configurable from 1 to 15. It does not apply to co-managed, Group Policy, Entra joined including bulk, Autopilot or device enrollment manager enrolments, because those use shared device mode. A hard limit for those is configured in Microsoft Entra ID instead.

Device platform restrictions use assignment filters, and the update between Entra and Intune that processes user, group and filter assignments typically happens within 15 minutes rather than instantly. Microsoft advises enrolling several minutes after adding users to a group rather than immediately.

On Windows generally, and on Android device administrator, Android Enterprise personally-owned work profile and iOS or iPadOS only for devices enrolled through the Intune Company Portal. That Company Portal qualifier is significant if your users enrol another way.

On Android only. The device manufacturer restriction applies to Android devices and nothing else, so a requirement to block a particular vendor on another platform needs a different approach entirely rather than a variation of this setting.

A common cause is Workplace Join on a device that was previously Entra joined to the tenant. Microsoft notes those can be blocked from enrolling, and the remedy is to deregister the device and remove its associated object in Entra ID before attempting the join again.

Each restriction type comes with one default policy that you can edit and customise. Intune applies that default to all user and userless enrolments until you assign a higher-priority policy, which is why the default deserves more design attention than it usually gets.

Android device administrator, Android Enterprise personally-owned devices with a work profile, iOS, macOS and Windows, with availability varying by restriction type. Note also that Android device administrator management is deprecated and no longer available for devices with Google Mobile Services.

Compliance policies and Conditional Access. Enrolment restrictions decide what may enrol. Compliance and Conditional Access decide what an enrolled device may reach, and those are evaluated continuously rather than once at enrolment, which is what makes them a control rather than a guardrail.

We scope by the number of platforms and enrolment paths in use. The free first step: open your default enrolment restriction policy and read what it allows. In most tenants nobody has looked at it since setup, and it governs more devices than any policy anybody assigned deliberately.

You can set the device limit from 1 to 15. Each restriction type also comes with a default policy that Intune applies to all user and userless enrollments until you assign a higher priority policy of your own.

Because a co-managed device enrols based on its Microsoft Entra device token rather than a user token, only the default Intune enrollment restriction applies to it. That is documented behaviour rather than a misconfiguration.

Personal. Intune classifies iOS and iPadOS devices as personally owned by default. To be treated as corporate owned, the device must be registered with a serial number or IMEI, or enrolled using Automated Device Enrollment.
Configuration review

Fifteen questions about your own enrolment controls.

The first question is the one that matters most and the one almost nobody has an answer to, because the default policy is rarely designed on purpose.

Default policy

  • What does our default policy actually allow?
    It governs all automated enrolment.
  • 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 enrol 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 authorised?
    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 enrolment 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.
Related reading

The pages around this one.

Device enrolment

The enrolment paths themselves and what each requires.

Learn more

Intune compliance policies

The control that actually governs what a device can reach.

Learn more

Assignment filters

The mechanism platform restrictions are built on.

Learn more
Next step

Open your default enrolment restriction policy and read what it allows.

It governs every automated enrolment path: Autopilot self-deploying, co-management, Windows 365, bulk provisioning and userless Apple enrolment. In most tenants nobody has looked at it since setup.

Book an enrolment restriction reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Device Enrolment

Which path, which reset, and what you can enforce after

Learn more

Intune Compliance Policies

The default that lets unassessed devices through Conditional Access

Learn more

Intune Assignment Filters

Targeting by device property, without the delay

Learn more

Windows Autopilot Dubai

Zero-touch laptop deployment, supplier registration onward

Learn more

Autopilot Device Preparation

Cloud-native Windows provisioning with real reporting

Learn more

MDM Solutions Dubai

Device management across Windows, Apple and Android

Learn more

Microsoft Intune

Device management and endpoint security

Learn more

Android Enterprise

Choose the enrolment method before you buy the phones

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy