Fix Autopilot Self-Deploying Mode Error 0x801C03EA During TPM Attestation

If Windows Autopilot self-deploying mode fails with 0x801C03EA, do not start by rebuilding the profile, deleting app assignments, or blaming Enrollment Status Page timing. Microsoft’s current Windows Autopilot known issues page is clear: this code means TPM attestation failed, causing Microsoft Entra join to fail with a device token.

That matters because this is a hardware trust and deployment-path problem first. In self-deploying mode, the device has to prove itself without a normal user sign-in. If the TPM attestation step breaks, the entire join flow stops before Intune can do anything useful with apps or policy.

This is why the code shows up most often in kiosks, shared PCs, digital signage, frontline terminals, and bench-built devices. Those are exactly the scenarios where self-deploying mode is attractive, and exactly the scenarios where TPM attestation is non-negotiable.

Quick fix checklist

Use this order before you wipe the device again:

1. Confirm the deployment is really self-deploying mode.

2. Confirm the visible code is 0x801C03EA and not 0x800705B4, 0x81039001, or 0xC1036501.

3. Collect diagnostics from the failure screen before changing anything:

   mkdir C:\Temp -Force
   Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\autopilot-0x801c03ea.cab

4. Pull the Autopilot event log and look for event IDs 171 and 172.

5. Verify the device is a physical device with TPM 2.0. Self-deploying mode is not supported on VMs, including Hyper-V virtual TPM scenarios.

6. Check whether the device can reach the TPM attestation endpoints required by Microsoft and the TPM vendor.

7. Sync the system clock if the device time is off.

8. Update BIOS/UEFI and TPM firmware if the model is behind.

9. Retest one pilot device only after you confirm network, time, and firmware.

If ten kiosks are failing the same way, fix one model path first. Do not burn the whole rollout window reimaging identical devices against the same broken attestation path.

What error 0x801C03EA actually means

Microsoft lists 0x801C03EA in the Windows Autopilot known issues page under Windows Autopilot self-deploying mode fails with an error code with this description:

This error indicates that TPM attestation failed, causing a failure to join Microsoft Entra ID with a device token.

That wording separates this failure from the other common self-deploying mode errors:

• 0x800705B4 usually points to a timeout, commonly because the device is not suitable for self-deploying mode, such as a VM or hardware without valid TPM 2.0 support.
• 0xC1036501 means Microsoft Entra automatic MDM enrollment is conflicted by multiple MDM configurations.
• 0x801C03EA means the device never completed the TPM trust step needed for self-deploying mode.

So when this code appears, the first question is not “what changed in Intune policy?” The first question is “why did TPM attestation fail on this device, on this network, at this moment?”

Why this code breaks self-deploying mode so early

Microsoft’s Windows Autopilot self-deploying mode documentation says the process depends on:

• a physical device
• TPM 2.0
• TPM device attestation
• access to a set of HTTPS attestation endpoints used by Microsoft and the TPM provider

Self-deploying mode uses the TPM to authenticate the device into the organization’s Microsoft Entra tenant without a user credential prompt. If the device cannot complete that attestation, Microsoft Entra join does not finish, and automatic Intune enrollment never gets a chance to stabilize.

That is why 0x801C03EA tends to look harsh and immediate. It usually fails before the deployment feels “in progress” to the admin watching the screen.

Root causes that matter in real environments

Microsoft’s official description for 0x801C03EA is short, but the surrounding Autopilot documentation gives enough context to build a practical troubleshooting workflow.

1. The device is not a valid self-deploying candidate

Microsoft states that self-deploying mode requires TPM 2.0 and that devices without TPM 2.0 support cannot use this path. Microsoft also explicitly says deployments attempted on virtual machines fail in this mode, including Hyper-V virtual TPM scenarios.

If your bench image or lab validation is happening in a VM, stop there. That is the wrong test path.

2. TPM attestation endpoints are blocked or intercepted

Microsoft’s Autopilot requirements page says self-deploying mode and pre-provisioning require access to attestation URLs, including:

• *.microsoftaik.azure.net
• Intel: https://ekop.intel.com/ekcertservice
• Qualcomm: https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1
• AMD: https://ftpm.amd.com/pki/aia

If a proxy, SSL inspection device, captive network rule, or filtered VLAN blocks those calls, the TPM may be fine but the attestation flow still fails.

3. The system clock is far enough off to break trust

Microsoft also documents a separate Autopilot known issue where provisioning can fail because the real-time clock is off by several minutes or more. Microsoft’s fix there is simple:

w32tm /resync /force

That issue is broader than 0x801C03EA, but it is directly relevant because TPM attestation and cloud trust are time-sensitive. On devices fresh from storage, a bad RTC can produce confusing early-stage failures.

4. TPM or BIOS firmware is outdated

Microsoft’s Autopilot known issues and requirements content repeatedly reinforce that self-deploying mode depends on a healthy attestation path. If the device model is behind on BIOS or TPM firmware, you can get repeated attestation failures even though the device technically has TPM 2.0.

This is especially likely when:

• one model fails while newer hardware passes
• failures cluster on a specific OEM platform
• the same device family recently had a motherboard swap, BIOS rollback, or depot repair
• the issue appears after moving devices to a more locked-down provisioning network

Logs and where to check

Collect the Autopilot CAB first

From the failure screen, collect the diagnostic CAB before a reset:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\autopilot-0x801c03ea.cab

