Allowing users to enrol Windows devices into Microsoft Intune is useful, but that does not necessarily mean you want somebody’s personal Windows laptop becoming a fully managed device in your tenant. This article covers how to block personal Windows devices.

Intune includes device platform enrolment restrictions that can control new enrolments by platform, operating system version and ownership type. For Windows, that includes an option to leave Windows MDM enrolment enabled while specifically blocking devices that Intune evaluates as personally owned.

In this guide, I’m going to configure that restriction, attempt to enrol a personal Windows 11 device and prove the block from both sides. We’ll then take the lab one step further by adding the same Windows device as an approved corporate device using its manufacturer, model and serial number, before repeating the enrolment.

The checkbox itself takes a few seconds. The interesting part is understanding what Intune considers a personal Windows device in the first place.

As we’ll see, that is not always as simple as:

“Device bought from Currys = personal.”

What are Intune enrolment restrictions?

Microsoft Intune provides two main types of enrolment restriction:

• Device platform restrictions control which platforms and ownership types can enrol, and can also apply operating system restrictions.
• Device limit restrictions control how many devices an individual user can enrol.

For this guide, we are using a device platform restriction.

Every Intune tenant has a Default restriction. Intune uses that policy for user and userless enrolments until a higher-priority custom restriction applies to the enrolling user.

There is an important limitation worth understanding before configuring anything.

Microsoft explicitly says that enrolment restrictions are not security features. They are a best-effort barrier designed to stop non-malicious users from enrolling devices that should not be enrolled. A compromised device could potentially misrepresent its characteristics.

I think that distinction matters.

An enrolment restriction is a useful guardrail for normal users. It is not a security boundary. If somebody is deliberately trying to spoof device information, this checkbox is not where your incident response plan ends.

Never miss an article and subscribe, and don’t forget to check out my YouTube channel, Control Alt Delete Tech Bits

Like the article? Feel free to buy me a coffee

Also check out my redact app, Redact PDFs and images, review email evidence and manage subject access requests without sending source files to a processing server.: https://redactninja.com

And my other projects IntuneAccess and IdentityAtlas
 

Blocking enrolment is not the same as blocking Microsoft 365 access

This setting controls whether a Windows device can enrol into Intune.

It does not mean:

Personal Windows device = cannot access Microsoft 365.

If your requirement is that only compliant or organisation-managed devices can access Microsoft 365, that is a separate design involving Intune compliance and Microsoft Entra Conditional Access.

Here we are solving a narrower problem:

Do I want this Windows device becoming Intune managed?

Why block personal Windows devices?

If your organisation issues Windows devices centrally and does not support fully managed Windows BYOD, there is usually little benefit in allowing users to enrol personal Windows PCs.

Blocking personal enrolment can help:

• prevent users accidentally enrolling home computers
• keep the Intune device inventory cleaner
• separate corporate hardware from BYOD more clearly
• prevent device configuration policies being applied to machines that were never intended to be managed
• support an Autopilot-first or organisation-owned Windows strategy

There is also a user-experience consideration.

If someone enrols their own PC into full MDM management without understanding what they are agreeing to, both the user and IT department can end up having a considerably more interesting day than either intended.

Licensing and prerequisites

An Intune licence is required for users or devices benefiting from the Intune service. Microsoft Intune Plan 1 is the base Intune service and is included in Microsoft 365 packages including Microsoft 365 E3, E5 and E7.

For the automatic Windows MDM enrolment used in this lab, Microsoft currently lists:

• Microsoft Intune
• Microsoft Entra ID P1 or P2

as prerequisites. Automatic MDM enrolment is a Microsoft Entra Premium capability.

You will also need:

• a supported Windows 11 device or VM
• an Intune-licensed test user
• the user to be in scope for Windows automatic MDM enrolment
• suitable Intune administrative permissions
• a Windows device that isn’t already managed by another MDM

For the lab, I used a clean Windows 11 VM.

This site and my YouTube channel are supported by Tech-Source.

Tech-Source is a UK-based technology supplier that works closely with IT teams across education, public sector, and commercial environments. They provide hardware, licensing, and infrastructure solutions, with a strong focus on practical advice rather than upselling.

Their support helps keep this site running and allows me to continue publishing in-depth, admin-focused content and walkthroughs without paywalls.

You can find out more about what they do at https://tech-source.co.uk/

Check Windows automatic MDM enrolment first

Before creating the restriction, check that your user is actually able to trigger an Intune enrolment.

In the Microsoft Intune admin centre, go to:

