AADSTS700226: Only managed identity tokens work with the Entra ID issuer (fix)

What does AADSTS700226 mean?

Microsoft’s error code reference doesn’t list AADSTS700226 (checked 30 October 2026). The wording below is from a lab run:

AADSTS700226: Only MSI tokens may be used as Federated Identity Credentials for AAD issuer.

A public repository of federated-credential experiments records the same line, with the trigger: “AADSTS700226: Only MSI tokens may be used as Federated Identity Credentials for AAD issuer.” (when trying to use tokens from app registration to another app registration).

“MSI” is managed service identity, the older name for a managed identity. “AAD issuer” means a federated identity credential whose issuer is a Microsoft Entra tenant itself, in the form https://login.microsoftonline.com/<tenant id>/v2.0, rather than GitHub, Kubernetes or another external provider.

Why this is worth knowing

Workload identity federation lets an app registration accept a token from somewhere else instead of holding a secret. One of its configurations uses Entra as the issuer. Microsoft documents that configuration for exactly one case: an app registration trusting a managed identity. From Microsoft’s page on configuring an app to trust a managed identity:

• “issuer is the URL of the Microsoft Entra tenant’s Authority URL in the form https://login.microsoftonline.com/{tenant}/v2.0. Both the Microsoft Entra app and managed identity must belong to the same tenant.”
• The issuer field in the portal is described as “the OAuth 2.0 / OIDC issuer URL of the Microsoft Entra ID authority that issues the managed identity token. This value is automatically populated with the current Entra tenant issuer.”
• “subject: This is the case-sensitive GUID of the managed identity’s Object (Principal) ID assigned to the Azure workload.”
• “Select managed identity: Click on this link to select the managed identity that will act as the federated identity credential. You can only use User-Assigned Managed Identities as a credential.”

Our reading: 700226 is the runtime half of that restriction. The configuration will accept an Entra issuer and a subject GUID, so nothing stops you entering another app registration’s service principal object ID and expecting that app’s own token to be exchanged. At token time Entra checks the presented token’s type and refuses it. So app registration to app registration federation through the Entra issuer does not work, however correct the issuer, subject and audience look. Microsoft’s pages describe the managed identity case and do not state the refusal, which is why the error has no documented wording.

This matters if you were planning to give one app registration access to another tenant’s or another app’s resources without a secret. The supported routes are a client secret, a certificate credential, an external identity provider as the issuer, or on-behalf-of for a user’s token.

The siblings cover the other federated failures: 70025 (no credential at all), 700211 (issuer), 700213 (subject), 7002121 and 700212 (audience). 700226 is different in kind: the three values matched and the token was still refused.

Reproduced in the lab

On 30 October 2026 an automated lab run configured a federated identity credential on an app registration, using the lab tenant itself as the issuer (https://login.microsoftonline.com/<tenant id>/v2.0), and presented a normal app token in a client-credentials request. The run expected a token, because the credential’s issuer, subject and audience were the ones the presented token carried. Entra returned:

AADSTS700226: Only MSI tokens may be used as Federated Identity Credentials for AAD issuer.

The run calls this scenario “Federated credential matches”, and that is what makes the code useful: in the same run a mismatch on one of the three values gave 700211, 700213 or 7002121. 700226 is what Entra returns when those three match and the token is still the wrong kind. The lab did not test the supported arrangement, so it confirms the refusal, not that a managed identity token would have been accepted.

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

Is it an attack?

No. It is a design limit being hit by a configuration someone built on purpose.

Pattern	Likely meaning
A new integration fails on its first run, with issuer, subject and audience all verified correct	Someone federated one app registration to another. That is what 700226 refuses.
A workload that used to work starts failing	The workload now presents an app token instead of its managed identity token, for example after moving off an Azure host or switching to a client secret in configuration.
The subject in the credential is a service principal object ID rather than a managed identity’s Object (Principal) ID	The credential points at the wrong principal. Only a user-assigned managed identity works here.

Our reading on the security side: 700226 is a refusal, so a row means the exchange did not happen. It is worth noticing if you did not configure an Entra-issuer credential at all, because someone added a federated credential to one of your apps. Credential additions are in the audit log, not the sign-in log.

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

Which table 700226 lands in is undocumented. Our reading: the app registration whose credential was used is the one signing in, so AADServicePrincipalSignInLogs is the likely place. Check with a union first:

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

The filter covers both columns because the tables document them differently: in SigninLogs, ResultType “provides the 5-6 digit error code”, while in AADServicePrincipalSignInLogs it is described as “Success or Failure” and ResultSignature as “the error code, if any, for the sign-in operation”.

Which app and which credential:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700226" or ResultSignature == "700226"
| summarize Failures = count(),
            LastSeen = max(TimeGenerated),
            Credentials = make_set(FederatedCredentialId, 5),
            CredentialTypes = make_set(ClientCredentialType, 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” (Microsoft’s typo). Whether it is populated on a refusal is not documented, so confirm on a row of your own.

How does Conditional Access affect it?

Nothing to configure here. The request fails on the token type before any policy decision matters, and a federated credential exchange for an app carries no user and no MFA step.

How do I fix AADSTS700226?

For developers:

1. If the workload runs on Azure, give it a user-assigned managed identity and present that identity’s token. Set the credential’s subject to the managed identity’s Object (Principal) ID, exactly as Microsoft’s page requires, and keep both objects in the same tenant.
2. If the caller is an app registration and not a managed identity, stop using the Entra issuer. Use a client secret or a certificate credential on that app, or on-behalf-of when you are acting for a signed-in user.
3. If the caller is outside Azure, use its own provider as the issuer: GitHub, Kubernetes or any OIDC provider that signs with RS256. Microsoft’s restrictions page: “Only issuers that provide tokens signed using the RS256 algorithm are supported for token exchange using workload identity federation.”

For admins:

1. Check the federated credential’s subject. It must be a user-assigned managed identity’s Object (Principal) ID, not an app’s service principal object ID.
2. Both objects must be in the same tenant. Microsoft: “Both the Microsoft Entra app and managed identity must belong to the same tenant.”
3. If you did not expect an Entra-issuer credential on this app, review who added it and why, in the audit log.