This blog will show you what the “Ready for Attestation” flag truly means. I will also show you how to make sure the device is Ready for Attestation, so you won’t be getting the 0x81039001 error anymore!
1. Introduction
Some time ago “someone” reached out to me asking me the question about what was required to get the EK Certificate working.
He asked me that question because some of his Lenovo L480s were failing on TPM Attestation when using Autopilot Pre-provisioning. Those devices were throwing 0x81039001 errors at him!
I decided to help out as much as possible, with only Twitter PMs. Please note that I didn’t have a TeamViewer session or something else, so it was sometimes hard to get to the bottom of the issue.
Luckily, I already wrote a huge amount of articles about TPM attestation stuff so I guess this is going to be a piece of cake?
TPM Provisioning | GetCaCaps | 0x800705b4 | AIK | EKCert (call4cloud.nl)
AMD and TPM Attestation Failing | 0x81039024 | 0x800705b4 (call4cloud.nl)
TPM Attestation flow Explained | Intel 11th Gen Tiger Lake (call4cloud.nl)
Fix TPM Intel Tiger Lake TPM attestation Issues KB5007253 (call4cloud.nl)
Please Note: Before reading further, these blogs do provide some more context about the attestation process, so it could be worth to check them out first!
All of those blogs are focusing on why attestation doesn’t work for new Intel 11th gen and AMD devices but not an article that focuses on the “Ready for Attestation” flag and why it could still give you issues. So here we go!
Please note that it really took me down a huge rabbit hole…. It was the largest rabbit hole I have ever encountered!
2. The Issue
I was approached and asked to troubleshoot the “Ready for Attestation” issue. I guess we all have seen this tpmtool getdeviceinformation output so everyone knows what we are talking about!
As Shown above, the output showed me: “Ready for Attestation: False”. When the TPM is not ready for attestation you can forget about the possibility of pre-provisioning your device.
The screenshot also showed an important “Information flags description”. It was telling me Information_EK_Certificate AKA Your Ek Cert is missing, go fetch!
A small heads up! Did you take a good look at the TPM tool output? If not, please do!
Luckily I have enough troubleshooting skills to get to the bottom of this right? So let’s start some troubleshooting
3. Troubleshooting Information_EK_Certificate
If you have read my TPM attestation series blogs, you will probably know how to determine if the EK Certificate (EK_Cert) was on the device. If not, let me explain again…
The first option we have is to run the: Get-TPMEndorsementkeyinfo
As Shown above, it showed me a ManufacturerCertificate… Mmm okay okay, let’s run the certreq tool : certreq -enrollaik -config “”
Okay, now I am beginning to start doubting my knowledge about EK Certificates! Let’s open the good old registry to determine if there is a nice certificate in the EKCertStore!
As shown above, it pretty much looks like the EK Cert is also stored in the registry right? But okay I was still not convinced so I again used the Get-TPMEndorsementkeyinfo, but this time to export the manufacturer certificates
(Get-TpmEndorsementKeyInfo).ManufacturerCertificates | Foreach-Object -Process { Set-Content -Value $_.RawData -Encoding Byte -Path “$($_.Thumbprint).crt” -Force }
Please Note: Besides this PowerShell command tool, you could also use the new TPMDiagnosticstool from the Microsoft Store and use the GetEkCertFromReg parameter
Okay, I need to find myself another hobby, because the device had the manufacturer’s certificate. I really was expecting that one to be missing. So what is going wrong here?
Let’s go back to the TPM tool output from earlier. (yes the one I asked you to take a good look at!!!!)
As shown above, the TPM Maintenance Task was NOT complete (FALSE)! Sounds like something we need to check!
In the pursuit of HAPPY… Uhhh TPM Intel Happyness I was talking about the wonderful TPM Maintenance task. I showed you some bits of what was happening when running this TPM-Maintenance task if you have deleted (why?) the EkCertStore registry keys
But I guess it still needs to deserve some more explanation… And I need to tell you, otherwise an important part to solve the issue is going to be missing
4. TPM-Maintenance Task
Before getting to the bottom of the issue we need to take a better look at this MaintenanceTask. When opening this scheduled task from the GUI, there is not much to see.
As shown above, it only shows us some “custom triggers“, luckily you could still use the schtasks command to export the task.
schtasks /query /xml /tn “\Microsoft\Windows\TPM\Tpm-Maintenance” > “c:\temp\TASK-EXPORT-NAME.xml”)
After opening it, you will notice that TPM-maintenance task relies on the DDL file: Tpmtasks.dll
But there is more information because when taking a better look at the Windows Notification Facility (that opened a nice new world of information) it showed me these 4 triggers. Please take good note of them! (maybe I am going to mention one of them later on?)
This maintenance task has some jobs to perform.
- This wonderful maintenance task is configured to execute at every system startup and will create a threat that will execute the CTpmTasksHandler::Worker function which is implemented in the tpmtasks.dll
It will provision the TPM by launching the CtpmCoreClass::Provision function which is implemented in the tpmcoreprovisioning.dll (More on this great DLL file later on). In this provisioning process, it will generate a new Owner Authorization value, and this value is submitted to the TPM driver. (TPM.Sys). The driver will store the new Owner authorization in the TPM device.
After provisioning the device it will also make sure it will store the required information in the registry. (please read the above line twice…..)
2. Besides the TPM provisioning job, it will also trigger another scheduled task (AikCertEnrollTask)to generate a new Windows Attestation Identity Key (AIK) when it’s not present.
As you could have read above, the TPM-Maintenance task will also store some information in the registry. You can check it out for yourself, just delete all the registry keys inside the CurrentControlSet\Services\TPM\WMI\Endorsement key and run the maintenance task
Before running the TPM Maintenance task I opened Procmon.
As shown above, one of the registry keys the TPM task will set is the EkCertificatePresent registry key! I guess that couldn’t be a coincidence right?
The TPM-Maintenance task is not run that configures that registry key, and the TPMTool is telling us that it is missing the EkCert while IT IS NOT missing!
5. TPM-Maintenance Task Troubleshooting
Now we know that the TPM-Maintenance task is quite important let’s take a look at why it didn’t execute the way it was meant to do! How do we troubleshoot this task?
I decided to start using a different approach! Event Trace Logs! If you don’t know what ETL or WPA means, go read this blog first
Autopilot | wprp | WPA | ETL | Windows Performance Analyzer (call4cloud.nl)
This WPRP file I attached to the blog, has an event provider that could save us! So why not use it?
<EventProvider Id=”EventProvider-Microsoft.Tpm.ProvisioningTask” Name=”470baa67-2d7f-4c9c-8bf4-b1b3226f7b17” />
After downloading the required WPRP file I started the trace and tried to execute the TPM Maintenance task. When the task showed me it failed, I stopped the trace and opened the trace log in the WPA tool.
Guess what I spotted when looking at the TPMTaskInfo and the TpmTaskInfoHR
As shown above, the task wasn’t executed because the EULA was not accepted? Okay, that is definitely something I didn’t know. To be sure I opened the Interactive Disassembler (IDA) tool and opened the tpmtasks.dll to search for the IsEULAAAccepted in the CTpmTasksHandler function
It’s indeed an important requirement for the TPM-maintenance task to be executed. If the EULA was not accepted, it will not run! Looking back, It’s also a little bit mentioned in the WnfStateChangeTrigger!
The question now is, why wasn’t the EULA accepted and what does it check for?
6. EULA Accepted
To let you relax for a couple of seconds and let your brains cool down. Let’s take a look at what we are accepting when we accept the EULA
Fun right? Let’s move on! To get a better understanding of what it was doing I first decided to check out my own working device first with the tpmdiagnostics tool I mentioned earlier. It has a nice parameter: IsEULAAccepted. Let me guess why that parameter was added…..
As shown above, it is mentioning the Registry and SetupDisplayedEula = 0x1. So I opened my own registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OOBE
On my device, it showed me the SetupDisplayedEula key. Guess what happens when that key is gone! The TPM-Maintenance task will refuse to run, only because you didn’t accept the EULA! Stupid you
But now the question remains…. Is that registry key on his device and if not why wasn’t that registry key on his device? Because normally when you are installing your device you will be prompted to accept the License term right?
After I asked the guy (who asked me to help with the attestation issue) to take a look at the registry he sends me a new wonderful screenshot
So I asked him first to manually create that registry key and run the TPM-maintenance task again and if he could run the TPMTool command again
As shown above, after creating the EULA key and running the TPM Maintenance task the TPMTool showed us that the TPM was ready for attestation. Isn’t that cool?
7. EULA NOT Accepted?
So for now question 1 is answered. The key is definitely not on his device… without it, the TPM-maintenance task is not run and without it, the ready for attestation is false
now we still need to answer question 2. It’s obvious now, that the EULA key is necessary but now the question still remains why it wasn’t accepted. After asking some more questions about the setup it hit me
He was using OSDCloud and somehow that EULA registry key was missing. Luckily when running the wonderful OSDCLoud solution, you can resolve this easily by adding the key with a simple reg add command
Another possibility (and better) would be by changing the unattended XML itself and adding the AcceptEula part to the WindowsPE part
After he added the part to the XML all was good! So the case is closed, right? No NO NOOOO and NOOOOOOOOO
8. EKCert
When you have read the last 7 parts, you have probably learned that the presence of the EKCert is necessary but that still doesn’t mean the device is ready for attestation. Let’s find those breadcrumbs!
If you remember the Procmon trace I showed you when I was running the TPM-maintenance task, you will know that one of the parts the “Is ready for Attestation” checks for is the “EkCertificatepresent” exists!
If you simply remove this registry key, you will instantly end up again with the INFORMATION_EK_CERTIFCATE error when running the TPMTool!
Resume: The EkCertificatePresent NEEDS to be configured in the “Taskstates” part in the registry and that Taskstates reg key is only created when the tpm-maintenance task has been run successfully.
I guess it’s obvious that the first thing that the “ready for attestation” checks is the presence of the EkCertificatePresent in the “Taststates” registry key
But that is only one small piece of the pie! Did you have a brain melt when reading the last 7 parts? If so, please strap your seatbelts, and let’s go because there are still some more requirements that are nowhere documented by Microsoft
The problem I was asked to take a look at was resolved but it left me with way more questions. Of course, the EKCert is an important part of making sure your device is ready for attestation but there should be more right?
9. The Missing Pieces
I decided to spend some time on Google first to determine if I could find some more stuff of value. One of the first searches I performed, was to find the missing pieces was: INFORMATION_EK_CERTIFICATE
That one led me to a nice Microsoft Doc which was mentioning the IsReadyInformation Method
Win32_Tpm::IsReadyInformation method – Win32 apps | Microsoft Docs
This website is mentioning the same error code you could get when checking the “isreadyinformation”.
So I guess the “Ready for attestation” could also be using some of these build-in functions?
Please Note: That method could also be used with the Tpmdiagnostics tool to determine if the TPM is ready.
So if the tool also tells the same I must be getting warm I guess? To be sure the EKcert wasn’t the only one I opened Procmon again and applied some filtering and launched the TPM-maintenance task again after removing all the subkeys in the WMI registry key.
As shown above, it is mentioning the Tpmcoreprovisioning.dll, the WBCL, and the EkCertificate. The last one is obviously needed as we witness in the last parts but what about the other two? Let’s focus on the WBCL first.
10. WBCL
When opening the registry and browsing to the control\integrityservices we will notice the PlatformLogfile mentioning the Measured boot logs and PCR Banks
The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering) log of all boot components. Besides the registry, you could also find these logs in the c:\windows\logs\measuredboot folder
I decided to do something stupid… or maybe not so stupid after all. I removed the Windows Boot Configuration Log (WBCL) key to taking a look at the TPM tool output
As shown above, after removing the WBCL key, suddenly my device fails to perform attestation!! and is mentioning INFORMATION_TCG_EVENT_LOG
Sound familiar right? Yes indeed! This one is also mentioned in the Microsoft Doc I showed you earlier
So resume: We already found 2 requirements to make sure the device will be Ready for attestation, the EkCert. and the TCG_event_log. What’s next? The tpmcoreprovisioning.dll of course!
11. The TPMCoreProvisioning.dll
I had the feeling I was still missing some important pieces of the puzzle. I decided to spend some time looking at the tpmcoreprovisioning.dll because it was mentioned in my Procmon trace, so it must be doing something.
As mentioned earlier, when you are curious about what functions a DLL has and what it does, you need to download IDA.
This time I didn’t open the Tpmtasks.dll but the Tpmcoreprovisioning.dll and the first thing that came to mind to search for gave me 2 results
I decided to take a better look at the Graph overview instead of looking at the text. Let me sum up first which “calls” I noticed
- Tbsi_Get_TCG_LOG
- IsEkcertificatePresent
- HasRsaKeyGenVulnerability
- HasActiveCredentialVulnerability
- LostAuths
- IsReadyForStorage
I guess we are on the right track here because it shows us 2 of the requirements I was talking about before. The 2 “vulnerability” ones, speak for themselves I believe or I hope so…..
Shall we take a look at the total Ready for attestation overview first? When looking at the overview below, we will notice that it also shows us a couple of subroutines that are mentioning GetStorageOwnerAuth and TPM2_IsOwned
Please click on the picture to get a bigger overview! And way better is to save it and take a look at it!
12. Storage Root Key / OwnerAuth
This one is more difficult to trace as it doesn’t use a registry or a file location but an internal API call. When spending a lot of time looping through all the functions in the tpmcoreprovisioning.dll and looking at all the subroutines of the IsReadyForStorage function I can only conclude that the TPM needs have a Storage Root Key/SRK
The Storage Root Key(SRK) is the mother of all keys. This “root” key is used to protect TPM keys created by the application. It will make sure those keys cannot be used without a TPM. The Storage Root Key is created when you take ownership of the TPM. When using PowerShell you can clear the ownership by using clear-tpm, after a reboot, the system will automatically initialize the TPM again.
So without a TPM being “Owned” there is NO Storage Root Key! I guess that also explains why the Tpm-maintenance task also checks/creates this admin registry key
When taking a look at what’s inside, we will notice the SRKPub and the StorageOwnerAuth registry keys
Important! The “Is ready for attestation” does not check this registry key! The required information is fetched by using an internal API call by using the DLLs/Driver I was talking about earlier. It should be weird that you could mess with this information, right?
13. Ready For Attestation Requirements
I guess I still need to show you (or everyone who skipped the other parts ..) a small summary of which requirements the “Ready for Attestation” has. Of course, it’s pretty obvious that the TPM in question needs to support attestation in the first place, but that’s a no-brainer.
Also please, pretty please with sugar on top! make sure your device/bios have the proper time set! I know this is also a no-brainer but it could really kick you in the nuts when you forget about it. It isn’t a direct requirement of the Ready For Attestation but, please don’t forget about it!
So let’s assume you have a TPM 2.0 Device (TPM 1.1/1.2 aren’t going to work!!) that also does support TPM attestation, we still have some other hard requirements
13.1 TCG Log / Measured Boot logs
- Win32_TPM::Isreadyinformation
- TPMTool Output
- Registry Key required
- IDA
13.2 Endorsement Key Certificate
- Win32_TPM::Isreadyinformation
- TPMTool Output
- Registry Key required
Please note that: This TaskStates key IS ONLY created if the TPM-Maintenance task has run successfully!!
- IDA
13.3 No Vulnerable Firmware
- Win32_TPM::Isreadyinformation
- TPMTool Output
- Solution
Update the TPM firmware!
Also please note that there is an Allow/Block list that makes sure some TPMs with vulnerable firmware are blocked
13.4 Storage Root Key Present
- Win32_TPM::IsReadyInformation
Please note: It is difficult because I am not 100% sure as I wasn’t able to get reproduces them. Looking at the description, it does look like the two.
My money is on the INFORMATION_NOT_REDUCED… only because it’s next to the other two in the win32_tpm::isreadyinformation overview
- IDA
14. Almost forgot to Mention!
When looking back at the whole flow and what is happening when you check the device if it’s ready for attestation I almost forgot to mention 1 more thing. Okay, Okay, I didn’t forget but I still needed to tell more information first otherwise it wasn’t making any sense.
When you launch your Autopilot pre-provisioning enrollment, this TPM Maintenance task is also executed behind the scenes during this process to make sure the device has all the “requirements” to perform attestation. It will use the TPM-Maintenance task because it has no other method (API) to run that process! I
After the TPM-Maintenance task is executed, the “Autopilot Process” will determine if it could perform attestation by checking the registry for the results.
15. Did I miss something?
Looking back at the few requirements “Is ready for Attestation” has, I am truly missing the “Attestation” checks!
You would expect that when you check if the device is ready for attestation that it also checks if it’s capable of creating an Attestation key (AIK) or/and receiving a certificate for that key (AIK Certificate).
When thinking about it, I guess Microsoft can’t change those already existing checks. Because when Microsoft choices to add the AIK checks out of a sudden it will be a big shitstorm!
Let me explain a little bit more. Do you remember the AMD Attestation blog I wrote?
AMD and TPM Attestation Failing | 0x81039024 | 0x800705b4 (call4cloud.nl)
In this blog, I showed you that the device was looking at the AMD Root Certificate instead of the Intermediate one to perform attestation. Guess what would happen when Microsoft would add those AIK checks out of the sudden? A lot more attestation issues and a lot of complaining customers and suppliers!
Maybe Microsoft could add an additional check? “Is really ready for attestation”
If you want to check for yourself if it’s possible to perform a real attestation we could do so on our own before starting an Autopilot pre-provisioning enrollment. We have multiple options to do so.
15.1 Certreq
Opening a Command Prompt (NOT POWERSHELL!!) and entering certreq -enrollaik -config “”
15.2: TPMDiagnosticsTool
Even the new wonderful tpmdiagnosticstool is capable of testing if its possible to get and install the required Attestation Identity Key Certificate
If you have a Windows 11 device, you can install the tool on your own with PowerShell
DISM /Online /Add-Capability /CapabilityName:Tpm.TpmDiagnostics~~~~0.0.1.0
If you have a Windows 10 device, please click on the picture above, it contains a download link to the zip file
16. Troubleshooting Tool
When you are enrolling a device with Autopilot for pre-provisioned deployments, you could encounter some errors because of some TPM attestation issues. I decided to write a PowerShell script/tool/module to give you an option to first test the device before starting the pre-provisioning!
I wrote a separate blog, explaining what it does.
PowerShell script to troubleshoot TPM attestation issues (call4cloud.nl)
Conclusion:
Hopefully, this blog showed you the true requirements behind the “Is ready for attestation” check. I did my best to tell the story as simply as possible. For now… I am done… “walks to the fridge”
Hi, one of the best in detail descriptions, I’ve seen so far regarding TPM attestation.
We have > 1000 Lenovo L14, T14 and X1 struggling with self-deployment. All devices are staged to our tenant directly by Lenovo.
How can we enforce the EK enrollment during OOBE? Creation of the EULA key (SetupDisplayedEula = 0x1) allows us to request the certificate (certreq -enrollaik -config “”).
But the device is already in ESP failed mode then. Even with sysprep -oobe -reboot the device directly runs into ESP with 0x81039001.
Best regards, Robert
Hi.. Thanx for your compliments!… I am working (and a powershell scripting guy :P) are working an a script to determine check everything “before” you start the enrollment
so you need to press shift+f10 and need to install-script… it.. and run it…
Once you start the enrollment and not having the tpm in a ready state…. your done for 🙂 ….
That would be really, really great!
We are having issues every once in a while with self-deployment. Sometimes Microsoft seems to “remove” the “hard” attestation checks – and best of it: per tenant in waves! Same profile, same hardware, same image fails on one tenant, works on the other and a day later also works for the other and then fails on both a week later… how to do proper troubleshooting? Aargh…
We are having our own custom image in Lenovo factory. We can replace that with an updated version of the existing factory image through “Cloud Recovery” (PXE or USB) from Lenovo Cloud Image Solution.
When you script is ready, we can let the Lenovo engineers incorporate the script in the updated version.
We have been working with Lenovo for one year now to solve that issue with the TPM’s missing endorsement key. Microsoft premier support says the manufacturer did something wrong with the provisioning process during PW already, Lenovo says it’s a Microsoft bug in OOBE…
Most devices having that issue were equipped with TPM from ST Microelectronis, but now also Nuvotron TPM seem to be affected. They all have shown an EK certificate as “additional certificate” and not as “manufacturer certificate” while not working.
After your mitigation steps there is no additional, but a manufacturer certificate but the device refuses to proceed with OOBE.
Hi… you could run wpr -start autopilot.wprp …feel free to reach out to me on twitter as I am curious about the issue
Thanks for that offer!
I’m working remotely (I’m a freelancer) and the guys doing hardware replacements are having their weekend and I do not have access to affected hardware right now but the task has been delegated.
One internal colleague will be back on Monday, has access to hardware and will grab information from the device.
Hi,
Is it possible with Hyper-V VM with a Intel CPU 11th Gen ?
Already a “Ready for Attestation = false”
Your post are awesome. A pleasure to read your job
Regards, Damien
-TPM Present: True
-TPM Version: 2.0
-TPM Manufacturer ID: MSFT
-TPM Manufacturer Full Name: Microsoft
-TPM Manufacturer Version: 8213.275.21.18466
-PPI Version: 1.3
-Is Initialized: True
-Ready For Storage: True
-Ready For Attestation: False
-Information Flags Description:
INFORMATION_EK_CERTIFICATE
-Is Capable For Attestation: False
-Clear Needed To Recover: False
-Clear Possible: True
-TPM Has Vulnerable Firmware: False
-PCR7 Binding State: 2
-Maintenance Task Complete: True
-TPM Spec Version: 1.16
-TPM Errata Date: Wednesday, October 29, 2014
-PC Client Version: 0.00
-Is Locked Out: False
Hi… Thanks !!
To answer your question …nope… did you read the part about the allow/block list ? vTPMs are on that list..
Unfortunately Microsoft does not really tell us, what they are doing: “The device’s TPM hasn’t been whitelisted (not a common issue, unless you’re on a VM – we explicitly block TPMs from VMs).”
“Hasn’t been whitelisted” would mean that they have to whitelist every hardware ID of accepted TPM.
“We explicitly block TPMs from VMs” would mean that they maintain a blacklist of vTPM from hypervisors (Hyper-V, ESXi).
Whitelist – if there is one, why blacklisting (“we explicitly block”) vTPM?
Blacklist – if there is one, why whitelisting TPMs?
Hi…
Before the new tpm serie will be shipped, the vendor needs to tell Microsoft when it will be released.. so Microsoft could create the corresponding aik ca service for it.. only of course if that series is “allowed”/”trustworthy”. To do so the vendor needs to hand over the test results.. and sometimes an already created aik ca will be put offline because of the tpm firmware being not trustworthy
Without tha aik ca… no attestation 🙂
Ok, so it is whitelisting (and corresponds to “has vulnerable firmware”). Premier support refused to answer that question or did not have your insights.
Maybe in addition they actively block vTPM as they say.
where can get the tpmdiagnosticstool .exe file? thanks
Hi,
Updated the blog a bit and also added my powershell script and the links to the tpmdiagnostics tool and how to install it on windows 11
Hi, and thank you for this thorough walkthrough. I learned a lot 🙂