Last Updated on January 30, 2023 by rudyooms

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!

I will divide this blog into multiple parts

1. Introduction
2. The Issue
3. Troubleshooting Information_EK_Certificate
4. TPM-Maintenance Task
5. TPM-Maintenance Task Troubleshooting
6. EULA Accepted
7. EULA NOT Accepted?
8. EKCert
9. The Missing Pieces
10. WBCL
11. TpmCoreProvisioning.dll
12. Storage Root Key / OwnerAuth
13. Ready For Attestation Overview
14. Almost forgot to Mention!
15. Did I miss something?
16. Troubleshooting Tool

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.

1. 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”