Devices > Device onboarding > Enrollment

Open the Windows tab and select:

Automatic Enrollment

Check MDM user scope.

The available options are:

• None – automatic MDM enrolment is disabled
• Some – only selected users are enabled
• All – all users are enabled

Microsoft states that when the MDM user scope is Some or All, devices can automatically enrol in Intune when the user joins or registers the device with Microsoft Entra ID.

In my lab, this is configured as:

MDM user scope: All

This check matters.

If the user is outside the MDM scope, Windows can complete part of the Microsoft Entra registration process without actually attempting Intune MDM enrolment.

You could then spend twenty minutes troubleshooting an enrolment restriction that never had anything to block.

Screenshot: Windows Automatic Enrollment showing the MDM user scope.
Alt text: Microsoft Intune Windows automatic MDM enrolment scope.

Create the Windows enrolment restriction

Now go to:

Devices > Device onboarding > Enrollment

Under Enrollment options, select:

Device platform restriction

Select the:

Windows restrictions

tab.

Microsoft’s current documented configuration path uses this Device platform restriction area.

You should already see the Default restriction.

I recommend creating a new policy rather than changing Default, particularly if you are testing this in an existing tenant.

Select:

Create restriction

For my lab, I used:

Name

No personal devices

You can of course use something slightly more descriptive in production, such as:

Block Personal Windows Devices

Configure the Windows restriction

On Platform settings, configure:

Setting	Value
MDM	Allow
Personally-owned	Block
Minimum OS version	Not configured
Maximum OS version	Not configured

The distinction here is important.

We are not blocking Windows MDM enrolment.

MDM = Allow

means Windows devices are still allowed to enrol.

Personally-owned = Block

means the ownership evaluation decides whether a particular enrolment request is allowed through.

Microsoft documents Personally-owned as the setting that determines whether devices can enrol and operate as personal devices.

Screenshot: Platform settings showing MDM Allow and Personally-owned Block.
Alt text: Microsoft Intune enrolment restriction blocking personally owned Windows devices.

Assign the restriction

Continue to Assignments.

In my lab tenant, I assigned the restriction to:

All users

That means the restriction applies broadly rather than only to a pilot group.

For a production environment, I would normally start with a smaller test group first.

You can assign a new enrolment restriction to everyone immediately.

You can also test a fire alarm by setting fire to the building.

A pilot group is normally less stressful.

Once assigned, create the policy.

Check the restriction priority

Back on the Windows restrictions page, you should now see your custom policy alongside the Default restriction.

In my tenant I have:

Priority 1: No personal devices
Default: All Users

Intune evaluates the highest-priority applicable restriction for the user, while the Default restriction remains the lowest priority fallback.

Make sure the policy you expect to apply is actually at the correct priority.

Screenshot: Custom No personal devices policy at priority 1.
Alt text: Microsoft Intune Windows enrolment restriction priority.

Give the policy time to apply

Do not create the policy and immediately assume it is broken if the next enrolment succeeds.

Allow the Intune and Microsoft Entra assignment processing some time before testing.

For my lab, I allowed approximately 15 minutes before attempting the enrolment.

This is also a perfectly valid point in the troubleshooting process to make a cup of tea.

Test the enrolment from Windows 11

Now move to your personal Windows device or clean VM.

Go to:

Settings > Accounts > Access work or school

Select:

Connect

Enter the user’s organisation account.

Microsoft documents this Windows Settings route as a supported way for personal Windows devices to register and automatically enrol when the user is in scope for MDM automatic enrolment.

This is a particularly useful test because Microsoft explicitly classifies Automatic MDM enrollment with Add Work Account from Windows Settings as personal unless the device is defined by a corporate identifier.

Continue through the sign-in process.

Windows now attempts to register the work account and enrol the device.

Because our user is covered by:

Personally-owned = Block

the Intune enrolment should be rejected.

What does the user see?

In my lab, Windows was unable to enable device management for the organisation account.

That gives us the first half of our evidence:

the user-side enrolment failed.

But I don’t like stopping a test there.

A failed Windows dialog tells us something went wrong. It doesn’t necessarily tell us why.

So next we go back to Intune.

Check the Intune enrolment failure

In the Microsoft Intune admin centre, go to:

Devices > Monitor > Enrollment failures

The Enrollment failures report shows failed enrolment attempts including:

• date
• failure reason
• operating system
• OS version
• username
• enrolment method

Microsoft documents this report specifically for troubleshooting enrolment problems.

Find the failed attempt from your test user.

