It attested last month: how a TPM firmware update breaks Autopilot self-deploying mode

Last month this device sailed through Windows Autopilot pre-provisioning. The technician pressed the Windows key five times, chose Windows Autopilot provisioning, watched the success screen appear, and resealed the box. Nothing about the tenant has changed since. Nothing about the network has changed since. But the original equipment manufacturer (OEM) shipped a firmware update in the meantime. The fleet took it. Now the same model stalls on Securing your hardware.

This is the part of Trusted Platform Module (TPM) attestation that almost nobody plans for. Attestation is usually discussed as a static hardware capability. Either the device has a TPM 2.0 or it does not. Either the network reaches the attestation service or it does not. That framing is fine on day one. It falls apart on day four hundred, because the TPM is not static. It has firmware. Firmware gets updated. And the thing attestation depends on most, the endorsement key certificate, lives inside that firmware boundary.

The problem: a device that attested last month fails today

Start with what Microsoft actually requires. Self-deploying mode "uses a device's Trusted Platform Module (TPM) 2.0 hardware to authenticate the device into an organization's Microsoft Entra tenant." Devices "must also support TPM device attestation." Pre-provisioning inherits the same requirement. The pre-provisioning process uses Autopilot self-deploying capabilities underneath. Both modes also need network access to a set of HTTPS URLs that are unique for each TPM provider.

That is the day-one checklist, and most teams pass it. The failure mode in this post is different. The device already passed. Then something changed inside the TPM.

Here is the shape of it in practice. A batch of laptops of one model is registered, assigned a self-deploying profile, and deployed successfully. Weeks later the OEM releases a system firmware package. Your patching tool, or the OEM update agent, or a technician working through a security advisory, applies it. TPM firmware is part of that package. The next device from the same batch that goes through the out-of-box experience (OOBE) now sits on Securing your hardware until it times out.

The tempting conclusion is that a proxy rule changed. Sometimes it did. But before you spend a day with the network team, read Microsoft's own Autopilot known-issues list. It is full of entries where the TPM itself was the cause, and specifically its firmware. Those entries are the strongest evidence that this is a real lifecycle problem, not a rare edge case.

Read that table twice. Two of those five entries point at TPM firmware as the fix. One points at TPM firmware as the cause. One points at the operating system. That is the whole problem in miniature: the TPM firmware version is a variable in the attestation equation, and it moves.

Why it happens: the EK certificate is a lifecycle object

To understand why a firmware update matters, you have to know where the endorsement key certificate comes from. Microsoft is explicit about this, and the wording is the hinge of this entire post.

Microsoft's exact words: "Firmware TPM devices, which are only provided by Intel, AMD, or Qualcomm, don't include all needed certificates at boot time and must be able to retrieve them from the manufacturer on first use." And the other half of it: "Devices with discrete TPM chips come with these certificates preinstalled."

Three consequences follow directly.

First, a firmware TPM has a fetch step. The certificate is not baked into silicon at the factory. It is requested over the network. Microsoft publishes the URL pattern *.microsoftaik.azure.net for the attestation process, plus a per-vendor URL for the certificate request itself.

Second, "on first use" is a state, and state can be reset. If the certificate was fetched once and cached, and the firmware boundary underneath it changes, the device may need to fetch again. That is the moment a device suddenly needs vendor URLs it never needed at your site before. Often it needs them on a network segment nobody tested for it.

Third, clearing the TPM destroys keys. Some OEM firmware update procedures ask you to clear the TPM. Microsoft documents exactly what that costs. The Clear-Tpm cmdlet "resets the Trusted Platform Module (TPM) to its default state." More specifically: "A reset removes the owner authorization value and any keys stored in the TPM." The troubleshooting guidance is blunter still. Clearing the TPM "causes you to lose all created keys associated with the TPM, and data protected by those keys, such as a virtual smart card or a sign-in PIN."

The second-order effect: the hardware hash contains the EK public key

There is a subtler failure path. It is the one that surprises experienced Autopilot admins. The Autopilot hardware hash, the 4K HH, is built from a set of platform values. Microsoft lists them when explaining what a repaired motherboard BIOS must populate. The list is DiskSerialNumber, SmbiosSystemSerialNumber, SmbiosSystemManufacturer, SmbiosSystemProductName, SmbiosUuid, TPM EKPub, MacAddress, ProductKeyID and OSType.

The endorsement key public key is a hash input. The same document adds a second detail. Rewriting old device information into a replacement board "wouldn't include the TPM 2.0 endorsement key, as the associated private key is locked to the TPM device." A separate scenario in that document notes the resulting device identifier "won't be stable until after TPM attestation is complete."

So a firmware change that alters the endorsement key can change the hash the service computes. That hash then stops matching the hash you registered. The symptom is not an attestation error at all. It is a registration state change. In the Intune admin center the device shows Fix pending or Attention required. Selecting the status returns a message saying a hardware change was detected on the device.

And a third path: PCR banks

