AADSTS50020 User Account Does Not Exist In Tenant

Error AADSTS50020 means the signed-in account is unknown in that Microsoft Entra tenant and must be added or matched to the right directory.

If you see the AADSTS50020 User Account Does Not Exist In Tenant message, you are dealing with a sign-in that points to the wrong Microsoft Entra ID directory or to an account that the target tenant does not know. The wording looks scary, but in most cases the problem is a missing guest user, a misconfigured app registration, or a mix-up between personal and work accounts.

This guide walks you through what the error text really means, why it appears, and clear steps to fix it both as an end user and as an administrator. You will also see how to set up your tenants and apps so that this error stays rare in later sign-ins.

What AADSTS50020 User Account Does Not Exist In Tenant Means

The aadsts50020 user account does not exist in tenant error comes from Microsoft Entra ID (formerly Azure AD) during the OpenID Connect or OAuth sign-in flow. The full message usually looks like this:

Error text — “AADSTS50020: User account ‘user@domain.com’ from identity provider ‘live.com’ does not exist in tenant ‘TenantName’ and cannot access the application ‘AppId’ in that tenant.”
Tenant name — The directory that owns the app you are trying to reach, sometimes called the resource tenant.
Identity provider — The home directory for your account, such as Microsoft personal accounts, another Entra tenant, or a social or enterprise IdP.
Application — The client or service that relies on Entra ID to sign you in.

In plain terms, Microsoft Entra ID is saying: “You are signing in with a valid account, but this directory has never seen that account as a local user or guest, so access is blocked.” The system will not silently add cross-tenant users; it needs an explicit guest invite or a configuration that allows that account type.

For many users this appears when they try to open the Entra admin center, Teams, Azure Portal, or a line-of-business app while signed in with a personal Microsoft account instead of their organization account. It can also show up when an app is tied to one tenant, but the login request points to another.

Why You See AADSTS50020 User Account Does Not Exist In Tenant

There is no single trigger for this error. The message appears in several sign-in patterns that all share one thing: the tenant that owns the resource does not have the right link to the account you used.

Personal account used for an admin task — You open the Entra admin center or Azure Portal with an Outlook.com or Hotmail address that is not tied to a directory. The service routes you to the Microsoft Services tenant, which cannot manage your organization resources.
Wrong tenant in the URL — The sign-in endpoint includes a specific tenant ID or name, but your user lives in another tenant. Entra ID checks the target tenant, finds no match, and returns AADSTS50020.
Guest user never invited — An app or SharePoint site is hosted in one tenant, and you try to open it as an external user from another tenant or provider without a guest invitation.
Old guest record no longer matches — The guest entry in the resource tenant is out of date or was created before changes to the home account, so Entra ID treats the incoming identity as a mismatch.
App registration restricted to single tenant — The app’s sign-in audience is set to only accept accounts from one tenant, while you are coming from another directory or from a personal account.
App requires assignment — Enterprise applications can be configured so that only assigned users can sign in; if a guest or local user lacks that assignment, the error may mention that the account cannot access the application in that tenant.

The aadsts50020 user account does not exist in tenant message does not mean the account is deleted everywhere. It only tells you that the specific tenant that owns the app has no valid entry for that identity, or that the configuration blocks that account type.

Fixing The AADSTS50020 User Account Does Not Exist Error

Fix steps depend on whether you are an end user trying to open an app, or an administrator responsible for Entra ID and app registrations. Start with the quick checks below. They do not require admin rights and often clear sign-in confusion.

Quick Checks For Regular Users

Confirm which account you need — Check the invite email, admin instructions, or app description to see whether you should use a work or school account, or a personal Microsoft account.
Sign out of all Microsoft sessions — Log out of portal.office.com, azure.microsoft.com, and other Microsoft sites in the browser, then close all tabs.
Use a private browser window — Open an InPrivate or Incognito window and go to the app URL again so cached tokens do not steer the sign-in flow.
Pick the correct account when prompted — If the login prompt lists several accounts, choose the one that belongs to the tenant that hosts the resource.
Retry with the direct tenant link — If your admin gave you a URL that includes a tenant name or ID, use that exact link instead of a bookmark you created earlier.

If you still get the error after these steps, the missing link is inside the tenant. At that point you usually need an admin to create or fix your guest entry or to adjust the app settings.

Steps For Administrators On The Resource Tenant

Check if the user exists locally — In the Entra admin center, search Users for the UPN or email from the error text. Confirm whether there is a member or guest entry with that sign-in name.
Review sign-in logs — Open Sign-in logs, filter by the user or correlation ID from the error, and look at the detailed error codes and tenant IDs.
Invite the guest user — If no guest entry exists, add a new external user with the same email that appears in the error, and send an invitation.
Resend or reset the invitation — If a guest exists but cannot sign in, resend the invitation or reset redemption so the user can accept a fresh link.
Confirm app assignment — For enterprise apps that require assigned users, make sure the guest or member user is added to the app and, if needed, to any relevant group.

