AADSTS700212: Federated credential audience doesn't match (fix)

What does AADSTS700212 mean?

Microsoft’s error code reference doesn’t list AADSTS700212 (checked 30 October 2026). We found no other Microsoft page that names it either, so the wording below comes from user reports. A user on Microsoft Q&A, running a workload on Azure Kubernetes Service, posted this response (cluster values shortened):

AADSTS700212: No matching federated identity record found for presented assertion audience ‘https://uaenorth.oic.prod-aks.azure.com/<tenant>/<guid>/,https://<cluster>.hcp.uaenorth.azmk8s.io,...’. Please note that the matching is done using a case-sensitive comparison. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion.

The response had "error":"invalid_client". The audience the user’s token carried was the cluster’s own URLs, not api://AzureADTokenExchange.

What Microsoft does document is the audience rule. A federated identity credential lists the audience Entra accepts. Microsoft’s Graph overview: it “says what Microsoft identity platform should accept in the aud claim in the incoming token” and “should be set to api://AzureADTokenExchange for Microsoft Entra ID”. The restrictions page: “You must add a single audience value”. Matching is case-sensitive.

700212 looks like the audience-specific form of 70021; Microsoft doesn’t say so. Its siblings are 700211 (issuer) and 700213 (subject); 70025 means the app has no federated credentials at all.

A lab test on 30 October 2026 returned a different code for this case. With a federated credential whose audience didn’t match the presented token, my lab tenant answered with AADSTS7002121, not 700212:

AADSTS7002121: No matching federated identity record found for presented assertion audience ‘’. The Audience for the federated identity credential…

In the same run, a wrong issuer gave 700211 and a wrong subject gave 700213, so those two are confirmed. For the audience, 7002121 is what Entra returns today on a current tenant. We can’t tell from one tenant whether 700212 is an older code, a different-cloud code, or tied to a particular issuer; the user report above is real and recent, so both appear to exist. If you are writing a detection, match on both. See 7002121 for the lab-reproduced page.

Is it an attack?

No. It means the workload asked its own provider for a token meant for something else.

Pattern	Likely meaning
Kubernetes pod fails and the audience in the error is the cluster URL	The pod is using its default service account token, not a token projected for api://AzureADTokenExchange. Users report this; the Q&A thread above is one case.
GitHub Actions fails after changing the audience input	The workflow asks GitHub for a token with an audience that the credential doesn’t list. The Azure/login README: “The default audience is api://AzureADTokenExchange.”
A non-public Azure cloud	The Azure/login README notes that for non-public clouds “the audience will also need to be updated.” Presumably the credential and the workflow must agree on the cloud’s value.
Case differs only (api://azureadtokenexchange)	Microsoft has moved to case-sensitive matching in stages since 2024. Fix the case on whichever side is wrong.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 700212 lands in. Our reading: app registration failures land in AADServicePrincipalSignInLogs; a user-assigned managed identity may log in the managed identity sign-in log instead. Check:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700212" or ResultSignature == "700212"
| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceTable

Failures per app with the error text. Whether ResultDescription (documented as “the error description for the sign-in operation”) carries the presented audience is our assumption; check a row:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "700212" or ResultSignature == "700212"
| summarize Failures = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Descriptions = make_set(ResultDescription, 5),
            IPs = make_set(IPAddress, 10)
          by AppId, ServicePrincipalName
| sort by Failures desc

How do I fix AADSTS700212?

For developers and pipeline owners:

1. Read the audience from the error message, or decode the token your workload sends and read aud.
2. Make the workload request its token for api://AzureADTokenExchange, unless you deliberately chose another value. Microsoft: “For security reasons, you should pick a value that is unique for tokens meant for Microsoft Entra ID.”
3. Kubernetes: the token Entra receives must be a projected service account token with that audience. The answer in the Q&A thread shows a projected volume with audience: api://AzureADTokenExchange, mounted at /var/run/secrets/azure/tokens. The same answer says the workload identity webhook should inject this when workload identity is enabled. If the mount is missing, check that first.
4. GitHub Actions: leave the audience input of azure/login at its default unless the credential says otherwise.

For admins:

1. Check the credential’s audience. It holds exactly one value, and Microsoft recommends api://AzureADTokenExchange.
2. If you changed it from the default, make sure every workload that uses the credential requests that same value, in the same case.