This blog discusses a TPM attestation issue affecting brand-new Lenovo Carbon X1 Gen 13 devices, which caused Autopilot pre-provisioning to fail with error code 0x81039001. The TPM attestation failure wasn’t your typical timeout or missing EK Certificate; 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 had never seen before. Well, the last part, yes, but not the double 0x0x.
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 ensures that the device hasn’t been tampered with and 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 encountered unexpected TPM attestation errors and completely blocked the enrollment process. Before we delve into what happened, let’s start with some background information on how Windows provisions the TPM.
How Windows Normally Provisions the TPM
When a device starts for the first time, Windows checks whether the TPM is already provisioned. Provisioning means creating the Endorsement Key (EK), verifying its certificate, and preparing the TPM for attestation.
If the TPM is blank or was recently cleared, Windows begins by creating a new Endorsement Key. This key is the root identity of the TPM, a permanent asymmetric key pair used to prove that the device’s TPM is genuine and untampered. The private half never leaves the TPM, while the public half is either stored in a predefined handle or written to an NV index.
Windows uses the TPM2_CreatePrimary command under the Endorsement hierarchy to generate this EK.
By default, Windows requests an RSA key with a SHA template, following Microsoft’s EK Root CA policy. The EK’s public portion is persisted under the standard handle 0x81010001, and the operating system tries to retrieve or download the corresponding EK certificate (EKCert) from the TPM vendor’s endorsement CA. That certificate chain enables Microsoft’s attestation service to verify that the EK was issued by a trusted manufacturer.
After the EK is validated, Windows generates two more keys derived from it:
- the Storage Root Key (SRK) for sealing BitLocker secrets, and
- the Attestation Identity Key (AIK) used in MDM and Autopilot attestation.
During Autopilot pre-provisioning, the AIK certificate request is signed using the EK, and the Microsoft Attestation Service verifies that the EK public key and certificate match a trusted RSA-2048 template. Now that we know what a normal TPM provisioning flow looks like, let’s see what went wrong on these new Lenovo devices
TPM Attestation Fails on Lenovo Carbon X1 Devices
Now that we’ve covered what TPM attestation is supposed to do and how it is provisioned, 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 an AIK enrollment test. The moment the certreq command is launched, it will start gathering the EKCert information using the EKCertInfo Function.
The EkCertInfo function attempts to retrieve the EKCert from the TPM (or the web) and read the necessary properties. 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 command 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 3072 bits combined with a SHA384 signature hashing algorithm.
This caught my attention because Microsoft doesn’t commonly document or consider the RSA 3072 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.
However, on our device, the TPM was provisioned with RSA 3072 with SHA384, which caused Attestation to fail with the error: 0x81039001
TPM Attestation Technical Background
Upon examining the CertEnroll source code closely, specifically around the EncryptSecret failure, we confirmed our suspicion that the Microsoft AIK service rejected this uncommon pairing of RSA 3072 with SHA-384.
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.
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 exactly the same thing as I was noticing. That prompted me to check the TPM Dll’s itself to see how Windows decides which EK size to use. That’s where things got interesting!
The Hidden Feature Flag: EkRsa2kDefaultFix
While reviewing the TPM stack, I found something interesting inside TrustedPlatformModule::NVDefineIndex (in nv.cpp).
The code calls a Windows feature flag:
This EkRsa2kDefaultFix feature appears to control how Windows defines the TPM’s default EK key size during provisioning. Its name implies that it forces or restores RSA 2048 as the default key, possibly correcting older or inconsistent behavior where a 3072-bit EK might be used instead. If this flag isn’t active, the TPM could generate an RSA 3072 EK, leading to exactly the attestation issue above.
So, rather than being a random firmware quirk, the issue appears to be tied to whether this feature is enabled at runtime — meaning it’s partly a Windows configuration oversight, not just an STM hardware issue.
Conclusion
The failure on these Lenovo Carbon X1 Gen 13 devices wasn’t about missing certificates or timeouts. It was a mismatch between what the TPM generated and what Microsoft’s attestation service expected.
The EkRsa2kDefaultFix flag within Windows suggests that this issue could be prevented, ensuring TPMs provision RSA 2048 EKs by default until the AIK service fully supports 3072-bit configurations.
