Autopilot ESP ignores blocking apps: user-targeted fix

Assign the Enrollment Status Page (ESP) profile that holds your blocking-app list to a device group, or put the list in the default ESP profile. During device setup, Intune can’t resolve a user-targeted ESP profile because it doesn’t know who the user is yet, so the blocking list in that profile is ignored. Then make sure each blocking app is a required, device-context assignment to a group that contains the device.

Microsoft documents this as a Windows Autopilot known issue. If you are about to rewrite a detection rule because ESP “skipped” an app, check the ESP profile assignment first.

Symptoms that point to this issue

You are probably hitting this exact issue when all of these are true:

• The ESP profile that contains Block device use until these required apps are installed if they are assigned to the user/device (set to Selected, with a blocking-apps list) is assigned to a user group.
• The app you put in that list doesn’t hold up the Device setup phase. ESP moves on to Account setup, or finishes, without waiting for it.
• On the device, the app has no entry under the device-setup tracking key (see Prove it from the registry).
• No dedicated error code appears. ESP doesn’t fail. It just doesn’t treat the app as blocking.

Microsoft’s title for the issue is the closest thing to an exact error string:

Blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP

If ESP shows a timeout or an app install error instead, you have a different problem. Use the general AI-assisted ESP failure triage workflow to narrow it down.

What Microsoft says

The Windows Autopilot known issues page describes it this way:

The services responsible for determining the list of apps that should be blocking during device ESP aren’t able to determine the correct ESP profile containing the list of apps because they don’t know the user identity. As a workaround, enable the default ESP profile (which targets all users and devices) and place the blocking app list there. To avoid this issue, target the ESP profile to device groups.

The ESP setup documentation explains why. Under Prioritize profiles, Intune picks an ESP profile in this order:

1. The highest-priority profile assigned to the device.
2. If no profile targets the device, the highest-priority profile assigned to the user. Microsoft adds: “This only works in scenarios where there’s a user. In pre-provisioning and self-deploying scenarios, Intune only applies profiles targeted at devices.”
3. If nothing is assigned to the device or the user, the default ESP profile.

Two things follow from that order. First, in pre-provisioning and self-deploying mode, a user-targeted ESP profile never applies, so its blocking list can’t apply either. Second, any device-targeted profile beats every user-targeted one. If a device-group profile without your blocking list exists, that’s the profile the device gets.

Fix it in Intune

Before you change anything, write down every ESP profile, its priority, and its assignments.

1. In the Intune admin center, select Devices > Device onboarding > Enrollment. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
2. Find the profile that holds the blocking-apps list. Under Assignments, check whether it targets a user group.
3. Pick a fix:
   • Preferred: assign that profile to a device group that contains your Autopilot devices. Microsoft recommends this to avoid the issue.
   • Quick workaround: put the blocking-apps list in the default ESP profile, which Intune applies to all users and all devices when no other profile is assigned. This only works if no other profile targets the device or user, so it suits small tenants better than large ones.
4. Check priority. If several device-targeted profiles reach the same device, the one with priority 1 wins. Drag the profile with the blocking list above any device profile that lacks it.
5. In the profile settings, confirm Show app and profile installation progress is Yes and Block device use until all apps and profiles are installed is Yes. Then confirm Block device use until these required apps are installed if they are assigned to the user/device is Selected, with your apps in the list. You can select up to 100 apps.
6. Fix each blocking app’s own assignment (next section). The profile fix alone won’t make an app track.
7. Test on one pilot device from a fresh OOBE before you change production assignments.

Make each blocking app trackable in device setup

Microsoft’s ESP troubleshooting article lists the conditions an app must meet for ESP to install and track it:

• It has a required assignment to a Microsoft Entra group that contains the device. Device-targeted apps are tracked in device setup. User-targeted apps are tracked in user setup.
• Block device use until all apps and profiles are installed is set, or the app is in the blocking list.
• It installs in device context and has no user-context applicability rules.

