Windows Autopilot Pre-Provisioning Bypasses Enrollment Restrictions?

This blog explores why and how Intune Device Platform enrollment restrictions don’t always block outdated Windows versions when you have configured an additional enrollment restriction policy. Many assume assigning it to all users will prevent enrollment, but Windows Autopilot for Pre-Provisioned Deployments bypasses user-based restrictions entirely. We’ll break down why this happens and how to properly enforce OS version blocks in all enrollment scenarios.

Introduction to the Platform Enrollment Restrictions

Let’s say you have configured an additional Device Platform Enrollment restriction policy in Intune to block outdated Windows versions from enrolling instead of using the Default one.

Once the additional platform restriction is created, you assign it to a specific user group, double-check the settings, and expect everything to work as planned. As shown below, we configured the platform restriction to require a minimum Windows version of 10.0.0.26100 (Windows 11 24h2 Feb 2025)

But somehow, devices with outdated (No Windows 11 24H2) Windows builds are still showing up in Intune. They’re fully enrolled and managed by Intune, even though they clearly don’t meet the OS version requirement (10.0.26100).

They should have been blocked with it, right? You check the device platform restriction policy again, and everything looks correct. So why isn’t Intune enforcing the restriction as expected?

The Assumption: Additional Enrollment Restrictions Apply Everywhere

When a user-driven Windows Autopilot enrollment happens, the assumption is that as soon as the user signs in and the device starts enrolling into Intune, the OS version Platform restrictions will be checked. If the device is running an unsupported build, enrollment will be blocked immediately.

But that’s not exactly how it works.

What Happens in a User-Driven Enrollment:

1. The user reaches the Entra ID authentication screen and logs in.
2. The device is Entra ID joined.
3. Intune enrollment starts after the Entra join is complete.
4. At this point, Intune checks the user’s assigned platform enrollment restrictions. If the OS version does not meet the requirement, the enrollment process stops, and the device is never fully enrolled in Intune, causing Windows Autopilot enrollment to fail.

That’s where enrollment restrictions come into play. They don’t apply at the Entra ID join stage but rather at the moment the device attempts to enroll in Intune after the join is complete.

But what if a device enrolls without a user signing in at all? That’s exactly what happens in Windows Autopilot for Pre-Provisioned Deployments, and that’s where things get interesting.

Windows Autopilot Enrollment: User-Driven vs. Pre-Provisioned Deployments

There are two ways a device can enroll in Intune via Windows Autopilot:

1. User-Driven Enrollment – The user logs in, the device joins Entra ID, and when Intune enrollment starts, it checks if the OS version restriction applies to the user. If the version is below the minimum, the enrollment will be blocked.
2. Windows Autopilot for Pre-Provisioned Deployments – The device enrolls into Entra ID and Intune before any user logs in, using TPM attestation and the Autopilot@ or “foo” user to authenticate itself to Intune.

Because Pre-Provisioned Deployments happen without a real user sign-in, Intune never seems to check user-based enrollment restrictions. The device authenticates at the hardware level, meaning any additional user-targeted platform restrictions are bypassed.

This is why outdated Windows versions are still enrolling, even though you configured an additional enrollment restriction. Since there is no user context at enrollment, the additional enrollment restriction isn’t evaluated, and Intune allows the process to be completed.

The Default Enrollment Restriction Policy: The Only Way to Block Pre-Provisioned Deployments

If you want to prevent outdated Windows versions from enrolling in all scenarios, including Windows Autopilot for Pre-Provisioned Deployments, you NEED to configure the default platform restriction policy instead.

Unlike additional policies that only apply when a user signs in, the default policy is enforced as soon as the device contacts Intune for enrollment!

https://learn.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set

As shown above, Intune enforces the default policy in enrollment scenarios that aren’t user-driven!

This means:

• It enforces OS version restrictions even when Windows Autopilot for Pre-Provisioned Deployments is used.
• Pre-Provisioned Deployments cannot bypass it. If an OS version is blocked in the default policy, the device is prevented from enrolling before the process even starts.
• User-driven enrollments still respect it, so the restriction applies regardless of whether a user is present or not.

If you only configure an additional user-based enrollment restriction and leave the default one untouched, Pre-Provisioned Deployments will ignore the restriction entirely. That’s why outdated devices are still enrolling.

How to Actually Block Old Windows Versions

If you want to ensure that outdated Windows versions never enroll, no matter the scenario, you must:

1. Edit the default enrollment restriction policy in Intune.
2. Set a minimum OS version for Windows under platform restrictions.
3. Save the policy and ensure it applies to all devices.

Once this is configured, Intune will enforce the OS version check in both Windows Autopilot user-driven enrollment and Windows Autopilot for Pre-Provisioned Deployments. With this restriction in place, the enrollment will be blocked!

Besides configuring an enrollment restriction, ensuring you have a compliance policy in place is also a good idea.

Compliance Policy

Enrollment restrictions decide if a device can get in… Compliance policies decide what happens after that. If a device manages to enroll with an outdated OS, a compliance policy can still flag it and block access. The first step is to configure a minimum OS version in the compliance policy.

Once that’s in place, you can combine it with Conditional Access to block access to company resources until the device is updated. This gives you a second layer of control, even if the enrollment restriction didn’t catch the device at the start.

If the device slips through, it won’t get far. No access until it meets the OS version requirement.

Conclusion

If you’re only relying on additional enrollment restrictions assigned to users, outdated Windows devices will still find a way in, especially when using Windows Autopilot for Pre-Provisioned Deployments, where no user context exists during enrollment. These deployments skip user-based checks entirely.

To truly block unsupported Windows versions from enrolling, you need to configure the default platform restriction policy. It’s the only restriction enforced before any user signs in, making it effective during all types of enrollment.

But don’t stop there. Devices that bypass enrollment restrictions can still be stopped at the compliance level. By enforcing a minimum OS version in your compliance policy and combining it with Conditional Access, you ensure only supported, compliant devices gain access to company resources.

Block it at the door with the default restriction. Catch anything that gets through with compliance.