Windows Autopilot Overview: Deployment Modes, Requirements and Entra Join

Windows Autopilot Overview: Deployment Modes, Requirements and Entra Join

Originally published 3 January 2021 · Reviewed 5 November 2026

Windows Autopilot lets you hand a new Windows laptop to a user straight from the box, with no custom image and no technician touching it. The device signs in, joins your Microsoft Entra tenant, enrols in Microsoft Intune and installs what you assigned. This article explains the flow, the deployment modes, the choice between Entra join and hybrid join, and what to check before you start. It is an overview; deployment details change with each Windows and Intune release, so follow Microsoft's current documentation when you build.

What problem it solves

Traditional device preparation means building a standard image, applying it to each machine, joining the domain and installing software before the user receives it. That costs technician time, ties you to specific hardware models and slows delivery to remote staff. Autopilot moves the work to the cloud: the manufacturer's Windows installation is used as shipped, and your configuration is applied at first sign-in.

How it works in outline

1. Register the device. The supplier or you register the device's hardware identifier with the Autopilot service in your tenant. For devices you already own, you can collect and upload a hardware hash.
2. Assign a profile. A deployment profile defines how the first-run experience behaves: the join type, whether the user is a standard user or administrator, and which setup screens appear.
3. User turns on the device. On the first connection to the internet, Windows contacts the Autopilot service, recognises the device and applies the profile.
4. The user signs in with their work account, using multifactor authentication where your policy requires it.
5. Join and enrol. The device joins Microsoft Entra ID, and, through automatic enrolment, enrols in Intune.
6. Intune applies policy. Configuration profiles, compliance policies, applications and updates arrive, often tracked by an Enrollment Status Page that holds the user at setup until essentials are installed.

Deployment modes

• User-driven mode. The usual choice. The user signs in and the device is personalised for them.
• Self-deploying mode. For shared devices, kiosks and digital signs that have no assigned user. The device authenticates itself, which relies on hardware features such as a TPM, so check the device requirements.
• Pre-provisioning. A technician or supplier performs part of the setup, for example installing larger applications, before the device goes to the user, who then finishes quickly.
• Existing devices. Autopilot can also be used to reset and redeploy existing devices.

Microsoft has been introducing a newer Autopilot device preparation approach alongside the original one, so check which fits your scenario in the current documentation.

Entra join or hybrid join

Microsoft recommends cloud-native Microsoft Entra join for new Autopilot deployments, which avoids needing a domain controller during setup. Some scenarios support Microsoft Entra hybrid join for organisations that still need the device joined to on-premises Active Directory; that adds requirements such as the Intune connector for Active Directory and line of sight to a domain controller during setup. Decide which you need after listing your on-premises dependencies; our device join comparison and hybrid join prerequisites cover them.

What to check before you start

• Licences. Intune for management, and Microsoft Entra ID P1 or equivalent for automatic enrolment; Microsoft 365 Business Premium and E3 include these.
• Windows edition and version. Use supported Windows 10 or 11 editions as listed in Microsoft's requirements.
• Network access. Devices need internet access to Autopilot, Entra ID and Intune endpoints during setup.
• Identity. Automatic MDM enrolment must be enabled for the users, and your sign-in policies must allow enrolment, including any MFA rules.
• Policy design. Decide the baseline configuration, applications and updates before you give devices to users.
• Registration process. Agree with your supplier how hardware identifiers are provided.

Common problems

• Policies that block enrolment, such as Conditional Access requiring a compliant device for the very sign-in that enrols it.
• Slow Enrollment Status Page because too many apps are marked as required.
• Missing registration, which sends the device to the default experience.
• Mixed ownership, where personal devices end up in the same profile as corporate ones.

A sensible pilot

Start with ten devices and a small group of willing users. Build one deployment profile, one compliance policy and a short list of required applications. Unbox a device on a home network, not the office network, because that is how most devices will first connect. Time the process and write down every surprise: a prompt you did not expect, an application that failed to install, a policy that conflicted. Fix those, then widen the group. Keep a reset-and-retry routine for devices that fail, and decide who owns the hardware registration list, since that list is the part that is easy to forget once the pilot ends.

Microsoft references

• Windows Autopilot overview, reviewed 5 November 2026.
• Windows Autopilot requirements, reviewed 5 November 2026.

This article was first published on 3 January 2021. It was rewritten on 5 November 2026 with current product names. Microsoft's live documentation takes precedence if it has changed.