Fix Autopilot TPM Attestation Error 0x81039023 During Pre-Provisioning or Self-Deploying Mode

If Windows Autopilot stops during Securing your hardware and throws 0x81039023, start by checking the Windows build on the device before you burn time on ESP tuning, profile reassignment, or device cleanup.

Microsoft documents this code as a TPM attestation failure on Windows 11 that can hit pre-provisioning technician flow and self-deploying mode. Microsoft also gives a very specific fix: apply the May 2022 cumulative update for Windows 11 version 21H2, KB5013943 (OS build 22000.675) or later.

That makes 0x81039023 different from the newer Autopilot attestation codes that point to TPM vulnerabilities or retry exhaustion. This one is strongly tied to an outdated Windows 11 base image or unpatched device state on attestation-dependent Autopilot flows.

Quick Fix Checklist

Work the problem in this order:

1. Confirm the exact code is 0x81039023.

2. Confirm the failure happened in pre-provisioning or self-deploying mode.

3. Check the local Windows build. If the device is on Windows 11 21H2 below 22000.675, you already have the most likely root cause.

4. Capture diagnostics before making changes:

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

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

6. If you are using self-deploying mode, verify the hardware is a physical device with TPM 2.0. Virtual machines are not supported.

7. Make sure the network path allows the TPM attestation endpoints, including *.microsoftaik.azure.net and the vendor certificate URLs.

8. Update the device to Windows 11 21H2 22000.675 or later, or rebuild from current supported media if the image is stale.

9. Retest one pilot device before retrying a full batch.

What Error 0x81039023 Actually Means

Microsoft’s current Windows Autopilot known issues page describes 0x81039023 like this:

Some devices might fail TPM attestation on Windows 11 during the pre-provisioning technician flow or self-deployment mode with the error code 0x81039023. To resolve the issue, apply the May 2022 cumulative update for Windows 11, version 21H2 KB5013943 or later to the device.

That wording matters because it narrows the problem:

• the failure is at the TPM attestation stage
• the affected flows are pre-provisioning and self-deploying mode
• the published fix is OS update level, not profile redesign or Intune-side reassignment

In other words, if you are seeing this code, treat it as a device-state and build-baseline issue first.

Why It Appears in Pre-Provisioning and Self-Deploying Mode

Microsoft’s Autopilot documentation says both pre-provisioning and self-deploying mode rely on TPM 2.0 and device attestation.

The pre-provisioning documentation states that physical devices must support TPM 2.0 and device attestation, and that the process uses self-deploying capabilities under the hood. The self-deploying documentation is even more direct: the mode uses a device’s TPM 2.0 hardware to authenticate the device into the Microsoft Entra tenant, and devices must support TPM device attestation.

That design is the reason the failure appears early.

In user-driven Autopilot, you can sometimes reach later stages before a separate issue becomes visible. In pre-provisioning and self-deploying mode, the device has to pass the attestation gate up front. If the OS image is too old or the attestation path is incomplete, the deployment stops before your normal Intune troubleshooting playbook becomes relevant.

For many admins, this shows up in one of three patterns:

• old OEM or lab stock shipped with an early Windows 11 21H2 build
• a bench image was captured from outdated media and reused too long
• a device was reset into Autopilot without first bringing the OS to a supported patch level

Root Cause: Usually an Outdated Windows 11 Baseline

The official Microsoft fix is tied to Windows 11 21H2 KB5013943 / build 22000.675 or later. That is the core clue.

If a device still uses pre-22000.675 Windows 11 21H2 media during a self-deploying or pre-provisioning attempt, the TPM attestation step can fail with 0x81039023.

That does not mean every device with 0x81039023 is only missing one monthly update. In practice, you should think in terms of baseline health:

• Is the device still on an old 21H2 image?
• Is the OEM recovery image stale?
• Was the machine factory-reset into an outdated build?
• Are you using older task-sequence or provisioning media in your staging area?

If the answer to any of those is yes, do not keep changing Intune assignments and expecting a different result.

Also separate 0x81039023 from nearby codes:

• 0x800705B4 usually maps to an attestation timeout, often when the device or scenario is unsuitable for the self-deploying path.
• 0x81039001 means the client exhausted TPM attestation retries.
• 0x81039024 points to known TPM vulnerabilities and usually requires TPM firmware remediation.
• 0x801C03F3 is a different pre-provisioning failure tied to a deleted Microsoft Entra device object.

With 0x81039023, the first question is usually not “what changed in Intune?” It is “what Windows build is this machine actually on?”

Logs and Where to Check

1. Capture the diagnostic CAB first

Before you wipe or reseal the device:

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

Export that CAB and keep it with the ticket. It gives you a clean before-state if the issue spreads across a model batch.

