Windows Autopilot Explained and How to Register Devices

Windows Autopilot is a cloud-based device provisioning system that eliminates the need to build and maintain model-specific OS images, typically delivering devices to users through a guided setup experience that applies the organization’s identity, management enrollment, and security configuration automatically. Getting that experience to work reliably requires more than registering a device. Correct licensing, properly assigned deployment profiles, application readiness, and unobstructed internet access all need to be in place before the first device ships.

This article covers what Windows Autopilot is, how Intune Autopilot works in practice, what an Autopilot hardware hash is and how it is used, how to manually register devices with Autopilot, and what deployment modes and licensing look like as of November 14, 2026. Readers should verify current Microsoft requirements before implementation, since documentation is updated regularly and requirements vary by deployment scenario.

What is Windows Autopilot in plain terms? It is a way to redirect the first-boot setup experience so that a device recognizes the organization, follows a configured deployment profile, and lands in a managed, policy-compliant state without requiring IT to touch every unit by hand. The OEM ships the device with standard Windows. Autopilot takes it from there, provided the registration, profiles, and management backend are ready.

Practical use cases include:

• New employee devices shipped directly to remote or hybrid workers.
• Device refresh and replacement programs where IT cannot feasibly handle physical setup at scale.
• Standardized configuration for user-assigned laptops and desktops.
• Shared or kiosk-style devices, where the selected deployment mode matches the intended scenario.
• Supported reset and redeployment situations for returning or repurposed devices.

Contrasting Autopilot with traditional imaging clarifies why organizations adopt it. Traditional imaging commonly requires IT to build, test, maintain, and deploy OS images for each hardware model in the fleet. When a new model arrives, the image often breaks. Autopilot sidesteps that by leaning on the OEM-installed Windows client and cloud-driven policy delivery rather than a master image. The tradeoff is that Autopilot introduces its own dependencies: registration data must be accurate, Intune must be configured correctly, and the network must permit the necessary cloud traffic.

One important distinction worth stating plainly: Windows Autopilot and Windows Autopilot device preparation are not the same thing. Microsoft maintains separate documentation and requirements for device preparation. This article covers Windows Autopilot specifically and does not use the two terms interchangeably.

“Intune Autopilot” is a phrase you will see frequently in IT forums and job postings. It is not a separate Microsoft product. It refers to the common combination of Windows Autopilot as the provisioning experience and Microsoft Intune as the MDM service that handles enrollment, configuration, apps, and ongoing endpoint management.

The division of responsibility matters. Windows Autopilot recognizes a registered device during setup and delivers the selected provisioning experience. Intune, working alongside it, manages mobile device management enrollment, application deployment, configuration policies, compliance settings, and day-to-day endpoint administration. Some organizations use a different MDM service, but Intune is the most common pairing, and it is what this article focuses on.

For teams that already handle managed Microsoft 365 services, adding Autopilot to the mix is usually an extension of existing Intune work rather than a fresh start. The tenant, licensing, and policy structures are often already in place.

The Windows Autopilot Provisioning Sequence

When Windows Autopilot runs, the sequence works like this:

1. 1
   The organization purchases or prepares a Windows device.
2. 2
   The device identity is registered with the Windows Autopilot service and associated with the organization’s tenant.
3. 3
   IT assigns an Autopilot deployment profile, typically through a device group in Intune.
4. 4
   A user or technician powers on the device and connects it to the internet during the Windows out-of-box experience.
5. 5
   Windows contacts the Autopilot service, identifies the organization, and follows the assigned setup experience.
6. 6
   The device enrolls in management and receives applicable policies, configurations, and apps according to the organization’s setup.

Profile assignment timing is not fixed. Microsoft describes progression from Unassigned to Assigning to Assigned, and the actual time depends on group membership evaluation, device hash status, Intune and Autopilot service processing, and connectivity. Promising users a specific wait window is a mistake. Monitor profile status in the Intune admin center and confirm assignment before beginning any setup experience.

Application installation and policy delivery timing vary by tenant configuration, app type, enrollment status page settings, and application dependencies. Not every app finishes before the user can begin working, and that is by design in many configurations.

What Intune Manages After Setup

Intune carries the operational load before, during, and after provisioning. The administrative tasks that commonly run through Intune include:

• Creating and assigning Autopilot deployment profiles.
• Building device groups and managing profile assignments.
• Configuring enrollment status page behavior.
• Assigning required and available applications.
• Applying endpoint security, device configuration, and compliance policies.
• Monitoring enrollment results, application deployment status, and setup failures.

Registering a device for Autopilot does not by itself create a complete device-management or security configuration. That point gets glossed over in a lot of Autopilot coverage. Registration links the hardware to the tenant. Intune configuration determines what actually happens to that device once it checks in. Before testing with production users, confirm that tenant permissions, enrollment settings, licensing, and the intended join configuration are all correct.

Manual registration covers three situations: existing devices being brought into Windows Autopilot for the first time, newly purchased devices the vendor did not register, and controlled pilots where IT wants to validate the process before scaling. Microsoft identifies Intune as the preferred manual registration mechanism for customers.

The practical process follows a consistent sequence: collect the device identity data, create or validate the CSV, import it through the Intune admin center, assign the device to the correct group and deployment profile, verify profile status, and then place the device into the appropriate setup or redeployment experience.

Guardrails that prevent common failures:

• Confirm the device is associated with the correct tenant, not a previous owner’s or a reseller’s staging tenant.
• Use appropriately authorized administrator accounts for all import and assignment steps.
• Check Windows version, licensing, network, and deployment-mode requirements before proceeding.
• Avoid duplicate or inaccurate device records; importing the same hardware hash twice can cause unpredictable behavior.
• Do not assume every registered device needs an immediate reset. Whether a reset or redeployment is needed depends on the device’s current state and the intended scenario.

