# Autopilot device preparation vs classic Autopilot: which to choose in 2026?

> A field comparison of Windows Autopilot device preparation and Windows Autopilot: architecture, scenarios, limits, hybrid join, pre-provisioning and migration.

- URL: https://benjamintestart.fr/en/autopilot-device-preparation-vs-autopilot/
- Author: Benjamin Testart (Devices Practice Leader & Microsoft Intune consultant)
- Published: 2026-09-28
- Updated: 2026-09-28
- Category: Microsoft Intune
- Language: en
- Tags: Windows Autopilot, Autopilot device preparation, Microsoft Intune, Microsoft Entra ID, Windows 365
- Version française: https://benjamintestart.fr/fr/autopilot-device-preparation-vs-autopilot/

## TL;DR

Choose Windows Autopilot device preparation for Microsoft Entra joined Windows 11 PCs in user-driven mode, without hardware hash registration, or for Windows 365 Cloud PCs in automatic mode. Stick with classic Windows Autopilot whenever you need hybrid join, pre-provisioning, self-deploying, Autopilot Reset, Windows 10 or more than 25 apps during OOBE.

In 2026, Windows Autopilot device preparation is the right choice for Microsoft Entra joined Windows 11 PCs in user-driven mode (and for Windows 365 Cloud PCs), while classic Windows Autopilot remains essential as soon as you need hybrid join, pre-provisioning, self-deploying, Autopilot Reset or Windows 10. Both coexist without any trouble in the same tenant.

It's a question I get in almost every modern workplace project: "do we go with the new version of Autopilot or stay on the old one?". Here's how I look at it, up to date with the 2026 changes.

## Two products, two philosophies

**Windows Autopilot** (which I call "classic" here) is the established solution. It relies on registering devices up front (the hardware hash), a deployment profile and an enrollment status page (ESP). It's very rich in options, but also heavier to prepare and troubleshoot.

**Windows Autopilot device preparation** has been available since June 2024. Microsoft designed it around four goals: simple, fast, observable and reliable. It doesn't replace classic Autopilot: it's a second approach that covers fewer scenarios but covers them better.

## Device preparation architecture

### A single policy

Everything is configured in a **device preparation policy**: deployment mode, join type, user account type, OOBE settings, apps and scripts. No more stacking an Autopilot profile + ESP + dynamic group.

### Enrollment Time Grouping

This is the heart of the system. When the user authenticates, the device is added **directly** to a predefined device security group. Apps, scripts and policies assigned to that group are then delivered immediately, without waiting for a dynamic group to be evaluated.

A few rules to know:

- Only the apps and scripts **selected in the policy** are tracked during OOBE; other assignments to the group arrive after the deployment.
- Configuration policies assigned to the group are synced, but their application **isn't tracked**: they may apply during or after the deployment.

### The device group and the Intune Provisioning Client

The group must be a **security group with assigned membership** (not dynamic), and its **owner** must be the **Intune Provisioning Client** service principal, AppId `f1346770-5b25-470b-88bd-d5744ab7952c`. In some tenants it shows up as **Intune Autopilot ConfidentialClient**: only the AppId matters.

If it doesn't exist in your tenant, Microsoft documents how to create it:

```powershell
Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppID f1346770-5b25-470b-88bd-d5744ab7952c
```

A 409 "already in use" error simply means it already exists.

## The full comparison

| Criterion | Autopilot device preparation | Classic Autopilot |
|---|---|---|
| Modes | User-driven, automatic (Windows 365) | User-driven, pre-provisioning, self-deploying, existing devices |
| Join type | Microsoft Entra only | Microsoft Entra and hybrid |
| Registration (hardware hash) | Not required | Required |
| Objects to configure | Policy + assigned device group (owner Intune Provisioning Client) | Deployment profile + ESP |
| Configurations during OOBE | Device-based only | Device ESP and user ESP |
| Apps during OOBE | 25 max | 100 max (ESP blocking apps) |
| PowerShell scripts during OOBE | 10 max | No equivalent limit documented in the comparison |
| LOB and Win32 in the same deployment | Yes | No |
| Report | Near real-time, all deployments | Registered devices only, not real-time |
| Autopilot Reset | No | Yes |
| Windows versions | Windows 11 24H2+, or 22H2/23H2 with KB5035942 | Supported Windows 10 and 11 versions |
| GCC High / DoD | Yes | No |
| HoloLens, Teams Rooms, DFCI, co-management | No | Yes |

