AADSTS7002138: Federated credential subject differs in case (fix)

What does AADSTS7002138 mean?

Microsoft’s error code reference doesn’t list AADSTS7002138 (checked 30 October 2026). The README of Microsoft’s Azure/login GitHub Action documents it in its troubleshooting section:

Error: AADSTS7002138: No matching federated identity record found for presented assertion subject ‘repo:<org>/<repo>:ref:refs/heads/main’. The subject matches with case-insensitive comparison, but not with case-sensitive comparison.

A user on Microsoft Q&A posted the full response, which goes on:

…Check your federated identity credential Subject, Audience and Issuer against the presented assertion. See documentation at: https://learn.microsoft.com/entra/workload-id/workload-identity-federation. See breaking change notification and remediation at: https://learn.microsoft.com/en-us/entra/identity-platform/reference-breaking-changes#august-2024.

The breaking change it points to: in August 2024 Microsoft announced that federated identity credential issuer, subject and audience values are matched case-sensitively, where they used to be matched case-insensitively. Microsoft’s invalid example:

• Token subject: repo:contoso/contoso-org:ref:refs/heads/main
• FIC subject: repo:Contoso/Contoso-Org:ref:refs/heads/main

The notice rolled the change out in stages: first to apps and managed identities created after 14 August 2024, then to inactive ones from 27 September 2024, and “For active applications, case-sensitive matching comes at a later date to be communicated.” That explains setups that ran for years and then broke with no change on your side.

Our reading: 7002138 is a more specific form of 700213. The notice itself said the 700213 message would be revamped to mention case. 7002138 goes further and tells you case is the only difference. Microsoft doesn’t document whether there are matching codes for issuer or audience that differ only in case; the case-only codes we found all concern the subject. See 70021 for the general no-match code and 700211 and 700212 for issuer and audience.

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 the same value in different capitals, Entra returned AADSTS7002138 rather than 700213:

AADSTS7002138: No matching federated identity record found for presented assertion subject ‘’. The subject matches with case-insensitive comparison, but not with case-sensitive comparison.

That confirms the split in practice: a subject that is wrong gives 700213, and a subject that is right apart from capitals gives this code. If you see 7002138, the value is correct and only the case is off, which is usually an environment name such as Production against production.

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

Is it an attack?

No. Entra found a credential that would have matched before the 2024 change. The fix is the casing.

Pattern	Likely meaning
A GitHub workflow uses environment: Production and the error shows :environment:Production	The credential says production, or the other way round. On the Q&A thread, the top answer fixed it by renaming the environment to lowercase. Microsoft’s notice gives the same advice for Azure App Service users.
The org or repo name has capitals	GitHub sends the casing it holds. The README: uppercase characters in the org, repo, branch or environment name must match the subject claim in the run log.
Deployments broke without anyone changing the workflow	The staged rollout above reached your app.
It still fails after “fixing” the case	Users report puzzling cases where the subject looks identical (Azure/login issue 573). Copy the subject from the log rather than retyping it.

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

Microsoft doesn’t document which sign-in table 7002138 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 == "7002138" or ResultSignature == "7002138"
| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceTable

To catch every app hit by the case change, list both codes together. If ResultDescription holds the returned message (our assumption; check a row), it shows the subject with the casing the token used:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("7002138", "700213") or ResultSignature in ("7002138", "700213")
| summarize Failures = count(),
            LastSeen = max(TimeGenerated),
            Codes = make_set(ResultType, 5),
            Descriptions = make_set(ResultDescription, 5)
          by AppId, ServicePrincipalName
| sort by LastSeen desc

How do I fix AADSTS7002138?

For developers and pipeline owners:

1. Copy the subject from the error or from the run log (Federated token details, subject claim).
2. Either update the credential’s subject to that exact string, or change the workflow so the token carries the credential’s casing. Microsoft’s notice: “replace the current issuer, subject, or audience value in the FIC with the issuer, subject, or audience value that was contained in the error message.”
3. For a GitHub environment, renaming it in the workflow (for example Production to production) is the fix users report and Microsoft suggests for App Service.

For admins:

1. Use the query above to find every app still failing, and fix the credentials in one go.
2. Microsoft’s overview now states the rule plainly: the values “must case-sensitively match”. Copy values from tokens or logs, never type them by hand.