This blog explains what can go wrong when Autopilot devices aren’t properly deregistered or offboarded and how something as simple as a motherboard replacement can lead to enrollment failures, tenant conflicts, and even serious security risks if the device ends up in the wrong hands.
What You’ll Learn
- Why motherboard replacements can break Autopilot identity
- How reused hardware can cause tenant conflicts
- The risks of improper deregistration, including security exposure
- Why Microsoft’s old fix for this no longer works
- How to properly offboard Autopilot devices before hardware changes
- What role Autopilot Device Preparation (AP-DP) plays and its limitations
Introduction
Windows Autopilot is a cloud-based service that simplifies the deployment and initial configuration of new Windows devices. It enables devices to be configured with the right settings, apps, certificates, and policies without needing to be reimaged. Instead of building custom OS images, organizations can use Windows Autopilot to automatically enroll devices into Intune and Entra ID as part of the out-of-box experience (OOBE).
Before a device can be provisioned with Windows Autopilot, it must be registered with your tenant. This is done by uploading the hardware hash, a unique identifier that includes details like motherboard serial numbers and TPM data (EKPub/EkCert).
Once a deployment profile is assigned, the device will automatically configure itself with your organization’s settings when it connects to the Internet. When the device contacts the Autopilot service (ZTD), it receives its assigned profile.
When a Motherboard Replacement Breaks Identity
A motherboard isn’t just a piece of hardware, it holds something far more critical: your device’s identity, embedded in the Trusted Platform Module (TPM).
The TPM is critical to how Windows identifies and trusts a device. It’s used as the root of trust and plays a key role during Autopilot. Each TPM includes a unique Endorsement Key (EK) and often an Endorsement Certificate (EKCert), both used for attestation. This is essential for Autopilot Pre-Provisioning and Self Deployment scenarios.
It allows Windows to securely enroll into Intune using Enrollment Attestation and proves the device identity during MDM enrollment and TPM key provisioning. But once the motherboard is replaced, so is the TPM. The original EKPub and EKCert are gone, breaking the trust link between the device and your tenant.
The Autopilot service uses this trust (hardware hash/hwdeviceid) to identify the device.
When you replace the motherboard, especially if the TPM is part of the board, the hardware hash/hardware changes completely. That means the device no longer matches the original registration. At that point, Autopilot provisioning fails. The service no longer recognizes the device’s identity and won’t assign the expected profile.
Things get worse if that old motherboard is repaired and reused in another device
The Cross-Tenant Collision: When Things Really Break
Let’s say:
- Device A (registered to Tenant A) has its motherboard replaced.
- The old motherboard is repaired and reused in Device B.
- Device B is owned by Tenant B.
When Device B boots and connects to the internet during OOBE, Autopilot recognizes the hardware hash on that motherboard as belonging to Tenant A.
Autopilot sends down Tenant A’s deployment profile, and Device B tries to enroll in Tenant A. This is a hard block; you cannot enroll the device in your own tenant because it’s still tied to someone else’s.
This is exactly what the infographic above shows. This has nothing to do with TPM attestation. It’s all about tenant ownership.
Security Risks
Besides enrollment issues, there’s a real security concern.
If the replaced motherboard came from another organization and still has an active Autopilot registration with a self-deploying or pre-provisioning profile, it could automatically enroll into that original tenant. As soon as it connects to the internet, it will start applying policies, apps, Wi-Fi settings, certificates, or VPN profiles from another environment.
This goes beyond a failed deployment. In the wrong hands, it could provide access to a different organization’s network and could lead to a data breach.
Microsoft was aware that hardware changes like this could break the Autopilot flow. To help with this, they had a backend solution that supported devices after a motherboard replacement.
Microsoft’s Attempt at Solving the Hardware Hash Problem
At one point, Microsoft had a backend service that helped devices deal with motherboard replacements. When a device was already registered with Autopilot and had its motherboard repaired or replaced, the service would try to match the new hardware hash with the existing device record.
As long as the device was still active in Intune and Entra ID and the registration was intact, the backend would accept the new hash as a replacement for the old one, effectively updating the existing Autopilot object. No manual intervention or re-registration was needed.
This enabled devices to re-provision successfully after a motherboard swap without running into tenant assignment errors or hash mismatches.
That behavior is no longer supported.
Today, if the hardware hash changes, the Autopilot service no longer automatically updates it. If the device identity no longer matches, provisioning will fail, and the only way to fix it is to deregister the device and register it again from scratch.
➡️ For a deep dive into how that remediation service used to work, check out this blog post.
That’s why offboarding has become more important than ever.
Motherboard Replacement: Offboarding:
Before repairing a device, especially when the motherboard might be replaced, you must offboard/deregister it properly.
That means:
- Remove the Autopilot registration
- Remove the device from Intune
- Remove the Entra ID object
Wipe the device if it’s still bootable
If the device is totally broken and can’t be reset, it’s even more important to manually remove/deregister it from the cloud. If you skip this, you lose control over the identity linked to that hardware.
Once it’s reused, the next tenant won’t be able to claim it. If they try to register the device, they will get the error 808 ZtdDeviceAssignedToOtherTenant, and you’ll be the reason why. The device’s motherboard is still linked to another Tenant!
If this happens, you need to contact Microsoft Support. They can manually remove the device from the Autopilot service. If Microsoft Support needs to deregister the device on your behalf, they must verify ownership of the device.
Autopilot Device Preparation (AP-DP)
You might be wondering, doesn’t Autopilot Device Preparation solve this?
It certainly improves the provisioning experience. AP-DP supports faster profile assignment using Enrollment Time Grouping and removes the need to upload the hardware hash in advance.
However, AP-DP still depends on whether the device is registered to a different tenant. If that motherboard and its identity are already claimed, AP-DP can’t help.
The enrollment will still fail because the device is effectively “locked” to the wrong customer, and the old method (Hash) still comes down to the device before AP-DP can be used.
Final Thoughts
If the motherboard gets replaced and the device wasn’t properly deregistered, you might not be able to enroll it into your own tenant. It will keep trying to register with the original one.
That’s already bad enough. But if the original registration used a self-deploying or pre-provisioning profile, the device could automatically join the wrong tenant without any user action.
This isn’t just a broken enrollment. It’s a real security risk. That’s why you need a clear deregistration process in place before replacing or reusing hardware.