Azure AIK enrollment 404 "authority does not exist" for INTC-KeyId-824b22601f... (Intel CSME ADL PTT, Raptor Lake HX) - COD attestation fails

The unchanged GetCACaps 404 after validating the Intel PTT and EK chain should be escalated as a Microsoft AIK service authority-recognition issue; there is no supported client-side method to create or register that INTC-KeyId authority.

What the 404 establishes

Your request reaches microsoftaik.azure.net, and that service explicitly returns:

The authority ... does not exist.

Because this happens at GetCACaps, before certificate submission or issuance, it is distinct from failures such as an unsupported AIK key algorithm or a rejected EK certificate later in enrollment.

A closely matching accepted Microsoft Q&A response for the same command, stage, HTTP status, and message concludes that the AIK authority is not recognized by the backend. It also states that end users cannot manually register TPM KeyIDs or modify the Microsoft AIK trust database, with no known client-side workaround when the authority entry is absent.^1^

Your additional intermediate certificates only affect local chain discovery and validation. They cannot create the authority named by the service, so the unchanged 404 is expected. Windows certificate chaining selects locally available issuer candidates and constructs a trust path; that is separate from the remote service’s authority configuration.^2^

Do not clear the TPM, reinstall Windows, or repeatedly alter the certificate stores for this specific response. Clearing the TPM deletes TPM-backed secrets and would not provision a missing remote authority.

Is this Intel authority expected to exist?

The public documentation does not publish a catalog mapping Intel EK issuing keys to INTC-KeyId-* AIK authorities. It therefore cannot confirm whether this exact authority:

INTC-KeyId-824b22601fdf262120c641d841f0fe2733bfa1f5

was expected to be onboarded, was removed, or was generated from an unsupported/unrecognized Intel issuer.

What is documented is the intended architecture:

• Intel firmware TPMs obtain a signed endorsement certificate from the manufacturer.
• Windows creates a TPM-protected AIK.
• Microsoft’s cloud CA verifies that it is communicating with a real TPM possessing that AIK, then issues the AIK certificate.
• The AIK certificate is subsequently used for device-health attestation.^3^

Thus, the exact authority’s expected enrollment status requires investigation by Microsoft and potentially Intel/MSI; it cannot be resolved from the client.

Escalation package

Open a Microsoft support case under Windows security/TPM attestation and request routing to the team responsible for Microsoft AIK/Cloud CA enrollment. Include:

1. Full certreq -enrollaik -config "" output.
2. The complete INTC-KeyId authority.
3. UTC timestamp and x-ms-request-id.
4. Windows build, BIOS version, CPU/platform, PTT model, manufacturer and firmware versions.
5. Sanitized EK leaf certificate and full chain.
6. tpmtool getdeviceinformation output.
7. TPMDiagnostics results showing ekchain, ekchainNV, and the enrollment stage.
8. A note that local chain completion changed from one to four certificates but the same authority returned the same 404.
9. References to other affected ADL/Arrow Lake systems, clearly separated by their exact HTTP stage and status.

Also open an MSI support case asking MSI to verify that this model’s CSME/PTT firmware and EK provisioning are valid for the installed CPU/platform. Microsoft documents that Intel firmware TPM endorsement-certificate provisioning can involve Intel’s online EK certificate service, so OEM/Intel provisioning remains relevant even though your current failure is returned by Microsoft’s AIK endpoint.^3^

Is RICOCHET using the same lookup?

That cannot be confirmed from public Microsoft documentation. The documented Windows flow requires an AIK certificate before TPM-backed health information can be reported, and the resulting health token contains AIK information.^3^ However, no available public source documents whether RICOCHET:

• calls this same Microsoft AIK endpoint directly,
• consumes a Windows attestation result that depends on it,
• uses another attestation provider, or
• maps several failures to the generic “BIOS firmware: Update Required” message.

The matching timing and missing AIK certificate make a dependency plausible, but not proven. Submit the certreq failure, authority, request ID, and timestamp to Activision support and ask them to correlate the game’s attestation transaction. Only Activision can confirm how that RICOCHET result was derived.

References

1. Windows AIK Certificate Enrollment Fails with 404 Not Found (Pluton TPM / MSFT-KeyId) - Microsoft Q&A
2. Microsoft Cloud PKI fundamentals
3. Control the health of Windows devices