Measured boot writes hashes into Platform Configuration Registers, grouped into PCR banks by hash algorithm. Firmware decides which banks are active. Microsoft's guidance is direct: "if the currently used PCR bank is switched, all keys that are bound to the previous PCR values no longer work." So a firmware update that changes the advertised PCR banks changes the key-binding environment. Windows records the current state in the registry, which makes it measurable.

How to verify: read the TPM before you blame the network

Verification has three layers: the device TPM state, the Autopilot event log, and the registry. Do them in that order, because the first one is cheap and rules out the most expensive investigation.

Layer one: the TPM management surface

Windows exposes the TPM three ways. The tpm.msc console gives you the human view. The TrustedPlatformModule PowerShell module gives you Get-Tpm and Get-TpmEndorsementKeyInfo. The Windows Management Instrumentation (WMI) class Win32_Tpm, in the namespace Root\CIMV2\Security\MicrosoftTpm, gives you the firmware version and the Trusted Computing Group (TCG) specification version.

Start with Get-Tpm. It returns a TpmObject with the readiness flags, and Microsoft documents each one. TpmPresent is whether there is a TPM. TpmReady is whether the TPM complies with the baseline standards Windows expects. LockedOut tells you whether anti-hammering has kicked in. Then go to Win32_Tpm for the identity values.

Now the part that matters most. Get-TpmEndorsementKeyInfo returns an EndorsementKeyObject. Microsoft documents its members precisely. IsPresent is "a Boolean that represents whether the endorsement public key is known to the operating system". ManufacturerCertificates is "a X509Certificate2Collection object that contains the manufacturer endorsement key certificates". AdditionalCertificates holds certificates registered to the operating system, such as enterprise certificates. The object also carries PublicKey and PublicKeyHash, which you should not paste into a ticket.

Layer two: the Autopilot event log

Autopilot writes its own event log, and two of its event IDs are specifically about TPM attestation. Microsoft documents the channel location, so navigate to it exactly.

Event 171 is your smoking gun. It carries an HRESULT, and that HRESULT is what you match against the error table later in this post. Event 908 is the one to watch if a firmware change shifted the device identity rather than the attestation result.

There is a second event surface worth knowing, though it is much less documented. Microsoft's BitLocker and TPM troubleshooting article records event ID 1026 from source Microsoft-Windows-TPM-WMI, logged under Windows Logs > System. Its text says the TPM hardware "cannot be provisioned for use automatically" and directs you to tpm.msc. That article documents 1026 specifically. I have not found a Microsoft-published catalog of the other TPM-WMI event IDs, so I am not going to list numbers I cannot source. If you see other IDs from that source, treat them as a lead to raise with the OEM, not as a documented diagnostic.

Layer three: the registry

Two registry areas are relevant and both are documented. Neither one stores the EK certificate, which is an important negative finding in its own right.

First, the measured boot state.

Second, the Autopilot profile state the device believes it has. This is the area to check when the failure looks like a registration problem rather than an attestation problem.

Matching the error code

Once you have the HRESULT from event 171, or the code on the OOBE error screen, match it against what Microsoft documents. Every code below is published by Microsoft. I have deliberately not filled gaps with codes I could not source.

The fix: re-fetch, re-register, re-baseline

There is no policy toggle for this. Say it plainly before anyone goes looking.

Step 1: confirm the vendor URLs are reachable from the OOBE network

This is the highest-yield check, because it is the one thing that changes silently. A firmware TPM must retrieve certificates from the manufacturer on first use. If the device has to fetch again after a firmware change, that path must be open. It must be open on the network the device actually uses during OOBE. That is often a provisioning VLAN with tighter rules than the corporate network your test device sat on.

Allow the URL pattern *.microsoftaik.azure.net for all TPM providers, plus the firmware-TPM vendor URL that matches your silicon, from the earlier table. Check them from the provisioning segment, not from your desk.

Step 2: turn on the diagnostics you will need next time

Do this once, tenant-wide, before the next firmware wave. Microsoft documents both switches.

1. Sign in to the Microsoft Intune admin center.
2. In the left pane, select Devices.
3. Under By platform, select Windows.
4. Under Device onboarding, select Enrollment.
5. Select the Enrollment Status Page profile you want to change.
6. Set Show app and profile configuration progress to Yes.
7. Set Turn on log collection and diagnostics page for end users to Yes.
8. Save the profile.

With that on, a technician at a failing device can press CTRL + SHIFT + D to open the Autopilot diagnostics page. Microsoft notes this page is supported on Windows 11 in Autopilot user-driven mode, when signing in with a work or school account. So it will not help you inside a userless self-deploying flow. For that, collect the cab.

Step 3: retry, because Microsoft says retrying can work

For error 0x81039001 Microsoft's documented guidance is that subsequent attempts to provision might resolve the issue. That is not hand-waving. It is consistent with a certificate fetch that needs to complete. Retry once deliberately, and note whether the retry succeeds, because "succeeds on second attempt" and "never succeeds" are different OEM cases.

