Fix Autopilot TPM Attestation Failures on ST Micro and Nuvoton TPMs During Pre-Provisioning or Self-Deploying Mode

If Windows Autopilot keeps failing during Securing your hardware on newer hardware and your affected models use ST Micro or Nuvoton TPMs, stop blaming ESP app targeting first.

Microsoft documents a separate known issue for the latest models of ST Micro and Nuvoton TPMs that support RSA 3072bit. In this branch, TPM attestation can fail during pre-provisioning or self-deploying mode, which means the device never clears the hardware trust step that those deployment paths depend on.

This is the pattern that burns time during rollout waves: the same model fails on the bench, the same device profile works on older hardware, and admins keep resetting devices while the real problem sits in the TPM and OEM firmware path.

Quick Fix Checklist

Work this list in order before you reimage another device:

1. Confirm the failure happens during Securing your hardware in Windows Autopilot pre-provisioning or self-deploying mode.

2. Record the affected model, BIOS/UEFI version, TPM manufacturer, and TPM firmware version.

3. Collect diagnostics before changing anything:

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

4. Pull the Autopilot event log and check for Event ID 171 and 172.

5. Run Get-Tpm and tpmtool getdeviceinformation.

6. Verify the device can reach the TPM attestation endpoints, including *.microsoftaik.azure.net and the relevant vendor certificate URL.

7. Update the device with the latest OEM BIOS/UEFI and TPM firmware.

8. If the hardware is Lenovo and still matches this pattern, open the case through Lenovo support instead of treating it like a generic Intune issue.

9. Retest one pilot device after firmware remediation before reopening the full rollout.

What Microsoft Is Actually Saying

Microsoft’s current Windows Autopilot known issues page describes the issue this way:

TPM attestation isn't working for some ST Micro and Nuvoton TPMs

The OEM has resolved the issue. Lenovo customers should work with Lenovo support if they encounter an issue.

Platforms with the latest models of TPMs manufactured by ST Micro and Nuvoton that support RSA 3072bit might fail TPM attestation and cause failures during pre-provisioning and self-deploying mode.

That wording matters for two reasons.

First, Microsoft is not describing a generic enrollment problem. It is pointing at a specific TPM family and a specific cryptographic capability: RSA 3072bit support on newer ST Micro and Nuvoton TPMs.

Second, Microsoft is telling you the fix path is OEM-led. This is why app retry counts, ESP timeout tuning, or profile reassignment usually do not solve it.

Why This Breaks Autopilot So Early

Microsoft’s documentation for both self-deploying mode and pre-provisioning says those flows require:

• TPM 2.0
• TPM attestation
• network access to the Microsoft and vendor attestation certificate endpoints

That requirement is stricter than normal user-driven enrollment. In self-deploying and pre-provisioning flows, the device must prove its hardware trust state before it can move forward with little or no user interaction.

When attestation fails, the deployment stalls before the usual policy and app-delivery troubleshooting steps even matter.

This is why the symptom often looks like one of these:

• Securing your hardware never completes
• the same profile works on older devices but fails on one newer hardware line
• pre-provisioning fails on the bench even though the device hash and profile assignment are correct
• self-deploying kiosks or shared devices repeatedly fail before enrollment is fully established

Root Cause

The Microsoft known-issues page gives the clearest public clue: the problem is tied to the latest ST Micro and Nuvoton TPM models that support RSA 3072bit.

In practice, that means you should treat this as a TPM platform and firmware compatibility issue first. Your most likely root-cause buckets are:

• TPM firmware that still exposes the attestation problem on the affected model line
• BIOS/UEFI baselines that bundle the vulnerable or incompatible TPM state
• an OEM-specific remediation that has not yet been applied to your rollout batch
• network filtering that blocks the TPM certificate retrieval path and makes the hardware issue harder to distinguish

Microsoft also notes that the OEM has resolved the issue and calls out Lenovo support explicitly. That is a strong signal that this is not something Intune policy alone will repair.

Logs and Where to Check

1. Collect the Autopilot and TPM CAB first

At the failure screen, press Shift + F10 and run:

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

Export that CAB before the device is reset.

2. Check the Windows Autopilot event log

