How I Fixed Call of Duty / Warzone TPM Attestation on an Older Intel Z370 PC

I ran into an unusually difficult TPM attestation problem while trying to get Call of Duty HQ / Warzone working correctly on Windows 11.

Everything looked correct on the surface. I had TPM 2.0 through Intel PTT, Secure Boot was enabled, Windows recognized the TPM, and my BIOS was updated.

Yet Call of Duty still would not properly accept the system's TPM/attestation state.

After going much deeper than the normal enable TPM and Secure Boot fixes, I discovered that my Intel PTT TPM existed and worked for storage, but Windows could not properly attest it because its Endorsement Key certificate was unavailable.

In my case, the major turning point was updating the system's Intel Management Engine / CSME firmware from 11.8.80.3746 to 11.8.97.4739.

After the firmware update and TPM reprovisioning, the missing Intel EK certificate appeared, Windows became capable of attestation, and Call of Duty finally recognized the system as compliant.

My System

The important parts of my configuration were:

• Motherboard: ASUS ROG Strix Z370-I Gaming
• BIOS: 3005
• TPM: Intel PTT / TPM 2.0
• OS: Windows 11
• Intel CSME: 11.8.x

This is an older Intel platform, which turned out to matter.

The Problem

Initially, basic Windows TPM checks looked perfectly normal. Running Get-Tpm showed essentially:

• TpmPresent: True
• TpmReady: True
• TpmEnabled: True
• TpmActivated: True
• TpmOwned: True
• Manufacturer: INTC

If I had stopped there, I would have assumed the TPM was fine. But Call of Duty's attestation still failed.

The breakthrough came from running tpmtool getdeviceinformation. Windows was reporting:

• TPM Present: True
• TPM Version: 2.0
• Ready For Storage: True
• Ready For Attestation: False
• Is Capable For Attestation: False

That distinction was extremely important. The TPM could be present, enabled, initialized, and usable by Windows while still being incapable of performing the attestation COD required.

Finding the Missing EK Certificate

I then checked the TPM's Endorsement Key with Get-TpmEndorsementKeyInfo -HashAlgorithm Sha256. The EK itself existed, with IsPresent: True, but there was no manufacturer EK certificate.

• ManufacturerCertificates: {}
• AdditionalCertificates: {}

Running tpmdiagnostics CheckEkCertState confirmed it: EKCertState is NotPresent.

Windows' deeper Measured Boot diagnostics told the same story. The machine had HealthStatus: Cannot be attested and EkCertIsAvailable: false, while the fundamental TPM and Secure Boot components were working.

• TpmPresent: true
• TpmMeetsMinimumVersion: true
• TpmIsResponsive: true
• TcgLogFound: true
• PcrsMatchTcgLog: true
• SecureBootEnabled: true

So the TPM itself was not simply broken. The attestation chain was broken.

Intel's EK Certificate Server Was Not Solving It

TpmDiagnostics could generate Intel EK certificate URLs with tpmdiagnostics EKCertificateURL, but trying to retrieve or install the certificate failed.

For example, tpmdiagnostics GetEkCertFromWeb rsa-ek.cer returned Command failed, ASN1 bad tag value met, HR: 0x8009310B. Checking the generated Intel URLs manually resulted in HTTP 404 responses.

I also tried tpmdiagnostics InstallEkCertThroughCoreProv, which failed with Unable to fetch EK Certificate if TPM-generated EPS after a TPM2_ChangeEPS, HR: 0x80290603.

At this point, repeatedly clearing the TPM or reinstalling Windows was not looking like the real solution.

Digging Into Intel Management Engine / CSME

Because Intel PTT is firmware-based, I started investigating the Intel Management Engine / CSME firmware underneath it. Intel's firmware tools reported that my system was running FW Version: 11.8.80.3746.

Backing Up the Firmware

Before modifying anything, I wanted backups. Using Intel Flash Programming Tool, I dumped the current ME region with .\FPTW64.exe -me -d me_current.bin.

FPT successfully read the approximately 2.5 MB ME region. I then verified the dump directly against flash with .\FPTW64.exe -me -verify me_current.bin, which returned RESULT: The data is identical and FPT Operation Successful.

I also kept previous/original firmware dumps and calculated SHA-256 hashes with Get-FileHash .\me_original.bin -Algorithm SHA256 and Get-FileHash .\me_current.bin -Algorithm SHA256.

