AADSTS700016: Application Not Found in the Directory or Tenant

AADSTS700016 — "The application wasn't found in the directory/tenant" means Entra ID searched the tenant your sign-in request named and found no such application. This guide covers the three documented causes, how to tell which one you have, and the fix for each.

The Error

AADSTS700016: Application with identifier '<client-id>' was not found
in the directory '<tenant>'. This can happen if the application has not
been installed by the administrator of the tenant or consented to by
any user in the tenant. You may have sent your authentication request
to the wrong tenant.

Microsoft's internal name for the code is UnauthorizedClient_DoesNotMatchRequest.

The message is unusually informative — it names both the application identifier that was searched for and the tenant that was searched. Note both before you do anything else.

Why This Happens

Microsoft documents three causes:

1. The application has not been installed by an administrator of the tenant.
2. No user in the tenant has consented to it, so no service principal exists there.
3. The request carried the wrong identifier — a misconfigured client ID, or an authentication request sent to the wrong tenant.

Underneath all three sits one concept. An app registration is the definition of an application and lives in exactly one tenant. A service principal is that application's local presence in a tenant, and one is created when the app is installed or consented to there. AADSTS700016 means no service principal exists in the tenant that was searched.

The application can be perfectly healthy and still produce this error, because the problem is where it was looked for.

If You're a User (Not an Admin)

Nothing you can do from your side changes this — it is a configuration problem, not a credential one. Retrying, clearing cookies, and switching browsers all fail identically.

Send your administrator:

• The full error text, including the client ID and tenant it names
• The application you were opening and the account you used
• The Request ID and timestamp from the error page

The client ID and tenant in the message are what your admin needs; do not paraphrase the error.

Diagnose Which Cause You Have

Do this before applying any fix. Two minutes here saves an hour.

Step 1: Read the tenant in the error. Does the tenant GUID or domain in the message match the organization you meant to sign in to? If not, you have cause 3 — go to Fix 3.

Step 2: Look for the app in your tenant.

1. Microsoft Entra admin center → Identity → Applications → Enterprise applications
2. Change Application type to All applications
3. Search for the client ID from the error message

If it appears, the app is in your tenant, and your problem is the identifier or authority in the request — again Fix 3. If nothing is returned, continue.

Step 3: Check whether it was deleted. Go to App registrations → Deleted applications. A recently deleted registration can usually be restored, which is far quicker than rebuilding it with all its reply URLs and permissions.

Step 4: If it was never there, you have cause 1 or 2 — install it or consent to it.

Fix 1: Install the Application in the Tenant

Requires: Cloud Application Administrator, Application Administrator, or Global Administrator.

For a gallery application:

1. Entra admin center → Identity → Applications → Enterprise applications
2. New application
3. Find the app in the gallery and add it
4. Configure single sign-on and assign users

Adding the application creates the service principal, which is the thing that was missing.

Fix 2: Grant Admin Consent

Requires: Privileged Role Administrator or Global Administrator for tenant-wide consent.

If the app exists as a registration but has never been consented to in the tenant:

1. Entra admin center → Identity → Applications → Enterprise applications → the app
2. Permissions
3. Grant admin consent for <your organization>
4. Review what is being granted, then confirm

For a third-party or multitenant app you do not yet have, the vendor can supply an admin consent URL of the form https://login.microsoftonline.com/{tenant}/adminconsent?client_id={client-id}. Opening it as an administrator creates the service principal in your tenant.

Read the permission list before consenting. Admin consent grants the requested permissions for every user in the tenant, and over-permissioned applications are a genuine security problem. If an app asks for more than its function needs, that is a conversation with the vendor, not a checkbox.

Fix 3: Correct the Client ID or Authority URL

This is a developer or vendor fix, not a directory one.

Check the client ID. Compare the identifier in the error message against the Application (client) ID on the app registration's Overview page. A single wrong character produces exactly this error.

Check the authority URL. The tenant segment decides which directory gets searched:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize

A single-tenant app registration pointed at a different tenant GUID fails with AADSTS700016 every time, and the app looks completely fine in its home tenant while it does so. Developers testing against a customer tenant hit this constantly.

If the app genuinely needs to serve multiple organizations, change its supported account types on the registration to a multitenant option — and understand that each customer tenant still needs consent before their users can sign in.

Verify the Fix

1. Confirm the service principal exists. Enterprise applications, filtered to all application types, searched by client ID — it should now return the app.
2. Sign in again from a private browser window to avoid a cached failed state.
3. Check the sign-in logs. Entra admin center → Monitoring → Sign-in logs, filtered to the user. The entry should now succeed, or fail with a different code — which is progress, and usually AADSTS50105 next.

Prevent It Coming Back

• Never delete an enterprise application to "clean up" without confirming nothing authenticates through it. This error is a common aftermath.
• Keep client IDs in configuration, not in code, so a wrong environment cannot ship a wrong ID.
• Use organizations rather than a hard-coded tenant GUID for apps that serve more than one customer.
• Document the consent step in your onboarding runbook if you publish a multitenant app — most "your app is broken" reports from new customers are an ungranted consent.
• Review app registrations before they expire or are cleaned up. An orphaned registration removed during a tidy-up takes every integration using it down with it.

Related Errors

For scripted inspection of service principals and consent grants, connect with the Microsoft Graph PowerShell module; the module install and connection pattern is the same one covered in how to install and connect to Exchange Online PowerShell.

Related Articles

• Customizing Admin Roles for Delegated Administration in Office 365
• Configuring Conditional Access Policies in Office 365