Fix Autopilot TPM Attestation Error 0x81039024 on Windows 11 During Pre-Provisioning

If Windows Autopilot stops at Securing your hardware and throws 0x81039024, do not waste the first hour on ESP app targeting, device cleanup scripts, or a blind wipe-and-retry loop.

Microsoft’s Autopilot known-issues documentation is unusually direct here. 0x81039024 means known vulnerabilities were detected with the TPM, so TPM attestation fails. In other words, this is a hardware trust problem first. Until the TPM firmware is corrected, the device cannot prove itself well enough for the Autopilot flow that depends on attestation.

That is why this code hurts most in pre-provisioning and self-deploying mode. Both deployment paths depend on TPM 2.0 attestation before the device can continue without a normal user-led setup path.

Quick Fix Checklist

Work this list in order before you reset the device:

1. Confirm the visible code is 0x81039024 and that the failure happened during Securing your hardware.

2. Confirm the deployment mode is Windows Autopilot pre-provisioning or self-deploying mode.

3. From the failure screen, press Shift + F10 and collect diagnostics before changing anything:

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

4. Check the TPM state immediately:

   Get-Tpm | Format-List *
   tpmtool getdeviceinformation

5. Record the device model, BIOS/UEFI version, TPM manufacturer, and TPM firmware version.

6. Update BIOS/UEFI and TPM firmware from the OEM or device manufacturer.

7. Retest one pilot device after the firmware update instead of reimaging the whole batch.

8. If the same model still fails, escalate it as a model-and-firmware issue, not a random enrollment incident.

What Error 0x81039024 Actually Means

Microsoft lists 0x81039024 on the current Windows Autopilot known issues page with this meaning:

Some devices might fail TPM attestation on Windows 11 during the pre-provisioning technician flow or self-deployment mode with the error code 0x81039024. This error code indicates that there are known vulnerabilities detected with the TPM and as a result attestation fails. If this error occurs, visit the PC manufacturer's website to update the TPM firmware.

That wording matters because it separates this failure from other Autopilot hardware-stage errors:

• 0x800705B4 usually points to a timeout, often when the device is not suitable for the self-deploying path or the attestation flow cannot complete at all.
• 0x81039001 means the Autopilot client exhausted TPM attestation retries.
• 0x801C03F3 is a different pre-provisioning failure tied to a missing Entra device object.
• 0x81039024 specifically means Windows detected TPM vulnerabilities and blocked attestation.

So when this code appears, the safest assumption is not “Intune is broken.” The safer assumption is the TPM trust chain on this hardware is not acceptable in its current firmware state.

Root Cause

Pre-provisioning and self-deploying mode both rely on the device TPM to establish trusted identity during Autopilot. Microsoft’s self-deploying mode and pre-provisioning documentation both say these paths require:

• a physical device
• TPM 2.0
• TPM device attestation
• access to the TPM attestation HTTPS endpoints, including the *.microsoftaik.azure.net pattern and vendor-specific certificate endpoints

When the platform reports 0x81039024, the TPM is present, but attestation is blocked because known TPM vulnerabilities were detected. In practical terms, the usual causes are:

• outdated TPM firmware
• outdated BIOS/UEFI package that still ships the vulnerable TPM state
• a model family with a known TPM issue that has not yet been remediated in your estate
• inconsistent firmware baselines across the same hardware model

This is why rebuilding the Autopilot profile, changing Win32 app assignments, or increasing ESP patience almost never changes the outcome. The failure happens earlier, during device trust validation.

Why It Shows Up in Pre-Provisioning and Self-Deploying Mode

Microsoft states that both self-deploying mode and pre-provisioning require TPM 2.0 attestation. These flows are designed to let the device continue with little or no user interaction.

That advantage becomes the weakness when the TPM is not trusted. In a user-driven deployment, you might get farther into the workflow before seeing another symptom. In pre-provisioning or self-deploying mode, the device must pass the hardware trust check up front, so the failure is immediate and repeatable.

If you are imaging shared devices, kiosks, frontline carts, or bench-built laptops, one bad TPM firmware baseline can stall an entire wave.

Logs and Where to Check

1. Collect the Autopilot and TPM CAB first

At the failure screen:

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

Copy that CAB off the machine before you wipe anything.

2. Check the Autopilot event log

Microsoft’s Autopilot troubleshooting FAQ says these event IDs matter for TPM attestation:

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

Pull the events with PowerShell:

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

If you see 171 and 172 clustered around the same timestamp as 0x81039024, that confirms the failure is at the attestation stage and not later in enrollment.

3. Check TPM health directly

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Record at least:

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

