Your Autopilot Device Came Back From Repair and Won't Enroll — Here's Why

A laptop goes out for a hardware repair. It comes back, the user turns it on, and instead of your company's branded sign-in screen, they get a plain, generic Windows setup screen — the kind you'd see on a brand-new machine (this first-run screen is called the "out-of-box experience," or OOBE for short). No branding, no automatic enrollment, nothing.

You check Intune. The device is still there, still listed under the right serial number. So it looks fine. But it isn't — the device is orphaned: it exists in your records, but Windows Autopilot (the service that recognizes a device and automatically sets it up for your company) no longer recognizes it as the same machine.

This happens because of a common misunderstanding about how Autopilot actually identifies a device. Most people assume it works like a serial number: one fixed value that stays the same forever. It doesn't. Autopilot identifies a device using something called the hardware hash — sometimes nicknamed the "4K hash" because of its size (it's a block of text about 4,000 characters long). It's built from several hardware and firmware details combined together, it looks slightly different every single time you read it, and Autopilot doesn't need an exact match to recognize a device — it allows for some difference. Once you understand those three things, repair scenarios stop being confusing and become predictable.

The problem: a repaired device Autopilot no longer recognizes

Here's the pattern, and it's easy to misread if you don't know what to look for. A device goes out for a hardware repair — say, a new motherboard. It comes back, boots up, connects to the network, and shows the generic Windows setup screen instead of your company's branded one. No user is assigned, no company apps install, nothing happens automatically. Meanwhile, if you look the device up in Intune by its serial number, it's still sitting there in your device list — which is exactly what tricks people into assuming everything is fine.

Here's what that actually looks like on the physical machine. Both of these are real captures from a repaired device that lost its Autopilot identity:

The generic, unbranded setup screen a repaired device shows instead of your company's sign-in page. The "Eine Anmeldung ist nicht möglich" (sign-in isn't possible) message is the device failing to resolve a company identity.

A related but distinct error you may see instead: "This device is already enrolled," error 8018000a. This happens when stale enrollment data from the device's old identity conflicts with a fresh setup attempt — exactly what can happen if a repair skips a clean deregistration first.

Sometimes Intune gives you a clearer warning. In the Autopilot device list, the Profile status column will show Fix pending or Attention required instead of the normal Assigned. Microsoft's own documentation says both of these messages mean the same thing: a hardware change was detected on the device. If you click the Fix pending link, you'll see this exact message:

A real Autopilot device list — three devices showing "Attention required" instead of "Assigned." Serial numbers and purchase orders redacted.

That message sounds reassuring, but in practice it's often wrong. Microsoft's own guidance says that if the status stays on Fix pending for a long time, or changes to Attention required, waiting won't fix it — you have to step in and manually remove and re-add the device (covered in the fix below).

There's a second, trickier version of this problem. Microsoft documents that Autopilot's setup profile won't apply if a hardware change happens and the device gets reimaged with an old version of Windows (older than Windows 11 21H2 with a specific update, or older than Windows 10 22H2). Microsoft says this is expected behavior — not a bug. So if your repair vendor reimages the device using an outdated company image, you can hit this problem even when the hardware repair itself would have been fine on its own.

Why it happens: what the hash actually is, and how matching works

To predict which repairs will break Autopilot and which won't, you need to understand three facts about the hardware hash. All three are documented by Microsoft, and all three go against the common assumption that the hash is basically a fancy serial number.

Fact one: it's built from several different identifiers, not one

Microsoft's own documentation says the hardware hash contains details like the manufacturer, the model, the device's serial number, the hard drive's serial number, information about when the hash was created, and "many other attributes that can be used to uniquely identify the device."

The Autopilot FAQ is more specific about the minimum requirement. Every hardware hash a manufacturer submits must include a unique firmware ID (called the SMBIOS UUID), the network card's MAC address, and a unique disk serial number. The reasoning is simple: there's no single ID that reliably and uniquely identifies every Windows device, so Microsoft combines several fields together as the next best thing.

The same FAQ lists the specific fields a manufacturer's firmware needs to get right for the hash-generation tool to work properly. This table is the closest thing to an official "ingredients list" for the hash that exists:

That last row explains most repair outcomes. Microsoft's own motherboard-replacement guidance notes that even if a repair centre copies all the old device details onto a new motherboard, they cannot copy the TPM's identity key — the private half of that key never leaves the original chip. A new motherboard means a new TPM, which means a new identity key. That's why swapping the motherboard (or just the TPM chip) is treated as a brand new device, full stop.

If a device has more than one network card or more than one disk, Microsoft documents that all of them get factored in — but the system disk's serial number carries more weight than any secondary disk, removable network adapters are ignored, and it doesn't matter whether the network connection is wired or wireless.

Fact two: the hash is deliberately impossible to take apart

You'll come across blog posts online claiming to show exactly which part of the hash contains which piece of data — a byte-by-byte map. Treat those claims with real skepticism. Microsoft's own documentation for the technical interface that exposes this hash on a live device says, in plain terms, that it's "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 changes every time you read it, and matching allows for that

This is the fact that changes everything else. Microsoft states plainly that "the hardware hash changes each time it's generated because it includes details about when it was generated." In other words, this isn't a fixed ID you can check for an exact match — it's a snapshot that includes a timestamp, so it's different every single time.

Because of that, Autopilot can't just check "does this hash exactly equal that hash." It has to allow for some difference. Microsoft's documentation confirms this directly: the matching process accounts for the fact that the hash changes on every read, and it also tolerates larger changes — like swapping a hard drive — and still finds a match. But a genuinely large change, like a new motherboard, won't match, and a fresh hash has to be captured and uploaded.

You can see this changeability yourself in a few seconds. Reading the exact same value twice in a row, on a completely untouched machine, gives you two different strings of text:

On the test device used for this article, the hash was consistently 4,000 characters long — about 1,714 of those characters were real data, and the rest was padding at the end. Those exact numbers will vary machine to machine; Microsoft doesn't document them as fixed. The one thing that is documented and reproducible is simply that the text changes every time you read it.

The myth: reinstalling Windows does not break your Autopilot registration

Here's a correction that will save you a lot of unnecessary work. A lot of people believe that wiping or reinstalling Windows on a device breaks its Autopilot registration. Microsoft's documentation says the opposite, in three separate places.

The FAQ directly asks: do you still get the Autopilot experience after wiping a machine and restarting it? The answer is yes, as long as the device is still registered and running a supported version of Windows. It also asks whether Autopilot survives a motherboard replacement or a full reimage, and again answers yes (for the reimage case — motherboard replacement has its own process, covered below).

The reason this works is structural. Your Autopilot registration lives in Microsoft's cloud service. The device's identity lives in its hardware and firmware. Neither of those two things has anything to do with what's installed on the hard drive. In fact, the Autopilot setup profile isn't even stored permanently on the device — Microsoft states it's downloaded fresh during setup, applied, and then thrown away.

The repair outcomes, at a glance

Microsoft has published a tested table of repair scenarios and what happens to Autopilot in each case. This is worth memorizing:

The second-network-card row is worth a closer look, because the reason behind it is genuinely useful to understand. Microsoft explains that in that specific scenario, the device's identity "won't be stable until after TPM attestation is complete" — and even then, having two possible MAC addresses (one from the old board's leftover card, one from the new board) creates real ambiguity about which one is correct.

How to verify: check the hash, the registry, and the event log

Verification has two parts. First, confirm the device can even produce a valid hash. Second, compare its key identifying details against what Microsoft's service has on record for it.

What if the device won't let you sign in at all?

Everything in this section assumes you can get to an elevated PowerShell prompt. That's easy on a device that's already working — sign in, right-click Start, choose Windows Terminal (Admin). It is not obvious at all on a device stuck on the exact screens earlier in this post: the generic sign-in page, or the "This device is already enrolled" error. There's no desktop, no local admin account you can sign into yet, nothing to right-click.

Windows has a documented way in anyway: press Shift+F10 at that screen. This opens a command prompt running with SYSTEM-level rights, before any user has signed in — higher privilege than a normal administrator session, and more than enough to run every check in this post. From that prompt, type:

