Fix Autopilot TPM Attestation Timed Out on Infineon SLB9672 Platforms

If Windows Autopilot dies at Securing your hardware with Something happened, and TPM attestation timed out, and the affected hardware uses an Infineon SLB9672 discrete TPM, stop treating it like a generic Intune enrollment problem.

Microsoft documents this as a separate known issue: platforms with the Infineon SLB9672 TPM, firmware release 15.22, with EK certificate might fail TPM attestation. That matters because the fix path is different from the usual Autopilot checks around ESP, profile assignment, or app targeting. In this branch, the fastest path is usually to prove the TPM family, collect the attestation evidence, and work the OEM firmware update angle first.

Quick fix checklist

Use this order while the device is still on the error screen:

1. Confirm the failure is happening in pre-provisioning or self-deploying mode.
2. Press Shift + F10 and collect diagnostics before resetting the device.
3. Export Autopilot and TPM logs:

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

4. Check the Autopilot event log for Event ID 171 and 172.
5. Run Get-Tpm and tpmtool getdeviceinformation.
6. Confirm the TPM manufacturer is Infineon and capture the TPM firmware version.
7. Verify the bench network can reach *.microsoftaik.azure.net and the standard Autopilot endpoints.
8. If the device uses an Infineon SLB9672 discrete TPM and the firmware maps to the affected branch, open the case with the OEM for the TPM update path.
9. Re-test one pilot device after firmware remediation before touching the wider rollout.

What Microsoft is actually saying

Microsoft’s current Windows Autopilot known issues page calls out this exact issue:

TPM attestation isn't working on some platforms with Infineon SLB9672 discrete TPMs

Platforms with the Infineon SLB9672 TPM with firmware release 15.22 with EK certificate might fail with error message Something happened, and TPM attestation timed out. To resolve this issue, contact the OEM for an update.

That wording gives you three important anchors:

• the issue is tied to a specific TPM model family
• Microsoft names firmware release 15.22
• Microsoft’s remediation direction is contact the OEM for an update

That is why this deserves its own panic-search article. If your team keeps retrying Autopilot with the same hardware and the same TPM state, nothing meaningful changes.

Why this breaks so early in Autopilot

Microsoft’s docs for both Windows Autopilot pre-provisioning and self-deploying mode say these flows depend on TPM 2.0 and TPM device attestation.

For pre-provisioning, Microsoft states that physical devices must support Trusted Platform Module (TPM) 2.0 and device attestation. For self-deploying mode, Microsoft says the device uses TPM 2.0 hardware to authenticate itself into the tenant and that the TPM attestation process requires access to provider-specific HTTPS URLs.

That means the device has to clear the hardware trust step before the normal policy and app-delivery troubleshooting steps even matter.

When this issue hits, the pattern usually looks like this:

• the failure appears during Securing your hardware
• the same deployment profile works on other models
• repeated resets do not change the outcome on the affected hardware line
• the device never really gets past the attestation boundary

In other words, this is not where you start by retuning ESP timers or reassigning Win32 apps.

Logs and where to check

1. Capture the CAB before the reset

At the failure screen:

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

Export that CAB before somebody clicks through another reset cycle.

2. Check the Autopilot event log

Microsoft’s Windows Autopilot troubleshooting FAQ says these TPM attestation events are the key ones:

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

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 are present at the time of the timeout, stay in the TPM-attestation branch. Do not jump ahead to profile or app logic unless the evidence says the device moved farther than that.

3. Confirm the TPM family and firmware state

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Capture at least:

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

If the hardware shows Infineon and the model line is using SLB9672, that lines up directly with the Microsoft known-issue wording.

4. Validate attestation networking

Microsoft’s Autopilot networking requirements say self-deploying mode and pre-provisioning require access to *.microsoftaik.azure.net.

Microsoft also notes that discrete TPM devices come with the needed certificates preinstalled, while firmware TPM devices from Intel, AMD, or Qualcomm may need to retrieve certificates from vendor endpoints on first use.

