This sheet builds the enrollment restriction set for a tenant from the default policies outward, in the order that does not break provisioning. It is the one place in the Intune baseline where a competent admin needs a reproducible procedure and cannot find one, so it is written to be followed from the text alone.
What this builds, and the order it has to happen in
By the end you will have both default policies configured deliberately, a small set of group-targeted exceptions above them, a corporate identifier list for Windows that is complete before anything depends on it, and an end-to-end test that fails for the right reason. The order matters more than any individual value. Configure the defaults first, because seven common enrollment paths ignore group assignment entirely and use the default. Prove the corporate identifier list is complete second, because uploading it changes the tenant’s ownership default. Turn on personally-owned blocking last, because it is the setting that converts an incomplete identifier list into a provisioning outage.
Two facts govern the whole sheet. Edits apply to new enrollments only and never to devices already enrolled, so nothing here retroactively fixes an estate. And assignment to at least one group is mandatory for a non-default policy to take effect at all; a restriction you built and never assigned does nothing and reports nothing.
Naming convention used throughout, so the policies sort predictably and the purpose survives the person who built them:
| Object | Pattern | Example |
|---|---|---|
| Platform restriction | ENR-PLAT-[scope]-[intent] | ENR-PLAT-Corp-WindowsAppleOnly |
| Device limit restriction | ENR-LIMIT-[scope]-[n] | ENR-LIMIT-Standard-3 |
| Assignment group | SG-ENR-[scope] | SG-ENR-Contractors |
| Corporate identifier file | corpids-windows-[site]-[yyyymmdd].csv | corpids-windows-hq-20260801.csv |
The default policies cannot be renamed and do not follow this convention. That is fine, and it is a useful visual signal: anything without a prefix is a default and governs the paths nobody assigned.
Before you start
Rights, and this is asymmetric in a way that catches delegated teams. Managing enrollment restrictions requires the Intune Administrator role, which Microsoft also documents under its other name, Intune Service Administrator. Every other built-in Intune role has read-only access to them, and custom Intune roles that once carried these permissions have been reduced to read-only. Corporate identifiers are different and lower: the built-in Policy and Profile Manager role can create, read, update and delete them, and custom roles are supported there. So a delegated administrator can upload the identifier list that changes tenant behaviour without being able to see the restriction that consumes it, which is worth knowing before you delegate either.
Licensing is Intune Plan 1 for everything in this sheet. Requiring multifactor authentication at enrollment, which is an adjacent control most baselines want, is a Conditional Access policy and needs Entra ID P1 or P2.
Collect before you begin: the platforms your organisation actually deploys, the minimum OS versions you are willing to admit per platform, the device count a normal user is entitled to, the list of enrollment methods currently in production, and the manufacturer, model and serial for every Windows device you intend to treat as corporate. That last one is the long pole and step 4 will not let you skip it.
Step 1. Inventory the enrollment paths in production
Nothing else in this sheet is safe until you know which of these are live, because the ones in the second list will ignore everything you assign to a group.
| Path | Governed by | Note |
|---|---|---|
| Company Portal, user-driven, any platform | Assigned policy, then default | The path the assigned policy is written for |
| Apple automated device enrollment with user affinity | Assigned policy, then default | Min and max OS range does not apply to ADE |
| Autopilot self-deploying and pre-provisioned | Default only | Not user-driven |
| Bulk enrollment via Configuration Designer | Default only | Not user-driven |
| Co-managed enrollment | Default only | Enrols on a device token, not a user token |
| Userless Apple automated device enrollment | Default only | No user affinity |
| Azure Virtual Desktop | Default only | Not user-driven |
| Windows 365 | Default only | Not user-driven |
| Android Enterprise dedicated | Default only | Not user-driven |
Write down which rows are live in your tenant. If more than one or two are, the default policy is your real policy and steps 2 and 3 are the whole job.
Note separately that device limit restrictions cannot apply at all to co-managed, group policy, Entra joined including bulk, Autopilot, or device enrollment manager scenarios on Windows, because those use shared device mode. Microsoft’s documented alternative is a device limit in Entra ID itself, which is a different console and a different owner. Decide now whether that limit is someone’s job.
Step 2. Configure the default platform restriction
Open the default device platform restriction, the one that cannot be deleted, and set every platform deliberately. There are six platform tabs on this policy type: Windows, Android, macOS, iOS/iPadOS, tvOS and visionOS. The last two exist whether or not your organisation has ever considered them, which is the point.
Note the label asymmetry before you start, because it trips scripted work and written procedures alike. The allow or block toggle is called Platform on Android and MDM on every other platform. It is the same control.
| Setting | Value | Why |
|---|---|---|
MDM or Platform, per platform | Block for every platform you do not deploy | Keeps unmanaged platforms out of reporting, licensing and the support queue |
Personally-owned, per allowed platform | Block only after step 4, and only where you mean it | On Windows this blocks Entra join at first sign-in; see step 5 |
Allow min/max range, per allowed platform | Minimum set to your supported floor, maximum left open | A maximum blocks the OS release you have not tested yet, which is usually not what you want |
Device manufacturer (Android) | Comma-separated blocklist, or empty | Android only, and not expressible in Graph v1.0 |
Version format is per platform and the orderings differ. Windows takes major.minor.build.rev and Intune does not receive the revision at enrollment, so enter 0 for it. iOS and iPadOS take major.minor.rev. Android device administrator and Android Enterprise work profile are documented as major.minor.rev.build, which is the reverse of Windows in its last two segments; that is Microsoft’s wording reproduced exactly, and if you are entering a four-part Android version it is worth confirming what the portal accepts rather than trusting either the doc or this sheet.
The minimum and maximum range does not apply to Apple devices enrolling through automated device enrollment, Apple School Manager or Apple Configurator. Intune does not block those enrollments, but a device below the floor cannot create the Entra device record, so the user hits a failure at Company Portal sign-in reading Couldn't map device record with a user. Recognise that string; it is a version-floor failure wearing an unrelated costume.
Step 3. Configure the default device limit restriction
The limit range is 1 to 15. Pick the number a normal user is entitled to and set it on the default, then create exceptions above it rather than raising the floor for everyone.
Before you pick, understand what counts. A device counts against the limit only if it is Intune-managed, has contacted Intune within the last ninety days, has not been in a registration-pending state for more than twenty-four hours, has not failed Apple enrollment, has not been deleted, and is not in a shared enrollment mode. The ninety-day window is the one that generates support tickets: a user replaced a laptop three times in a year and is at their cap because of records nobody removed. Microsoft’s own advice is to remove stale device records, and that belongs in your operations calendar rather than in this sheet.
The user-facing failure when the limit is reached is documented and worth putting in your service desk script verbatim: Couldn't add your device. You have added the maximum number of devices allowed by your IT support. You must remove a device before you can add a new one.
Step 4. Build the corporate identifier list, and prove it is complete
This step is the one that can take the estate down, so read the consequence before you do the work. Once you add Windows corporate identifiers, Intune marks devices matching all three identifiers as corporate-owned and marks every other enrolling device in the tenant as personal. Not just the ones you were thinking about. Every one. Enrollment paths that previously produced a corporate device, including Entra join during Windows setup and Autopilot for existing devices, flip to personal unless the device is on your list.
On its own that is a reporting change. Combined with step 5 it is an outage. So build the list completely, or do not upload it and leave ownership to the enrollment method.
Collect the three fields from a Windows device with the command Microsoft publishes for it:
(Get-WmiObject -Class Win32_ComputerSystem | ForEach-Object {$_.Manufacturer, $_.Model, (Get-WmiObject -Class Win32_BIOS).SerialNumber -join ',' })File rules, all of which are hard limits rather than guidance. Up to 5,000 rows or 5 MB per file, whichever comes first. No header row. One identifier type per file. Up to ten CSV files for Windows corporate identifiers. Windows does not support the device details column at all, so the file is three fields and nothing else, in the order manufacturer, model, serial. Note that the admin center’s picker labels this identifier type in the reverse order from the prose documentation, which is cosmetic and does not change the file.
Worked example. A firm with 340 Windows laptops across two sites builds corpids-windows-hq-20260801.csv and corpids-windows-branch-20260801.csv, 212 and 128 rows. Before uploading, they reconcile the combined row count against their asset register and against the Intune device list filtered to Windows, and find eleven machines present in Intune and absent from the CSVs, all of them loan stock rebuilt last quarter. Those eleven are the devices that would have failed enrollment after step 5. They are added, the count reconciles at 351, and only then does the upload happen.
Do the same reconciliation. The completeness check is the step, not the upload.
Two limits to note for the other platforms while you are here. Corporate identifiers by IMEI or serial stop applying above Android 9 for device administrator and Android 11 for personally-owned work profiles, so on a current Android estate they are not an ownership mechanism any more. And Apple user enrollment and account-driven user enrollment do not support corporate identifiers at all, because the MDM never receives the serial, IMEI or UDID.
Step 5. Decide personally-owned blocking, per platform
On Windows, blocking personally-owned devices does not mean what the label suggests. Intune checks that each new Windows enrollment has been authorised for corporate enrollment, and the paths that pass are Autopilot, group policy or Configuration Manager enrollment for co-management, a bulk provisioning package, and a device enrollment manager account. The paths Intune marks corporate and blocks anyway, because they give the administrator no per-device control, are automatic MDM enrollment with Entra join during Windows setup, the same from Windows Settings, and Autopilot for existing devices. The paths blocked as personal are Add Work Account from Windows Settings, the MDM-enrollment-only option, Company Portal, and the Allow my organization to manage my device checkbox during a Microsoft 365 app sign-in.
Read that list against step 1. If your organisation provisions by having someone sign in to a new laptop and join it to Entra, turning this on stops the build process, and it will look like an Autopilot fault rather than a restriction. Either move provisioning to Autopilot first or leave this setting alone.
One more Windows trap worth a line in the runbook: a device joined by Workplace Join can be blocked if it was ever previously Entra joined to the tenant. The remedy is to deregister and remove the device’s object in Entra before attempting the Workplace Join.
On iOS, iPadOS and macOS the default classification is personally owned, and corporate requires either registration by serial or IMEI, or automated device enrollment. On Android Enterprise, blocking personal enrollment on the work profile means only corporate-owned devices can enrol with personally-owned work profiles, which is a narrower statement than it first reads.
Step 6. Add the exceptions above the defaults
Now, and only now, build the group-targeted policies. Up to twenty-five per restriction type. New policies are inserted just above the default and reordered by dragging in the priority column, where 1 is highest.
Priority resolves rather than merges, and this is the mechanic most often got wrong in the field. A user in two assigned groups is subject only to the policy with the lower priority number. The other policy is discarded entirely, not combined. Microsoft’s Graph documentation states the same rule more precisely: users are subject only to the configuration with the lowest priority value.
Filters are available on macOS, iOS and Windows policies, and are not available on Android. The property set is reduced compared with other policies, because the device is not enrolled yet and Intune does not have full device information: manufacturer, model, OS version, operating system SKU, ownership and enrollment policy name, with manufacturer and model on Windows requiring Windows 11 22H2 or later with the relevant cumulative update. Microsoft’s own worked example uses the SKU property to allow personal Windows devices while blocking a specific edition, with the documented effect of blocking Windows 10 Home.
Assign each policy to at least one group. Then wait. The update between Entra and Intune that processes user, group and filter assignments typically completes within fifteen minutes and is not instant, so a test enrollment run immediately after adding a user to a group tests the previous state.
Step 7. The consolidated Graph equivalent
The whole family lives under one collection, and it is split across API versions in a way that matters. Read the current state from v1.0:
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
# Every enrollment configuration, in priority order
Get-MgDeviceManagementDeviceEnrollmentConfiguration |
Select-Object Id, DisplayName, Priority, '@odata.type' |
Sort-Object Priority | Format-Table -AutoSize
# The assignments on one configuration
Get-MgDeviceManagementDeviceEnrollmentConfigurationAssignment `
-DeviceEnrollmentConfigurationId '<id>'What v1.0 exposes on a platform restriction is exactly four properties: platformBlocked, personalDeviceEnrollmentBlocked, osMinimumVersion and osMaximumVersion. Three things this sheet configures are not expressible there at all. Android manufacturer blocking is blockedManufacturers, SKU blocking is blockedSkus, and scope tags on the restriction are roleScopeTagIds, and all three exist only in beta. So a script that reproduces this build in full has to talk to beta for those properties:
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
Select-MgProfile -Name 'beta'
Invoke-MgGraphRequest -Method GET `
-Uri 'https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations' |
ForEach-Object { $_.value } |
Select-Object id, displayName, priority, deviceEnrollmentConfigurationType, platformTypeReading that output is also how you settle a question this sheet deliberately does not assert. The per-platform tabbed experience in the admin center appears to be backed by the beta-only singular type rather than the v1.0 all-platforms-in-one object, judging by the shape of the types and the presence of a singlePlatformRestriction enum value. That is an inference, not a Microsoft statement. The GET above returns the actual @odata.type and configuration type of what your tenant holds, which answers it for your tenant in one call.
Permissions: reading needs DeviceManagementServiceConfig.Read.All, creating needs DeviceManagementServiceConfig.ReadWrite.All, and updating accepts either that or DeviceManagementConfiguration.ReadWrite.All.
Step 8. The validating test
A test that any lesser configuration would also pass is not a test. This one is built to fail for a specific, checkable reason.
Take a device that is deliberately outside your rules. The strongest single case, if you completed step 4, is a Windows machine that is genuinely absent from the corporate identifier CSVs while personally-owned blocking is on, because it exercises the interaction between two steps rather than one setting. Attempt an enrollment. Then, and this is the assertion, go to the enrollment failures view and read the failure reason. The pass condition is the string Enrollment restriction not met. Anything else, including a generic Company Portal error or a timeout, means you have observed a failure but not the failure you configured.
Run the positive case too, on a device that is on the list, and confirm it enrols and lands with the ownership you intended rather than merely enrolling. Ownership is the thing step 4 changes, so ownership is what proves it.
Then run the case that catches the ordering mistake: enrol via one of the paths from step 1’s second list, an Autopilot self-deploying build or a Windows 365 Cloud PC. It should be governed by your default policy and no other. If it is admitted when your default says it should not be, your default is not what you think it is.
Documented and observed. The admin-side failure reason and the device-limit notification text above are documented by Microsoft and can be relied on from the text. The exact on-device wording a user sees when a platform block or a personally-owned block stops a Windows, macOS or Android enrollment is not published, and this sheet does not invent it. Key your test on the admin-side reason, which is authoritative, and record whatever your own estate shows the user so your service desk recognises it.
Rollback
Every destructive step here has a reverse, and none of them repairs devices that already enrolled under the old rules, because edits are not retroactive.
| If this breaks | Reverse it by | Residue |
|---|---|---|
| Provisioning stops after enabling personally-owned blocking | Set Personally-owned back to Allow on Windows; allow fifteen minutes | None; devices that failed simply retry |
| Devices are marked personal after a corporate identifier upload | Remove the identifiers; Entra joined devices return to being marked corporate at enrollment | Devices already enrolled keep the ownership they got |
| A group is blocked by the wrong exception | Lower the policy’s priority below the one that should win, or unassign it | None |
| The default is too strict | Edit it; it cannot be deleted, which is the safety property | None |
| Users at their device cap | Remove stale device records rather than raising the limit | Raising the limit hides the stale-record problem |
Completion checklist
The build is done when all of the following are true and you have observed each one rather than assumed it.
| Check | How you know |
|---|---|
| Live enrollment paths are written down | Step 1 table completed against your tenant |
| Default platform restriction set on all six platform tabs | No tab left at its shipped value by accident |
| Default device limit set deliberately | A number you can defend, not the shipped one |
| Corporate identifier list reconciles | CSV row count matches the asset register and the Intune Windows device list |
| Personally-owned blocking decided per platform | Decided after the identifier list, not before |
| Every non-default policy is assigned to at least one group | Unassigned policies have no effect and no report |
| Priority order verified | The intended policy wins for a user in two groups |
| Negative test fails correctly | Enrollment failures shows Enrollment restriction not met |
| Positive test lands with the right ownership | Not merely enrolled; the ownership type is what you intended |
| A non-user-driven path was tested | Governed by the default and nothing else |
| DEM accounts enumerated | Each one is a deliberate exception to everything above |
One closing caution that belongs with this sheet rather than in the doctrine. Enrollment restrictions are not a security control, and Microsoft says so on the page that defines them: compromised devices can misrepresent their character, and the restrictions are a best-effort barrier for non-malicious users. Build them because they keep an estate clean and a licence count honest and a support queue small. Do not build them believing they stop an attacker, because that belief is what leads someone to skip the control that would have.
Best Practices
‹ Previous: [BP 4.1] The Intune Baseline: The Critical Tier
Next: [BP 4.2] The Intune Baseline: Recommended and Optional Tiers ›
