AADSTS7002121: Federated credential audience doesn't match the assertion (fix)

What does AADSTS7002121 mean?

Microsoft’s error code reference doesn’t list AADSTS7002121 (checked 30 October 2026). We found no other Microsoft page that names it either. The wording below is from a lab run, not from a Microsoft page.

A federated identity credential on an app registration or a user-assigned managed identity says which external token Entra will exchange for an access token. It pins three values: issuer, subject and audience. 7002121 is the audience failing to match.

Microsoft’s Graph overview describes the property: audiences is “the audience that can appear in the external token”, it “says what Microsoft identity platform should accept in the aud claim in the incoming token”, and it “should be set to api://AzureADTokenExchange for Microsoft Entra ID”. The restrictions page adds “You must add a single audience value, which has a limit of 600 characters”, and lists the error a wrong count gives at configuration time: “Federated identity credentials must have exactly one audience.”

The accepted value depends on the cloud. For a managed identity acting as the credential, Microsoft lists:

Cloud	Audience value
Microsoft Entra ID global service	api://AzureADTokenExchange
Microsoft Entra ID for US Government	api://AzureADTokenExchangeUSGov
Microsoft Entra China operated by 21Vianet	api://AzureADTokenExchangeChina

Matching is case-sensitive. Microsoft’s breaking-changes page, under “Federated Identity Credentials now use case-sensitive matching” with an effective date of September 2024: “Previously, when matching the Federated Identity Credential (FIC) issuer, subject, and audience values against the corresponding issuer, subject, and audience values contained in the token sent to Microsoft Entra ID by an external IdP, case-insensitive matching was used. To provide more fine-grained control to customers, we’re switching to enforcing case-sensitive matching.”

The siblings tell you which of the three values failed:

• 700211 issuer doesn’t match
• 700213 subject doesn’t match
• 7002138 subject matches except for case
• 700212 audience doesn’t match, in user reports
• 70025 the app has no federated credentials at all

700212 carries almost the same message text and the same meaning. Users report 700212; our lab tenant returned 7002121 for the audience case on 30 October 2026. We can’t tell from one tenant whether 700212 is older, cloud-specific or issuer-specific, so treat the two as one condition and match on both in detections.

Reproduced in the lab

On 30 October 2026 an automated lab run created an app registration with a federated identity credential, then presented a token whose aud claim was a GUID rather than the credential’s configured audience. Entra returned AADSTS7002121:

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

The lab records only the first line of error_description, cut at about 160 characters, so the sentence about the configured audience is truncated. The same run confirmed the siblings on the same app: a wrong issuer gave 700211, a wrong subject gave 700213, a subject differing only in case gave 7002138, and an app with no credential at all gave 70025. So Entra does distinguish the three fields, and 7002121 is specifically the audience.

No sign-in log row was captured. See how pages are checked.

Is it an attack?

No. The workload asked its own identity provider for a token meant for something else, or the credential and the workload disagree about the audience string.

Pattern	Likely meaning
A new pipeline or workload fails on its first federated run	The token is requested for the provider’s default audience rather than api://AzureADTokenExchange.
Kubernetes pod fails and the audience in the error is a cluster URL	The pod is using its default service account token, not one projected for the credential’s audience.
Works in the commercial cloud, fails in US Government or China	The audience must be that cloud’s value from the table above.
Only the case differs	Matching has been case-sensitive since the September 2024 change. Fix the case on whichever side is wrong.
The error appears right after someone edited the credential	The audience was changed on one side only. A credential holds exactly one audience value.

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

Which sign-in table 7002121 lands in is undocumented. Our reading: an app registration’s token request lands in AADServicePrincipalSignInLogs, and a user-assigned managed identity presenting the token may land in the managed identity sign-in log instead. Start with a union so you don’t miss it:

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

The query filters ResultSignature as well as ResultType because the two tables document the column differently. For SigninLogs, ResultType “provides the 5-6 digit error code that’s generated during a sign-in event”; for AADServicePrincipalSignInLogs it is described only as “Success or Failure”, with ResultSignature holding “the error code, if any, for the sign-in operation”. Look at one failed row in your own workspace and keep the filter that matches.

Which app and which credential, with the error text:

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

FederatedCredentialId is documented as “Th identifier of an application’s federated identity credential if a federated identity credential was used to sign in” (the typo is Microsoft’s), and ClientCredentialType as “the type of client credential used”. Whether either column is filled in when the match fails is not documented; check a row before building a rule on it. The same goes for whether ResultDescription carries the presented audience.

A failing workload that also succeeds tells you the audience it should be sending. Compare the two:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where AppId == "<app id of the failing app>"
| summarize Rows = count(), LastSeen = max(TimeGenerated)
          by ResultType, ResultSignature, FederatedCredentialId, ClientCredentialType
| sort by LastSeen desc

A starting point for alerting: more than about 20 of these in an hour for one app usually means a deployment went out with the wrong audience, not an attack.

How do I fix AADSTS7002121?

For developers and pipeline owners:

1. Read the audience out of the error message, or decode the token your workload presents and read its aud claim.
2. Request the token for api://AzureADTokenExchange, in that exact case, unless your credential deliberately uses another value. Use the cloud-specific value from the table above outside the commercial cloud.
3. Kubernetes: mount a projected service account token with that audience instead of the pod’s default token.
4. GitHub Actions and Azure DevOps: leave the audience input of the login step at its default unless the credential says otherwise.
5. If the issuer or the subject is also wrong, you will see 700211 or 700213 next. Fix all three against the values in the error messages.

For admins:

1. Open the app registration or managed identity, Certificates & secrets > Federated credentials, and read the audience. It holds exactly one value.
2. If you changed it from api://AzureADTokenExchange, every workload using that credential must request the same string, in the same case.
3. Don’t fix a case mismatch by recreating the credential with a different case. Fix whichever side is wrong and leave the other alone, so the other workloads using it keep working.