There's no browser at this screen, so you can't copy-paste the script from GitHub or reliably reach it over a proxy. The practical fix technicians use: keep the script on a USB drive and run it directly from there, writing the report back to the same drive so you can carry it away with you:

This is genuinely a separate, deeper topic — there are actually three different interactive routes into a device stuck at OOBE (Shift+F10 is only the most capable one), and each is gated by a different, easy-to-miss setting. The full breakdown, including the other two routes and exactly which Intune setting controls them, is covered in Troubleshooting Autopilot from inside OOBE.

Read the hash on a live device

The hash is exposed through a low-level Windows configuration interface, at a location called ./DevDetail/Ext/DeviceHardwareData. This has existed since an early 2017 Windows update. On a running device, you can read it through PowerShell using the exact query Microsoft's own material uses:

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

# The length stays the same. The content itself does not.

If the hash really is missing, the documented cause is missing firmware information — specifically, both the manufacturer name and serial number need to be present in firmware, or the device simply can't be registered. Here's the exact check Microsoft recommends:

Real output of the minimum-firmware-fields check — both Manufacturer and SerialNumber are present, which is the healthy state. Serial number redacted.

Other ways to collect the hash

Microsoft documents four different ways to collect this hash, and it's worth knowing all of them, because a repair centre often won't have your specific tooling installed. You can use Configuration Manager, which does this automatically for existing devices. You can use the Get-WindowsAutopilotInfo PowerShell script (covered in detail in the fix below). On Windows 11, you can press CTRL + SHIFT + D during the initial setup screen to open a diagnostics page that exports a CSV containing the hash. Or you can export it from within a running copy of Windows:

The exported files land in C:\Users\Public\Documents\MDMDiagnostics. You can jump straight to that settings page by running ms-settings:workplace.

Check the device's own registration record

The device keeps a local cached copy of what Autopilot last told it. Microsoft documents these values under a single location in the Windows registry (a settings database built into Windows):

The real registry location on a live, registered device. Tenant-identifying values (domain, tenant ID, correlation ID, MDM ID) redacted — everything else is genuine.

Read the event log

Autopilot writes its own dedicated event log. In Event Viewer, open Applications and Services Logs, then Microsoft, then Windows, then ModernDeployment-Diagnostics-Provider, then Autopilot. If you're reading it via PowerShell, the full channel name is:

Event 908 is the clearest signal for the exact problem this article covers: Microsoft's own description says plainly that the serial number or product key on record doesn't match the physical machine, and it's blocking setup. Event 807 is the second one worth watching for, and 171 paired with 172 usually point specifically at a TPM (security chip) problem.

The real Autopilot event log channel, showing a healthy run: events 101, 103, 153, and 170, all Information level. Computer name redacted.

Run the companion script

The companion script for this article pulls all of the above into one read-only report. By default, it hides the hash itself and masks every identifying value, because Microsoft is explicit that the hash and related identifiers count as sensitive information. You can opt in to see the real values with -ShowHash and -ShowIdentifiers when you genuinely need them.

The script also has an -OutputHtml option that renders the same read-only data as a self-contained, styled HTML report instead of a terminal dump — useful if you want to attach it to a ticket or share it with a colleague who doesn't live in PowerShell:

Here's a live example of that report (with masked, illustrative data) rendered directly below:

The fix: remove, recapture, re-add, reset

Microsoft's recommended process for a motherboard replacement has six steps, and the order genuinely matters — doing them out of order can leave you with a broken or unrecoverable device record.

Step 1: delete the device from Intune

1. Sign in to the Microsoft Intune admin center.
2. Select Devices in the left menu.
3. Under By platform, select Windows.
4. Find the device by its name and select it.
5. Note down the serial number shown — you'll need it in the next step.
6. Select Delete in the toolbar, then confirm with Yes.

Step 2: remove it 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 using the serial number from step 1.
5. Select the checkbox next to it.
6. Select the "..." menu at the end of the row. If Unassign user is available, use it and confirm. If it's greyed out, that's fine — move on.
7. Select Delete in the toolbar, then confirm with Yes.
8. Select Sync to speed things up, then keep hitting Refresh every few minutes until the device disappears from the list.