Using Python + ME Analyzer to Verify the Firmware

I did not want to blindly flash a firmware file simply because its filename said 11.8. I installed Python and used ME Analyzer to inspect my existing firmware dump.

My current firmware reported:

• Family: CSE ME
• Version: 11.8.80.3746
• Release: Production
• Type: Extracted
• SKU: Consumer H
• TCB Security Version: 3
• Version Control Number: 289
• Production Ready: Yes

Then I analyzed the candidate update:

• Family: CSE ME
• Version: 11.8.97.4739
• Release: Production
• Type: Extracted
• SKU: Consumer H
• TCB Security Version: 3
• Version Control Number: 343
• Production Ready: Yes

This was important because both images identified themselves as CSE ME, Consumer H, and Production, rather than relying solely on the download's filename.

The Actual Turning Point: Updating CSME

I then updated Intel CSME from 11.8.80.3746 to 11.8.97.4739.

After rebooting, Intel MEInfoWin64 confirmed:

• FW Version: 11.8.97.4739 H
• CurrentState: Normal
• ManufacturingMode: Disabled
• InitComplete: Complete
• BUPLoadState: Success
• ErrorCode: No Error
• Intel Platform Trust Technology: PRESENT/ENABLED
• Re-key needed: False

This firmware update was the major turning point in the repair.

What Happened to the TPM After the Firmware Update

After the update and subsequent TPM provisioning, I reran tpmtool getdeviceinformation. The results had changed:

• TPM Present: True
• TPM Version: 2.0
• Manufacturer: Intel
• Ready For Storage: True
• Ready For Attestation: True
• Is Capable For Attestation: True
• Clear Needed To Recover: False
• TPM Has Vulnerable Firmware: False
• Bitlocker PCR7 Binding State: Binding Possible
• Maintenance Task Complete: True

That is exactly what I had been trying to achieve. Then tpmdiagnostics CheckEkCertState returned EKCertState is Present. Previously, that had been EKCertState is NotPresent.

The Intel EK Certificate Finally Appeared

This was probably the most satisfying confirmation. Running Get-TpmEndorsementKeyInfo -HashAlgorithm Sha256 now returned an actual manufacturer certificate.

Instead of ManufacturerCertificates: {}, I now had certificate information including TPMVersion=id:00020000, TPMModel=SPT, TPMManufacturer=id:494E5443, and an issuer containing CN=www.intel.com, OU=TPM EK intermediate for SPTH_EPID_PROD_RK_0, O=Intel Corporation.

The same TPM that previously had no manufacturer certificate now had its Intel EK certificate.

Windows AIK Started Working Too

I checked Windows' Attestation Identity Key with tpmdiagnostics IsWindowsAIKInstalledInNCrypt. Windows reported that Windows AIK is installed and Windows AIK Cert is installed.

I could also successfully generate a fresh platform claim with tpmdiagnostics GetWindowsAIKPlatformClaim fresh. The result was: Successfully created the claim.

Finally, tpmdiagnostics MaintenanceTaskStatus reported: TPM maintenance task is completed.

The Final Measured Boot Confirmation

Originally Windows' Measured Boot report said HealthStatus: Cannot be attested and EkCertIsAvailable: false. After the CSME update and reprovisioning, the newest report changed to HealthStatus: Attestable.

• TpmPresent: true
• TpmMeetsMinimumVersion: true
• TpmIsResponsive: true
• EkCertIsAvailable: true
• EkCertRsa2048IsAvailable: true
• TcgLogFound: true
• PcrsMatchTcgLog: true
• WindowsAikCertRsa2048IsAvailable: true
• SecureBootEnabled: true

That was the strongest evidence that the repair actually worked. It was not simply that Get-Tpm looked healthy anymore. Windows' actual attestation health evaluator considered the machine attestable.

Before vs. After

• Before: CSME 11.8.80.3746. After: CSME 11.8.97.4739.
• Before: TPM 2.0 detected and ready for storage. After: TPM 2.0 detected and ready for storage.
• Before: attestation unavailable. After: ready for attestation.
• Before: EK certificate missing. After: Intel EK certificate present.
• Before: ManufacturerCertificates {}. After: Intel certificate populated.
• Before: AIK/attestation problems. After: AIK certificate installed.
• Before: Cannot be attested. After: Attestable.
• Before: COD attestation failed. After: COD system compliant.

