Fix Autopilot Error: That Username Belongs to Another Organization

A Windows Autopilot device reaches the work account sign-in page, accepts a valid username, then stops with “That username looks like it belongs to another organization. Try signing in again or start over with a different account.” Retyping the password or resetting MFA will not fix the underlying problem.

Microsoft lists this exact message as a Windows Autopilot known issue and points administrators to the Autopilot diagnostics registry key. The decisive check is whether the tenant tied to the device’s Autopilot registration matches the Microsoft Entra tenant of the user signing in. When TenantMatched is 0, Windows forces the user to start over.

This is a tenant-registration problem first. Confirm the IDs before wiping the device, deleting random Entra objects, or blaming Conditional Access.

Quick fix checklist

Use this order on one affected device:

1. Press Shift+F10 during OOBE to open Command Prompt, if your deployment permits it.
2. Read HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot.
3. Compare AadTenantId with CloudAssignedTenantId.
4. Confirm CloudAssignedTenantDomain is the organization that should own the device.
5. Check TenantMatched. A value of 0 confirms the user and device registration point to different tenants.
6. Check IsAutopilotDisabled. A value of 1 can mean the device is not registered or could not download its profile.
7. In Intune, locate the device by serial number under Windows Autopilot devices and verify its assigned profile.
8. If the device belongs to another tenant, have that tenant’s administrator remove the Autopilot registration. A local reset does not transfer cloud ownership.
9. If it belongs to your tenant, correct the stale or duplicate registration, wait for profile assignment to show Assigned, then reset and retry OOBE.

Do not keep asking the user to try other credentials. The error exists because Windows has already compared tenant state and rejected the match.

What the error actually means

Autopilot downloads tenant and profile information before the user completes enrollment. Windows stores the received values here:

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Microsoft documents five values that matter for this failure:

Registry value	What it tells you
AadTenantId	Tenant GUID associated with the user who attempted sign-in
CloudAssignedTenantId	Tenant GUID from the device’s Autopilot registration
CloudAssignedTenantDomain	Tenant domain assigned to the device, such as contoso.onmicrosoft.com
TenantMatched	1 when the user tenant matches the registered device tenant; 0 when it does not
IsAutopilotDisabled	1 when the device is not operating as an active Autopilot device or profile retrieval failed

Microsoft’s troubleshooting FAQ is explicit: the user receives an error if AadTenantId does not match the tenant used to register the device. It also says a TenantMatched value of 0 causes the error and forces the user to start over.

That distinction prevents two common mistakes.

First, this message does not prove the password is wrong. Authentication can succeed far enough for Windows to resolve the user’s tenant and still reject enrollment because the device belongs to a different tenant.

Second, the company branding shown during OOBE is not enough evidence. Read the tenant GUIDs. A familiar logo can remain while the underlying registration, cached profile, or device record is wrong.

Collect the evidence before changing anything

Read the Autopilot registry state

Run this from PowerShell during OOBE or from a diagnostic session:

$path = 'HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot'

Get-ItemProperty -Path $path -ErrorAction Stop |
    Select-Object AadTenantId,
                  CloudAssignedTenantId,
                  CloudAssignedTenantDomain,
                  TenantMatched,
                  IsAutopilotDisabled,
                  CloudAssignedOobeConfig

For a healthy user-driven deployment:

• CloudAssignedTenantId should equal your production Microsoft Entra tenant ID.
• CloudAssignedTenantDomain should name the expected tenant.
• AadTenantId should equal CloudAssignedTenantId after the sign-in attempt.
• TenantMatched should be 1.
• IsAutopilotDisabled should not be 1.

Get the expected tenant ID from Microsoft Entra admin center > Identity > Overview > Tenant ID. Compare the GUID character for character. Do not compare display names.

You can create a compact local report with:

$expectedTenantId = '00000000-0000-0000-0000-000000000000'
$ap = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot'

[PSCustomObject]@{
    ComputerName          = $env:COMPUTERNAME
    ExpectedTenantId      = $expectedTenantId
    UserTenantId          = $ap.AadTenantId
    RegisteredTenantId    = $ap.CloudAssignedTenantId
    RegisteredDomain      = $ap.CloudAssignedTenantDomain
    TenantMatched         = $ap.TenantMatched
    RegistrationIsExpected = ($ap.CloudAssignedTenantId -eq $expectedTenantId)
}

Replace the placeholder GUID before running it. This script only reports state; it does not repair or overwrite registration values.

Check Autopilot event logs

The registry gives you the tenant comparison. The event log helps establish whether the device downloaded a usable profile and where OOBE stopped.

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 250 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

Look for evidence that profile retrieval started and completed, plus registration errors such as:

• 807: the device is not registered correctly in Autopilot
• 809: the assigned profile was deleted
• 815: no profile is assigned and no default profile exists
• 908: serial number or product key mismatch

Those codes describe adjacent failures, not synonyms for the tenant mismatch. If one appears, repair that condition as well instead of forcing every symptom into the same diagnosis.

Export diagnostics when the device is remote

If a technician cannot use PowerShell interactively, export Autopilot diagnostics from the failure screen when available. Microsoft identifies these files as useful:

• microsoft-windows-moderndeployment-diagnostics-provider-autopilot.evtx
• microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx
• MdmDiagReport_RegistryDump.reg
• microsoft-windows-provisioning-diagnostics-provider-admin.evtx

The registry dump lets you inspect the same Autopilot values without asking a remote user to transcribe GUIDs from a screen.

Repair workflow by root cause

Case 1: The user is signing into the wrong tenant

This happens in organizations with multiple tenants, mergers, test tenants, or similarly named domains. The user’s account works, but it is not in the tenant that owns the Autopilot record.

Verify the user’s home tenant, not just the UPN suffix displayed on the sign-in page. Guest access to the device-owning tenant does not make a user a valid member account for normal Autopilot user-driven enrollment.

Use an authorized account from the tenant shown in CloudAssignedTenantId. If the device was intentionally migrated, continue to the next case because the registration itself must move.

Case 2: The device is still registered to a previous organization

This is common with returned, refurbished, acquired, or redeployed hardware. Reinstalling Windows does not remove a server-side Autopilot registration. A BIOS reset and a new SSD do not transfer ownership either.

The previous organization’s Intune administrator must delete the Windows Autopilot device record. Follow the organization’s disposal and proof-of-ownership process. Do not attempt to bypass the registration locally.

After deletion, allow time for the service state to clear. Reset the device and confirm that CloudAssignedTenantDomain no longer points to the old tenant before importing it into the new tenant.

For corporate hardware transfers, keep the handoff auditable:

1. Record serial number and current owning tenant.
2. Remove the device from the old tenant’s Autopilot device list.
3. Remove stale Intune managed-device and Microsoft Entra device objects as required by your runbook.
4. Confirm the Autopilot record is gone.
5. Import or register the hardware in the destination tenant.
6. Assign the intended deployment profile.
7. Wait until profile status is Assigned before restarting OOBE.

Case 3: Your tenant has a stale or duplicate device record

If CloudAssignedTenantId is correct but OOBE still behaves inconsistently, search Intune and Entra by serial number, hardware identity, and device ID. Duplicate or partially cleaned records can send technicians down the wrong path.

Do not delete every matching object at once. Establish which record is the active Autopilot registration and preserve the hardware hash if your process requires it. Then remove stale records using your approved redeployment workflow.

After repair, confirm:

• the serial number appears once in the expected Autopilot inventory
• the correct deployment profile is assigned
• group membership has finished evaluating
• profile status is Assigned, not Assigning or Unassigned
• the expected tenant domain appears after a fresh OOBE profile download

Case 4: The profile did not download

If CloudAssignedTenantId is blank and IsAutopilotDisabled is 1, do not call it a confirmed cross-tenant issue yet. Microsoft notes that this state can also result from connectivity, firewall blocking, or profile-download timeouts.

Test from a clean network without a captive portal. Check time synchronization and required Microsoft endpoints. Then restart OOBE and inspect the registry again.

The key distinction is simple:

• wrong non-empty CloudAssignedTenantId: registration or ownership problem
• blank tenant values with IsAutopilotDisabled = 1: registration or profile-retrieval problem
• matching tenant IDs with TenantMatched = 1: investigate another OOBE or enrollment failure

What not to do

Do not edit the tenant GUIDs in the registry

Those values are diagnostics received from the Autopilot service. Changing them locally does not transfer ownership or correct the server-side device record. It only destroys useful evidence and can leave the next technician with a misleading snapshot.

Do not delete the device from Entra only

The Autopilot registration is the critical ownership record for this symptom. Deleting a Microsoft Entra device object alone does not guarantee removal from Windows Autopilot.

Do not assume a reset clears Autopilot

Autopilot is designed to survive operating system reinstall and reset workflows. That persistence is useful for enterprise recovery and a problem when asset offboarding is incomplete.

Do not treat guest membership as tenant ownership

A user invited as a B2B guest can access resources in another tenant, but that does not make the guest account the correct tenant identity for ordinary Autopilot enrollment.

Prevention for enterprise deployment teams

Add a tenant-ownership gate to every hardware transfer and redeployment runbook.

Before shipping a device, verify the serial number, Autopilot owner, assigned profile, and destination user tenant. For acquisitions or tenant migrations, include Autopilot deregistration in the migration plan rather than treating it as an endpoint cleanup task after users receive hardware.

A practical preflight report should capture:

• device serial number
• expected tenant ID
• Autopilot registration status
• assigned profile and profile status
• destination user’s home tenant
• date the old tenant confirmed deregistration

This turns a vague OOBE complaint into a checkable ownership control.

Conclusion

“That username looks like it belongs to another organization” is not a password-reset problem. It is Windows telling you that the user’s Microsoft Entra tenant does not match the tenant associated with the Autopilot device, or that the device did not retrieve valid registration state.

Start with HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot. Compare AadTenantId with CloudAssignedTenantId, read TenantMatched, and verify CloudAssignedTenantDomain. Then repair the server-side registration, profile assignment, or account choice that produced the mismatch.

The fastest safe fix is the one that makes the tenant records agree. Registry edits, repeated resets, and random object deletion only hide the evidence.