Microsoft’s troubleshooting FAQ says the key TPM attestation events are:

• 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 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 appear at the same time as the bench failure, you are still in the TPM attestation branch and not in a later ESP app or compliance branch.

3. Check TPM identity and firmware state

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Record these values for every failed pilot device:

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

4. Verify attestation networking

Microsoft’s Windows Autopilot requirements page says self-deploying mode and pre-provisioning need access to:

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

You will not hit every vendor URL on every device, but if your network blocks certificate retrieval or time sync, troubleshooting gets noisy fast.

5. Confirm the deployment path

In Intune, verify whether the device is actually using:

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

That matters because Microsoft documents this issue specifically against the attestation-heavy paths, not generic user-driven Autopilot.

PowerShell and Validation Commands

Device-side evidence collection

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

Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerId, ManufacturerIdTxt, ManufacturerVersionFull20

tpmtool getdeviceinformation

dsregcmd /status

dsregcmd does not diagnose the TPM family issue directly, but it helps confirm whether the device ever moved beyond the expected attestation boundary.

Network checks from OOBE or a test bench

Test-NetConnection login.live.com -Port 443
Test-NetConnection ztd.dds.microsoft.com -Port 443
w32tm /resync /force

If your staging network is restrictive, also validate that UDP 123 to time.windows.com is available. Clock drift can create misleading attestation symptoms even when the TPM family issue is the real blocker.

Remediation Workflow That Usually Works

Step 1: Prove the model pattern

Do not start by resetting ten devices. Compare at least:

• one failed device on the affected model
• one successful device on a different model using the same profile

If only the newer ST Micro or Nuvoton-backed hardware fails, that is your strongest signal that the profile is not the primary issue.

Step 2: Update OEM firmware first

Because Microsoft says the OEM has resolved the issue, your first real remediation path is:

• update BIOS/UEFI
• update TPM firmware
• apply any model-specific OEM package that references TPM, security processor, or trust-chain fixes

If you are a Lenovo shop, do not bury the OEM step. Microsoft explicitly says Lenovo customers should work with Lenovo support if they encounter this issue.

Step 3: Retest one device on a clean network path

After firmware remediation:

1. sync the clock
2. verify internet access for Autopilot and attestation endpoints
3. rerun pre-provisioning or self-deploying mode on one device
4. capture whether Event IDs 171 and 172 still occur

Step 4: Quarantine the model if it still fails

If the same model still fails after OEM remediation, stop deploying that model in attestation-dependent Autopilot paths until the OEM confirms the correct firmware baseline.

That is usually cheaper than letting the help desk absorb repeated bench failures with no real change between attempts.

What Not to Waste Time On

When this exact ST Micro or Nuvoton RSA 3072bit pattern is in play, these are common time-wasters:

• changing Win32 app assignments before proving the device clears attestation
• tuning ESP timeouts before checking the TPM events
• deleting and reimporting the hardware hash as your first move
• assuming every failure is 0x81039001, 0x81039023, or 0x81039024
• treating a vendor firmware issue like a generic Intune outage

Those other Autopilot error articles still matter, but this issue deserves its own branch because Microsoft ties it to a specific TPM family.

Prevention

To keep this from breaking another hardware wave:

• validate TPM manufacturer and firmware during pilot intake for new laptop or kiosk models
• keep OEM BIOS and TPM firmware baselines current before large pre-provisioning runs
• test one device per model family in self-deploying mode or pre-provisioning before broad rollout
• document which models use ST Micro or Nuvoton TPMs in your bench notes
• keep staging networks open for *.microsoftaik.azure.net, the vendor certificate endpoints, and UDP 123 time sync
• escalate early when the same model shows repeated Event ID 171/172 failures

Bottom Line

If Windows Autopilot fails during pre-provisioning or self-deploying mode on newer hardware with ST Micro or Nuvoton TPMs that support RSA 3072bit, treat it as a TPM attestation and OEM firmware problem first.

Microsoft’s own guidance points to the TPM family, says the OEM has resolved the issue, and specifically says Lenovo customers should work with Lenovo support. The fastest path is to collect the TPM evidence, confirm the model pattern, update OEM firmware, and retest one pilot device before you touch the wider rollout.