Two documented details catch people out here:

• The blocking list is a filter. It doesn’t deploy anything. Per the ESP setup page, ESP tracks only listed apps that are also targeted to the device or user. In user-driven and self-deploying mode, a targeted Win32, Microsoft Store, or Enterprise App Catalog app that isn’t on the list isn’t installed until after ESP completes.
• On Microsoft Entra hybrid join, “Win32 and UWP apps assigned to the device with user installation context aren’t tracked during provisioning.” A device-group assignment won’t help if the app’s install behavior is set to User.

I’d keep the device-setup blocking list short: only the apps the device genuinely can’t be handed over without. Every extra blocking app is another way for provisioning to time out.

Prove it from the registry

Run a capture on the affected device before you reset it. The command comes from Microsoft’s ESP troubleshooting article (Windows 10, version 1809 and later):

mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:\Temp\esp-device-phase.cab

Open MDMDiagReport_RegistryDump.Reg from the CAB and check two places:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync holds the ESP settings the device received.
2. Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking, the Device\Setup subkey lists the Win32 apps tracked in device setup. Each one appears as Apps\Tracking\Sidecar\Win32App_{AppID} with an InstallationState value.

If your blocking app has no Win32App_{AppID} entry under Device\Setup, ESP never tracked it in device setup. That matches this known issue, or an app that fails the conditions above. If the entry exists with InstallationState 4 (Error), ESP did track the app and the install failed. In that case, go to the Intune Management Extension log, not the ESP profile.

How this differs from similar ESP issues

Several Autopilot known issues look like “ESP didn’t wait for my app.” They have different causes and different fixes:

What you see	Cause	Article
Blocking apps in a user-targeted ESP profile don’t block device setup	User identity isn’t known during device ESP	This page
Required apps aren’t shown on ESP after an Autopilot Reset	Known issue specific to Autopilot Reset	Required apps not showing on ESP after Autopilot Reset
Account setup never appears after a FIDO2 (YubiKey) sign-in on a Shared PC in self-deploying mode	Known issue with FIDO2 sign-in	ESP account setup not shown for FIDO2 sign-in
The Autopilot report shows Failed but the device finished	Reporting known issue	Autopilot report false failure

Get the Deployment Doctor

Kit 1 founding presale is open: $39 (regular $49). The Autopilot + Device Prep Deployment Doctor checks your tenant, read-only, for the config that breaks ESP and Device Preparation. You pay now and get the files by Tuesday, December 1, 2026, sooner if they’re ready. Full refund any time before delivery, then 14 days after delivery.

Want to look first? The free, read-only beta scripts are on GitHub: autopilot-deployment-doctor-beta. Its README says they haven’t been run against a live tenant.

FAQ

Does this affect the account setup (user) phase?

No. Microsoft’s known issue is limited to device ESP. Once a user signs in, Intune knows the identity and can apply a user-targeted profile, and user-targeted apps are tracked in the user setup phase.

Will a user-targeted ESP profile work in self-deploying or pre-provisioning mode?

No. Microsoft’s profile priority rules say that in pre-provisioning and self-deploying scenarios, Intune only applies ESP profiles targeted at devices.

Should I use the default ESP profile or a device-group profile?

Use a device-group profile if you can. Microsoft lists it as the way to avoid the issue. The default profile is Microsoft’s workaround, and Intune applies it only when no other profile is assigned to the device or user.

Does adding an app to the blocking list deploy it?

No. The list only filters which targeted apps ESP waits for. The app still needs its own required assignment to a group that contains the device.

Is there an error code for this issue?

Microsoft doesn’t list one. ESP doesn’t fail. It just doesn’t wait for the app during device setup. If you do have an error code, troubleshoot that code first.

Sources

• Windows Autopilot known issues, Microsoft Learn (updated September 8, 2026)
• Set up the Enrollment Status Page in the admin center, Microsoft Learn
• Troubleshoot the Enrollment Status Page (ESP), Microsoft Learn