Microsoft documents Enrollment restriction not met as the failure reason when a personal device is prevented from enrolling by an enrolment platform restriction.

In my lab, the failure also clearly identified that the device could not enrol as personal.

That completes the first test:

Restriction created > Windows enrolment attempted > enrolment blocked > failure verified in Intune

This is the part I always want from an Intune lab.

A green configuration screen proves what we configured.

It doesn’t prove the endpoint behaved the way we expected.

Now we have both.

Screenshot: Intune Enrollment failures showing the blocked Windows enrolment.
Alt text: Microsoft Intune enrolment failure caused by a personal Windows device restriction.

What does Intune consider a personal Windows device?

This is probably the most useful part of the entire configuration.

If you remember one thing from this article, make it this:

Personally owned is an enrolment-time evaluation, not simply a description of who paid for the laptop.

Different Windows enrolment methods are treated differently.

Microsoft authorises several methods for corporate enrolment without requiring a Windows corporate identifier, including:

• Windows Autopilot
• Group Policy enrolment
• co-management
• bulk provisioning
• Device Enrollment Manager enrolment

Other user-driven methods can be blocked when personal Windows enrolment is disabled. These include:

• Add Work Account from Windows Settings
• MDM-only enrolment from Windows Settings
• Intune Company Portal enrolment
• enrolment initiated through a Microsoft 365 application where the user allows the organisation to manage the device

There are also Microsoft Entra join scenarios that can look slightly strange from an ownership perspective.

A device might ultimately be considered corporate after successful enrolment while still being blocked during the enrolment process because Intune does not have per-device evidence that the hardware has been authorised.

Microsoft has therefore managed to produce a device that can be blocked for looking personal on its way to becoming corporate.

Identity administrators will probably recognise the general theme.

What about Windows corporate device identifiers?

This brings us to the second half of the lab.

Suppose the Windows device that just failed actually is legitimate organisation-owned hardware.

We don’t want to disable the personal-device restriction just to allow one approved device.

Instead, Intune supports Windows corporate device identifiers.

For Windows, the identifier consists of three properties:

• Manufacturer
• Model
• Serial number

All three must match the enrolling device.

This gives the administrator per-device control over which Windows hardware should be treated as corporate during the enrolment restriction evaluation.

Windows corporate identifier requirements

Microsoft currently supports Windows corporate identifiers on:

• Windows 11 version 22H2 with OS build 22621.3374 or later
• Windows 11 version 23H2 with OS build 22631.3374 or later

The relevant servicing update is KB5035942 for those Windows 11 builds.

Windows 10 22H2 is also supported from build 19045.4598, although Windows 10 itself reached end of support on 14 October 2025.

For new labs and deployments, I would concentrate on Windows 11.

Get the manufacturer, model and serial number

On the Windows device, open PowerShell.

Run:

Get-CimInstance -ClassName Win32_ComputerSystem | ForEach-Object {
    $_.Manufacturer, $_.Model, (Get-CimInstance -ClassName Win32_BIOS).SerialNumber -join ','
}

Microsoft documents this approach for retrieving the values needed for Windows corporate identifiers.

On my VM, the result contained values similar to:

Microsoft Corporation,Virtual Machine,1234567890

Use the values actually returned by your device.

Do not replace them with what you think the model ought to be.

Intune is matching the data reported by Windows, not your asset spreadsheet’s opinion of the hardware.

Screenshot: PowerShell displaying manufacturer, model and serial number.
Alt text: PowerShell retrieving Windows corporate device identifier information.

Create the corporate identifier CSV

Windows corporate identifiers must be uploaded using a CSV file.

Manual entry is not currently available for Windows identifiers.

The CSV should contain:

Manufacturer,Model,SerialNumber

but those words are not column headings.

Replace them with the actual values.

For example:

Microsoft Corporation,Virtual Machine,1234567890

Do not include a header row.

Microsoft supports up to 5,000 rows or 5 MB per CSV file, whichever limit is reached first.

If the serial number contains full stops, Microsoft says to remove them before uploading the identifier.

Upload the Windows corporate identifier

In the Intune admin centre, go to:

Devices > Enrollment

Select:

Corporate device identifiers

Choose:

Add > Upload CSV file

For Identifier type, select:

Manufacturer, model, and serial number (Windows only)

Browse to your CSV file.

Intune validates the file first. Once the number of identifiers appears, validation has completed.

Select:

Add

You should then see the corporate identifier listed in Intune.

Screenshot: Windows corporate device identifier CSV upload.
Alt text: Uploading a Windows corporate device identifier to Microsoft Intune.

