AADSTS16000: Account isn't in the tenant the app uses (fix)

What does AADSTS16000 mean?

Microsoft’s description:

InteractionRequired: User account ‘{EmailHidden}’ from identity provider ‘{idp}’ doesn’t exist in tenant ‘{tenant}’ and can’t access the application ‘{appid}’({appName}) in that tenant. This account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Microsoft Entra user account. This error is fairly common when you try to sign in to Microsoft Entra admin center by using personal Microsoft Account and no directory associated with it.

The user proved who they are at their own identity provider. The tenant the app sent them to has no user or guest object for that account, so the sign-in stops there.

The wording is almost the same as 50020. Microsoft doesn’t document when Entra returns 16000 and when it returns 50020. Our reading: the name InteractionRequired suggests 16000 is the variant returned when the user can fix it by signing in again with another account. Treat the causes and fixes of the two codes as the same.

Is it an attack?

No, in almost all cases. Microsoft’s description names the most common cause itself: a personal Microsoft account used on the Entra admin center. Microsoft’s 50020 troubleshooting article explains that case: “you are connected to the Microsoft Services tenant by default. Within the default tenant, there is no linked directory for performing any actions. This behavior is expected.”

Pattern	Likely meaning
A personal account (outlook.com, hotmail.com) on an Azure or Entra portal	The user picked the wrong account, or has no directory of their own. Benign.
A partner user on one specific app, repeating	The partner was never invited as a guest, or the guest object was deleted.
One user who has both a work and a personal account	The browser silently reused the wrong session. Benign.
Many users from one other company on one app	The app sends everyone to your tenant (a tenant-specific authority) but expects outside users. App or invitation problem.

There is no documented attack pattern for 16000. The account has already authenticated at its home, and your tenant refuses it. As far as we can tell, an attacker gains nothing from this error that they didn’t already have.

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

Microsoft doesn’t document which sign-in table 16000 is logged in. Check where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "16000"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which apps and which home tenants are involved. HomeTenantId is documented as “the tenant identifier of the user initiating the sign in”, so it tells you which organisation the outside users come from:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "16000"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            Sample = make_set(UserPrincipalName, 10)
          by AppDisplayName, AppId, HomeTenantId, ResourceTenantId
| sort by Users desc

We haven’t checked this against real data, but the user name may be hidden or empty in these rows, because Microsoft’s message template shows {EmailHidden}. If UserPrincipalName is empty, look at SignInIdentifier.

Users who keep failing with 16000 on the same app and never succeed afterwards. These are the ones that need an invitation or an app change, not a retry:

let fails =
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == "16000"
    | summarize Fails = count(), LastFail = max(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;
let successes =
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == "0"
    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;
fails
| join kind=leftouter successes on UserPrincipalName, AppId
| where isnull(LastSuccess) or LastSuccess < LastFail
| where Fails >= 3
| project UserPrincipalName, AppDisplayName, Fails, LastFail
| sort by Fails desc

The threshold of 3 is a starting point. If the first query shows most rows in AADNonInteractiveUserSignInLogs, run the others against that table too. Non-interactive rows are aggregated when application, user, IP address, status and resource ID match, so row counts there are not request counts.

How do I fix AADSTS16000?

For the user: sign out, or open a private browser window, and sign in again with your work account. Microsoft’s description says to “sign in again with a different Microsoft Entra user account”. If you used a personal Microsoft account on the Azure or Entra portal and you have no directory of your own, you need to create one; Microsoft’s 50020 article says “If you aim to have a directory, you must create an Azure account and a new tenant.” If you are from another organisation, ask the app owner to invite you as a guest.

For developers: check which authority your app uses. Microsoft’s 50020 article says that with https://login.microsoftonline.com/<YourTenantNameOrID> “users from other organizations can’t access the application. You have to add these users as guests in the tenant that’s specified in the request.” If the app is meant for any organisation, use /organizations (or /common if personal accounts are allowed too), and make sure the app registration’s supported account types allow it.

For admins:

1. External user who needs access: invite them as a guest (B2B). Microsoft’s description says the account “needs to be added as an external user in the tenant first.”
2. Guest that used to work: check whether the guest object was deleted, or whether the home tenant re-created the account. For the second case Microsoft’s 50020 article says to reset the guest’s redemption status instead of deleting and re-inviting.
3. Give guests a tenant-specific link. Microsoft’s redemption article: “A direct link is tenant-specific. In other words, it includes a tenant ID or verified domain so the guest can be authenticated in your tenant.”
4. Many users from one partner on one app: decide whether that app should accept them at all. If yes, invite them, ideally as a group; if no, the error is doing its job.