2. Check the Autopilot event log for event IDs 171 and 172

Microsoft’s Autopilot troubleshooting FAQ lists these event IDs as the key attestation signals:

• 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 evidence directly:

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

If 171 and 172 appear at the same time as 0x81039023, you are dealing with the attestation stage, not a later app or policy failure.

3. Check the local Windows build

This is the check that saves the most time:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Or:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

For Windows 11 21H2, Microsoft’s published fix target is build 22000.675 or later.

If you are below that build, the remediation path is straightforward: update the OS before retrying Autopilot.

4. Verify the deployment mode

Confirm whether the device is using:

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

That matters because Microsoft documents 0x81039023 specifically against those attestation-heavy flows.

5. Check TPM and attestation prerequisites

Even though outdated OS level is the main published fix, validate the platform so you do not miss a second problem:

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Capture:

• TPM present / enabled / activated / ready
• TPM manufacturer
• firmware version
• device model
• BIOS or UEFI version

Network Checks That Still Matter

Do the OS-build check first, but do not ignore networking.

Microsoft’s Autopilot requirements page says the TPM attestation process requires access to HTTPS URLs that are unique to the TPM provider. Microsoft specifically says to allow:

• *.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 those endpoints are blocked by proxy rules, captive network controls, or restrictive staging VLAN policies, the symptoms can look like a device problem even after you update the build.

Microsoft also notes that proxy settings for Autopilot should be configured on the proxy server itself. Pushing proxy settings later by Intune policy is not a reliable fix for privileged early-deployment stages.

Practical Remediation Workflow

Step 1: Prove the build level

On one failed machine, record the build and UBR. If it is Windows 11 21H2 below 22000.675, stop there and correct the baseline.

Step 2: Update or rebuild from current media

Use one of these routes:

• install the required cumulative update if the device can be serviced directly
• use newer OEM media
• rebuild from current supported Windows 11 media before staging again
• refresh stale recovery or task-sequence content in the lab

For enterprise teams, the better long-term fix is usually removing old staging media from circulation, not patching one device at a time forever.

Step 3: Validate one device on the same model family

After remediation, retry one device first. Watch the same Autopilot log for the absence of repeated 171 and 172 errors.

Step 4: Validate network path if the code persists

If the machine is now on a compliant build and still fails, check whether the attestation URLs are reachable from the exact provisioning network.

A fast validation pattern from Shift + F10 is:

nslookup microsoftaik.azure.net
Test-NetConnection ekop.intel.com -Port 443
Test-NetConnection ekcert.spserv.microsoft.com -Port 443
Test-NetConnection ftpm.amd.com -Port 443

Not every device needs every vendor endpoint, but blocked outbound HTTPS to the needed provider is a real deployment breaker.

Step 5: Re-check that the scenario is supported

Microsoft says self-deploying mode is only supported for Microsoft Entra join devices. It is also limited to physical devices with TPM 2.0. If someone is testing in a VM or expecting self-deploying mode to behave like hybrid join, fix the scenario before reopening the Autopilot profile.

What Not to Do

When 0x81039023 appears, these are common time-wasters:

• repeatedly deleting and reimporting the Autopilot record without checking the build
• troubleshooting Win32 apps or ESP blocking apps before attestation is healthy
• blaming hybrid join connector issues when the device has not even passed TPM identity confirmation
• validating Intune assignments only, while the staging image remains old
• testing from a VM and expecting self-deploying mode to work

Those steps can be useful in other Autopilot incidents. They are just not the first move for this code.

Limitations and Caveats

A few caveats matter here:

• Microsoft’s published fix specifically names Windows 11 version 21H2 and KB5013943 / 22000.675 or later. If your environment uses newer supported builds, this exact code usually points to old media, old recovery state, or a stale bench process rather than a brand-new tenant-side issue.
• Pre-provisioning and self-deploying mode are more sensitive to TPM attestation prerequisites than normal user-driven flows.
• You can have two problems at once. An old build may be the first blocker, and a locked-down provisioning network may be the second.
• If you are using self-deploying mode, remember that Microsoft documents it as not supported for Microsoft Entra hybrid join.

Conclusion

0x81039023 is one of the cleaner Autopilot failure codes once you read Microsoft’s current wording closely.

It is a TPM attestation failure on Windows 11 that Microsoft ties to pre-provisioning and self-deploying mode, with a published fix of Windows 11 21H2 KB5013943 / build 22000.675 or later.

So the fastest path is usually:

1. prove the exact code
2. prove the deployment mode
3. prove the local OS build
4. update or replace stale media
5. confirm the attestation network path

If you treat 0x81039023 as an image-baseline problem first and an Intune-profile problem second, you will usually get to root cause much faster.