That distinction matters here. The Infineon SLB9672 issue is documented on a discrete TPM platform, so a dead-simple network block is not the only suspect. You still need to verify the network, but the Microsoft wording points you back toward TPM firmware and OEM remediation much faster than it does for some firmware-TPM cases.

Basic checks:

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

If your staging network uses SSL inspection, validate that the attestation and Autopilot endpoints are not being broken by proxy interception.

Practical remediation workflow

Step 1: Prove it is model-specific

Before you start changing tenant config, compare:

• one failed device on the affected hardware line
• one successful device on another model using the same profile and network

If the same profile succeeds elsewhere and the failures cluster on devices using the Infineon SLB9672 TPM, you have a strong signal that the profile is not the primary fault.

Step 2: Work the OEM path first

Microsoft’s remediation language is unusually direct here: contact the OEM for an update.

That usually means:

• check for a newer BIOS or UEFI package
• check for a separate TPM firmware update package
• verify whether the OEM has a bulletin tied to the platform or TPM behavior
• test the new firmware on one pilot device before rolling it wider

Do not assume a normal Windows Update or driver cycle included the TPM firmware payload you need.

Step 3: Re-test one device cleanly

After firmware remediation:

1. sync the clock
2. confirm internet access for Autopilot traffic
3. rerun pre-provisioning or self-deploying mode on one device
4. verify whether Event IDs 171 and 172 are gone
5. confirm the device now moves beyond Securing your hardware

If the device clears attestation after the TPM or OEM update, you have your root cause.

Step 4: Quarantine the hardware line if needed

If the same model still fails after the latest OEM guidance is applied, stop burning help-desk time on mass retries. Quarantine that hardware family from pre-provisioning and self-deploying mode until the OEM confirms the fixed baseline.

In some environments, that means temporarily moving the affected devices to a different Autopilot deployment path while you wait on the vendor fix.

What not to waste time on first

When this exact Infineon SLB9672 pattern is in play, these are common dead ends:

• deleting and reimporting the hardware hash before checking TPM evidence
• changing ESP app targeting before proving the device can complete attestation
• treating every timeout as the same root cause as 0x81039001, 0x81039023, or 0x81039024
• assuming a generic Intune outage because multiple devices fail on the same bench
• letting repeated resets erase the best evidence from the failed attempt

Those other Autopilot error families are real, but Microsoft’s Infineon SLB9672 known issue is a distinct branch with a different lead indicator: TPM attestation timed out on a specific discrete TPM family.

Caveats

A few limits matter.

First, not every TPM timeout means you have this Infineon issue. If the device is not using SLB9672, or the failure happens on unrelated hardware, use the broader TPM-attestation workflow instead.

Second, network and time hygiene still matter. Even on discrete TPM hardware, a badly filtered staging network or significant clock drift can make the Autopilot signal noisier.

Third, this article is aimed at pre-provisioning and self-deploying mode because those flows are the most sensitive to device attestation. If you are running a different deployment path, the symptom tree can look different.

Prevention

To keep this from wrecking the next laptop wave:

• record TPM manufacturer and firmware during pilot intake for new models
• validate one device per hardware family in pre-provisioning or self-deploying mode before broad rollout
• keep BIOS, UEFI, and TPM firmware current before benching hundreds of devices
• preserve a known-good staging network with working access to *.microsoftaik.azure.net
• document which models use Infineon SLB9672 discrete TPMs
• escalate to the OEM early when failures cluster by model and firmware version

Bottom line

If Windows Autopilot fails with Something happened, and TPM attestation timed out on devices using Infineon SLB9672 TPMs, do not burn cycles on generic Intune cleanup first.

Microsoft already points to the real branch: Infineon SLB9672, firmware release 15.22, and an OEM update path. Collect the TPM evidence, verify Event IDs 171 and 172, confirm the hardware pattern, and work the firmware remediation with the vendor before you reopen the rollout.

Sources

• Windows Autopilot known issues
• Windows Autopilot for pre-provisioned deployment
• Windows Autopilot self-deploying mode
• Windows Autopilot troubleshooting FAQ
• Windows Autopilot requirements