Autopilot device preparation has changed more in the first half of 2026 than in the eighteen months before it. The app limit went from ten to twenty five, managed installer stopped silently skipping your Win32 apps, and automatic mode for Windows 365 reached general availability. Most of the guides you will find have not caught up.
What actually changed in 2026
These are the dated entries from Microsoft’s own release notes, not a summary of someone else’s summary. If you last read about device preparation in 2025, three of these will be new.
| Date | Change | Why it matters |
|---|---|---|
| 11 May 2026 | Automatic mode for Windows 365 reached general availability | Covers Enterprise, Flex dedicated, Flex shared and Cloud Apps. Reserve is still preview. |
| 10 Apr 2026 | Managed installer policy supported during OOBE | Win32, Store and Enterprise App Catalog apps were previously skipped outright to avoid install conflicts. If you run App Control, this is the entry that unblocks you. |
| 30 Jan 2026 | App limit raised from 10 to 25 | Applies to user-driven and automatic modes, including Cloud PCs. Microsoft’s own note tells you to revisit your deployment timeout. |
| 9 Sep 2025 | Monthly security updates during OOBE delayed | Announced on 3 September, delayed six days later, and still not shipped. When it lands it adds 20 to 40 minutes. |
Worth knowing
Searching for this today returns an AI Overview stating a maximum of ten apps, and several of the highest ranking third party guides say the same. The limit has been twenty five since 30 January 2026. Check the date on anything you read about this feature, including this post.
Device preparation or classic Autopilot
This is the only question that matters, and it is not a question about which is newer. Device preparation is a narrower tool. It is faster and easier to reason about inside its boundaries, and outside them it simply does not apply.
| If you need | Use |
|---|---|
| Microsoft Entra hybrid join | Classic Autopilot. Device preparation supports Entra join only. |
| Pre-provisioning, sometimes called white glove | Classic Autopilot. |
| Self-deploying or kiosk style, no user present | Classic Autopilot. |
| Windows 10 | Classic Autopilot. Device preparation is Windows 11 only. |
| Autopilot Reset | Classic Autopilot. |
| Fine grained Enrollment Status Page behaviour | Classic Autopilot. Device preparation does not use the ESP at all. |
| New Windows 11 user-driven builds, fast, with readable failure reporting | Device preparation. |
| Cloud PCs configured before first sign in | Device preparation in automatic mode. |
The pre-provisioning row is the one that decides it for most people shipping hardware to remote staff. It is also the most common objection raised by admins who have tried to move and stopped.
The registration conflict that fails quietly
A device that is already registered as a Windows Autopilot device will use its Autopilot profile and ignore your device preparation policy. There is no error telling you this. The deployment simply behaves like classic Autopilot and you spend an afternoon wondering why your policy is not applying.
This bites hardest on repurposed hardware. Anything that has been through Autopilot before, including devices a supplier registered on your behalf, carries the registration until you deregister it.
Caution
Deregistering a device removes it from Autopilot for every profile, not just the one you are testing. On a shared tenant, confirm the device is genuinely yours to deregister before you do it.
Checking before you blame the policy
Run this before troubleshooting anything else. It lists every device registered for classic Autopilot, which is the population that will ignore a device preparation policy.
# Requires the Microsoft.Graph.DeviceManagement.Enrollment module.
Connect-MgGraph -Scopes ‘DeviceManagementServiceConfig.Read.All’
# Every device registered for classic Autopilot. Anything listed here will use
# its Autopilot profile and silently ignore a device preparation policy.
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
Select-Object SerialNumber,
Model,
GroupTag,
EnrollmentState,
DeploymentProfileAssignmentStatus |
Sort-Object Model |
Format-Table -AutoSize
If a serial you are testing appears in that output, the policy was never the problem.
The twenty five app limit is not a target
Microsoft raised the ceiling and, in the same release note, told administrators to review their deployment timeout. That pairing is the actual advice. Every app you add runs before the user reaches the desktop, so the limit is a budget rather than an allowance.
A sensible split is to deliver only what the device genuinely cannot be useful without, then let everything else arrive after first sign in through normal assignment. Applications and scripts assigned to the device group but not selected in the policy still deploy, just afterwards.
What I would do
If your estate is Windows 11, Entra joined, and you do not pre-provision, device preparation is the better tool and the reporting alone justifies the move. The near real time deployment report tells you which app failed and when, which classic Autopilot never did well.
If you ship pre-provisioned hardware to remote staff, or you still have hybrid join anywhere in scope, stay on classic Autopilot and revisit when pre-provisioning arrives. Running both in parallel is supported and is usually the honest answer during a transition, because the two are selected per device rather than per tenant.
