Skip to content
June 12, 2026 Senior (5+ years) Error Reference

Fix Autopilot Import Errors 806 and 808 in Intune

Fix Autopilot import errors 806 and 808 in Intune by removing stale device records, validating tenant ownership, and preparing support evidence.

Methodology

Practical guidance for working engineers, with a bias toward steps you can verify and repeat.

• What it covers: the exact problem, workflow, or decision
• What to verify: logs, settings, outcomes, or pass/fail checks
• What to avoid: risky changes without rollback or validation
• What to expect: prerequisites, caveats, and role fit

Updated: June 12, 2026

Fix Autopilot Import Errors 806 and 808 in Intune

If a Windows Autopilot CSV import fails with 806 - ZtdDeviceAlreadyAssigned or 808 - ZtdDeviceAssignedToOtherTenant, do not start by rebuilding deployment profiles or wiping the device again. Those two errors usually mean the hardware identity is already claimed somewhere in the Autopilot service. Your job is to prove who owns the record, remove the stale registration if you can, and gather the right evidence if you cannot.

Microsoft’s March 2026 support article now spells this out clearly: error 806 means the device is already registered to the same tenant, while error 808 means the device is assigned to another tenant. Microsoft also states that the blocking record must be removed before the CSV import can succeed.

This runbook is for desktop engineers and Intune admins who need a practical fix path, not a generic Autopilot overview.

What 806 and 808 actually mean

The visible symptoms are simple. In the Intune admin center, you go to Devices > Windows > Enrollment > Devices under Windows Autopilot, import a CSV, and the portal returns one of these messages:

Error details Device is already registered to the same Tenant. Error code: 806 - ZtdDeviceAlreadyAssigned

Error details Internal error Error code: 808 - ZtdDeviceAssignedToOtherTenant

The important distinction is this:

  • 806 / ZtdDeviceAlreadyAssigned: the hardware hash or device record already exists in your own tenant, or there is still a related device record in Microsoft Intune or Microsoft Entra ID that the service treats as active.
  • 808 / ZtdDeviceAssignedToOtherTenant: the hardware identity is tied to a different tenant. That may be an old employer tenant, a lab tenant, a reseller-managed tenant, a merger or divestiture scenario, or a replacement motherboard that was pre-registered elsewhere.

In both cases, the failure happens before normal Autopilot profile assignment troubleshooting matters. You are blocked at registration time.

Why this happens in real environments

These import errors usually show up in one of six situations:

  1. The device was deleted from one Intune blade but still exists in the Windows Autopilot devices list.
  2. The Autopilot object was deleted, but a related Entra device object still creates confusion during re-registration.
  3. The device was moved between tenants and the old registration did not fully clear before the new import.
  4. The hardware was repaired, especially a motherboard swap, and the replacement board is linked to another tenant’s Autopilot registration.
  5. A reseller or OEM pre-registered the device under the wrong customer tenant.
  6. An admin is retrying imports too quickly and assuming deletion has already completed even though the backend cleanup is still in progress.

Microsoft’s manual registration guidance adds two useful operational facts. First, a CSV upload can include up to 500 devices. Second, admins should confirm the prior batch completed before uploading the next one. That matters because rushed batch retries make stale-registration incidents harder to read.

Microsoft’s September 2023 Intune customer success guidance on tenant transfers also explains another common trap: after removing a device from Tenant A, you can attempt to register it in Tenant B, but if you still get an error during import, that can indicate the deletion was not fully completed in Tenant A yet.

Fast triage workflow before you open a support case

Use one affected serial number and walk through the checks in this order.

1. Confirm whether this is 806 or 808

Read the exact import error. Do not group both into a generic “Autopilot import failed” ticket. Your next step depends on which code you saw.

2. Check Windows Autopilot devices in Intune

In the Intune admin center:

  1. Go to Devices.
  2. Select Windows.
  3. Open Enrollment.
  4. Under Windows Autopilot, open Devices.
  5. Search by serial number.

If the device exists and you are dealing with 806, delete the Autopilot record there first. Microsoft’s support article says this is the primary remediation path.

3. Wait for deletion to finish

Do not delete and immediately retry the upload three times. Microsoft notes that deletion can take a few minutes. In real tenants, that delay is enough to create false escalation noise.

4. Check Intune managed devices and Microsoft Entra ID

The current Microsoft Q&A guidance for a 2025 806 case recommends exporting Intune devices with the serial number column visible and checking whether the device still exists. If it does, identify the associated Entra device object and remove the stale record before retrying the import.

Practical check list:

  • Search Intune managed devices by serial number.
  • Search Microsoft Entra ID > Devices for matching device names or the device ID tied to that serial.
  • Compare the device’s current dsregcmd /status output with the object you plan to remove if the endpoint is still accessible.
  • Confirm you are not deleting the active production object for a device that is still in use.

5. Decide whether you control the owning tenant

If the error is 808, ask a simple question: do you have admin access to the tenant that currently owns the device registration?

  • If yes, remove the Autopilot registration from that old tenant and wait for the deletion to complete.
  • If no, stop retrying imports. You likely need the previous tenant admin, your OEM or reseller, or Microsoft Support.

6. Capture incident evidence now

Whether you expect to self-fix or escalate, capture the following before anyone wipes or repurposes the device:

  • CSV file used for the failing import.
  • Serial number.
  • Current tenant name and tenant ID.
  • Exact error code and timestamp.
  • Screenshot of the Autopilot import result.
  • Whether the device had a motherboard replacement or ownership transfer.
  • Whether the device was recently part of a tenant migration.

That short evidence pack saves time when the issue turns out to be cross-tenant ownership rather than a local cleanup problem.

Fix path for error 806: device already registered to the same tenant

When the error is 806 - ZtdDeviceAlreadyAssigned, assume a stale record still exists until proven otherwise.

