"Resolved: AIK enrollment 404 on Intel PTT, fixed with a discrete TPM"
After HOURS of diagnostics using Claude Pro Opus 5, it saved the day. Thanks to Claude’s help, this was finally, resolved on my end by switching from Intel PTT to a discrete TPM.
I've solved this on my system, and I want to lay out the full before-and-after because this thread contains two different failures that look identical from the user's side. People are applying the fix for one to the other and getting nowhere.
My system did not change at any point during this: an MSI MAG Z890 Tomahawk WiFi (MS-7E32) on BIOS 1.AD0, which was the latest available, running Windows 10 22H2 build 19045.6332. Secure Boot enabled, UEFI boot mode, GPT disk. A check with msinfo32 came back clean on every relevant line.
THE FAILURE: My TPM was healthy. Get-TpmEndorsementKeyInfo reported IsPresent: True, with a valid Endorsement Key certificate issued by: CN=ODCA 2 CSME MTP PCH SVN 01 PTT CA. That certificate was valid from June 2024 through 2049. Nothing was missing, expired, or malformed on my machine.
When I ran the diagnostic command below, Windows built an enrollment URL from the key identifier of the CA that signed that certificate: certreq -enrollaik -config ""
https://intc-keyid-c83cf56e8da47031eefd28d0cac2d86619c08a97. microsoftaik.azure.net/templates/Aik/scep
Microsoft's service responded: GetCACaps: Not Found HTTP/1.1 404 Not Found {"Message":"The authority ... does not exist."} EnrollStage = 140
The timing breakdown is the important part. CreateRequest, SubmitRequest, and SubmitChallengeAnswer all reported 0ms. Enrollment never began. My certificate was never evaluated, because there was no endpoint at that address to evaluate it.
THE DISTINCTION THAT MATTERS: Earlier in this thread, other users reported HTTP 400 with the message "No valid TPM EK/Platform certificate provided." That is a different problem, and the fixes do not transfer between them. A 400 means the request reached Microsoft's service and the certificate chain was rejected. The NV-index intermediate certificate import posted upthread addresses this, and it works for that case. A 404 means no endpoint exists for your EK's issuing CA at all. Nothing is ever submitted, so there is nothing to fix on your end.
In my case I tried the obvious remedies before understanding this, and none of them did anything: updating the BIOS, clearing the TPM, resetting Secure Boot keys, importing intermediate certificates, and considering a Windows 11 upgrade. None could work, because which CA signs your EK is determined when CSME provisions the TPM. It is not a user-configurable property, and no software or firmware setting can change it. If you have the 404, stop troubleshooting your machine. There is nothing wrong with it.
THE FIX I installed a discrete TPM module: an Infineon SLB9670 in the 12-pin SPI form factor (MS-4462 on MSI boards), $24 from Amazon, and seats on the motherboard's JTPM1 header.
In the BIOS, under Settings > Security > Trusted Computing, I changed TPM Device Selection from PTT to dTPM. After a full power cycle, the BIOS Vendor line read IFX instead of INTC, and tpm.msc showed Infineon as the manufacturer with the TPM ready for use.
Running the same command produced a completely different result. The URL was now built from Infineon's CA:
https://ifx-keyid-5d0815951f5f60638a69e7252f3ec4becd7554b2. microsoftaik.azure.net/templates/Aik/scep Issuing CA: CN=Infineon OPTIGA(TM) TPM 2.0 RSA CA 042, O=Infineon Technologies AG, C=DE PkiStatus(0): SCEPDispositionSuccess EnrollStatus(1): Enrolled HTTP/1.1 200 OK EnrollStage = 120
This time CreateRequest took 1422ms, SubmitRequest 265ms, and SubmitChallengeAnswer 297ms. The full challenge-response handshake completed and Microsoft issued an AIK certificate valid through June 2030.
FINALLY, The Call of Duty Secure Attestation Wizard passed, and the game runs. Same board, same BIOS, same Windows installation, same Secure Boot configuration. The only variable that changed was which CA signed the Endorsement Key. Infineon's CA is registered with Microsoft's attestation service; Intel's CSME CA is not.
WARNING: BEFORE YOU TRY THIS — TWO REAL RISKS: Swapping the TPM invalidates anything sealed to the old one. There are two ways this can lock you out of your own machine, and both are easy to avoid if you plan for them.
First, BitLocker. If your drive is encrypted, changing the TPM invalidates the key protector, and you will be prompted for a 48-digit recovery key at boot. Without it you will not get into Windows. Check your status first by running "manage-bde -status" in an elevated command prompt. If protection is on, suspend it before you shut down with "manage-bde -protectors -disable C: -rebootcount 0", and retrieve your recovery key from account.microsoft.com/devices as a backup regardless. Re-enable protection afterward with "manage-bde -protectors -enable C:".
Second, your sign-in PIN. Windows Hello PINs and biometric logins are sealed to the TPM, so your PIN and any fingerprint or face login will stop working after the swap. You will need your actual account password at the login screen. Before you open the case, confirm you know it: lock the machine with Win+L, click Sign-in options, choose the password (key) icon rather than the PIN, and sign in. If that works, you are covered. If you have a Microsoft account and cannot remember the password, reset it at account.live.com while your machine still works.
Afterward, create a new PIN under Settings > Accounts > Sign-in options. Neither of these is difficult, but discovering them at a boot prompt with no way into your machine is a bad afternoon. ONE COMMAND TO IDENTIFY WHICH PROBLEM YOU HAVE If you are stuck on attestation, run this in an elevated command prompt before doing anything else:
certreq -enrollaik -config "" 404, "authority does not exist" Your EK's issuing CA is not registered.
Nothing on your machine will fix it. A discrete TPM is currently the only workaround. 400, "No valid TPM EK/Platform certificate" Certificate chain problem. Try the NV-index intermediate import posted earlier in this thread. 200, SCEPDispositionSuccess Attestation is working. Your problem is somewhere else.
One last problem: When I went back in to change the windows password back to my 4 digit pin, it accepted the change, but it did not “take”. When I rebooted, it wouldn’t accept my 4 digit pin. it still required me to use my full microsoft password.
This is expected fallout from the TPM swap, and it's fixable. Your PIN lives in a Windows Hello container that was sealed to the old Intel PTT. Creating a new PIN writes into that same stale container, which is why it accepts the change and then fails at boot — the container can't be unsealed by the new Infineon chip.
You need to delete the container so Windows builds a fresh one.
First try: the clean method
Open a
normal Command Prompt — not elevated, it has to run in your own user context:
certutil -deleteHelloContainer
Then
reboot. Sign in with your password, go to Settings → Accounts → Sign-in options → Windows Hello PIN, and set up your 4-digit PIN.
Reboot again and test. This works most of the time.
If it still fails: reset the NGC folder
Elevated Command Prompt:
takeown /f C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /r /d y
icacls C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /grant administrators:F /t
Then open File Explorer to that folder and
delete everything inside it — the contents, not the Ngc folder itself. You'll need "Show hidden files" enabled to navigate there.
Reboot, sign in with your password, then set up the PIN again.
Two things to know: this wipes Windows Hello for every account on the machine, so anyone else who signs in will need to re-create theirs. And you may want to restore the folder's permissions afterward, though leaving them is not a security problem on a single-user desktop.
Test it properly
Don't just reboot —
sign out first and test the PIN at the lock screen, then reboot and test again. Some failures only show on a cold boot, which is exactly the pattern you're describing.
If neither works
Check tpm.msc still reports IFX and "The TPM is ready for use." If something knocked it out of the ready state, Hello can't provision against it, and no amount of container deletion will help. Post back what it says.
One small consolation: Attestation is done, the game runs!
QUESTIONS FOR MSI:
Is a CSME/ME firmware update available or planned for the MS-7E32 that would provision PTT under a CA registered with Microsoft's attestation service?
BIOS 1.AD0 was current at the time I resolved this, but the ME region is versioned separately from the BIOS revision, and that is where the EK provisioning happens. For anyone else on an MSI board with this: the JTPM1 header takes a 12-pin SPI module in the MS-4462 form factor. Confirm your header pinout in your manual before ordering, and buy one built on a genuine Infineon SLB9670 — my first module was not detected by the BIOS at all and had to be returned. (from Amazon)
