AADSTS700213: Federated credential subject doesn't match (fix)

What does AADSTS700213 mean?

Microsoft’s error code reference doesn’t list AADSTS700213 (checked 30 October 2026). Microsoft documents it on other pages.

The Azure DevOps troubleshooting page:

AADSTS700213: No matching federated identity record found for presented assertion subject No federated credential was created or the subject is not correct.

Microsoft’s breaking-change notice from August 2024 gives the full message template:

AADSTS700213: No matching federated identity record found for presented assertion subject ‘{subject}’. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.

It adds two things that matter. First, '{subject}' “provides the value of the subject claim contained in the token being sent from the external IdP”, so the error tells you what the token said. Second: “This error template is also used for case-insensitive failures surrounding issuer and audience validation.” So 700213 doesn’t always mean the subject is the problem. Check all three values.

Users see shorter variants too. A Microsoft Q&A post from April 2025 quoted “…presented assertion subject ‘103432211958501047059’. Check your federated identity credential Subject, Audience and Issuer against the presented assertion.” without the case-sensitivity sentence.

Background: a federated identity credential trusts one subject from one issuer. The subject identifies the workload: a GitHub repo plus branch, environment or pull request; a Kubernetes service account; an Azure DevOps service connection; a Google service account ID. Microsoft’s create-trust page: “The values must exactly match the configuration”.

700213 looks like the subject-specific form of 70021; Microsoft doesn’t say so. Its siblings are 700211 (issuer) and 700212 (audience). When the subject is right apart from letter case, the Azure/login README and user reports show 7002138 instead. If the app has no federated credentials at all, you get 70025.

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 subject set to a value the token doesn’t carry, Entra returned AADSTS700213:

AADSTS700213: No matching federated identity record found for presented assertion subject ‘’.

As with the issuer, the subject printed is the one from the token. Copy it from the message into the credential rather than typing it out.

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

Is it an attack?

No. It is almost always a subject that doesn’t match.

Pattern	Likely meaning
GitHub: the subject in the error ends in :environment:<name> but the credential trusts a branch	The job declares an environment. Microsoft’s create-trust page uses repo:<org>/<repo>:environment:<name> for jobs tied to an environment, and :ref:<ref path> only for jobs that aren’t. A Q&A post shows exactly this mismatch (it has no answer).
GitHub: the credential was made in the portal and includes @<number> after the org or repo	The Azure/login README: portal subjects of the form repo:<org>@<org-id>/<repo>@<repo-id>:... never match, because “The OIDC token GitHub sends does not include those numeric IDs”.
GitHub: one credential per branch, and a new branch, tag or pull request fails	Microsoft: “Pattern matching isn’t supported for branches and tags.” Each one needs its own credential, or a flexible credential (preview, below).
Azure DevOps: worked before, fails after a rename	Microsoft lists renaming the organization, project or service connection as a cause, for the sc:// subject.
The subject looks identical	Look for an invisible difference. In the April 2025 Q&A case above, a moderator reported that a trailing full stop in the credential’s subject was the cause. Letter case gives 7002138.
Failures for your app with a subject from a repo or account you don’t own	Someone presenting their own token with your app’s client ID. Our reading: it fails because nothing trusts that subject. 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 700213 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 == "700213" or ResultSignature == "700213"
| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceTable

Failures per app, with the error text. If ResultDescription holds the same text as the returned message (our assumption; check a row), it shows the subject the token presented:

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

For an app that worked before, check whether its federated credentials were changed. A third-party write-up (trackr.live) reports this logs as Update application with a modified property FederatedIdentityCredentials; Microsoft doesn’t document that name on the pages we checked:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName == "Update application"
| mv-expand Target = TargetResources
| mv-expand Prop = Target.modifiedProperties
| where tostring(Prop.displayName) == "FederatedIdentityCredentials"
| project TimeGenerated,
          App = tostring(Target.displayName),
          Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
          OldValue = tostring(Prop.oldValue),
          NewValue = tostring(Prop.newValue)

How do I fix AADSTS700213?

For developers and pipeline owners:

1. Copy the subject from the error message. In GitHub Actions, the Azure/login README says the run log shows it under Federated token details as subject claim.
2. Set the credential’s subject to exactly that string. The README: “set the federated credential Subject to exactly match the subject claim”.
3. Also compare the issuer and audience, because Microsoft uses this message for those failures too.
4. GitHub: pick the entity type that matches the job. A job with environment: needs an Environment credential. A job without one needs Branch or Tag with the exact ref. Pull request runs need repo:<org>/<repo>:pull-request.
5. Kubernetes: the subject is system:serviceaccount:<namespace>:<service account>. A renamed namespace or service account needs a new credential.

For admins:

1. Azure DevOps after a rename: Microsoft names the cause but gives no fix. Update the subject on the identity to the new sc:// value.
2. Many branches: an app or user-assigned managed identity holds at most 20 federated credentials, and wildcards aren’t supported in ordinary credentials. Microsoft’s flexible federated identity credential (preview) uses a claimsMatchingExpression such as claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and supports issuers “such as GitHub, GitLab, and Terraform Cloud”. It is a preview; weigh that before relying on it.
3. Don’t widen trust to make an error go away. A subject that matches more branches or environments than needed would let more workflows act as the app.