Autopilot hardware hash: when you need one, and when you do not

An Autopilot hardware hash is a long base64 string that identifies one physical machine to the Windows Autopilot deployment service, and collecting one by hand is the slowest and most fragile way to register a device. Microsoft’s own documentation now recommends it only for testing and other limited scenarios. The obvious approach, booting every new machine and running a script at the out of box experience, does not scale, and it breaks the first time a motherboard is replaced. What follows is what the hash contains, the four supported ways to collect it, the errors a bad import throws, and the cases where you need no hash at all.

Hash problems rarely present as hash problems. They arrive as a laptop sitting at a generic sign-in screen with none of your branding, an import that fails with a bare number instead of a message, or a repaired machine that refuses to take its profile back. The symptom-first route through all three is Intune troubleshooting by symptom. Every Microsoft fact below was verified against Microsoft Learn on 13 October 2026, with the article dates given where they matter.

What the Autopilot hardware hash actually contains

Registration is two separate things, and conflating them causes most of the confusion. The Windows Autopilot registration overview, last updated 5 February 2026, states that successful registration requires both that the device’s unique hardware identity is captured and uploaded to the service, and that the device is associated to a tenant ID. A hash sitting in a CSV on your desktop has done neither.

The hash itself is not a serial number with extra characters. Per the registration overview, it contains the manufacturer, the model, the device serial number, the hard drive serial number, details about when the ID was generated, and, in Microsoft’s phrasing, many other attributes that can be used to uniquely identify the device.

Two consequences follow, and both surprise people.

First, the hash changes every time you generate it, because it includes the time of generation. Two captures from the same machine will not be identical. That is documented behaviour rather than a corrupt export, and it is why comparing hash strings to work out whether a device is already registered is a waste of an afternoon.

Second, matching is tolerant but not unlimited. The same article says the service considers changes such as a new hard drive and still matches successfully, but that large changes such as a motherboard replacement would not match, so a new hash has to be generated and uploaded. That one sentence is the whole of your hardware repair policy, and almost nobody reads it before the first laptop comes back from the depot.

1# The import CSV, exactly as the service expects it. Headers are case sensitive,
2# extra columns are rejected, quotation marks are rejected, and the file must be
3# ANSI rather than Unicode. Device Serial Number and Hardware Hash are the only
4# two columns an administrator has to supply.
5Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User

Four supported ways to collect it

The manual registration article, last updated 11 April 2025, lists four methods. They are not equivalent, and the first one is the only one that does not involve touching machines.

1. Configuration Manager. It collects hardware hashes for existing Windows devices automatically. If you already run it, start here and stop reading the rest of this list.
2. Windows PowerShell. The Get-WindowsAutopilotInfo.ps1 script from the PowerShell Gallery. Check the vintage of any guide you follow: the script was updated in July 2023 to use the Microsoft Graph PowerShell modules instead of the deprecated AzureAD Graph modules. A walkthrough that still tells you to install the AzureAD module is describing a dead dependency.
3. The Diagnostics Page during the out of box experience. Windows 11 only. The keystroke is CTRL and SHIFT and D.
4. Desktop export, from Settings, then Access work or school. This is the one for a device already in a user’s hands.

To get a command prompt during the out of box experience at all, the keystroke is Shift and F10 at the sign-in prompt after OOBE starts. The documentation is blunt that capturing a hash this way requires booting the device into Windows, which is exactly why it describes the approach as primarily for testing and evaluation scenarios.

1# Collect one hash to a file. Run elevated, in the full OS or in audit mode.
2# The -OutputFile parameter is not decoration: piping the output to a file by
3# hand produces formatting the importer rejects.
4New-Item -Type Directory -Path "C:\HWID"
5Set-Location -Path "C:\HWID"
6Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
7Install-Script -Name Get-WindowsAutopilotInfo
8Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv

Swapping the last line for Get-WindowsAutopilotInfo with the -Online switch uploads straight to the tenant and skips the CSV entirely. Whenever the device has network and you have credentials to hand, that is the better path, because every formatting rule in the next paragraph stops applying.

Those rules are stricter than they look. Up to 500 devices per file. Headers case sensitive. No extra columns. No quotation marks. ANSI, not Unicode. Microsoft tells you to edit the file in Notepad and not in Excel, and the reason is contained in the two rules before it: Excel adds quoting and will not reliably hand you an ANSI file.

When you do not need an Autopilot hardware hash at all

This is the part the tutorials ranking for this term do not cover, and it is the most useful thing on the page. Every minute spent on an Autopilot hardware hash is a minute spent on a registration route Microsoft is quietly steering away from.

Windows Autopilot device preparation, the newer provisioning path, does not mention hardware hashes anywhere in its overview, last updated 27 August 2026. It identifies devices differently. Corporate identifiers let you pre-upload the serial number, manufacturer and model, and the documentation states that device preparation only requires corporate identifiers for Windows if Intune enrollment restrictions are being used to block personal device enrolments. If you are not blocking personal enrolments, you upload nothing at all.