Remove the Autopilot record first

Microsoft’s official March 2026 article says to sign in to the Intune admin center, go to Devices > Windows > Enrollment > Windows Autopilot > Devices, select the device, and delete it.

After that:

  1. Wait for the deletion to complete.
  2. Refresh the Autopilot devices list.
  3. Search again by serial number.
  4. Only retry the CSV import once the device no longer appears.

If the Autopilot object is gone but 806 still appears, inspect adjacent records:

  • Intune managed device objects.
  • Microsoft Entra device objects.
  • Duplicate device names created after resets or re-enrollment.
  • Records left behind after motherboard replacement or device refurbishment.

A useful field trick from Microsoft Q&A is to export Intune devices with serial numbers included, then find whether the serial is still attached to another object path. This is especially helpful when names changed but the serial did not.

Retry with a single-row CSV

Do not test with a large batch after cleanup. Use a one-device CSV first. If that works, move back to the larger import batch.

If 806 still persists

At that point, treat the issue as a backend registration hold rather than a UI problem. Prepare to open Microsoft support with the required evidence. The fact that you cannot see the record does not mean the service has fully released it.

Fix path for error 808: device assigned to another tenant

Error 808 - ZtdDeviceAssignedToOtherTenant is more political than technical. The service is telling you the hardware identity belongs to someone else.

Scenario 1: You control both tenants

This is the cleanest case. Microsoft’s tenant transfer guidance says the sequence should be:

  1. Collect the hardware hashes for the devices you plan to move.
  2. Remove the Autopilot registration from the old tenant.
  3. Wait for the old registration to clear.
  4. Import or register the device into the new tenant.
  5. Confirm the new Autopilot profile assignment.
  6. Reset the device only after the new registration is confirmed.

Microsoft also warns not to use Autopilot Reset for this migration path because it leaves the device managed by the old tenant. Use a full reset method when you are ready to re-provision into the new tenant.

For large migrations, Microsoft recommends syncing in stages and notes that offline migration may be a better fit when timing between deregistration and re-registration is hard to control.

Scenario 2: You do not control the old tenant

This is common with refurbished hardware, lease returns, mergers, distributor mistakes, and replacement motherboards.

Your options are:

  • Ask the old tenant admin to deregister the device from Windows Autopilot.
  • Ask the OEM, reseller, or distributor to correct the registration if they enrolled it on your behalf.
  • Open a Microsoft support request if ownership needs to be verified centrally.

The Microsoft Q&A case for a motherboard replacement points to the same resolution: be ready for a Microsoft support ticket or vendor action, because a replacement board can inherit someone else’s Autopilot registration state.

Scenario 3: The device was repaired

If a motherboard was replaced, do not assume the old CSV hash or prior ownership history still applies. Replacement boards can introduce a new hardware identity and sometimes a new tenant conflict. Validate the current hardware hash and treat the repaired device as a fresh registration case.

What Microsoft Support will ask for

Microsoft’s March 2026 support article is very specific here. If you cannot remove the blocking record yourself, gather these items before you open the case:

1. Device CSV

Provide the CSV file that produces the 806 or 808 error.

2. Proof of ownership

Microsoft says this is usually a bill of sale or invoice in PDF format. The requirements matter:

  • It must be the original document, not a screenshot.
  • The serial number, chassis ID, or another unique device identifier must appear on the document.
  • Your company name must appear on the document.

If that unique identifier is missing, Microsoft says you need an updated ownership document from the vendor.

3. Diagnostic logs

Microsoft asks for Autopilot diagnostics from the endpoint. Run this command on the device:

Mdmdiagnosticstool.exe -area Autopilot -cab c:\out.cab

The resulting CAB file contains the Autopilot diagnostic data Microsoft uses during the deregistration process. Microsoft also notes that these logs can be collected at any point during the Autopilot process, so you do not need to wait for a perfect reproduction window.

4. Support context

Add these details yourself even though Microsoft does not list them as formal requirements:

  • Which tenant you are trying to import into.
  • Whether the issue is 806 or 808.
  • Whether the device was purchased new, refurbished, or repaired.
  • Whether this is tied to a tenant migration.
  • Whether you already deleted visible Intune and Autopilot records.

One more nuance from the support article: customers on Microsoft Premier Support do not need to provide proof of ownership to deregister a device, but they still need to prove they possess it.

Limitations and prevention steps

These errors are not fixed by profile changes, ESP changes, or reinstalling Company Portal. They are registration ownership problems.

To reduce repeat incidents:

  • Keep Autopilot removal and import actions documented in your tenant migration runbooks.
  • After deleting devices from an old tenant, wait and verify before retrying import in the new tenant.
  • Use single-row CSV tests for disputed devices instead of retrying entire batches.
  • Track motherboard replacements and refurbished hardware as potential Autopilot ownership exceptions.
  • Validate vendor and reseller registration processes for new purchases.
  • Preserve the import CSV and diagnostics the first time the error appears.
  • For batch work, stay within the documented 500-device CSV limit and confirm the previous batch completed before the next upload.

The hardest part of these cases is usually not the fix itself. It is identifying who can legally and technically remove the claim on the hardware identity.

Conclusion

806 - ZtdDeviceAlreadyAssigned usually means your tenant still has a stale Autopilot or related device record. 808 - ZtdDeviceAssignedToOtherTenant means another tenant owns the hardware identity and you need that claim removed before import can work.

The shortest path is to search the Autopilot devices list first, clean up visible records, retry with a one-device CSV, and escalate with the right evidence when the owning tenant is outside your control. If you skip those steps, you waste time troubleshooting profile assignment when the device was never successfully registered in the first place.

Was this helpful?

Comments

Comments are coming soon. Have feedback? Reach out via the About page.