AIK enrollment fails with 0x80070490 on Microsoft Pluton (EK issuer name mismatch) - blocks Call of Duty secure attestation, latest OEM BIOS does not help
My Microsoft Azure Attestation (MAA) check fails, which blocks Call of Duty (RICOCHET) secure attestation. My TPM is locally healthy and fully provisioned, and my OEM firmware is already the newest available for my model. The failure reproduces through Microsoft's own tooling AND through the game vendor's official diagnostic tool.
DEVICE
- Model: ASUS ROG Strix G16 (G614FR), ASUSTeK COMPUTER INC.
- OS: Windows 11, build 26200.9445, fully updated (all Windows Updates applied)
- BIOS: G614FR.317 (ASUS release 2026/08/27). This is the newest version on ASUS's official support site. I updated from G614FR.316 and the problem persists.
- Boot: UEFI, GPT, Secure Boot enabled
TPM (Get-Tpm)
- ManufacturerIdTxt: MSFT (Microsoft Pluton security processor)
- ManufacturerVersionFull20: 6.4.1.400
- TpmPresent / TpmReady / TpmEnabled / TpmActivated / TpmOwned: all True
- TpmLockedOut: False
EK CERTIFICATE (Get-TpmEndorsementKeyInfo)
- Subject: CN=PlutonId 04812ADF3B4F9E7B9228EFC6FD82620B00, OU=6.4.1.400, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
- Issuer: CN=00812ADF3B4F9E7B9228EFC6FD82620B00, OU=DEVICE EKICA DFID00A60F11, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
- Serial: 04812ADF3B4F9E7B9228EFC6FD82620B00
- Validity: 2021-09-15 to 2039-12-16
- Thumbprint: C113CAB2813A9CC136B4A5DFF70F26CF0055E4FC
REPRODUCTION (both performed with Administrator rights)
- Command line: certreq -enrollaik -machine Result: Certificate Request Processor: Element not found. 0x80070490 (WIN32: 1168 ERROR_NOT_FOUND)
- Activision's official Secure Attestation Wizard (CODSecureAttestationWizard.exe v1.1.3, downloaded from Activision's official support article updated 2026-08-06):
- The wizard reports its "authorization key" item as failed.
- When I click "Generate Key", which triggers enrollaik.exe, the key generation fails.
WHAT I HAVE ALREADY DONE
- Confirmed TPM 2.0 is enabled and healthy (tpm.msc reports "TPM is ready for use")
- Confirmed Secure Boot enabled, UEFI boot mode, GPT disk
- Updated BIOS to the newest version available for this model (G614FR.317)
- Applied all Windows Updates and performed a full Restart (not fast startup)
- Ran the vendor's official attestation wizard as described above
MY ANALYSIS
The AIK enrollment appears to fail because the EK certificate issuer is resolved by subject name, and my issuer name does not match what the backend expects. My issuer CN is a raw hex identifier (00812ADF3B4F9E7B9228EFC6FD82620B00) with OU=DEVICE EKICA DFID00A60F11, whereas Pluton EK chains reported to attest successfully use the form CN=PLUTON Firmware SVNxx, OU=FIRMWARE EKICA DFID00B20F40. My EK subject indicates Pluton firmware 6.4.1.400. This matches the previously reported class of issue where a Pluton firmware SVN change renames the issuing CA without a corresponding update to the Azure Attestation trusted EK certificate registry.
QUESTIONS
- Is the EK certificate chain for DFID00A60F11 (issuer CN 00812ADF3B4F9E7B9228EFC6FD82620B00, Pluton firmware 6.4.1.400) currently onboarded in the Azure Attestation trusted EK certificate registry?
- If it is not onboarded, can it be onboarded or corrected on the service side? This appears to be a server-side trust list issue that I cannot remediate locally.
- Is an additional OEM firmware update required, or is a server-side update sufficient? If OEM firmware is required, what specifically must change?
- Is there any end-user workaround while this is unresolved?
I can provide any additional diagnostics on request: full Get-Tpm and Get-TpmEndorsementKeyInfo output, TPM-WMI operational and admin event logs, TCG event log, and the exact error code returned by the MAA endpoint.