Once the guest entry is created and the user accepts the invite, sign-in requests that target the tenant should succeed as long as the app’s own audience and endpoint settings are correct.

Checking Tenant And Identity Provider Settings

When the steps above do not fix the sign-in path, the next area to check is the app registration and the endpoints your app or portal uses. Misalignment between sign-in audience, domains, and tenant-specific URLs is a common source of this error.

Common Configuration Patterns

Scenario	Who It Affects	Typical Fix
App set to single-tenant, users from other orgs try to sign in	External partners or contractors	Change sign-in audience to allow multiple orgs or personal accounts where appropriate
Login URL uses /common but app is restricted to one tenant	Users who come from the wrong directory	Switch to a tenant-specific endpoint or widen the sign-in audience
Tenant default domain changed, cached tokens still point to the old domain	Desktop and mobile clients, especially Office apps	Clear cached credentials and sign in again with the updated domain name

Key Checks For App Owners

Review sign-in audience — In App registrations, open the app and check whether the sign-in audience accepts AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount as needed.
Match endpoints to audience — If the app is single-tenant, use a tenant-specific URL such as https://login.microsoftonline.com// rather than /common for most flows.
Check reply URLs and redirect URIs — Make sure reply URLs match the app’s configuration so tokens from the right tenant reach the expected endpoint.
Confirm multi-tenant setup for IdP integrations — For systems like Auth0 or Okta that connect to Azure AD, enable or configure multitenant access if users from several tenants need to sign in.
Review user assignment requirement — In the enterprise app blade, decide whether users must be assigned and keep that choice consistent with your access model.

A short check of these settings often explains why some accounts can sign in while others see AADSTS50020, even when the usernames look similar or belong to the same company domain.

Handling Guest Users And External Directories

Many AADSTS50020 cases involve B2B collaboration users. A partner may have an account in their own tenant, yet the resource tenant does not have a valid, current guest entry for that exact identity. Getting this right means handling invitations, redemption, and lifecycle cleanly.

Inviting And Managing Guest Users

Create guests from accurate email addresses — When you invite a user, use the email they will use for sign-in, not an alias they barely touch.
Guide guests to accept invitations — Tell external users to open the invite link in a private window and to choose the same account that received the email.
Check guest creation dates — If the home tenant account was recreated or renamed, compare creation dates between the guest in the resource tenant and the user in the home tenant to spot mismatches.
Reset redemption when needed — If a guest accepted an invite with the wrong account, reset redemption and send a new invite so they can link the correct identity.
Remove stale guests carefully — When you clean up guests, confirm that no active apps still rely on them, so you avoid new AADSTS50020 errors for ongoing projects.

Good guest hygiene is just as helpful as good group and app management. Clean entries, clear ownership, and predictable invite patterns make tenant boundaries easier for users to handle.

Tips To Avoid Repeat AADSTS50020 Errors

Once you solve the immediate sign-in issue, it is worth adjusting a few habits and settings so you and your users hit this error less often. Small changes in documentation, URLs, and training go a long way.

Practical Habits For Users

Keep work and personal accounts separate in browsers — Use one browser profile for corporate tenants and another for personal services so cookies do not mix.
Check the tenant name when you switch directories — In the top-right corner of the portal, confirm that the listed directory is the one that owns the app or resource.
Avoid bookmarking sign-in errors — Save the clean app or portal URL, not the address that includes error parameters from a failed login.
Ask the owner which account to use — Before spending time on trial and error, ask the site or app owner which email address and tenant you should sign in with.

Good Practices For Administrators

Document tenant and domain setup — Keep a simple record of default and vanity domains, tenant IDs, and which apps live in each directory.
Standardize app sign-in URLs — Where possible, send users through consistent sign-in links instead of a mix of direct and tenant-neutral URLs.
Review app registrations on a schedule — Periodically review sign-in audiences, redirect URIs, and assignment rules for your key apps.
Monitor sign-in logs for patterns — Look for repeated AADSTS50020 entries tied to the same app or tenant and adjust configuration or training based on that signal.
Coordinate changes to default domains — When you rename a default domain, plan a short window to refresh cached credentials on devices and in third-party IdP connections.

With these steps in place, the AADSTS50020 User Account Does Not Exist In Tenant error becomes a rare signal of a real configuration gap rather than a regular headache for users. Clear tenant boundaries, accurate guest entries, and consistent app settings keep sign-ins predictable while still giving you tight control over who can reach each resource.