Windows Autopilot Deployment Flow & Recommended Enterprise Baseline

Traditionally, deploying a new Windows laptop in an enterprise meant imaging it with a custom OS build, installing agents, configuring settings manually, and shipping it to the user — a process that could take hours per device and required physical access to hardware.

Windows Autopilot replaces all of that. A device can come straight from a vendor, be powered on by the user at their home or office, and be fully enrolled, configured, and corporate-ready within 30–45 minutes — with zero IT hands-on time.

This guide covers every Autopilot deployment mode, the complete provisioning flow, and the enterprise baseline you should layer on top of it so every device lands in a consistent, secure state from day one.

What is Windows Autopilot?

Windows Autopilot is a cloud-native device provisioning service built into Windows 10/11 and managed through Microsoft Intune. It works by pre-registering a device's hardware fingerprint (the hardware hash) in your tenant. When that device boots for the first time, Windows detects it is an Autopilot-registered device and automatically:

• Skips the standard consumer OOBE (Out-of-Box Experience)
• Shows your organisation's branded sign-in page
• Walks the user (or the device itself) through corporate enrollment
• Pulls all policies, apps, and configurations from Intune automatically

The device never needs to be touched by IT. The user gets a fully configured, compliant machine. IT gets visibility and control from day one.

The Hardware Hash — The Foundation of Autopilot

Before any Autopilot deployment can happen, the device must be registered in your Intune tenant. Registration is done using a hardware hash — a unique fingerprint of the device's hardware (motherboard, NIC, CPU serial, etc.) combined with the Windows product key.

How to get the hardware hash into Intune

Manual hash capture PowerShell:

# Run on the target device (local admin required)
Install-Script -Name Get-WindowsAutoPilotInfo -Force
Get-WindowsAutoPilotInfo -OutputFile C:\AutopilotHWID.csv

Upload the resulting .csv in Intune → Devices → Enrolment → Windows → Windows Autopilot → Devices → Import.

Autopilot Deployment Modes

Windows Autopilot has five deployment modes. Choosing the right one depends on whether devices are shared or personal, whether you need on-premises AD connectivity, and whether IT wants to pre-stage devices before handing them to users.

Mode 1 — User-Driven, Azure AD Join (Cloud-Only)

The most common mode for modern cloud-first organisations. The device joins Entra ID only — no on-premises Active Directory required.

Who it is for: Organisations that are fully cloud — Microsoft 365, no on-prem file servers or legacy apps that require domain join.

What the user experiences:

• Powers on the device
• Sees the company-branded sign-in page
• Signs in with their corporate email and password + MFA
• Device joins Entra ID, enrolls in Intune, receives all policies and apps
• User reaches the desktop fully configured

Mode 2 — User-Driven, Hybrid Azure AD Join

The device joins both on-premises Active Directory AND Entra ID. This is needed when users require domain-joined access — for example, accessing on-premises file shares, using Group Policy, or running apps that authenticate against the on-prem domain.

Who it is for: Organisations in a hybrid model — still have on-prem AD, not fully migrated to cloud.

Additional requirement: The Intune Connector for Active Directory must be installed on a Windows Server in your on-prem environment. This connector performs the domain join on behalf of the device during Autopilot provisioning.

Mode 3 — Self-Deploying Mode

No user interaction at all. The device provisions itself completely — no username, no password prompt. Used for kiosks, digital signage, shared workstations, and meeting room devices.

How it authenticates: The device uses its own TPM 2.0 chip to authenticate to Entra ID using a device certificate. This is why TPM 2.0 is a hard requirement for this mode.

What IT configures: A device configuration profile is applied automatically (kiosk mode, assigned access, single-app lock, etc.) with no user needed.

Mode 4 — Pre-Provisioning (White Glove)

Pre-provisioning splits the Autopilot process into two phases:

• Phase 1 (IT/technician phase): IT scans a QR code on the device, the device downloads and installs all device-targeted policies and apps. This can take 20–45 minutes. When complete, IT reseals the device (ships it to the user or places it on their desk).
• Phase 2 (user phase): The user powers it on, signs in with their credentials. Only user-targeted policies and apps install at this point — which is much faster (5–10 minutes).

