This blog is about a TPM attestation issue occuring on brand new Lenovo Carbon X1 Gen 13 devices that caused Autopilot pre-provisioning to fail with error code 0x81039001. The TPM attestation failure wasn’t your typical timeout or missing EKCert, something else was going on under the hood. Shall we dive in?
Introduction
Recently, someone contacted me about an issue with their brand-new Lenovo Carbon X1 (Gen 13) devices. They reported facing TPM attestation problems during Windows Autopilot pre-provisioning, similar to those described in a Microsoft Answers forum post.
The moment they wanted to enroll the device with Autopilot for Pre-Provisioned deployments, they got the error message that TPM attestation failed: Error: 0x0x81039001.
Which to be honest I have never seen before. Well, I have seen the last part but not the double 0x0x part.
Before diving into the troubleshooting, let’s briefly discuss TPM attestation and its role in Windows Autopilot.
Understanding TPM Attestation
Trusted Platform Module (TPM) attestation is essential for securing device identity and integrity. In Windows Autopilot, TPM attestation ensures that devices enrolling through Self-Deployment mode or Autopilot Pre-provisioning meet security standards by verifying the TPM’s identity. A valid TPM attestation guarantees that the device hasn’t been tampered with and that it is trustworthy. But what happens when that trust can’t be established?
That’s exactly what happened during Autopilot pre-provisioning on a brand new Lenovo Carbon X1. The device threw unexpected TPM attestation errors and blocked the enrollment process entirely.
TPM Attestation Fails on Lenovo Carbon X1 Devices
Now that we’ve covered what TPM attestation is supposed to do, let’s take a look at the TPM attestation issue we encountered on those Lenovo Carbon X1 devices. The moment the device was enrolled, a weird TPM attestation issue happened. To start investigating to know what happened, the command you need to use is : certreq -enrollaik -config “”
This certreq command will perform a test AIK enrollment. The moment the certreq command is launched, it will start gathering the EKCert information using the EKCertInfo Function.
The EkCertInfo function will try to fetch the EKCert from the TPM (or web) and read the properties it needs. If this succeeds, we can be pretty sure the device got an EKCert, and that is accessible (in a normal situation).
As shown above, running the certreq commando on those Lenovo devices immediately resulted in an error I had never seen before:Client challenge cannot be created due to failure in EncryptSecret HTTP 400 Bad Request 0x80190190
Logs showed that the error came directly from the Microsoft AIK Service URL, stating clearly: “Submit Done: Bad Request.” So the AIK request was sent to the service, but it responded with a ‘Bad Request’ message
Investigating the Certificate on Lenovo Carbon X1
The next step was inspecting the Endorsement Key (EK) certificate from the TPM itself.
(Get-TpmEndorsementKeyInfo).ManufacturerCertificates | Foreach-Object -Process { Set-Content -Value $_.RawData -Encoding Byte -Path “$($_.Thumbprint).crt” -Force }
After running this command, it indeed exported the Endorsement Key Certificate to the folder from which I executed the command. The certificate indicated it used RSA 2048 bits combined with a SHA384 signature hashing algorithm.
This caught my attention because Microsoft doesn’t commonly document or consider the RSA 2048 and SHA384 standard combination. Looking at the export of my own EKCert, that indeed showed me sha256 and RSA 2048 bits.
Checking STM TPM Vendor Documentation
I decided to look deeper into the TPM vendor documentation (STM, in this case). It turned out that the STM TPM modules come pre-provisioned by default with three RSA 2048 bit key pairs. The idea behind this choice is to reduce TPM provisioning time during manufacturing. I guess this explain why the Lenovo Carbon X1 Device was provisioned with a 2048 RSA EK.
However, this default configuration (RSA 2048 with SHA384) matched exactly the problematic scenario we encountered.
The TPM Technical Background
Looking closely at the CertEnroll source code, specifically around the EncryptSecret failure, confirmed our suspicion that the Microsoft AIK service rejected this uncommon pairing of RSA 2048 with SHA384. While Microsoft’s documentation doesn’t explicitly list valid key-hash combinations, it consistently associates RSA 2048 with SHA256 and RSA 3072 with SHA384 in both guidance and implementation examples, suggesting these are the expected pairings.
The Fix: Clearing and Reprovisioning the TPM
Given the insights from the vendor documentation and code investigation, the fix became clear:
- First, I advised updating the Lenovo device to the latest available Windows updates as I know that even without Microsoft mentioning it in the release notes of the 2025-04 update, that update contains some important TPM fixes
- After the device was updated, we ensured the device rebooted to apply the update.
- Next, clearing the TPM entirely to remove the problematic default EK certificate, by using the PowerShell command: Clear-TPM
- Finally, I we run the Autopilot Test Attestation PowerShell script, which is available on the PowerShell Gallery. This script will kick off the EKCert retrieval manually using the tpmcoreprovisioning.dll functions. Another option is to manually execute the TPM-Maintenance task to kick off the ekcert retrieval
The RSA Result on the Lenovo Carbon X1 Device.
After completing these steps, the newly provisioned EK certificate now uses RSA 3072-bit keys with a SHA384 hashing algorithm instead of the RSA 2048-bit on the Lenovo Carbon X1 Device.
With the new 3072 Bits EkCert, we tried to perform the test attestation again using: certreq -enrollaik -config “”
This time, the attestation succeeded without errors, confirming that the Microsoft AIK Service fully supports RSA 3072-bit keys in combination with SHA384.
Microsoft Take on RSA 3072EK:
While investigating this issue and trying to discover what happened and why those Lenovo devices were failing, Microsoft added “something” to the list of known Autopilot issues.
Interestingly, they indeed mention that TPM attestation isn’t working for TPMs that use high-range RSA 3072EK… While the wording was vague, it feels and smells the same as my issue. The funny thing is that I needed to clear the TPM on that new Lenovo Carbion device to get the proper EKCert with an RSA 3072 Public Key.
Conclusion
The issue was resolved by ensuring the Lenovo Carbon X1 Gen 13 device it’s Windows version was updated. After Windows was updated we cleared the TPM and reprovisioned it with a supported configuration (RSA 3072 with SHA384). After these steps, Autopilot enrollment completed successfully.
This case shows that not all TPM attestation issues are vendor-specific. In a previous blog, I covered a Dell scenario where TPM-related problems caused remote wipe and provisioning failures (0x80070490 TPM Attestation Timed Out on Windows 11 24H2). In that situation, the problem centered around timing and attestation timeouts on newer Windows builds.
This time, the issue wasn’t Dell-specific but more like how STM TPMs were provisioned out of the box using RSA 2048 with SHA384 , which seems to be a combination that Microsoft’s attestation service doesn’t handle well. By updating the OS, clearing the TPM, and reprovisioning with a standard RSA 3072 configuration, the device successfully passed attestation and Autopilot enrollment.