4. Verify the deployment mode

In Intune admin center, confirm the device really uses the mode you think it uses:

Devices > Windows > Windows enrollment > Deployment profiles

Check whether the device is assigned to:

• self-deploying mode, or
• pre-provisioning on top of a user-driven profile

That distinction matters because 0x81039024 is documented specifically against attestation-dependent flows.

5. Verify attestation networking if firmware updates do not help

Microsoft’s Autopilot requirements page says the TPM attestation process needs access to vendor and Microsoft endpoints, including:

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

If one site or VLAN is blocking those endpoints, a firmware problem can look worse than it really is. Check network filtering only after you have validated firmware, not before.

PowerShell and Graph Commands

Pull device-side evidence fast

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

dsregcmd /status

dsregcmd will not decode the TPM vulnerability for you, but it helps confirm whether the device ever moved beyond the expected hardware trust stage.

Check the Autopilot object in Graph

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

$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 correcting records

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

These Graph steps do not fix 0x81039024 by themselves, but they help you rule out stale registration data once firmware is corrected.

Remediation Workflow That Actually Works

Step 1: Capture one clean failed sample

Do not start by wiping six machines. Capture one full evidence set from one failed device first:

• CAB from Mdmdiagnosticstool
• event IDs 171 and 172
• Get-Tpm output
• tpmtool getdeviceinformation
• BIOS and TPM firmware version

That gives you a baseline you can compare after firmware remediation.

Step 2: Update BIOS/UEFI and TPM firmware from the OEM

Microsoft’s own guidance for 0x81039024 is to visit the PC manufacturer’s website to update the TPM firmware.

In enterprise terms, that usually means:

• Dell: Dell Command Update / enterprise BIOS catalog process
• HP: HP Image Assistant / enterprise firmware workflow
• Lenovo: Lenovo Commercial Vantage / Update Retriever / enterprise catalog

If the vendor bundles TPM updates inside a BIOS or platform firmware package, deploy the package exactly as the OEM documents it.

Step 3: Retest only one pilot device

After the firmware update:

1. Reboot fully.
2. Re-check Get-Tpm and tpmtool getdeviceinformation.
3. Retry Autopilot on one pilot device.
4. If it passes, move to the rest of that hardware model.

This is the moment to avoid a classic rollout mistake: assuming one success means every warehouse device is identical. Validate the same firmware baseline on all affected models first.

Step 4: Separate firmware problems from registration problems

If the device still fails after firmware remediation, then verify the cloud-side record:

• serial number matches the physical device
• Autopilot identity is correct
• deployment profile assignment is correct
• the device is not being reused with a stale record from a previous deployment path

If you are reusing hardware, remember that old self-deploying and pre-provisioning records can create different failures like 0x80180014. Do not mix those up with 0x81039024.

Step 5: Escalate by model, not by ticket

If three devices of the same model show the same TPM firmware family and the same 0x81039024 outcome, stop handling them as unrelated incidents. Build a simple matrix:

Device	Model	BIOS	TPM vendor	TPM firmware	Result
Device 1					Failed 0x81039024
Device 2					Failed 0x81039024
Device 3					Passed after firmware update

That is the evidence your OEM or endpoint engineering team actually needs.

What Not to Waste Time On

These are common but low-yield reactions for this exact code:

• removing Win32 blocking apps from ESP
• changing compliance policies first
• rebuilding the Intune Connector for AD
• deleting and reimporting every Autopilot device before checking TPM firmware
• treating the issue like a generic network timeout
• assuming it is the same problem as 0x81039001

0x81039024 is more specific than that. Microsoft is telling you the TPM itself is the blocking factor.

Prevention

Use this as a durable operating rule for Autopilot hardware readiness:

1. Add TPM firmware version to your standard Autopilot certification checklist.
2. Test pre-provisioning and self-deploying mode on every new hardware model before broad rollout.
3. Keep BIOS and TPM firmware baselines aligned across warehouse, OEM, and field inventory.
4. Verify access to TPM attestation endpoints in any staging VLAN, imaging lab, or OEM provisioning network.
5. When one model shows repeated 0x81039024 failures, quarantine that model from attestation-dependent deployment modes until the firmware baseline is corrected.

Conclusion

0x81039024 in Windows Autopilot is not a vague enrollment glitch. It is Windows telling you TPM attestation failed because known TPM vulnerabilities were detected. The fastest path to resolution is to collect diagnostics, confirm the TPM and firmware state, update TPM firmware from the device manufacturer, and then retest one pilot device before reopening the rollout.

If you fix the firmware baseline, this error usually stops looking random very quickly.