## Supported scenarios in 2026

### User-driven

This is the main scenario for physical PCs. The user turns on the PC, signs in with their Entra ID account, and a simplified page shows a **progress percentage**. The policy is assigned to a **user group** (or directly to the device with device association, see below).

A setting I particularly like: **User account type** set to **Standard User**. Device preparation then removes the user from the local Administrators group before they reach the desktop.

### Automatic for Windows 365

Automatic mode has been generally available since **May 2026** for Windows 365 Enterprise, Windows 365 Flex (dedicated and shared) and Windows 365 Cloud Apps; it's in preview for Windows 365 Reserve. The policy is included in the Cloud PC provisioning policy and delivers apps and scripts before the first sign-in.

### What still isn't supported

I checked the documentation at the time of writing: **self-deploying**, **pre-provisioning** (formerly White Glove), the **existing devices** scenario and **Autopilot Reset** remain exclusive to classic Autopilot. For a kiosk, a userless shared device or bench preparation by a partner, device preparation isn't the right answer today.

## Hardware hash, corporate identifiers and device association

With device preparation, **there's no need to import the hardware hash**. But if you block personal device enrollment with Intune enrollment restrictions, the device must be recognized as corporate-owned. Two options, pick one:

- **Corporate identifiers**: import the manufacturer, model and serial number.
- **Device association** (added at the end of August 2026): a tenant affinity marker is written to the UEFI, with TPM-backed validation. Associated devices are automatically marked as corporate-owned.

Device association also unlocks options that device preparation lacked until now: language, keyboard, hiding the license terms and privacy settings, and above all a **device name template** (`%SERIAL%` or `%RAND:x%`). These settings **only apply to associated devices**.

To associate a device:

1. Boot the PC into OOBE and stop at the region selection page.
2. Press the **Windows** key five times to open the Autopilot menu, then choose **Export device information** to generate a CSV on a USB drive (NTFS recommended).
3. In the Intune admin center, go to **Devices** > **Enrollment** > **Device association** > **Devices**, then **Add** and import the CSV (one device per file for now).
4. Optionally assign a device preparation policy directly to the device.
5. Association completes automatically when the device connects to the network in OOBE.

A device assignment **takes precedence** over a user assignment. Device association doesn't apply to Windows 365 Cloud PCs.

## Apps and scripts during OOBE

Device preparation accepts up to **25 apps** (the limit was raised from 10 to 25 in January 2026): LOB, Win32, Microsoft Store (only WinGet-compatible ones), Microsoft 365 Apps and Enterprise App Catalog. It also accepts **10 PowerShell scripts**.

My configuration rules:

1. Assign every selected app and script to the policy's **device group**.
2. Configure them in **System context** (for scripts: **Run this script using the logged on credentials** set to **No**), since no user is signed in.
3. Tune **Minutes allowed before showing installation error** (between 15 and 720): the value covers the whole deployment, not a single app.
4. Only put the essentials in the policy (security, VPN, EDR agent, Microsoft 365 Apps); the rest will arrive afterwards.

With classic Autopilot, the ESP can block desktop access until up to 100 apps are installed and until user configurations are applied. If that lock is a requirement from your CISO, it's an argument for staying on classic.

## Monitoring and troubleshooting

This is device preparation's big strength. The **Windows Autopilot device preparation deployment status** report (available notably from **Devices** > **Enrollment**, **Monitor** tab) shows in near real-time, for each device: profile and version, deployment phase and status, the state of each app and each script, and deployment duration. When a deployment fails, diagnostic logs are collected automatically and can be downloaded from the report.

Another useful detail: the **enrollmentProfileName** property is populated with the policy name, which lets you build assignment filters or dynamic groups for post-deployment configuration.

## Prerequisites to check

