The Autopilot 4K Hardware Hash Is Not a Serial Number: What Is Actually Inside It, and What Breaks the Match

Almost every Autopilot runbook contains the same instruction: run Get-WindowsAutopilotInfo, save the CSV, upload it, forget about it. That works right up until a device comes back from a repair centre and quietly refuses to behave. The technician swapped a mainboard, the user powered the laptop on, and instead of your branded sign-in page they got the plain Windows out-of-box experience (OOBE). The Autopilot record still sits in Intune showing the right serial number, so nothing looks broken. But the device is orphaned.

This happens because most of us carry a wrong mental model of the 4K hardware hash. We treat it as a serial number with extra characters. It is not. It is a composite of hardware and firmware identifiers, it is regenerated fresh every single time you read it, and the Autopilot service matches it approximately rather than exactly. Once you understand that, the repair scenarios stop being mysterious and become predictable.

The problem: a repaired device that Autopilot no longer recognises

The failure mode is consistent and it is easy to misread. A device goes out for a hardware repair. It comes back, boots, connects to the network, and runs a completely generic OOBE. No tenant branding, no assigned user, no enrollment. Meanwhile the Autopilot device list in Intune still shows the device by serial number, which is exactly what makes engineers assume the registration is fine.

Sometimes you get a clearer signal. The profile status column changes to Fix pending or Attention required. Microsoft documents that both of these messages indicate a hardware change occurred on the device. Selecting the Fix pending link shows this exact text:

That message is reassuring and often wrong in practice. Microsoft's own guidance says that if the status stays on Fix pending for an extended period, or flips to Attention required, you must manually deregister and reregister the device. Waiting does not resolve it.

There is a second, nastier variant. Microsoft documents that the Autopilot profile is not applied when a hardware change occurs and the device is re-imaged to a Windows version older than Windows 11 version 21H2 with KB5017383, or older than Windows 10 version 22H2. Microsoft states this behaviour is expected. If your repair partner re-images to a stale golden image, you can hit this even when the hardware change itself was survivable.

Why it happens: the hash is a firmware fingerprint, matched with tolerance

To predict which repairs break Autopilot, you need three facts about the hash. All three are documented, and all three contradict the common mental model.

Fact one: it is a composite of many identifiers

Microsoft's registration overview states that the hardware hash contains details about the device such as the manufacturer, the model, the device serial number, the hard drive serial number, details about when the identifier was generated, and "many other attributes that can be used to uniquely identify the device."

The Autopilot FAQ is more specific about the minimum. Every hardware hash submitted by an original equipment manufacturer (OEM) must contain the SMBIOS universally unique identifier (UUID), the media access control (MAC) address, and a unique disk serial number. The FAQ explains why plainly: since there is no single unique identifier for Windows devices, these fields together are the best available logic for identifying one.

The same FAQ lists the SMBIOS fields that must hold unique values for the OEM Activation 3.0 (OA3) tool to produce a usable hash. That list is the closest thing to a documented ingredient list that exists:

That last row is the one that decides most repair outcomes. Microsoft's motherboard replacement guidance notes that rewriting old device information into a new board "wouldn't include the TPM 2.0 endorsement key, as the associated private key is locked to the TPM device." A new TPM means a new endorsement key, and there is no way to migrate it. That is why a TPM or mainboard swap is definitionally a new device.

Multi-adapter and multi-disk machines behave in a documented way too. Microsoft states that all available MAC and disk values are used, that the serial number of the system disk is more important than other disks, that removable network interfaces should not be used when detected as removable, and that wired versus wireless does not matter because both are used.

Fact two: the blob is deliberately not parseable

You will find blog posts claiming a byte-level field map of the hash. Treat those with suspicion. The DevDetail configuration service provider (CSP) documentation for the node that exposes the hash on a live device carries an unambiguous note: the node "contains a raw blob used to identify a device in the cloud. It's not meant to be human readable by design and you can't parse the content to get any meaningful hardware information."

Fact three: the hash is regenerated every read, and matching is tolerant

This is the fact that reframes everything. Microsoft states that "the hardware hash changes each time it's generated because it includes details about when it was generated." The blob is not a stable device key. It is a timestamped snapshot.

Because of that, the service cannot compare hashes for equality. It has to match approximately. The registration overview describes the tolerance directly. When the Autopilot deployment service attempts to match a device, it accounts for the generation-time change. It also accounts for large changes such as a new hard drive and still matches successfully. But large changes such as a motherboard replacement will not match, so a new hash must be generated and uploaded.

You can observe the volatility yourself in seconds. Reading the same node twice on an untouched machine returns two different strings:

On the test device used for this article the blob was consistently 4,000 Base64 characters long, of which roughly 1,714 were payload and the remainder were trailing A filler. The first differing character between consecutive reads sat around index 32, which is consistent with an early timestamp field. Those measurements come from one machine and Microsoft does not document them as fixed values, so do not hard-code them. The reproducible and documented point is simply that the string changes on every read.

The myth: re-imaging does not invalidate a registration

Now the correction that saves the most needless work. A very common belief is that wiping or re-imaging a device breaks its Autopilot registration. Microsoft's documentation says the opposite in three separate places.

The FAQ asks whether you still get the Autopilot experience after wiping the machine and restarting, and answers yes, provided the device is still registered and running a supported Windows version. It asks whether Autopilot works after motherboard replacement or image reinstallation, and answers yes. The repair scenario matrix includes re-imaging a damaged Autopilot device that was never deregistered, and marks it supported, noting the device remains associated with the previous tenant identifier.

The reason is structural. The registration lives in the Autopilot service and the identity lives in firmware and hardware. The operating system on the disk is not part of either. Autopilot profiles are not even resident on the device. Microsoft states they are downloaded during OOBE, applied, and then discarded.

The repair matrix, condensed

Microsoft publishes a tested scenario table. These are the outcomes worth committing to memory:

The second-network-interface row deserves a note, because the documented reason is instructive. Microsoft says that scenario breaks the Autopilot experience because the resulting device identifier "won't be stable until after TPM attestation is complete," and that even then registration might give incorrect results because of ambiguity in MAC address resolution. Two candidate MAC addresses from two different hardware generations create a genuinely ambiguous identity.

How to verify: read the blob and the attributes that feed it

Verification has two halves. Confirm the device can produce a valid hash at all, then compare the identifying attributes against what the service has on record.

Read the hash on a live device

The hash is exposed through the DevDetail CSP at ./DevDetail/Ext/DeviceHardwareData, which returns a Base64-encoded string of the device's hardware parameters. Microsoft added this node in Windows 10 version 1703. On a running device you reach it through the WMI-to-CSP bridge. The query below is the one Microsoft's own material uses:

PS C:\> Get-CimInstance -Namespace 'root/cimv2/mdm/dmmap' `
>>   -ClassName MDM_DevDetail_Ext01 `
>>   -Filter "InstanceID='Ext' AND ParentID='./DevDetail'" |
>>   Select-Object InstanceID, ParentID,
>>     @{ n='HashLength'; e={ $_.DeviceHardwareData.Length } }

InstanceID  ParentID      HashLength
----------  --------      ----------
Ext         ./DevDetail         4000

PS C:\> # The length is stable. The contents are not.

If the hash really is empty, the documented cause is missing firmware data. Microsoft's InvalidZtdHardwareHash guidance states that both the manufacturer and serial number information must be included, or the device cannot be registered. It gives the exact check:

Other ways to collect the hash

Microsoft documents four collection methods, and it is worth knowing all of them because repair centres rarely have your tooling. You can use Configuration Manager, which collects hashes for existing Windows devices automatically. You can use the Get-WindowsAutopilotInfo script from the PowerShell Gallery. On Windows 11 you can press CTRL + SHIFT + D during OOBE to open the Autopilot diagnostics page and export logs including a CSV with the hash. Or you can export from the desktop:

Logs land in C:\Users\Public\Documents\MDMDiagnostics. You can also reach that pane directly by running ms-settings:workplace.

Check the client-side registration state

The client caches what the service told it. Microsoft documents these values under a single parent key:

Read the event log

Autopilot logs to a dedicated channel. In Event Viewer, open Applications and Services Logs then Microsoft then Windows then ModernDeployment-Diagnostics-Provider then Autopilot. The full channel path for Get-WinEvent is:

Event 908 is the definitive signal for this article's failure mode. Microsoft's description is explicit: there is a mismatch between the serial number or product key recorded in Autopilot and the physical hardware, and it is preventing enrollment. Event 807 is the second one to watch, and 171 together with 172 point at the TPM.

Run the companion script

The companion script pulls all of the above into one read-only report. It withholds the hash and masks every identifier by default, because Microsoft states that 4K hardware hashes contain sensitive information that only device owners should maintain. Opt in with -ShowHash and -ShowIdentifiers when you actually need the values.

The fix: deregister, recapture, reregister, reset

Microsoft's recommended sequence for a mainboard replacement has six steps, and the order matters. Skipping steps or removing records out of order can produce orphaned or unrecoverable device records.

Step 1: delete the device from Intune