What does “Not contacted” mean?

After adding the identifier, you might initially see:

Not contacted

That is expected.

Intune knows about the authorised identifier, but the Windows device has not yet contacted Intune and completed enrolment using it.

Microsoft currently reports identifier states including:

• Enrolled
• Not contacted
• Not applicable
• Failed

At this point, Intune effectively knows:

If a Windows device arrives with this manufacturer, this model and this serial number, it is approved corporate hardware for the enrolment evaluation.

Retry the same Windows enrolment

Now repeat exactly the same test.

Keep the enrolment restriction unchanged:

MDM: Allow
Personally-owned: Block

Return to:

Settings > Accounts > Access work or school

Select:

Connect

Use the same organisation account.

This time, Intune can compare the device’s:

• manufacturer
• model
• serial number

against the corporate identifier we imported.

If all three match, Microsoft says Intune treats the device as corporate during the enrolment restriction evaluation.

In my lab, the same Windows device that was previously blocked could now complete the process after its corporate identifier was added.

That gives us a much more useful test than simply showing the Block setting:

Same user.

Same Windows device.

Same enrolment restriction.

The difference is that Intune now has administrator-provided evidence that the hardware is approved.

An important corporate identifier gotcha

There is one behaviour here that is very easy to misunderstand.

Windows corporate identifiers only apply at enrolment time.

They do not permanently force the device ownership field in Intune to Corporate.

For example, Microsoft specifically documents that a device enrolling with Add Work Account from Windows Settings can match a corporate identifier and therefore be treated as corporate for the enrolment restriction evaluation.

That lets it past our:

Personally-owned = Block

restriction.

However, after enrolment, that device can still appear as Personal in the Intune admin centre because the normal long-term ownership logic for that enrolment method takes over.

That is expected behaviour.

The corporate identifier is effectively saying:

“I authorise this piece of hardware to enrol.”

It is not saying:

“Forever mark this device Corporate regardless of how it enrols.”

If you need to change the ownership property after enrolment, Intune also allows an administrator to edit Device ownership from the device’s Properties page.

Another important Windows corporate identifier behaviour

There is another consequence worth knowing before uploading corporate identifiers across a production tenant.

Once Windows corporate identifiers have been added, Intune uses those identifiers during enrolment to determine which Windows hardware has been explicitly authorised.

A device matching all three values is treated as corporate during that check.

Other enrolling Windows devices that do not match the corporate identifier list are treated as personal for the enrolment-time evaluation.

That is useful when combined with:

Personally-owned = Block

because it creates an allow-list style model for applicable Windows enrolments.

It also means you should understand your enrolment methods before importing identifiers and enabling the block for everybody.

Test first.

Production users make remarkably effective monitoring systems for missed assumptions, but they rarely appreciate being used that way.

Existing enrolled devices are not affected

Changing an enrolment restriction affects new enrolments.

Microsoft says changes to enrolment restrictions do not affect devices that are already enrolled.

So enabling:

Personally-owned = Block

does not suddenly remove existing personal Windows devices from Intune.

If you already have personal Windows devices in the tenant, there are really two jobs:

1. prevent new personal enrolments
2. decide separately what to do with existing personal devices

That second task might involve reviewing ownership, compliance, retirement and your organisation’s BYOD policy.

If an organisation supplies all Windows endpoints centrally and does not support Windows BYOD management, I would seriously consider blocking personal Windows enrolment.

It fits particularly well where:

• Windows Autopilot is the standard provisioning route
• corporate devices are purchased centrally
• BYOD PCs should access services without becoming fully Intune managed
• device inventory needs a clear corporate boundary
• approved hardware can be identified before enrolment

Would I switch it on for All users without testing?

No.

The setting itself takes seconds to configure.

Understanding every Windows enrolment route being used in the organisation is the part that deserves the testing time.

Blocking personal Windows devices in Microsoft Intune is a small configuration change with more going on behind it than the interface suggests.

The basic policy is simple:

MDM = Allow

Personally-owned = Block

But the useful bit is understanding how Intune decides whether the device is authorised.

In our lab, the Windows device was initially rejected because it was attempting a personal enrolment.

We then collected the device’s manufacturer, model and serial number, uploaded those values as a Windows corporate device identifier and repeated the same enrolment.

This time Intune had enough information to recognise the hardware as authorised during the enrolment check.

That is the behaviour I would want to understand before deploying this broadly: not just where the Block option lives, but what Intune does when a real device reaches it.

You might also enjoy this article