There is a precedence rule worth knowing before you run both. Per the same overview, if a device is already registered as an Autopilot device, which deployment runs depends on its association state. If the device is not associated with the tenant, the Windows Autopilot profile takes precedence. If it is associated, device association takes precedence and the device preparation deployment runs. To use device preparation on a registered device without associating it, you deregister it first. The wider choice between the two is in Autopilot device preparation in 2026.

The other way to need no hash is to stop collecting them yourself. OEM, reseller, distributor and partner registration all put the hardware identity into the service at the point of purchase. Every hash captured by hand is work somebody upstream could have done for nothing, and the case for writing that into a procurement contract is stronger than anything you will achieve with a better script.

If you do adopt corporate identifiers, note that they only become mandatory because of what Intune enrollment restrictions actually block, which is the setting that decides whether an unknown device may enrol in the first place.

The failure modes

Import errors and enrolment errors are different populations with different fixes, and treating them as one list is why these take so long to clear.

806 and 808, at import

The support article Troubleshoot error 806 or 808 when importing Windows Autopilot CSV files, last updated 30 March 2026, covers both. 806 is ZtdDeviceAlreadyAssigned, and the admin centre shows Device is already registered to the same Tenant. 808 is ZtdDeviceAssignedToOtherTenant, and the admin centre shows, unhelpfully, Internal error.

The cause is the same for both: a record for that device already exists. The fix is to delete it under Devices, then Windows, then Enrollment, then Devices under Windows Autopilot, and import again. The case that costs a week is the one where the record is not visible there at all, which means it is sitting in a tenant you do not control. That is a support case, and Microsoft asks for proof of ownership as an original invoice in PDF form, explicitly not a screenshot, showing the serial number or chassis ID and your organisation’s name, together with diagnostics collected from the device.

1# What Microsoft Support asks for when an 806 or 808 record cannot be seen in
2# the admin center. Run it on the device and attach the cab file to the case.
3Mdmdiagnosticstool.exe -area Autopilot -cab c:\out.cab

The Ztd events, at enrolment

These come from the Windows Autopilot troubleshooting FAQ, last updated 16 April 2026, and they are logged on the device rather than shown in the portal. 807, ZtdDeviceIsNotRegistered, means the hash never landed or no profile is assigned. 809 and 815 are both ZtdDeviceHasNoAssignedProfile: 809 is a profile that was deleted without being cleaned up first, and 815 is no profile assigned and no default profile in the tenant. 908, SerialNumberMismatch ProductKeyIdMismatch, means the physical hardware no longer agrees with what Autopilot has recorded, and the documented answer is to reregister the device.

The distinction matters because 806 and 808 are fixed in the portal before the device ever boots, while the Ztd codes are fixed by profile assignment and usually surface at the enrollment status page.

The repaired machine

Motherboard replacement is the failure mode with the longest tail, because it involves people who have no access to your admin console. The Windows Autopilot motherboard replacement article, last updated 13 August 2025, gives a six step order: deregister, replace the board, capture a new hardware ID, reregister, reset, return.

Three details in it are easy to get wrong. The device has to be deleted from Intune before it can be deregistered from Autopilot, not afterwards. For Microsoft Entra joined devices you should not then delete the object from Microsoft Entra ID by hand, because the deployment process depends on it; for Microsoft Entra hybrid joined devices you delete the computer object from on-premises Active Directory Domain Services instead, so that it is not resynced. And whether the Entra object disappears on its own depends on history: for a device never enrolled in MDM, removing the Autopilot registration can remove it too, while for a device that is or was enrolled it will not.

The operational sting is in the capture step. A repair technician has to sign in to the repaired device to collect the new hardware ID. If they do not hold credentials for it, the documented answer is that they have to reimage the device to gain access. Whoever negotiates the warranty contract should know that before they sign it, because it is the difference between a two day turnaround and a rebuild.

A reset is not a substitute for any of this. Autopilot reset reuses the registration that already exists. It does not create one, and it will not repair one that no longer matches the hardware.

What I would do differently

I have not run this at fleet scale. My tenant is a lab with no enrolled devices, so what follows is reasoning from the documentation and from the shape of the errors, not from a rollout.

• Treat manual collection as a bridge rather than a process. Microsoft’s own wording is testing or other limited scenarios, and anything built on top of it will need rebuilding inside two years.
• Move registration to procurement. Getting the reseller to register at the point of sale removes the capture step, the CSV formatting rules and the 500 row limit in a single decision, and it is a contract clause rather than an engineering project.
• Set the Group Tag at import, never afterwards. It is an optional column in the same file, and it is the cheapest place to make profile assignment dynamic later.
• For a greenfield Microsoft Entra joined estate, cost out device preparation before building a hash pipeline you will have to retire.
• Write the repair path down before you need it. The order of deregistration, the on-premises cleanup for hybrid joined devices and the technician’s sign-in problem are all much cheaper to decide in advance than at the point a user is without a machine.

Last verified: 13 October 2026.