Windows Autopilot In A Nutshell: Quick Start Guide to Modern Windows Device Provisioning

Modern Windows provisioning has shifted from imaging and manual setup to an identity‑first, cloud‑orchestrated model—and Windows Autopilot sits at the center of that evolution. Whether you’re an Intune admin, an architect designing deployment strategy, or simply trying to understand how Autopilot actually works behind the scenes, this guide distills everything you need to know.

TL;DR

Windows Autopilot is a cloud‑based provisioning framework designed to streamline Windows device deployment through pre‑registration, cloud-side configuration, and automated enrollment. Instead of imaging, it relies on device identity—collected via hardware hash or OEM‑side registration—to pre‑assign configuration, policies, apps, and enrollment settings before the device ever reaches the user.

It’s foundation lies in correctly establishing device identity during the registration phase, which determines how the device will behave during Out‑of‑Box Experience (OOBE).

1. Registration Inputs and Device Identity Creation

1.1 Hardware Identity Collection

Autopilot registration begins with establishing device identity, typically via one of two pathways depending on who performs the registration:

A. IT Admin / Customer (High-Touch Registration)

IT Admins extract the Hardware Hash (Hardware ID) from a powered-on Windows device.

This is done using:

• PowerShell script: Get-WindowsAutopilotInfo.ps1
• Configuration Manager
• Diagnostics Page (Windows 11)
• Settings → Work/School (limited scenarios)

The hardware hash is a secure, unique, stable identifier that represents device hardware characteristics.

B. OEM / Reseller (Zero‑Touch Registration)

OEMs avoid unboxing devices and instead register them using secure metadata made available during manufacturing. They can register devices using:

• Tuple of identifiers:
  • Manufacturer
  • Model
  • Serial Number
• PKID (Product Key ID)
• CBR – Computer Build Report, generated during factory imaging
• Shipment-level barcode scanning

These methods rely on OEM ↔ Microsoft backend integration and bypass the need for a hardware hash, enabling mass, pre-shipment registration.

1.2 Identity Processing (DDS + DRS)

Once the device data is uploaded (whether by OEM via API or manually by IT admin via CSV through Intune portal):

1. The device identifier is forwarded to the Autopilot service a.k.a DDS (Device Directory Service).
2. DDS generates a ZTDID (Zero-Touch Deployment ID) — the immutable primary key identifying the device in the Autopilot service database.
3. DDS returns the ZTDID, which is consumed by the Azure DRS (Device Registration Service)
4. Azure DRS creates a disabled device object in Entra ID (previously Azure AD) to serve as the placeholder identity for Autopilot provisioning.

This empty disabled Entra ID device object serves the purpose of device auth in case of White Glove or Self-Deploy provisioning. This device object is also responsible to make the device part of the dynamic Autopilot device group that you, as an IT admin, have created based on ZTDID.

Creation the ZTDID by DDS service is a one-time process and non-recoverable. As such, if the device object gets deleted, the device will fall out from the Autopilot profile targeting and will require to be re-registered to Autopilot for DDS to create a new ZTDID which will be tattooed to a new device object in Entra ID by DRS.

2. Registration Methods

A. OEM / Vendor Automated Registration (Preferred)

OEMs rely on direct API integrations with Microsoft and can register devices using:

• Tuple (Manufacturer/Model/Serial) or Product Key ID (PKID) [Most common]
• CBR (Computer Build Report)
• Shipment Barcode Scans

This allow for large‑scale registration without requiring to unbox the device to obtain the hardware hash manually.

Advantages:

• Fully automated
• No need to unbox and power on devices
• Ideal for large enterprises and new device purchases
• Ensures devices arrive “Autopilot-ready” out of the box

B. Customer / IT Admin Manual Registration

To manually register a device to autopilot service, IT Admins must:

1. Extract device hardware hash locally using PowerShell (Get-WindowsAutopilotInfo).
2. Upload the .CSV file to Intune → Autopilot → Devices.

Typical use cases:

• Repair scenarios (motherboard replacement) where device requires re-registration
• Non-OEM or legacy devices
• Existing estate transformations
• Testing labs and POCs

3. DDS Validation and Autopilot Matching

At first boot, during OOBE, with network connectivity established, the device reaches out to Autopilot endpoint. If device registration is found based on the hardware hash sent along with the request, device downloads the Autopilot profile as is assigned to it from the tenant.

If no match is found, device proceeds with normal Windows OOBE.

4. Deployment Profile Assignment

Dynamic groups, as created by IT admins, often based on querying Autopilot attributes as found in devicePhysicalIds identifier like ZTDID/OrderID/GroupTag/PurchaseOrderID, automatically populates groups with newly registered devices matching the dynamic criteria as its member.

Intune then assigns:

• Autopilot deployment profile
• Hybrid Domain Join (ODJ) profile (if applicable)
• ESP (Enrollment Status Page)
• Applications
• Configuration profiles
• Compliance policies

It is the Autopilot deployment profile that controls:

• Join type (Azure AD Join vs Hybrid AD Join)
• Mode (User-Driven, Self-Deploying, Pre-Provisioning/White Glove)
• OOBE configuration (brand, privacy, account options)
• Allowing/disallowing local administrator rights

5. Autopilot Modes & Scenarios (What to Use & When?)

5.1 User-driven Entra ID Join

For individual user‑assigned corporate laptops.

Simplified flow below:

• Device hits Autopilot during provisioning
• Autopilot profile retrieved and applied, OOBE presents with branded sign-in screen
• User signs in
• Device joins Entra ID
• Enrolls in Intune.

5.2 User-driven Hybrid Join (Entra ID + On‑Prem AD)

For individual user‑assigned corporate laptops. Used in environments with strict requirement for on‑prem AD GPOs or legacy apps. Simplified flow below:

• Device hits Autopilot during provisioning
• Autopilot profile retrieved and applied, OOBE presents with branded sign-in screen
• User signs in

• Device temporarily enrolls to Intune to request for ODJ blob
• Intune connector delivers ODJ blob
• On‑prem AD computer object is created
• Object syncs back to Entra ID (via AAD Connect)
• Device gets auto enrolled to MDM service (can be scoped via GPO)
• User requires DC line-of-sight to sign-in to Windows
• Co‑management with SCCM (optional)

5.3 Self-deploying

• Best for kiosks, digital signage, shared devices

• Fully automated
• TPM 2.0 attestation required
• Physical devices only (no VM)
• Entra ID Join only
• Userless provisioning
• Ethernet recommended (Wi‑Fi requires minimal input)

5.4 White Glove / Pre‑Provisioning

White Glove is a two‑phase provisioning model:

• Phase 1 — Technician Flow (IT/OEM/Partner):

The IT technician prepares the device before shipping or before handing it to the user. Simplified workflow:

• Boot device → Enter White Glove mode
• TPM attestation verifies device
• Autopilot profile applied
• Apps & policies installed (device context)
• Device sealed for delivery

• Phase 2 — User Flow:

The end user receives a nearly ready device and completes only the final personalization steps (sign‑in, minor policy sync, etc.). Simplified workflow:

• User powers on device
• Signs in with Microsoft Entra ID
• Only user‑context items finalize
• Device ready in minutes

This approach reduces deployment time, ensures consistency, and avoids long waits during device setup.

Limitations:

• A device cannot auto‑reenroll via pre-provisioning after the first deployment. IT must delete its Intune record first before redeploying.
• Requires TPM attestation and stable network access.
• Not supported for Virtual Machines.

5.5 Autopilot for Existing Devices

Mostly used for converting legacy Windows 7/Windows 10 or non-modern existing capable devices to modern Autopilot state. Process includes:

• Autopilot JSON is exported through Graph API
• Injected into ConfigMgr Task Sequence
• Device is rebooted into OOBE with Autopilot configuration
• Device is effectively “converted” into an Autopilot-managed device

Note: Starting September 5, 2024, Intune has blocked Autopilot for existing devices functionality for all customers that have blocked enrollment of personal devices using enrollment restrictions. This aligns with the behavior of other automatic MDM enrollment methods where the device identity cannot be verified beforehand.

If you plan to deploy devices using Autopilot for existing devices functionality, upload their corporate identifier information (serial number, model, manufacturer) in Intune to ensure they are allowed to enroll as corporate devices. Devices registered for Autopilot don’t need corporate identifiers uploaded.

5.6 Windows Autopilot Device Preparation (a.k.a “Autopilot v2”)

A major modernization of Autopilot, with:

• No hardware hash requirement
• Entra ID Join only
• Near real‑time monitoring
• Enrollment‑time grouping
• Faster OOBE
• Installs required apps/scripts during OOBE
• Cannot override existing Autopilot‑registered devices

Use cases:

• Cloud‑first organizations
• Modern provisioning for Windows 11
• Large‑scale distributed workforce
• Where zero‑touch and speed matter

When not to use it:

• Hybrid AD Join
• Self‑deploying
• White Glove
• VMs
• Devices already registered in Autopilot v1

Limitations:

Corporate Identifiers Requirement -> If personal device enrollment is blocked, preload serial+manufacturer+model.

6. Summary Flow (End‑to‑End)

• Device identity acquired (Hardware Hash or OEM process)
• Identity uploaded to Intune / Autopilot
• DDS generates ZTDID
• Azure DRS creates a placeholder device object, an associated disabled Entra device object with [ZTDID] and other devicePhysicalIds identifiers like [OrderID], [Group Tag], and/or [PurchaseOrderId]

• Device becomes member of Autopilot dynamic group based on the Autopilot attributes [devicePhysicalIds
• Autopilot profile and other policies/configurations/apps gets assigned to it from Intune which are targeted to the Autopilot dynamic group (other groups the device is made a member of!)
• Device becomes ready for provisioning

• Device is handed over to user
• User powers on device
• Device boots, starts OOBE, user connects to internet
• Device reaches out to Autopilot endpoint to check for registration
• Autopilot match happens, profile gets retrieved
• OOBE customized per Autopilot profile
• Provisioning gets device in the required Joined state
• Intune enrollment completes, ESP ensures policies/apps apply
• Device becomes fully managed and ready for user

7. Device Lifecycle Management (Deletion & Repurposing)

As of Autopilot service release 2307, admins can:

• Delete Autopilot device records in one step, even if the Intune record still exists.

However, the recommended full decommission order still remains in the sequence Delete Intune device record -> Delete Autopilot device record -> Delete Entra ID device record

This prevents mismatches, ZTDID conflicts, and enrollment failures.

8. Final Thoughts: Why Autopilot Matters Today — and Even More Tomorrow

The most successful Autopilot deployments aren’t those that rely on a single mechanism, but those where organizations embrace:

• OEM‑based zero‑touch workflows for scale
• White Glove when logistics or performance matters
• User‑driven for everyday predictable provisioning
• Hybrid approaches only when truly necessary
• Device Preparation for cloud‑first, Windows 11‑aligned estates

With proper lifecycle governance—clearly defining registration, deletion order, and repurposing strategy—Autopilot becomes not just a provisioning tool, but an integral part of an organization’s identity and security platform.

As Windows 11 and cloud-native identity become the norm, Autopilot stands at the center of the modern endpoint ecosystem.

In short: Autopilot is no longer just about deploying devices. It’s about aligning identity, security, and the user experience from the moment the device leaves the warehouse to the day it’s retired.