This blog is a deep dive into the mystery of failing TPM attestation (0x80070490) on Dell Latitude devices (with an STM TPM), how Microsoft seems to have increased TPM security on 24h2, and what you can (or can’t) do about it. Let’s break it down.
Introduction: Autopilot Attestation with 0x80070490
It all started two months ago when the first Reddit users started reporting having Autopilot failures at the “Securing Your Hardware” step, specifically throwing 0x800705b4 errors.
One particular case caught my attention: a user working with a Dell Latitude 7410 who performed a remote wipe on their device and re-added it to Autopilot, only to hit a TPM attestation failure when enrolling the device with Autopilot for pre-provisioned deployments.
This wasn’t an isolated issue. More reports followed, especially on devices with STMicroelectronics (STM) TPM modules. In all cases, the devices were from Dell.
And here’s where it got interesting:
- On Windows 11 24H2, the error was instant before even reaching Microsoft’s attestation servers.
- On Windows 11 23H2, the request went through but eventually failed server-side with a different error.
- Other Dell 7410 devices with the same TPM version / BIOS / Windows version were not experiencing the issue. (which is weird… )
That’s when the real investigation began. During this investigation, Jan Schmutz provided me with many details about the device and tested some funny theories.
Reproducing the Issue: Step by Step
Step 1: CertReq and AIK Enrollment Failures
When we want to test if the device can perform attestation, we can execute the test attestation request manually: certreq -enrollaik -config “”
Let me show the results of using the same command on the same device, 23h2 and 24h2.
💥 On 24H2: Immediate failure with 0x80070490 (ERROR_NOT_FOUND)
As shown above, when running the certreq command, the device would start fetching the excerpt from the NVR to build the AIK url, but it is terminated with the error 0x80070490 before even reaching out to the AIK service. Besides the certreq request failing us, Fiddler was also showing no traffic!
💥 On 23H2: The request actually reached Microsoft’s attestation server but failed with: “Message”:”No valid TPM EK/Platform certificate provided in the TPM identity request message.”} and the error code 0x80190190
As shown above, instead of failing with the error 0x80070490 at fetching the ekcertinfo, it now continues but fails at receiving the AIK. When looking at it with Fiddler, we indeed noticed the same behavior.
This reminded me of a previous Attestation blog post I wrote about this same error message. I started asking myself if I was looking at the same time again, but then again, the difference between 23H2 and 24H2 immediately raised some other questions as well. Was Microsoft enforcing stricter local TPM checks in the Windows 24h2 build?
I decided to dig deeper…
Step 2: Checking the TPM’s EK Certificate (EKCert) and Public Key (EKPub)
From there on, we dumped the TPM’s Endorsement Key (EK) details:
Get-TpmEndorsementKeyInfo
Everything looked fine at first; as shown above, the Ekcert was on the device, and the ManufacturerCertificates had the “Subject” configured. I was expecting that one to be empty, just as I noticed in this blog. We could also spot the EKcert in the registry when opening the TPM\WMI\Endorsement\EKcertstore registry key
but then we tried manually installing the EK certificate from the TPM’s non-volatile storage:
tpmdiagnostics installekcertfromnvr
🚨 Error: Provider’s public key is invalid HR: 0x80090015
At this point, we suspected a mismatch between EKPub and EKCert, meaning the TPM’s public key didn’t match the one in its stored certificate. But was that really the issue?
Step 3: Diving into the Code (TPMCoreProvisioning.dll) that got us the 0x80070490 error
To confirm what was happening, I traced the AIK enrollment flow in CertEnroll.dll and TPMCoreProvisioning.dll. (Yeah, i am the one who looks at DLL files for fun)
Inside the HAS::TpmCertCheckEkCertMatchedEkPub function, I found the validation process:
· It retrieves the EKPub from the TPM.
· It extracts the EKPub from the EKCert stored in TPM NVR.
· It performs a byte-by-byte comparison to ensure they match.
If they don’t, attestation fails immediately before even reaching Microsoft’s attestation service. But the bigger discovery? It wasn’t just an EKPub/EKCert mismatch issue. It seems that Microsoft Raised the TPM security Bar in 24H2… which could explain the difference in the Certreq output on 23h2 and 24h2.
But why?
It turns out Microsoft updated its TPM security model to align with: EK Credential Profile for TPM 2.0 Specification (March 2022)
This document outlines stricter requirements for TPM attestation, including:
- Stronger verification of EKCert chains.
- Ensuring EKCert and EKPub match exactly.
- Rejecting improperly signed EKCerts or ones from untrusted CAs.
And that brings us back to the STM’s firmware. Why? As mentioned before, only Dell devices with a certain STM TPM were experiencing the issue… but some devices with the same exact hardware and firmware had no issues at all!
The STM Firmware Problem: When a TPM Update Breaks Everything
After testing different devices and configurations, we noticed a pattern in affected firmware versions:
| TPM Model | Firmware Version | Affected? |
| ST33TPHF2XSPI | 1.769 (shipped) | ❌ Not Affected |
| ST33TPHF2XSPI | 1.256 (shipped) | ✅ Affected |
| ST33TPHF2XSPI | 1.256 → 1.769 (upgraded) | ✅ Still Affected |
That last row is a bit weird if you ask me, as upgrading from 1.256 to 1.769 doesn’t fix it… but breaks it? This means many users installed a TPM update that permanently broke attestation on affected devices. Did STM/Dell release a faulty firmware update in combination with MSFT enhancing TPM security on Windows 24h2?
23H2 Workaround: Clearing the TPM to fix the 0x80070490 error!
At this point, we knew 24H2 was failing immediately due to strict local validation, while 23H2 at least tried to communicate with Microsoft before failing. So we tried something else on the Windows 23h2 device:
Initialize-TPM -AllowClear
*Clear-TPM
*Please note that after clearing the TPM, you will need to reupload the Hardware Hash. Otherwise, your device won’t be recognized.
After clearing the TPM, we rebooted the device and ran certreq -enrollaik again.
✅ On 23H2, it worked!
While doing so, we also had Fiddler open and running. By the looks of it Fiddler was thinking the same thing, we got back the signing cert.
Now that we know that clearing the TPM with the PowerShell command works on Windows 23h2, I am curious about what will happen when we switch back to 24h2.
From 23h2 to 24h2 and back
After the first test, we reinstalled the device with 23h2 again. After the device was installed, we upgraded to 24h2. After the upgrade, we executed the certreq command again. Well, this was unexpected.
As shown above, the Certreq command is no longer showing us the 0x80070490 (ERROR_NOT_FOUND), and with it, the device was able to perform attestation and enroll with Autopilot pre-provisioning.
24h2 And Wiping the TPM
With this test done, we decided to do the same, but now clearing the TPM with 24h2 installed. After reinstalling and upgrading the device with 24h2, we first performed the certreq command to be sure the device was still able to perform an test attestation.
As shown above, that worked as expected! From there on, we did the same as we did on a 23h2 build!
After clearing the TPM and rebooting the 24h2 device, we performed the test attestation again, only to notice that it was now broken again! As shown below, the error 0x80070490 is back!
Do you want to hear something funny? Guess what happens when you perform a remote wipe from Intune?
Key Takeaways: What You Can Do Now
Which Dell Devices are impacted?
Dell Latitude 7420 / 7320 seems to be affected, and maybe more. Check this list: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=y66j2&oscode=wt64a&productcode=latitude-14-7410-2-in-1-laptop
Check your TPM firmware version: tpmtool getdeviceinformation
You’re likely affected if your TPM is STM and running 1.256 or an upgrade from 1.256 to 1.769.
If you’re on Windows 11 23H2: Initialize-TPM -AllowClear + Clear-TPM seems to do the job.
If you’re on Windows 11 24H2: Follow the above steps… and reinstall the device back to Windows 23h2 and clear the TPM before upgrading it again.
Performing a remote Wipe: Performing a remote wipe also clears the TPM! If your Dell device is on 24h2, you are going to have a lot of fun with attestation!
Final Thoughts
If you have Dell devices that refuse TPM attestation during Windows Autopilot and that Dell device has an STM TPM, you are up for some fun!
With Windows 24h2 strengthening the TPM security and with the bad STM firmware in play, attestation will not work on Windows 24h2. The only way to fix it is to clear the TPM from a Windows 23h2 build, Upgrade, and enroll it!