1. Sign in to the Microsoft Intune admin center.
2. Select Devices in the left pane.
3. Under By platform, select Windows.
4. Find the device under Device name and select it.
5. Note the serial number shown under Serial number. You need it in step 2.
6. Select Delete in the toolbar, then Yes to confirm.

Step 2: deregister from Autopilot

1. Go to Devices then By platform then Windows.
2. Under Device onboarding, select Enrollment.
3. Under Windows Autopilot, select Devices.
4. Find the device by the serial number from step 1.
5. Select the checkbox next to it.
6. Select the extended menu icon at the far right of the row. If Unassign user is available, select it and confirm with OK. If it is greyed out, move on.
7. Select Delete in the toolbar, then Yes.
8. Select Sync to speed up the removal, then Refresh every few minutes until the device disappears.

Step 3: replace the hardware and confirm the firmware

This is the step organisations skip, and it is the one that determines success. Before the device leaves the repair centre, confirm the post-repair firmware can populate every field Microsoft lists as the minimum: DiskSerialNumber, SmbiosSystemSerialNumber, SmbiosSystemManufacturer, SmbiosSystemProductName, SmbiosUuid, TPM EKPub, MacAddress, ProductKeyID and OSType.

Microsoft is blunt that quality varies here. Repair facilities sometimes receive spare boards with replacement digital product keys pre-injected and sometimes do not. They sometimes receive working BIOS tools and sometimes do not. The documented failure case is explicit. If the repair facility lacks a BIOS tool to write device information after the board swap, Autopilot fails to recognise the repaired device even after a new hash is captured and uploaded.

Step 4: capture a new 4K hash

The device must be in the full operating system or in audit mode to capture the hash. Repair technicians without the user's credentials have to re-image the device to gain access. Then either the OA3 tool from the Windows Assessment and Deployment Kit or the PowerShell script will work:

Step 5: reregister with the new hash

1. In the Intune admin center, go to Devices then Device onboarding then Enrollment then Windows Autopilot then Devices.
2. Select Import in the toolbar.
3. Browse to the CSV file containing the new hash and select Import. This can take several minutes.
4. Select Sync, then Refresh until the device appears.

The CSV header and row format is fixed:

Step 6: reset the device back to a pre-OOBE state

This step is mandatory, not cosmetic. Capturing the hash required the device to be in the full operating system, and Microsoft states that a device is not actually deployed to Autopilot until it goes through OOBE. On Windows 11 the path is Settings then System then Recovery then Reset PC, choosing Remove everything. A repair centre without credentials will use Deployment Image Servicing and Management instead.

Proof it worked: a clean match and a quiet event log

You have three independent confirmations available, and you should check all three rather than trusting the portal alone.

First, the Autopilot device record shows the profile status as Assigned rather than Fix pending or Attention required:

Second, the event log stops producing identity errors. Events 908 and 807 should be absent. You should instead see 153 reporting the state change to ProfileState_Available, plus 161 confirming the profile downloaded.

Third, run the companion script and compare its output against what the service holds. The block below comes from a real run on the machine used to write this article. Every identifier value has been replaced with an obvious placeholder for publication, on top of the masking the script already applies. The structural figures are genuine: the 4,000 character length, the 1,714 payload characters, the 2,286 filler characters, and the event counts are all as measured.

Note the last line of section 4: no events 908, 807, 171 or 172. That is what a healthy device looks like. Note also that the script reports the hash as present and Base64-valid without ever printing it, which is the behaviour you want when a ticket attachment might end up in a shared mailbox.

One final confirmation is worth building into your process. Run the script twice in a row. The capture fingerprint will differ between the two runs on identical hardware, because the hash embeds its own generation time. If you ever meet a workflow that treats the hash as a stable device key, that single observation is enough to reject it.

Community deep-dives worth reading

References

• Windows Autopilot registration overview — what the hash contains, and the documented matching tolerance for disk versus mainboard changes.
• Windows Autopilot FAQ — required hash data, the unique SMBIOS field list, the OA3 collection interfaces, and the hardware replacement answers.
• Windows Autopilot motherboard replacement — the six-step repair sequence and the full tested repair scenario matrix.
• Windows Autopilot troubleshooting FAQ — the event ID catalog, the diagnostics registry values, the Base64 padding fix, and the hardware change behaviour.
• DevDetail CSP — the Ext/DeviceHardwareData node and the statement that the blob is not parseable.
• Manually register devices with Windows Autopilot — collection methods, CSV requirements, and the registration failure error codes.
• Windows Autopilot device guidelines — the SMBIOS Type 1 field requirements and OEM hardware best practices.
• List windowsAutopilotDeviceIdentities — the read-only Graph endpoint and least-privilege scope used by the companion script.