AADSTS90002: Tenant not found (fix)

What does AADSTS90002 mean?

Microsoft’s description:

InvalidTenantName: The tenant name wasn’t found in the data store. Check to make sure you have the correct tenant ID. The application developer will receive this error if their app attempts to sign into a tenant that we cannot find. Often, this is because a cross-cloud app was used against the wrong cloud, or the developer attempted to sign in to a tenant derived from an email address, but the domain isn’t registered.

Every sign-in request names a tenant in its URL, as a tenant ID (a GUID) or a domain: https://login.microsoftonline.com/<tenant>/.... 90002 means Entra has no tenant by that name in the cloud the request went to.

The “wrong cloud” cause is real because the clouds are separate. Microsoft’s national clouds page says “Each cloud instance is separate from the others and has its own environment and endpoints” and lists https://login.microsoftonline.com (global), https://login.microsoftonline.us (US Government) and https://login.partner.microsoftonline.cn (China, operated by 21Vianet). A US Government tenant ID sent to the global endpoint is not found, and the other way round.

Reproduced in the lab

On 25 October 2026 an automated lab run sent a token request to a tenant ID that doesn’t exist (a random GUID the script generated). Entra returned AADSTS90002 with this first line:

AADSTS90002: Tenant ‘{tenant-id}’ not found. Check to make sure you have the correct tenant ID and are signing into the correct cloud.

That confirms the code and its wording at the token endpoint. Note that the returned message mentions the cloud as well as the tenant ID. No sign-in log row was captured. Our reading: there is no tenant to log it in, because the tenant named in the request doesn’t exist, and the request never reached the lab tenant either. See how pages are checked.

Is it an attack?

No. It is a configuration error in the app or script that sent the request.

Pattern	Likely meaning
A new app or script fails on its first run	Typo in the tenant ID, or a placeholder value left in the config.
An app that works in one environment fails in another	The app points at the wrong cloud endpoint for that tenant.
A multi-tenant app that builds the tenant from the user’s email domain	The domain isn’t a verified domain of any tenant, as Microsoft’s description says.
An app that worked before and now fails	The tenant was deleted, or the custom domain used as tenant name was removed from it. Our interpretation.

Our reading: tenant discovery by attackers doesn’t need this error and doesn’t show up in your logs through it. A request to a tenant that doesn’t exist reaches no tenant.

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

Microsoft doesn’t document which sign-in table 90002 is logged in. It probably lands in none of yours, for the reason in the lab note above. Check anyway; this query is expected to return nothing:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "90002"
| summarize Rows = count() by SourceTable

What the logs can do is tell you the right value to configure. For an app that fails with 90002, find where it signs in successfully and which tenant that is. ResourceTenantId is documented as “the tenant identifier of the resource referenced in the sign in”:

union withsource=SourceTable
    SigninLogs,
    (AADServicePrincipalSignInLogs | extend ResourceTenantId = AADTenantId, AppDisplayName = ServicePrincipalName)
| where TimeGenerated > ago(30d)
| where ResultType == "0"
| where AppId == "<app id of the failing app>"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, ResourceTenantId, AppDisplayName

AADServicePrincipalSignInLogs has no ResourceTenantId or AppDisplayName column, so the query uses AADTenantId and ServicePrincipalName there (our choice; the table reference doesn’t describe AADTenantId). If this returns your tenant ID and the app config holds a different one, you found the cause.

How do I fix AADSTS90002?

For the user: you can’t fix this yourself. Report the app name to whoever set it up.

For developers:

1. Check the tenant ID or domain in the authority URL. Compare it with the real tenant ID; Microsoft’s page on finding it says to use Entra ID > Overview > Properties in the Entra admin center, or Get-AzTenant in Azure PowerShell.
2. Check the cloud. Microsoft’s national clouds page: “use the endpoints for the cloud instance where you’ll deploy the application.” A tenant in US Government or China needs that cloud’s login endpoint, not login.microsoftonline.com.
3. Don’t derive the tenant from the user’s email domain unless you handle the case where the domain isn’t registered. For a multi-tenant app, sign in through /organizations or /common and read the tenant from the token instead.

For admins:

1. Get the correct tenant ID from the admin center or with PowerShell:

Connect-AzAccount
Get-AzTenant

2. If the app uses a domain name as tenant, check that the domain is still verified in your tenant.
3. If the app is a third-party product, give the vendor your tenant ID and tell them which cloud your tenant is in.