Registering devices with Intune for management and policy enforcement
The GetCACaps response stating that INTC-KeyId-8b0906fdfc9769a2300771b97a5cee86e01fbb93 “does not exist” requires Microsoft to investigate or provision the corresponding AIK authority; end users cannot add a KeyId to the Microsoft Cloud CA trust database.
What can be confirmed
- Microsoft documents that Intel firmware TPMs obtain a signed endorsement certificate from the TPM manufacturer, while the subsequent AIK certificate is issued by a Microsoft cloud service. The Microsoft Cloud CA validates that it is communicating with a genuine TPM before issuing that AIK certificate.^1^
- Your HTTP response is not merely a generic 404: it identifies the generated
INTC-KeyIdauthority as nonexistent duringGetCACaps, before certificate submission or issuance. - A closely matching Microsoft Q&A case—healthy local TPM and EK chain,
certreq -enrollaik,0x80190194, and an AIK endpoint reporting “authority does not exist”—was classified as a service-side AIK enrollment problem. Its accepted answer states that users cannot manually register TPM KeyIds or modify the Microsoft AIK trust database, with no known client-side workaround.^2^ - Recent public reports associate the exact issuer
ODCA 2 CSME MTP PCH SVN 01 PTT CAwith Intel PTT AIK failures, but there is no published Microsoft trust list or authoritative status for your exact KeyId.^3^
Consequently, public information cannot confirm that the new authority is expected to exist, has been scheduled for onboarding, or has now been added. Only the AIK service team can inspect its current registration state.
Required escalation
Because this is Windows 11 Enterprise, open a Microsoft business support case through the organization’s support agreement or Microsoft Support.^4^ Request routing to the team responsible for Windows TPM attestation / Microsoft Cloud CA / Azure AIK enrollment.
Use a title such as:
Microsoft Cloud CA returns GetCACaps 404 for Intel PTT authority INTC-KeyId-8b0906fdfc9769a2300771b97a5cee86e01fbb93
Include:
- Exact authority and issuer:
-
INTC-KeyId-8b0906fdfc9769a2300771b97a5cee86e01fbb93 -
CN=ODCA 2 CSME MTP PCH SVN 01 PTT CA
-
- UTC timestamps for several failures.
- The supplied
x-ms-request-idvalues. - Complete Event ID 86 XML, including endpoint, stage, status and headers.
- Output from:
certreq -enrollaik -config "" -q - Exported EK certificate and its complete chain. Microsoft documents this extraction method:^5^
$ek = Get-TpmEndorsementKeyInfo $ek.ManufacturerCertificates | Export-Certificate -FilePath C:\Temp\Intel-PTT-EK.cer - BIOS/CSME/PTT firmware versions and the before/after KeyIds.
- The earlier HTTP 400 response for
INTC-KeyId-ea950d..., showing that its authority endpoint resolved at that time. - RICOCHET broker logs demonstrating the downstream impact.
Ask Microsoft to determine:
- Whether the new KeyId is absent, disabled, incorrectly derived, or missing its Intel ODCA chain mapping.
- Whether the corresponding Intel root/intermediate must be onboarded into Microsoft Cloud CA.
- Whether the older authority remains active.
- Whether this platform/firmware combination is approved for AIK issuance.
Do not publish the EK certificate or full diagnostic archive in a public Q&A post; attach them privately to the support case.
Ownership and rollback
Intel/platform firmware provides the EK and manufacturer-issued EK certificate. Microsoft Cloud CA validates that endorsement identity and issues the Windows AIK certificate.^1^ Therefore:
- Intel/ASUS may need to correct firmware or the generated EK chain if it is malformed or unsupported.
- Microsoft controls AIK authority registration and service-side trust; a Windows root-store import cannot create the missing
microsoftaik.azure.netauthority. - No supplied documentation identifies a supported client operation for selecting the old EK issuer or restoring the previous KeyId. A BIOS downgrade should not be treated as a supported rollback unless ASUS explicitly confirms that it restores the previous PTT endorsement hierarchy; it also carries firmware and security risk.
- Since clearing the TPM reproduces the same issuer and KeyId, repeating TPM clears, Secure Boot checks, DNS tests, or local certificate-store repairs will not address this particular 404.
The older INTC-KeyId-ea950d... authority’s current status also cannot be inferred from its earlier HTTP 400 response. That response establishes only that the service recognized or routed the authority at that time; Microsoft must verify whether it still exists now.
References