Why use it: Reduces user-facing provisioning time. Users do not sit waiting for apps to install — IT handles the heavy work in advance.

Mode 5 — Autopilot for Existing Devices

Allows you to re-deploy existing Windows devices that are currently managed by Configuration Manager (SCCM/MECM) using Autopilot — without reimaging them. The process wipes and reloads Windows, then goes through the standard Autopilot User-Driven flow.

Who it is for: Organisations migrating from SCCM-based imaging to a cloud-native Autopilot model.

The Full Autopilot Deployment Flow — Step by Step

This is the complete end-to-end flow for the most common scenario: User-Driven, Entra ID Join.

The Enrollment Status Page (ESP)

The ESP is the progress screen users see during provisioning. It is critical to configure it correctly — too strict and users sit waiting; too loose and they reach the desktop before security tools are installed.

ESP Phases

Recommended ESP settings

Recommended Enterprise Baseline

Once Autopilot handles the provisioning, what you configure in Intune determines how secure and consistent every device is. A well-designed enterprise baseline means every device — regardless of when it was provisioned — lands in the same known-good state.

Here is the baseline stack, layer by layer.

Layer 1 — Microsoft Security Baseline

Microsoft publishes a Security Baseline for Windows — a curated set of 300+ settings covering password policy, audit logging, Windows Defender, UAC, SMB signing, and more. These are based on the Center for Internet Security (CIS) benchmarks and Microsoft's own threat intelligence.

In Intune → Endpoint Security → Security Baselines, you can deploy the Microsoft 365 Security Baseline for Windows with a few clicks.

Layer 2 — Compliance Policy

A compliance policy defines the minimum health requirements a device must meet to be considered "trusted." Devices that fail become non-compliant, which Conditional Access uses to block access to company resources.

Recommended compliance settings:

Layer 3 — Configuration Profiles

These profiles push the actual settings to devices. Deploy all of these at device level (not user level) so they apply before the first user logs in.

BitLocker

Windows Hello for Business

Windows LAPS

Windows Firewall

Microsoft Defender Antivirus

Layer 4 — Conditional Access

Conditional Access is the enforcement engine. It ties identity (Entra ID) and device health (Intune) together to control who accesses what.

Baseline Conditional Access policies every org should have:

Layer 5 — App Deployment Strategy

Tip: Use Entra ID Dynamic Device Groups to automatically assign Autopilot profiles and app policies. For example:

(device.enrollmentProfileName -eq "Autopilot-Corporate-Standard")

This means any device enrolled with that profile is automatically in the group and receives the correct apps and policies — no manual assignment needed.

Layer 6 — Windows Update Rings

Windows Update for Business (WUfB) lets you control when devices receive Windows feature updates and quality updates. Staged rings prevent a bad patch from hitting all 5,000 devices at once.

Recommended ring structure:

Naming Convention — Device Name Template

Autopilot lets you define a device name template so every enrolled device gets a predictable, consistent name.

Rules: Max 15 characters, no spaces, letters/numbers/hyphens only. %RAND:n% generates n random alphanumeric characters. %SERIAL% uses the device serial number (may exceed 15 chars — test first).

License Requirements

Common Autopilot Issues and Fixes

Summary — Autopilot + Enterprise Baseline at a Glance

Windows Autopilot combined with a well-designed Intune baseline is the difference between "we manage devices reactively" and "every device in our fleet is in a known, secure, consistent state from the moment it is powered on."

The baseline I have described above — Microsoft Security Baseline + Compliance Policy + BitLocker + WHfB + LAPS + Conditional Access + staged update rings — is what I deploy for enterprise clients. It is not the most restrictive possible configuration, but it is the right balance of security and usability for most organisations.

If you are planning an Autopilot rollout or want help designing your Intune baseline configuration for your specific environment, drop a comment below — I am happy to walk through it with you.