Step 4: reset the Autopilot registration if the identity moved

If the symptom is Fix pending or Attention required rather than an attestation error, the device identity changed and the fix is a re-registration. Microsoft's documented order matters: delete from Intune first, then deregister from Autopilot.

1. Sign in to the Microsoft Intune admin center and select Devices.
2. Under By platform, select Windows.
3. Find the device, open its properties, and note the value under Serial number.
4. Select Delete in the toolbar, then Yes to confirm.

1. Under Device onboarding, select Enrollment.
2. Under Windows Autopilot, select Devices.
3. Find the device by the serial number you noted, and select its checkbox.
4. Open the extended menu, and if Unassign user is available, select it and confirm.
5. Select Delete in the toolbar, then Yes to confirm.
6. Select Sync to speed up the deregistration, then Refresh until the device is gone.
7. Capture a fresh hardware hash from the device and import it again.

Two warnings from Microsoft's own text. For Entra joined devices, no further steps are required after deregistering. Avoid manually deleting the device from Entra ID, because that can cause unexpected issues. Separately, reusing a device previously deployed with self-deploying or pre-provisioning mode needs the Intune device record deleted first. Skip that and you get 0x80180014. There is also an Unblock device action on the Windows Autopilot devices page for that specific case.

Step 5: re-baseline, so the next wave is a diff and not an investigation

This is the step that turns this class of incident from a two-day outage into a ten-minute check. Before you approve a firmware package, capture the TPM state on a representative device of every model in the ring. After the package lands, capture it again and compare.

Four fields carry almost all the signal. The TPM firmware version, from Win32_Tpm.ManufacturerVersion. Whether an EK certificate is present, from Get-TpmEndorsementKeyInfo. And the two PCR bank values from the IntegrityServices key. The companion script collects exactly those, plus the readiness flags. It refuses to report a clean result if any read fails.

Proof it worked: what a ready device reports

The companion script is read-only. It runs no state-changing cmdlet, installs no module, and makes no network call. It never prints the EK public key or its hash. If any required read fails, it exits 1 with an explicit message. That matters because an empty result from a failed query looks identical to a genuinely absent TPM.

A device in the failure state looks different in exactly the places you would expect. EK public key known to Windows flips to False, or ManufacturerCertificates count drops to 0. The verdict block then lists the blocker instead of a green READY line. If RestartPending is True, the script warns that a TPM change is staged and the reading is provisional. That warning matters a great deal immediately after a firmware update.

Script path:

One honest limitation. This script tells you the state of the TPM. It cannot tell you whether your OEM firmware version is known-good for attestation on your model. Nobody outside the OEM can tell you that. Microsoft does not publish per-model firmware compatibility. What you can do is establish the correlation yourself. Record the firmware version on devices that attest and on devices that do not. Then take that comparison to the OEM. A case that says "attestation fails at firmware version X and succeeds at version Y on the same model" gets a real answer. A case that says "Autopilot is broken" does not.

What the community found before the docs caught up

Both are community research, not Microsoft documentation. Read them for the investigative method and for evidence that OEM-side EK certificate remediation exists. Do not treat any vendor utility name or firmware version in them as current for your fleet.

References

• Windows Autopilot self-deploying mode — the TPM 2.0 and device attestation requirement, and the 0x800705B4 virtual machine limitation.
• Windows Autopilot requirements, networking tab — the per-TPM-provider URL requirement, the *.microsoftaik.azure.net pattern, and the Intel, Qualcomm and AMD certificate URLs.
• Windows Autopilot for pre-provisioned deployment — physical devices supporting TPM 2.0 and device attestation, virtual machines not supported.
• Windows Autopilot known issues — the documented TPM attestation error codes and the Infineon, AMD ASP, ST Micro and Nuvoton entries.
• Windows Autopilot troubleshooting FAQ — the Autopilot event log channel and event ID table including 171 and 172, and the Provisioning Diagnostics registry values.
• Windows Autopilot motherboard replacement — the hardware hash inputs including TPM EKPub, and the deregister and re-register sequence.
• TPM recommendations — discrete, integrated and firmware TPM implementations, and the Autopilot row in the Windows features table.
• Troubleshoot the TPM — what clearing the TPM does, the precautions, and the guidance to use tpm.msc rather than UEFI.
• Understand PCR banks on TPM 2.0 devices — the IntegrityServices registry values and the consequence of switching banks.
• Get-TpmEndorsementKeyInfo — the EndorsementKeyObject members including IsPresent, ManufacturerCertificates and AdditionalCertificates.
• Get-Tpm and Clear-Tpm — the TpmObject properties, and the documented statement that a reset removes the owner authorization value and any keys stored in the TPM.
• Win32_Tpm class — SpecVersion, ManufacturerId, ManufacturerVersion and the Root\CIMV2\Security\MicrosoftTpm namespace.
• BitLocker and TPM: other known issues — event ID 1026 from source Microsoft-Windows-TPM-WMI in the System log.