What an Autopilot Hardware Hash Does

The hash helps Windows identify the organization during the out-of-box experience. Once registered and assigned a profile, the device contacts the Autopilot service, matches its hardware identity to the tenant record, and follows the configured experience. Without a correct registration, Windows has no way to know which organization the device belongs to, and it proceeds through the standard consumer setup instead.

The hardware hash is one registration method among several. OEMs and reseller partners may use other supported device-identification approaches when registering devices during manufacturing or fulfillment. For IT teams handling registration themselves, the hash is the standard input.

Comparing registration paths in practical terms:

• OEM or reseller registration is generally the least manual option for new purchases and avoids IT needing to physically access each device before deployment.
• CSV import is the right path when IT collects the device identity itself, whether for existing devices or unregistered purchases.
• PowerShell collection supports the CSV process for devices already in IT’s possession.

One thing I see buyers assume incorrectly: they order new hardware and expect it to show up in their Autopilot tenant automatically. That only happens when the reseller is explicitly set up to register on the organization’s behalf and has the correct tenant ID. Verify the arrangement before the hardware ships.

How to Use Get-WindowsAutopilotInfo for CSV Collection

`Get-WindowsAutopilotInfo` is a PowerShell-based tool used to collect device identity information and produce a CSV file suitable for Autopilot import. The standard output command is:

“`powershell Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv “`

The resulting file contains the device information needed for upload through the Intune admin center. Microsoft also documents online collection and upload workflows that push directly to Intune during the collection process, but those require an authorized sign-in and appropriate permissions before the script runs.

After generating the CSV, the next steps are: import it in the Intune admin center, confirm the device appears in the Autopilot device list, assign it to the correct group and deployment profile, monitor profile status until it reaches Assigned, and then begin the intended setup experience. Validate the CSV before import. A file with malformed data or a missing column can cause the import to fail silently or partially.

Use current Microsoft-published instructions for installation and execution. The script’s installation method and permission requirements have changed over time. Test the full sequence on a non-production device before running it at scale.

Autopilot supports several deployment modes, and requirements differ meaningfully by scenario. Picking the wrong mode for a device type is a common early mistake.

Self-deploying and pre-provisioning modes also require access to TPM attestation endpoints during setup, in addition to general internet access. If network filtering blocks those endpoints, provisioning fails. User-driven mode requires internet access but does not carry the TPM attestation dependency in the same way.

Hybrid join scenarios carry additional infrastructure requirements. Organizations planning hybrid deployments need on-premises connectivity for the domain join component. That is worth flagging early in any Autopilot planning conversation because it affects both network design and the choice of deployment mode.

For licensing, eligible paths as checked November 14, 2026 include Microsoft 365 Business Premium, Microsoft 365 E3 or E5, Enterprise Mobility + Security E3 or E5, Intune for Education, or Microsoft Entra ID P1 or P2 combined with Intune or another MDM service. The right path depends on the organization’s specific scenario, since the required combination of Windows client rights, Entra ID tier, and MDM access varies.

Microsoft Intune Plan 1 pricing (US, annual commitment)

Microsoft’s US pricing page, updated March 29, 2026, listed Intune Plan 1 at $8 per user per month on an annual commitment and noted that Plan 1 is included with Microsoft 365 E3, E5, F1, and F3; Enterprise Mobility + Security E3 and E5; and Business Premium. Actual costs vary by region, agreement, and plan. Windows Autopilot itself does not carry a separate standalone per-device price based on the evidence reviewed.

Organizations adopting Windows Autopilot can reasonably expect less hands-on device setup, more repeatable onboarding for remote and hybrid users, reduced dependence on custom OS images, and consistent application and security-policy delivery when Intune is configured correctly. Those are real operational benefits. They depend on the quality of the underlying configuration, not on Autopilot working like a one-click deployment system.

The implementation realities that trip up rollouts are specific and predictable. App deployment order and application dependencies can affect what a user sees during first login. Incorrect group membership or profile assignments deliver the wrong setup experience, sometimes silently. Poor hardware-hash data or duplicate records prevent correct registration and can be difficult to diagnose after the fact. Network filtering that blocks Autopilot or Intune endpoints interrupts provisioning at unpredictable points. Hybrid join scenarios require additional infrastructure and connectivity planning that affects timelines and team scope.

My recommendation for any organization starting with Autopilot: run a pilot first, and make it representative. That means testing on the actual device models in the fleet, not just one reference machine. It means covering the user roles and network environments that production devices will land in. It means validating that required first-day applications install correctly and that the enrollment status page behavior matches what users will actually experience.

Practical rollout steps that reduce first-deployment failures:

• Start with a small pilot that covers actual device models, user roles, and networks.
• Prefer OEM or reseller registration for future new-device purchases, but verify the arrangement before hardware ships.
• Limit required first-day applications to those genuinely needed during initial setup. Additional apps can follow through Intune policy after the device is enrolled.
• Standardize profiles by use case, such as assigned employee devices versus shared or kiosk devices.
• Document the exception process for devices that must be manually registered, so the process is repeatable rather than improvised.
• Monitor Intune enrollment and deployment results after each pilot wave, resolve failures before expanding scope, and confirm the user experience matches expectations before broad rollout.

Autopilot standardizes setup only when registration, profiles, apps, policies, and connectivity are ready to work together. Organizations that treat it as a shipping-and-forgetting tool discover the gaps the hard way, usually on a new employee’s first day.