AADSTS700211: Federated credential issuer doesn't match (fix)

What does AADSTS700211 mean?

Microsoft’s error code reference doesn’t list AADSTS700211 (checked 30 October 2026). Microsoft’s Azure DevOps troubleshooting page does:

AADSTS700211: No matching federated identity record found for presented assertion issuer No federated credential was created or the issuer URL is not correct.

Users report that the full message names the issuer from the token and adds a hint. From a GitHub issue on the azure-workload-identity project:

AADSTS700211: No matching federated identity record found for presented assertion issuer ‘<issuer from the token>’. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion.

A federated identity credential trusts tokens from one issuer. Microsoft’s restrictions page: the issuer “is the URL of the external identity provider and must match the issuer claim of the external token being exchanged”, and “If the issuer claim has leading or trailing whitespace in the value, the token exchange is blocked.” Microsoft announced case-sensitive matching in August 2024 and rolled it out in stages (see 7002138).

700211 looks like the issuer-specific form of 70021; Microsoft doesn’t say so. Its siblings are 700212 (audience) and 700213 (subject). If the app has no federated credentials at all, you get 70025. Microsoft doesn’t document the order in which the three values are checked.

Reproduced in the lab

On 30 October 2026 an automated lab run set this up in my own tenant: one app registration presents its access token as a client assertion, and a second app carries the federated identity credential that is supposed to accept it. With the credential’s issuer set to a different URL than the token’s, Entra returned AADSTS700211:

AADSTS700211: No matching federated identity record found for presented assertion issuer ‘https://login.microsoftonline.com//v2.0’.

The issuer in the message is the one Entra read from the token, not the one on your credential. Compare it character for character with what the credential has.

The sign-in log row isn’t captured yet; see how pages are checked.

Is it an attack?

Usually not.

Pattern	Likely meaning
A new federation setup fails on the first run	The issuer on the credential differs from the token’s iss: a typo, a missing or extra trailing slash, or the wrong URL for the platform.
Azure DevOps fails after converting or recreating a service connection	The credential still holds the other Azure DevOps issuer. Microsoft lists two: https://vstoken.dev.azure.com/<organization id> and https://login.microsoftonline.com/<tenant id>/v2.0 for new connections.
Kubernetes fails after a cluster was rebuilt or the workload moved to another cluster	Each cluster has its own OIDC issuer URL. Likely the credential still points at the old one.
Failures for your app from an issuer and IP you don’t use	Someone presenting a token from their own provider with your app’s client ID. Our reading: it fails because nothing trusts that issuer. Check, but it is not an incident on its own.

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

Microsoft doesn’t document which sign-in table 700211 lands in. Our reading: app registration failures land in AADServicePrincipalSignInLogs, and a user-assigned managed identity may log in the separate managed identity sign-in log, which Microsoft says holds managed identity sign-ins “only”. Check where it lands in your tenant:

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

Failures per app, with the error text and source IPs. ResultDescription is documented as “the error description for the sign-in operation”. Whether it carries the issuer the way the returned message does is our assumption; check a row:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "700211" or ResultSignature == "700211"
| 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

An app that fails from many IPs you don’t own, with an issuer you never configured, is the one to look at. That threshold is a judgement call, not a rule.

How do I fix AADSTS700211?

For developers and pipeline owners:

1. Get the issuer from the error message, or decode your provider’s token and read iss.
2. Set the credential’s issuer to exactly that string: same case, same trailing slash, no spaces. Microsoft’s create-trust page shows the GitHub issuer both as https://token.actions.githubusercontent.com and with a trailing slash, so go by your token.
3. Kubernetes: use the cluster’s own OIDC issuer URL. Microsoft’s example looks like https://aksoicwesteurope.blob.core.windows.net/<guid>/.
4. Azure DevOps: Microsoft says “You can fix the issuer URL by editing and then saving a service connection. If Azure DevOps didn’t create your identity, you must manually update the issuer.” The correct issuer is shown in the service connection’s edit dialog.

For admins:

1. List the federated credentials on the app or managed identity and compare the issuers with the token. An app can hold at most 20.
2. If the issuer in the failures belongs to a provider you never set up, confirm no credential trusts it and review who can edit the app registration.