Windows Autopilot device preparation is now the default. Here’s how to move without breaking what works.

On 16 September 2026 the Intune team published its clearest statement yet on where Windows provisioning is heading: Windows Autopilot device preparation is now the recommended solution for user-driven scenarios, and future engineering investment will go to device preparation rather than classic Autopilot.

If you have spent years tuning deployment profiles, Enrollment Status Page settings, group tags and dynamic groups, that sentence deserves a calm reading. Nothing is being switched off. But the direction is set, and the organizations that plan the move now will get the reliability and reporting improvements first, while everyone else inherits a growing gap.

Here is how we read the announcement, and how we would approach it.

What device preparation actually changes

Classic Autopilot spreads a deployment across several objects: a deployment profile, an Enrollment Status Page profile, a hardware-hash registration, a group tag, and one or more dynamic groups that key off that tag. Device preparation collapses most of that into a single device preparation policy that carries the OOBE settings, required apps, PowerShell scripts, the device-name template and an enrollment-time grouping (ETG) target. During setup the device joins a static Entra security group, and that group carries its apps, policies and scope tags.

A second, optional capability, device association, binds a physical device to your tenant before it enrolls. It establishes corporate ownership and tenant affinity, and it lets you assign a device preparation policy per device. You can use policy alone, association alone, or both.

The user-facing change is the device preparation page, which replaces the Enrollment Status Page with clearer progress. The admin-facing change is near real-time, per-app and per-script deployment reporting.

What moves and what stays

This is the most important part of Microsoft’s guidance, and it is easy to miss. Device preparation is the recommended path for corporate-owned Windows 11 devices, user-driven Entra join, and Windows 365. It is not the path, yet, for pre-provisioning (white glove), self-deploying mode, hybrid Entra join, or Autopilot into co-management. Those stay on classic Autopilot.

So the first design decision is a boundary, not a policy. Which device populations are eligible, and which are legitimate exceptions that keep their existing flow? The two models coexist in the same tenant, so this is a phased move by population rather than a cutover date.

Don’t recreate the old design

The temptation is to rebuild every existing profile one-for-one. Microsoft’s advice, and ours, is the opposite: start from the outcome each population needs (OOBE behaviour, apps, scripts, naming, support experience) and design the smallest set of device preparation policies and static groups that delivers it. Most organizations find that years of group tags have produced more variants than they actually need.

The order we would do it in

Define the first eligible population, typically corporate-owned Windows 11 devices with user-driven Entra join. Create assigned static security groups only where location, role, device type or required configuration differs. Inventory each deployment-profile and ESP pairing and map it into a device preparation policy. Decide whether device association is needed for that population; many user-targeted deployments don’t need it. Pilot the complete reset-to-desktop experience on representative devices and validate policy selection, group placement, apps, scripts, naming and reporting. Then expand in waves.

Existing devices can be pre-associated while they stay enrolled and in use, by collecting diagnostics logs, exporting the DeviceLink CSV and uploading it under Associated devices in Intune. Nothing changes for the user until the device next goes through OOBE, at which point it follows the device preparation path. If a device is both registered and associated, association wins, so plan the pilot around that rather than expecting a fallback.

The one thing not to do

Don’t remove Windows Autopilot registrations early. Deleting them can strip Autopilot properties and break the dynamic-group membership that the device’s current configuration depends on. Retire profiles, ESP settings, groups and registrations only after the deployments report confirms nothing still relies on them.

Where Lumeplex fits

This is the kind of transition where a few days of design saves months of cleanup. If you would like a second pair of eyes on your eligible populations, your ETG model, or a pilot plan, book a free strategy call and we will walk through it with you.

Source: Microsoft Tech Community, Intune Customer Success, Moving from Windows Autopilot to Windows Autopilot device preparation, 16 September 2026.