- **Windows 11** 24H2 or later, or 22H2/23H2 with KB5035942 (April 2024 media or later).
- Pro, Pro Education, Pro for Workstations, Enterprise, Education or Enterprise LTSC editions.
- MDM automatic enrollment configured and users allowed to join devices to Microsoft Entra.
- Licensing: Microsoft 365 Business Premium, E3/E5, F1/F3, A1/A3/A5, EMS E3/E5, or Entra ID P1/P2 + Intune.
- For a delegated administrator: the **Enrollment time device membership assignment** permission under **Enrollment programs**.

## When to choose which?

Choose **device preparation** if:

- your fleet runs Windows 11 and is 100% Microsoft Entra joined;
- you no longer want to manage hash imports with your resellers;
- you deploy Windows 365 Cloud PCs and want apps and scripts delivered before the first sign-in;
- you want a simple deployment and fast troubleshooting.

Stay on **classic Autopilot** if:

- you still have hybrid join or Configuration Manager co-management;
- you do bench pre-provisioning or self-deploying (kiosks, shared devices);
- you use Autopilot Reset, DFCI, HoloLens or Teams Rooms;
- you must block the desktop until user configurations are applied.

## Migration tips

1. **Don't migrate everything at once.** Both solutions coexist: start with a pilot on a simple Entra joined population.
2. **Watch out for already registered devices.** If a device is registered in Autopilot and **not associated**, the classic Autopilot profile runs. Deregister the device or associate it.
3. **Create a dedicated device group per policy**, without reusing groups from the old model.
4. **Review enrollment restrictions**: without corporate identifiers or association, a device is considered personal.
5. **Move your apps to System context** and trim the list to the essentials.
6. **Review your dynamic groups and filters**: for devices provisioned with device preparation, rely on the enrollmentProfileName property.

Device preparation isn't yet a full replacement for classic Autopilot, but for a cloud-native Windows 11 fleet, it's the option I now recommend by default.

## Key takeaways

- Device preparation relies on a single policy and an assigned device security group owned by the Intune Provisioning Client service principal (AppId f1346770-5b25-470b-88bd-d5744ab7952c).
- No hardware hash registration is required; corporate identifiers or device association are used if you block personal devices.
- Device preparation doesn't support hybrid join, pre-provisioning, self-deploying, Autopilot Reset or Windows 10.
- During OOBE: up to 25 apps and 10 PowerShell scripts with device preparation, versus 100 blocking apps with the classic model's ESP.
- Both solutions coexist in the same tenant, but a registered device that isn't associated always runs the classic Autopilot profile.

## Frequently asked questions

### Does Autopilot device preparation require importing the hardware hash?

No. Device registration isn't required. However, if you block personal device enrollment, you need to import corporate identifiers (manufacturer, model, serial number) or associate the devices with your tenant.

### Does Autopilot device preparation support Microsoft Entra hybrid join?

No. Only Microsoft Entra join is supported. For a hybrid joined device, you need to stay on classic Windows Autopilot with the Intune Connector for Active Directory.

### Is self-deploying mode available with Autopilot device preparation?

No, not at this time. Microsoft's comparison table states that self-deploying, pre-provisioning and existing devices scenarios remain exclusive to classic Windows Autopilot. Device preparation's automatic mode is intended for Windows 365 Cloud PCs.

### How many apps can be installed during OOBE with device preparation?

Up to 25 apps (LOB, WinGet-compatible Microsoft Store, Win32, Microsoft 365, Enterprise App Catalog) and 10 PowerShell scripts. Other apps assigned to the device group install after the deployment completes.

## Sources and documentation

- [Compare Windows Autopilot device preparation and Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/device-preparation/compare)
- [Overview of Windows Autopilot device preparation](https://learn.microsoft.com/en-us/autopilot/device-preparation/overview)
- [Windows Autopilot device preparation requirements](https://learn.microsoft.com/en-us/autopilot/device-preparation/requirements)
- [What's new in Windows Autopilot device preparation](https://learn.microsoft.com/en-us/autopilot/device-preparation/whats-new)
- [Overview of Windows Autopilot device association](https://learn.microsoft.com/en-us/autopilot/device-preparation/device-association/overview)