Autopilot registration is tenant-bound: deregister, then re-register the hash

A pile of laptops from an acquired company shows up on your desk, and you assume you can just point them at your tenant. You can't. Every one of them is already claimed, keyed on a hardware fingerprint, and until you release that claim your tenant will refuse them.

New to cloud? CAMPUX is a free, build-first course. Start here →

This is part of the Azure tenant-to-tenant migration guide, and Autopilot devices are one of the sharper edges in it. A Windows Autopilot device is registered to exactly one tenant. That registration is not a label you can repaint — it is a record in the Windows Autopilot deployment service that binds the machine's hardware hash to a single tenant ID. Try to add a device whose hash already belongs to someone else and the service stops you cold with ZtdDeviceAssignedToAnotherTenant. There is no merge, no override. The only way across the boundary is to release the device from the old tenant and claim it in the new one.

Why the device belongs to one tenant

Registration, in Microsoft's own terms, takes two things: the device's unique hardware hash is captured and uploaded to the Autopilot service, and the device is associated to an Azure tenant ID. That association is the whole game. The hash is a fingerprint built from the manufacturer, model, serial numbers, and a stack of other attributes — enough to identify one physical machine even after a disk swap. Once that fingerprint is tied to a tenant, the deployment service treats the pairing as exclusive. When the same hash appears in a second tenant's import, the service already has an owner on file and rejects the newcomer. So the boundary is not bureaucratic. It is baked into how Autopilot recognizes hardware.

The hardware fingerprint has one owner. Two tenants cannot hold the same device.

Deregister from the source, then register in the target

Moving the device is a release-and-reclaim, done in order. First, capture the hardware hash from each machine while you still have access — the Get-WindowsAutopilotInfo PowerShell script or Configuration Manager both harvest it into a CSV. You want that CSV in hand before anything else, because once the device is gone from the old tenant, collecting the hash again is a lot harder.

Then deregister from the source. Microsoft's guidance is explicit that a clean removal is more than deleting one row: the device has to come out of Intune first, then out of Windows Autopilot, and the Entra object is handled as part of that sequence. Skip steps or do them out of order and you can strand orphaned records or a device that lands in an unrecoverable state. Deleting the device from the source tenant's Autopilot devices list triggers the deregistration and clears the old tenant's claim on the hash. Only now can you import that same hash into the target tenant and add it there.

Reset, then re-provision through the target's profile

Registration alone does not transform the machine. The device still has to run through the out-of-box experience again so it can pick up the new tenant's Autopilot profile. That means a reset — wiping the current state and rebooting into OOBE — at which point the device contacts the service, is recognized by its now-target-owned hash, and provisions through the target tenant's deployment profile and its Enrollment Status Page. The ESP is what holds the user at a progress screen while apps and policies land, so the machine is business-ready before anyone starts working on it. If the hash is not registered in the target when OOBE runs, none of this fires, which is exactly why the ordering above matters so much.

Rebuild profiles and settings on the far side

Nothing follows the hash across the boundary except the hash itself. Deployment profiles, the Enrollment Status Page, enrollment settings, the compliance and configuration policies behind them — all of it lives inside a tenant and has to be rebuilt or reused in the target. The device's compliance state is worth thinking through early, since it shapes how your policies target the machine once it lands. This Autopilot dance is only the enrollment slice of the larger move; the fuller story of what happens to the managed device and its policies lives in Intune device migration.

One more angle if the hardware came through a partner. When an OEM, reseller, or distributor registered the device on your behalf through Partner Center, a Cloud Solution Provider can remove it there — but that only clears the Autopilot registration, not the Intune enrollment or the Entra join. So for partner-sourced fleets, coordinate the release with whoever registered them, and confirm the hash is genuinely free before you import it into the target. A half-released device is the one that throws ZtdDeviceAssignedToAnotherTenant at the worst possible moment.

The takeaway

An Autopilot device is bound to one tenant by its hardware hash, and there is no cross-tenant transfer button. Capture the hash, deregister the device from the source tenant in the right order, register that hash in the target, then reset the machine so it re-provisions through the target's profile and Enrollment Status Page — with the profiles, ESP, and policies rebuilt on that side first. Keep the gap between release and reclaim short. "Deregister, re-register the hash, reset, re-provision" is the whole of it, and getting the order right is the difference between a clean move and a pile of unmanaged laptops.

Questions people also ask

Can an Autopilot device be registered to two tenants at once?

No. Registration associates the device's hardware hash with exactly one tenant ID. If you upload a hash that already belongs to another tenant, the service rejects it with a ZtdDeviceAssignedToAnotherTenant error. The device has to be deregistered from the first tenant before the same hash can be registered in the second.

How do I move a Windows Autopilot device to a new tenant?

Capture the hardware hash, delete the device from the source tenant's Autopilot devices list to deregister it, then import that hash into the target tenant and assign a deployment profile. Reset the device so it runs the out-of-box experience again and provisions through the target tenant's Autopilot profile and Enrollment Status Page.

What happens if I reset the device before registering it in the new tenant?

You risk it coming up as an ordinary unmanaged device. If the hardware hash is not registered in the target tenant when the machine finishes its reset and runs the out-of-box experience, there is no profile waiting for it, so it does not provision through Autopilot and loses the configuration and policy you expected.

Do I have to rebuild the Autopilot profile in the new tenant?

Yes. Deployment profiles, the Enrollment Status Page, enrollment settings and the policies behind them all live inside a tenant. Nothing follows the hardware hash across the boundary. You register the device in the target, then rebuild or reuse an existing profile and ESP there and assign it before the machine provisions.

Who deregisters a device that was registered by an OEM or partner?

If a partner registered it through Partner Center, a Cloud Solution Provider can remove it there, but that only clears the Autopilot registration, not the Intune or Entra records. For devices an admin registered through Intune, deregister from Intune instead. Coordinate with the reseller so the hash is fully released before you re-register it.