That is why I consider the CSME firmware update the central fix in my case.

About the SCEP Errors

I still encountered Windows SCEP/AIK certificate-enrollment errors such as SCEPDispositionPendingChallenge, EnrollUnknown, TPM_E_KEY_NOT_LOADED, and 0x8029040f.

These initially looked extremely concerning. However, correlating their timestamps with Windows Event Viewer showed that at least one of the SCEP errors I thought caused a system freeze actually happened after Windows had already rebooted.

So do not assume SCEP error equals system crash simply because the SCEP error is near a Kernel-Power event. Windows Event Viewer timestamps matter.

Secure Boot Was Also Verified

During the troubleshooting process, I also verified Secure Boot and worked through the newer Windows UEFI CA 2023 certificate state. PowerShell's Confirm-SecureBootUEFI returned True.

The firmware Secure Boot database was also verified to contain the newer Windows UEFI CA 2023 certificate. That allowed me to rule out another possible source of COD's compliance failure.

What I Think Was Happening

My working theory based on the before/after diagnostics is that the old Intel CSME/PTT state allowed Intel PTT TPM to exist and work for normal storage operations, but the usable manufacturer EK certificate was unavailable.

That meant Windows could not establish the expected attestation identity, Ready For Attestation stayed False, and COD attestation/compliance failed.

After updating to CSME 11.8.97.4739, PTT/TPM reprovisioning made the EK certificate available, Windows AIK became available, Measured Boot validated, Ready For Attestation became True, HealthStatus became Attestable, and COD recognized the system as compliant.

I cannot prove that every machine showing this symptom has the exact same root cause, but the before-and-after results on my machine make the firmware update/reprovisioning connection very strong.

Commands That Helped Me Diagnose It

For anyone diagnosing a similar problem, these were the most useful Windows commands:

• Get-Tpm
• tpmtool getdeviceinformation
• Get-TpmEndorsementKeyInfo -HashAlgorithm Sha256
• tpmdiagnostics CheckEkCertState
• tpmdiagnostics EkInfo
• tpmdiagnostics IsWindowsAIKInstalledInNCrypt
• tpmdiagnostics GetWindowsAIKPlatformClaim fresh
• tpmdiagnostics MaintenanceTaskStatus
• Confirm-SecureBootUEFI

For Intel CSME diagnostics I used Intel's MEInfoWin64, FPTW64, and FWUpdLcl64. Python plus ME Analyzer was extremely useful for determining exactly what firmware images I was dealing with before performing the update.

Important Warning About Flashing CSME

I do not recommend blindly copying my firmware update onto another computer. The important lesson is not download 11.8.97.4739 and flash it.

The real lesson is this: if your Intel PTT TPM is present and functional but Windows reports Ready For Attestation: False and the EK certificate is missing, investigate the platform's CSME/PTT firmware and provisioning state.

Firmware must match the appropriate Intel ME generation, platform, SKU, and update mechanism. Before touching mine, I:

• Dumped the existing ME firmware
• Maintained backups
• Verified the dump against the actual flash
• Calculated SHA-256 hashes
• Inspected the original firmware with ME Analyzer
• Inspected the replacement firmware with ME Analyzer
• Confirmed the CSE ME family and Consumer H SKU
• Used Intel's firmware tooling rather than blindly writing the entire SPI image
• Verified ME health after the update
• Verified TPM, EK, AIK, and Measured Boot health afterward

TL;DR

My Call of Duty TPM problem was not simply that TPM or Secure Boot were disabled.

The machine originally showed TPM 2.0 present, Ready For Storage: True, Ready For Attestation: False, EKCertState: NotPresent, ManufacturerCertificates: {}, and HealthStatus: Cannot be attested.

I backed up and verified the Intel ME firmware, used Python plus ME Analyzer to identify the existing and replacement firmware, and updated Intel CSME from 11.8.80.3746 to 11.8.97.4739.

After the update and TPM reprovisioning, Windows reported Ready For Attestation: True, Is Capable For Attestation: True, EKCertState: Present, Intel Manufacturer EK Certificate: Present, Windows AIK Certificate: Installed, HealthStatus: Attestable, and Secure Boot: Enabled.

Call of Duty then recognized the system as compliant.