Fix Autopilot TPM Attestation Error 0x81039001 During Pre-Provisioning

A device that fails Windows Autopilot at Securing your hardware with 0x81039001 is not failing because the Enrollment Status Page is slow. It is failing before the deployment can trust the device hardware.

Microsoft documents this code as:

0x81039001 E_AUTOPILOT_CLIENT_TPM_MAX_ATTESTATION_RETRY_EXCEEDED

In practical terms, the Autopilot client tried TPM attestation too many times and gave up. You usually see it during pre-provisioning technician flow or self-deploying mode, because those scenarios depend on TPM attestation to prove the device identity without a normal user-driven sign-in path.

Quick Fix Checklist

Work this list in order. Do not wipe the device until you have collected the logs.

Confirm the scenario. 0x81039001 matters most in Autopilot pre-provisioning and self-deploying mode. If this is user-driven Autopilot, confirm the visible error is not a later ESP app, policy, or account setup failure.

Collect Autopilot + TPM diagnostics before reset. At the failure screen, press Shift + F10 and run:

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

Retry once after a clean reboot. Microsoft notes that later attempts can succeed because this failure can be intermittent. Do not loop forever; one controlled retry is enough data.
Check firmware and TPM vendor. Update BIOS/UEFI and TPM firmware from the OEM. Pay extra attention to models using newer STMicro, Nuvoton, or older AMD firmware TPM implementations.
Verify TPM 2.0 state from Windows PE/OOBE. Run:
```
Get-Tpm
tpmtool getdeviceinformation
```
If TPM is missing, disabled, not owned correctly, or stuck in a bad state, fix firmware/UEFI first.
Confirm the device is correctly registered in Autopilot. Check the serial number and hardware hash in Intune. A stale or mismatched Autopilot object can make TPM issues look like random enrollment failures.
Move blocked devices to user-driven mode if you need same-day deployment. Self-deploying and pre-provisioning need TPM attestation. User-driven Autopilot is often the fastest workaround while the OEM firmware issue is escalated.
Escalate repeat failures by model and TPM vendor, not by individual ticket. If multiple devices of the same model fail at Securing your hardware, treat it as a firmware or OEM platform issue until proven otherwise.

Root Cause

Autopilot TPM attestation is the process where Windows proves to the cloud service that the local TPM is genuine and bound to that device. Pre-provisioning and self-deploying mode use that proof to continue without relying on a normal interactive user sign-in.

0x81039001 means the Autopilot client exhausted the TPM attestation retry limit. Common causes:

Intermittent attestation service or network failure during OOBE.
Outdated BIOS, UEFI, or TPM firmware that cannot complete the attestation flow reliably.
Known TPM vendor/platform behavior, including Microsoft-documented issues affecting some STMicro and Nuvoton TPMs that support RSA 3072-bit, and older AMD ASP fTPM firmware issues.
Unsupported hardware path, such as trying self-deploying mode on a VM or on hardware that is not TPM 2.0 capable.
Device registration mismatch, where the Autopilot object, serial number, or hardware hash no longer matches the physical machine.
TPM state problems after motherboard replacement, refurbishing, imaging, or previous enrollment attempts.

The key point: this is a hardware trust failure during the Autopilot device phase. Rebuilding Intune app assignments or changing ESP timeout values will not fix it.

Logs and Where to Check

On the failed device during OOBE

At the error page, press Shift + F10 and collect the CAB:

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

Copy the CAB off the device before wiping it:

notepad.exe

Use File > Open in Notepad as a quick file browser if you need to copy the CAB to USB from OOBE.

Inside the CAB, check these logs first:

Location	What to look for
`Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot`	Event ID `171`: `AutopilotManager failed to set TPM identity confirmed`. Event ID `172` often follows because the Autopilot profile cannot be marked available.
`Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin`	MDM enrollment state and policy handoff failures around the same timestamp.
`Microsoft-Windows-User Device Registration/Admin`	Entra device registration or join errors if the flow advanced past attestation.
`TPM` diagnostics in the CAB	TPM health, manufacturer data, attestation attempt failures.

Also capture the TPM state:

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Useful fields to record in the ticket:

Manufacturer and manufacturer version
TPM spec version
Whether TPM is present, enabled, activated, and ready
Device model and BIOS version
Autopilot profile type: self-deploying, pre-provisioning, or user-driven
Whether the failure is repeatable on the same model

In Intune admin center

Check:

Devices > Windows > Windows enrollment > Devices
Search the serial number.
Confirm the device has the expected Autopilot profile assigned.
Confirm the profile type matches the intended scenario.
Check the Autopilot deployments report for whether the failure is always at the hardware/security step.

If the object looks stale, do not immediately delete it in production. First export the hardware hash and record the current Autopilot identity ID so you can prove what changed.

PowerShell and Graph Commands

Install and connect to Microsoft Graph if needed:

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

Find the Autopilot object by serial number:

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

Trigger an Autopilot sync after importing or correcting devices:

Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotSettings/sync"

If the device object is genuinely stale and you have approval to re-register it, remove the Autopilot identity, then re-import the hardware hash:

# Confirm before deleting. This removes the Autopilot identity from Intune.
$AutopilotId = $Device.Id
Invoke-MgGraphRequest -Method DELETE -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeviceIdentities/$AutopilotId"

On the device, export a fresh hardware hash from OOBE or full Windows:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Install-Script Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo.ps1 -OutputFile C:\Temp\AutopilotHWID.csv

Then import the CSV in Intune or with your normal Autopilot registration automation.

Remediation Workflow

1. Separate intermittent failures from model-wide failures

If one device fails once and then succeeds on the next attempt, record it and move on. Microsoft notes that subsequent attempts can resolve 0x81039001.

If the same model fails repeatedly, stop treating this like a helpdesk incident. Build a small table:

Device	Model	BIOS	TPM vendor	TPM firmware	Result
Device 1					Failed `0x81039001`
Device 2					Passed after BIOS update
Device 3					Failed again

That table is what your OEM support case needs.

2. Update BIOS and TPM firmware

For repeat failures, update firmware before changing Intune configuration.

Dell: use Dell Command Update, Dell Repository Manager, or your enterprise BIOS deployment workflow.
HP: use HP Image Assistant or HP Connect for Microsoft Endpoint Manager.
Lenovo: use Lenovo Commercial Vantage, Update Retriever, or your enterprise update process.

After firmware update:

Reboot fully.
Confirm TPM status with Get-Tpm and tpmtool getdeviceinformation.
Retry pre-provisioning once.
If it still fails, collect a new CAB so you have before/after evidence.

3. Reset TPM only when you understand the impact

Clearing TPM can remove keys used by BitLocker, Windows Hello for Business, certificates, and other security features. On a brand-new device at OOBE, this is lower risk. On a repurposed or active device, it can create a recovery incident.

For a new device with no user data and no production BitLocker dependency:

Clear-Tpm
shutdown /r /t 0

If the device has ever been in production, suspend BitLocker and back up recovery keys before touching TPM state.

4. Re-register Autopilot when the hardware identity is suspect

Re-registration is appropriate after:

Motherboard replacement
Refurbished device intake
Serial number mismatch
Hardware hash imported from the wrong machine
Manual deletion of Entra or Intune objects without cleaning Autopilot

Clean up in this order:

Retire/delete the Intune managed device record if present.
Delete the stale Autopilot identity after approval.
Remove stale Entra device objects if they are orphaned.
Import a fresh hardware hash.
Sync Autopilot.
Assign the correct profile and wait for assignment status to complete.

5. Use user-driven mode as the operational workaround

If a shipment is blocked and firmware remediation is not available today, switch the affected model to user-driven Autopilot for the current deployment wave.

This is not a perfect replacement for self-deploying mode, but it avoids the TPM attestation dependency that blocks the device at Securing your hardware. Document the exception and move the model back only after OEM firmware is validated.

What Not to Waste Time On

These changes usually do not fix 0x81039001:

Increasing ESP timeout
Removing Win32 apps from the blocking list
Rebuilding compliance policies
Changing update rings
Reassigning unrelated configuration profiles
Reinstalling the Intune Management Extension

Those are useful for later ESP failures. This error happens earlier, at hardware attestation.

Prevention

Add TPM attestation to your Autopilot model certification

Before approving a new laptop model for enterprise purchase, test:

User-driven Autopilot
Pre-provisioning technician flow
Self-deploying mode if you use kiosks/shared devices
BIOS current version and one previous version
Wired and Wi-Fi OOBE paths
Factory image and clean Microsoft media if your OEM supports both

Do not certify the model until pre-provisioning passes twice from a clean reset.

Track TPM vendor in your hardware readiness report

For each approved model, record:

Manufacturer
Model
BIOS baseline
TPM manufacturer
TPM firmware version
Autopilot mode validated
Known exceptions

This turns the next 0x81039001 wave from guesswork into a model-specific remediation task.

Keep an emergency fallback profile

Maintain a small, documented user-driven Autopilot profile for break-glass deployment. Scope it carefully and use it only when pre-provisioning or self-deploying mode is blocked by firmware or attestation issues.

Watch Microsoft known issues and OEM advisories

Microsoft has documented multiple TPM attestation issues over time, including intermittent 0x81039001, AMD fTPM firmware problems, and STMicro/Nuvoton TPM behavior on newer platforms. Your OEM firmware bulletin is often the actual fix, but Microsoft Learn is where the Autopilot symptom usually appears first.

Final Triage Pattern

If you only remember one workflow, use this:

Failure at Securing your hardware + 0x81039001 = TPM attestation path.
Collect Mdmdiagnosticstool.exe -area Autopilot;TPM CAB.
Check Autopilot Event ID 171 and TPM manufacturer/version.
Retry once.
Update BIOS/TPM firmware.
Re-register only if the Autopilot identity is stale or hardware changed.
Use user-driven mode as the temporary deployment workaround.

That sequence fixes the common cases and gives you enough evidence to escalate the real firmware cases without wasting days on ESP policy changes.

References

Microsoft Learn: Windows Autopilot known issues
Microsoft Learn: Windows Autopilot troubleshooting FAQ
Microsoft Learn: Collect MDM logs with Mdmdiagnosticstool.exe