What Windows Autopilot Actually Does
Windows Autopilot is a zero-touch deployment capability built into Microsoft Intune. When a new Windows device is powered on for the first time, Autopilot intercepts the out-of-box experience (OOBE), authenticates the device to Azure Active Directory (now Microsoft Entra ID), applies an Autopilot deployment profile, and hands off enrollment to Intune — which then delivers configuration policies, certificates, and applications. IT never touches the hardware.
The practical outcome: a device ships directly from a hardware vendor to an end user, the user powers it on, signs in with their corporate credentials, and the device configures itself to corporate standards. No imaging. No help desk involvement. No shipping devices back to IT. For organizations managing hundreds or thousands of endpoints, the operational savings are significant.
CyberOne implements Autopilot as part of our Microsoft Intune Implementation service. The Intune enrollment architecture and Autopilot deployment profile configuration are the two decisions that determine whether a deployment goes smoothly or creates problems that take months to untangle.
Autopilot Deployment Modes
Autopilot has four deployment modes. The right one depends on whether devices are cloud-only or hybrid-joined, and whether user interaction during setup is acceptable.
User-driven mode (cloud-only) is the most common configuration for cloud-native organizations. The user authenticates during OOBE, the device joins Microsoft Entra ID directly (no Active Directory domain join), and Intune delivers policy. No line-of-sight to a domain controller required.
User-driven mode (hybrid Azure AD join) adds an on-premises Active Directory domain join. A domain controller must be reachable — either on the corporate network or via VPN — during the OOBE process. This mode is appropriate for organizations that still have on-premises resources requiring Kerberos authentication, but it adds complexity and a common failure point.
Self-deploying mode is used for shared devices, kiosks, and meeting room systems that don’t have an assigned user. No user credentials are required during OOBE. The device joins Entra ID as a device identity rather than a user identity and receives a device-targeted Intune policy set.
Pre-provisioning (formerly White Glove) allows IT or resellers to do partial configuration before device delivery. IT powers on the device, completes the technician flow, and ships to the end user, who then completes sign-in. This mode is appropriate for environments with complex app deployment requirements where the full ESP process is too long for an end-user setup experience.
Autopilot Deployment Profiles: What to Configure
The Autopilot deployment profile determines what the user sees during OOBE and what behavior is enforced:
- Deployment mode: User-driven vs. self-deploying
- Join to Azure AD as: Azure AD joined vs. Hybrid Azure AD joined
- EULA: Skip or show (recommended: skip — users don’t read it and it adds friction)
- Privacy settings: Skip or show
- Account change options: Block or allow (block prevents users from bypassing corporate credential setup)
- User account type: Standard or administrator (security baseline: standard; admin rights delivered via LAPS for local admin scenarios)
Profile settings are applied at enrollment. Getting the “User account type” setting wrong is the single most common Autopilot deployment mistake — devices that provision users as local administrators create endpoint security debt that requires remediation across every affected device.
The Enrollment Status Page
The Enrollment Status Page (ESP) shows users a progress screen during device setup while policies, certificates, and applications install. It prevents users from using the device before corporate configuration is complete. Without the ESP, users can reach the desktop before Intune policy has applied — an unacceptable state from a security standpoint for most organizations.
The ESP has two phases: the device setup phase (which runs even without a logged-in user, relevant for pre-provisioning) and the account setup phase (which runs after the user signs in). Each phase can be configured with a timeout and a “Block device use until all apps and profiles are installed” enforcement setting. CyberOne configures ESP timeouts based on the application set being deployed — getting the timeout wrong either blocks users waiting for optional apps or allows users past setup before required apps finish.
Device Registration: How Autopilot Knows a Device Belongs to You
Before Autopilot can configure a device, the device hardware hash must be registered in your Autopilot device inventory. Registration happens in four ways:
- OEM/reseller registration: Dell, HP, Lenovo, and Surface register device hardware hashes directly to your tenant at time of manufacture or order. This is the cleanest approach — devices arrive pre-registered.
- Autopilot for existing devices: Run the Get-WindowsAutopilotInfo PowerShell script on an existing enrolled device to generate the hardware hash CSV, then import it via Intune or Windows Autopilot portal.
- Co-management with SCCM: Devices enrolled in SCCM can be automatically registered to Autopilot via co-management enrollment policy.
- Microsoft Store for Business: Increasingly deprecated — OEM registration is the preferred path.
Autopilot in a Co-Management Environment
Organizations that haven’t completed the transition from SCCM (Microsoft Endpoint Configuration Manager) to Intune can use Autopilot alongside co-management. New devices enroll in Intune via Autopilot; existing devices managed by SCCM can be incrementally migrated. Co-management workloads determine whether SCCM or Intune has authority for specific management functions — compliance policy, configuration profiles, Windows Update policy. CyberOne designs the workload split as part of Intune implementation engagements that include Autopilot.
For organizations ready to eliminate SCCM entirely, the migration path requires inventorying every workload currently managed by SCCM, replicating those workloads in Intune, validating equivalent management capability, and then cutting over. CyberOne has executed that migration for organizations ranging from 200 to 5,000 managed endpoints.
Autopilot Reset
Autopilot reset redeploys Windows on an enrolled device — wiping user data and returning it to corporate-configured state — without reimaging. It’s used for device reassignment and for remediation of devices that have drifted from baseline. Remote Autopilot reset can be triggered from the Intune console for any enrolled, network-connected device. Local Autopilot reset allows IT or users to initiate the reset from the Windows login screen.