This is the cleanest artifact to preserve when you need to compare multiple failures or hand evidence to another admin.

Check the Autopilot event log

Microsoft’s troubleshooting FAQ says these event IDs matter for TPM attestation in self-deploying mode:

• 171 — AutopilotManager failed to set TPM identity confirmed. HRESULT=[error code].
• 172 — AutopilotManager failed to set Autopilot profile as available. HRESULT=[error code].

Pull them with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Where-Object { $_.Id -in 171,172,807,809,815 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If 171 and 172 line up with the failure timestamp, you are looking at an attestation-stage break, not a later policy or enrollment problem.

Check device registration state

dsregcmd /status

dsregcmd will not decode the attestation failure for you, but it helps confirm whether the device got far enough into Microsoft Entra registration to create partial state.

Check the TPM locally

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Record at least:

• TPM manufacturer
• TPM spec version
• firmware or manufacturer version
• whether TPM is present, enabled, activated, and ready
• BIOS/UEFI version
• device model

Verify the profile assignment

In Intune admin center > Devices > Windows > Windows enrollment > Deployment profiles, confirm the device is actually assigned a self-deploying mode profile.

That sounds obvious, but it matters. If the device is really in another Autopilot flow, the visible failure might point you in the wrong direction.

Practical remediation workflow

Step 1: Prove the mode and the code

Start by confirming this is a self-deploying deployment and the code is 0x801C03EA. Microsoft uses different error meanings for nearby Autopilot scenarios, so sloppy classification wastes time.

Step 2: Rule out unsupported platform paths

If the device is a VM, stop. Microsoft explicitly says self-deploying mode is unsupported there. Move the test to physical hardware.

If the device is physical, verify TPM 2.0 really exists and is ready.

Step 3: Fix time before deeper resets

If the device clock is wrong at OOBE, correct it first:

w32tm /resync /force

Then retry the attestation path. This is a fast check, and it avoids chasing policy ghosts when the trust problem is really time drift.

Step 4: Validate network reachability for attestation

Have the network team verify that the provisioning segment allows outbound access to:

• *.microsoftaik.azure.net
• Intel EK certificate service
• Qualcomm EK certificate service
• AMD fTPM certificate endpoint

Also confirm that proxy behavior is enforced on the network side, not via half-applied device policy during Autopilot. Microsoft warns that Intune-delivered proxy settings are not a reliable way to support privileged Autopilot deployment paths.

Step 5: Update BIOS and TPM firmware

If the device model is on an older BIOS or TPM package, update it using the OEM’s enterprise tooling. Do not assume Windows Update has already handled this. For many models, TPM fixes ride inside broader firmware packages.

Step 6: Retest one known-failing device

After correcting time, network, or firmware, retest one affected device. Watch what changes:

• If 0x801C03EA disappears, you fixed the attestation blocker.
• If the device now fails with 0xC1036501, you exposed the next tenant-side issue.
• If the device now fails with 0x800705B4, revisit whether the hardware path or deployment mode is valid.

That is real progress. One clean root cause at a time is how you get a rollout moving again.

PowerShell and Graph commands that help

Pull local Autopilot evidence

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

Capture TPM state

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Verify the Autopilot device record in Graph

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
Select-MgProfile -Name beta

$Serial = "YOUR-SERIAL-NUMBER"
Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "serialNumber eq '$Serial'" |
  Format-List Id,SerialNumber,Manufacturer,Model,DeploymentProfileAssignmentStatus,EnrollmentState

Graph will not fix TPM attestation, but it helps rule out a stale or misassigned Autopilot record before you touch more hardware.

What not to waste time on

For this exact code, these are usually low-yield moves:

• deleting Win32 app assignments first
• changing ESP blocking-app configuration first
• rotating through random Autopilot profile settings
• reimporting hardware hashes before checking time, firmware, and attestation reachability
• wiping ten devices at once before one pilot retest succeeds

Those actions may be useful for other Autopilot failures. They are rarely the first fix for 0x801C03EA.

Limitations and caveats

A few realities matter here:

• Microsoft’s official description for 0x801C03EA is accurate but brief. You still have to do the local work to identify whether the actual blocker is unsupported hardware, time drift, network filtering, or firmware.
• The same tenant can have more than one failure at once. After attestation is fixed, another issue may appear underneath it.
• Some OEM-specific TPM failures only become obvious when you compare several devices of the same model side by side.
• If the device was recently repaired or had a motherboard replacement, expect TPM and registration history to deserve extra scrutiny.

Prevention

To reduce repeat incidents:

1. Validate self-deploying mode only on physical devices.
2. Keep a standard preflight for kiosks and shared PCs that checks time, firmware, and network egress before mass enrollment.
3. Maintain model-based firmware baselines instead of assuming all TPM 2.0 devices behave the same.
4. Test attestation-sensitive deployments on the actual provisioning VLAN, not a friendlier admin subnet.
5. Save one good evidence pack for each failing model so you can compare before and after remediation.

Conclusion

0x801C03EA in Windows Autopilot self-deploying mode means the device failed the TPM attestation step needed to join Microsoft Entra with a device token. The fastest path to resolution is to treat it as a trust-path incident: confirm the mode, collect event IDs 171/172, verify physical TPM 2.0 hardware, check attestation endpoint reachability, correct time drift, update firmware, and retest one pilot device. When you handle it in that order, you stop guessing and start narrowing the failure to something you can actually fix.