A customer called me on a Tuesday morning in March with twelve brand-new Dell Latitude 7450s sitting on a conference room table, every single one stuck at the same blue screen: "Something went wrong. Confirm you are using the correct sign-in information, then try again. (0x80180014)". They had paid the OEM to pre-register the hashes, the devices showed up in the Autopilot blade in Intune, and the user could authenticate with their Entra ID credentials just fine. But the moment Autopilot tried to enroll the device into Microsoft Intune as an MDM, the whole thing fell over.
I have hit 0x80180014 enough times now — on Surface Pro 11s, on HP EliteBooks, on virtualized Hyper-V test rigs — that I keep a runbook for it. This is that runbook, cleaned up and explained. If you are staring at this error right now and you just need the fix, jump to the diagnostics section, pull the IME log, and the right remediation will be obvious within five minutes.
What 0x80180014 Actually Means
The hex code 0x80180014 resolves to MENROLL_E_DEVICE_AUTHENTICATION_ERROR in the MDM enrollment subsystem. Microsoft documents this in the MDM enrollment error reference as "the device cannot be enrolled because the authentication of the device failed." That phrasing sounds like an account password problem, but in 99% of real cases I have seen, the user's credentials are fine. The failure is that the device itself cannot prove who it is to the Intune service.
Autopilot enrollment works by uploading a device hash — a SHA-256 fingerprint derived from the TPM endorsement key, the hardware hash, and a few other identifiers — to your tenant's Autopilot devices list. When the device boots into OOBE, it computes that same hash, sends it to Microsoft, and the Autopilot service replies "yes, that hash belongs to tenant contoso.onmicrosoft.com, here is the deployment profile." Enrollment then proceeds. 0x80180014 means that handshake completed but the subsequent MDM token exchange — the one that binds the device to the Intune service — failed.
From my logs the four root causes, in rough order of frequency, are:
- The device is assigned to a deployment profile but is not in any Entra ID dynamic group that grants an Intune license to the enrolling user.
- MDM auto-enrollment is not configured for "All" or for the right user group in the Entra admin centre.
- The uploaded device hash does not match the device's current hardware (motherboard swap, TPM clear, or factory image refresh after hash collection).
- The user account is blocked from device enrollment by an Intune enrollment restriction policy — usually the "Personally owned" restriction silently catching a corporate device whose serial number was not pre-staged.
Pulling the Diagnostics That Actually Tell You Something
The OOBE error screen tells you nothing. The trick is to escape OOBE without rebooting and read the Intune Management Extension log. Hit Shift+F10 on the error screen to drop into a command prompt — this works on Windows 11 24H2 and 25H2, which is what most fleets are on as of 2026.
cd C:\Windows\Temp\MDMDiagnostics
MdmDiagnosticsTool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -zip C:\diag.zip
That single command bundles every log Autopilot writes — the ETW traces, the registry snapshots under HKLM\SOFTWARE\Microsoft\Enrollments, and the IME log itself. Copy C:\diag.zip off the machine with a USB stick or, if you can get network up, a quick PowerShell upload to an Azure storage account:
$sas = "https://mytenantdiag.blob.core.windows.net/uploads/diag-$(Get-Date -Format yyyyMMdd-HHmmss).zip?sv=2024-11-04&sp=cw&sig=..."
Invoke-RestMethod -Uri $sas -Method Put -InFile C:\diag.zip `
-Headers @{ "x-ms-blob-type" = "BlockBlob" }
Then on your workstation, unzip and open MDMDiagReport.html. Scroll to the Enrollment State section and look for the entry timestamped just before the failure. You want one of two strings:
HTTP 401 from https://manage.microsoft.com/... — this is cause #1, #2 or #4 (licensing, auto-enrollment, or restriction).The device record was not found or ZTDID mismatch — this is cause #3 (hash mismatch).
I have wasted hours guessing without this log. Pull it first.
Fix 1: License Assignment and the "Intune-Only" Trap
This is the one that bit my Dell customer. They had bought a Microsoft 365 Business Premium pack for fifty users but had not yet assigned the license to the helpdesk service account that the Autopilot devices were enrolling under. Without the Intune service plan on the user object at the moment of enrollment, the MDM token comes back with a 401 and you get 0x80180014.
Check it with Microsoft Graph PowerShell. If you do not have the module, install it first — note the v2.x module is what ships now, the v1.x cmdlets are gone:
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
$user = Get-MgUser -UserId "[email protected]" -Property AssignedPlans
$user.AssignedPlans | Where-Object {
$_.ServicePlanId -eq "c1ec4a95-1f05-45b3-a911-aa3fa01094f5" # Intune Plan 1
} | Format-Table CapabilityStatus, AssignedDateTime
If CapabilityStatus comes back as anything other than Enabled, or the result is empty, that is your problem. Assign the license either directly in the Entra admin centre or — better — via group-based licensing on a security group that includes every user who will ever enroll a device. The full list of service plan GUIDs is on Microsoft Learn's service plan reference; bookmark it.
The "Intune-Only" Gotcha
If you are using a standalone Intune license rather than a Microsoft 365 bundle, make sure the user also has an Entra ID P1 license. Autopilot requires Entra ID join, Entra ID join requires conditional access evaluation, and on tenants without P1 the silent enrollment token issuance fails in a way that surfaces as — you guessed it — 0x80180014.
Fix 2: MDM Auto-Enrollment Scope
Even with the right license, the Entra ID tenant has to be told that Intune is the MDM authority and that this user is in scope for auto-enrollment. The setting lives at Entra admin centre → Mobility (MDM and MAM) → Microsoft Intune. The default after April 2024 is "None," which is fine for tenants that have never used Intune but useless for new Autopilot deployments.
Set MDM user scope to All if you have a single-tenant Intune deployment, or to a specific group if you are running mixed MDM. Leave the three URL fields (Terms of use, Discovery, Compliance) at their defaults — they are read-only and point to the correct Microsoft endpoints automatically. You can verify the setting was applied by querying the policy via Graph:
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/policies/mobileDeviceManagementPolicies"
$policies.value | Format-Table displayName, appliesTo, isValid
If appliesTo shows none, no device anywhere in your tenant will ever auto-enroll, regardless of license. I have seen this on tenants that were originally created for Office-only use and later expanded to include Intune; nobody thought to flip the switch.
Fix 3: Re-Capturing the Hardware Hash
If the IME log shows "device record not found" or a ZTDID mismatch, the hash on file does not match the hardware. Common triggers I have logged: a TPM 2.0 clear (after a firmware update on Surface devices, this happens automatically), a motherboard swap by Dell ProSupport, or an OEM that uploaded the hash from a pre-imaging tool and then re-imaged the device with a different SKU of Windows.
Capture a fresh hash from OOBE — again with Shift+F10 — using the official Microsoft script:
md C:\HWID
Set-Location C:\HWID
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Install-Script -Name Get-WindowsAutoPilotInfo -Force
Get-WindowsAutoPilotInfo -OutputFile AutoPilotHWID.csv
The script is maintained by the Intune product group and lives on the PowerShell Gallery. Once you have the CSV, delete the old device record from Intune admin centre → Devices → Enrollment → Windows → Devices first, then import the new CSV. Do not skip the delete step — Intune will reject the import as a duplicate serial number otherwise. Wait fifteen minutes for the device to sync to the Autopilot service, then reboot into OOBE.
While you are at it, confirm the device's actual TPM is healthy. A flaky TPM will produce intermittent 0x80180014s that look exactly like the other causes:
Get-Tpm | Format-List TpmPresent, TpmReady, TpmEnabled, ManufacturerVersionFull20
All four should read True (or a version string for the last one). If TpmReady is False, run Clear-Tpm from an elevated prompt and let the firmware re-initialize it before you try enrollment again.
Fix 4: Enrollment Restrictions Catching Corporate Devices
This one is sneaky because the device is technically enrolling correctly — the policy is just blocking it after the handshake. Go to Intune admin centre → Devices → Enrollment → Enrollment restrictions → Device platform restrictions. The "All Users" default policy has a "Personally owned" column for Windows. If that is set to Block (which it should be for security), Intune needs to know your Autopilot devices are corporate-owned.
Autopilot marks devices as corporate-owned automatically only if they were imported via the Autopilot CSV or assigned through an OEM/CSP partner. Devices added by serial-number-only or by manual hash import sometimes land in the "Personal" bucket. Fix it by pre-staging the serial numbers under Devices → Enrollment → Corporate device identifiers before the first OOBE attempt. The full enrollment restriction model is documented in the Intune enrollment restrictions guide.
Once the serial is registered as corporate, the next OOBE attempt will succeed. I have never needed to delete and re-import the Autopilot hash after this fix — the corporate identifier table is read independently at enrollment time.
Caveats and Things I Got Wrong the First Time
Two warnings from my own mistakes. First, do not try to "reset" Autopilot enrollment by running sysprep /oobe on a device that has already partially enrolled. The MDM enrollment registry keys under HKLM\SOFTWARE\Microsoft\Enrollments\{GUID} survive sysprep on Windows 11 24H2 and later, and the next OOBE attempt will hit a different but equally cryptic error. Always do a full Autopilot reset from the Intune blade or a USB reimage.
Second, the 30-minute Autopilot profile assignment window is real. If you import a hash and immediately try to enroll, you will get 0x80180014 not because anything is wrong, but because the profile has not propagated to the device-facing service yet. Set a timer, walk away, come back. The deployment profile assignment timing writeup I did last year covers the propagation paths in more detail.
Third — and this only bit me once but it cost a day — if your tenant has Conditional Access policies that require a compliant device for Microsoft Graph access, the enrollment itself can be blocked because the device is, by definition, not yet compliant. Add an exclusion for the Microsoft Intune Enrollment cloud app (app ID d4ebce55-015a-49b5-a083-c84d1797ae8c) on any policy that targets all cloud apps. The fix for the related conditional access enrollment loop is essentially the same idea.
FAQ
Does 0x80180014 ever fix itself if I just retry?
Sometimes, yes — specifically when the cause is the 30-minute profile propagation delay. If you have just imported the hash, wait at least 30 minutes (Microsoft says up to 24 hours but I have never seen it take more than 40 minutes in practice) and retry. If three retries spaced an hour apart all fail, it is not a propagation issue and you need to diagnose properly.
Will resetting the TPM lose BitLocker recovery keys?
Only if the device is already enrolled and the recovery key has not yet escrowed to Entra ID. Brand-new Autopilot devices have nothing to lose because BitLocker has not been provisioned yet. For already-enrolled devices, check the recovery key is visible under the device record in Entra before you clear the TPM.
Can I use Autopilot pre-provisioning (white glove) to work around this?
White glove uses the exact same MDM enrollment flow, so if you have a 0x80180014 problem on regular Autopilot you will have the same problem in white glove — possibly with a different error code surfaced to the technician. Fix the root cause first.
Is this error different from 0x801c03ed or 0x80004005?
Yes, all three are MDM-related but they fail at different stages. 0x801c03ed means the device is already enrolled to a different tenant (common with refurbished hardware). 0x80004005 is a generic COM error usually caused by a corrupted enrollment registry key. 0x80180014 is specifically the authentication handshake failing, which is why the four fixes above all centre on identity, licensing, and device record integrity.
Closing
The reason 0x80180014 feels infuriating is that the OOBE screen blames the user's sign-in, but the actual failure is almost always somewhere in your tenant configuration. Pull the IME log, find out whether you are looking at an HTTP 401 or a missing device record, and apply the matching fix. Twelve Dells back in March, three Surfaces in April, and one Hyper-V test rig last week — same playbook every time, and it has not failed me yet.