Step 3: replace the hardware and confirm the firmware is correct

This is the step most repair processes skip, and it's the one that actually determines whether the fix works. Before the device leaves the repair centre, make sure the post-repair firmware correctly reports every field Microsoft lists as required: the disk serial number, the system serial number, manufacturer name, model name, the unique firmware ID, the TPM's identity key, MAC address, product key, and OS type.

Microsoft is upfront that quality here varies a lot between repair vendors. Some replacement motherboards come with a product key already programmed in; some don't. Some repair centres have the right tools to write this firmware data correctly; some don't. If the repair centre doesn't have a tool to write the correct device information onto the new motherboard, Autopilot simply won't recognize the repaired device — even after you capture and upload a brand new hash.

Step 4: capture a fresh hash

The device needs to be fully booted into Windows (or in audit mode) to capture a new hash. If the repair technician doesn't have the user's sign-in details, they'll need to reimage the device first just to get access. From there, either Microsoft's official OA3 tool or this PowerShell script will work:

A real hash capture in progress — the script installs, runs, and reports "Gathered details for device with serial number." Serial number redacted.

Step 5: re-add the device using 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 keep hitting Refresh until the device shows up.

The required CSV format is fixed and must match exactly:

Step 6: reset the device back to a fresh, unconfigured state

This step is required, not optional. Capturing the hash meant the device had to be fully booted into Windows, but Microsoft states that a device isn't actually considered "deployed" through Autopilot until it goes through the first-run setup screen again. On Windows 11, the path is Settings › System › Recovery › Reset PC, choosing Remove everything. A repair centre without the user's login can use Windows' imaging tools instead to achieve the same result.

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

There are three independent ways to confirm the fix actually worked, and you should check all three rather than trusting just one screen.

First, the Autopilot device record should now show Assigned as its profile status, instead of Fix pending or Attention required:

The healthy end state — real devices showing "Assigned" as their profile status. Serial numbers and purchase orders redacted.

Second, the event log should stop producing identity errors. Events 908 and 807 should no longer appear. Instead, you should see event 153 reporting the state change to "profile available," along with event 161 confirming the profile downloaded successfully.

Third, run the companion script again and compare its output to what you found earlier. The block below is from a real run on the test device used to write this article — every identifying value has been replaced with an obvious placeholder before publishing, on top of the masking the script already applies by default. The structural numbers (the 4,000-character length, 1,714 real payload characters, and the event counts) are genuine measurements, not made up for illustration.

Notice the last line of section 4: no events 908, 807, 171, or 172. That's what a healthy, working device looks like. Also notice the script confirms the hash is present and valid without ever printing the actual value — which is exactly the behavior you want when a ticket attachment might end up sitting in a shared mailbox somewhere.

One more check worth adding to your routine: run the script twice in a row. The "capture fingerprint" will be different both times on the exact same, untouched hardware, because the hash embeds its own creation time. If you ever find a process at your organization that treats this hash as a fixed, unchanging device ID, that single test is enough to prove it's built on a wrong assumption.

Community deep-dives worth reading

References

• Windows Autopilot registration overview — what the hash contains, and the documented matching tolerance for disk versus motherboard changes.
• Windows Autopilot FAQ — required hash data, the required firmware fields, hash collection methods, and the hardware-replacement questions.
• Windows Autopilot motherboard replacement — the full six-step repair process and the complete tested repair-scenario table.
• Windows Autopilot troubleshooting FAQ — the full event ID list, the diagnostics registry values, the padding/import fix, and hardware-change behavior.
• DevDetail CSP — the technical interface exposing the hash, and Microsoft's statement that it cannot be parsed.
• Manually register devices with Windows Autopilot — collection methods, CSV format requirements, and registration error codes.
• Windows Autopilot device guidelines — required firmware fields and manufacturer hardware requirements.
• List windowsAutopilotDeviceIdentities — the read-only Graph API endpoint used by the companion script.