AADSTS700016: application not found in the directory, and the fix

AADSTS700016 is the error Microsoft Entra ID returns when the application ID in a sign-in request does not match any application in the tenant that received the request. The usual reaction is to grant consent again or recreate the app registration, and neither helps when the request simply went to the wrong tenant. This post covers the three things the AADSTS700016 message can mean, how to tell them apart from one failed sign-in, and the order I would check them in.

It is a spoke of every AADSTS error code, grouped by cause, which sits under the Conditional Access and sign-in policy hub. Every Microsoft fact below was checked against Microsoft Learn on 31 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so what follows is the documentation read carefully, plus where I would expect it to bite.

What AADSTS700016 actually means

The full message usually reads AADSTS700016: Application with identifier '{appId}' was not found in the directory '{tenant}'. The Microsoft Entra authentication and authorization error code reference lists it as UnauthorizedClient_DoesNotMatchRequest and gives three causes: the application has not been installed by an administrator of the tenant or consented to by any user in it, the identifier value for the application is misconfigured, or the authentication request was sent to the wrong tenant.

All three reduce to one fact. The tenant that received the request has no service principal whose identifier matches the one in the request. Microsoft Learn describes the application object as the template that lives in the app’s home tenant, and the service principal as the local instance created in every tenant where the application is used. AADSTS700016 is Entra telling you it looked for that local instance and found nothing.

That is why the message names two values, and why both matter. The identifier is what the app sent. The directory is where it sent it. Read both before changing anything.

The checks in order

Most of the time spent on AADSTS700016 goes on fixing the wrong half of the message. This is the order I would work in, cheapest check first.

1. Copy the identifier and the directory from the error page. Do not retype them.
2. Confirm which tenant the directory value belongs to. A tenant ID, a verified domain or an onmicrosoft.com name all resolve to one tenant, and it may not be the one you expected.
3. In that tenant, search Enterprise applications for the identifier as an application ID. If nothing appears, the app has no service principal there.
4. In the app’s home tenant, open App registrations and compare the Application (client) ID character for character with the identifier in the error.
5. If the app is meant to be used by other tenants, check its supported account types on the registration.
6. If it is a SAML app, compare the Issuer the service provider sends with the Identifier (Entity ID) on the enterprise application.
7. Check the deleted items for both the app registration and the enterprise application before you create anything new.

Wrong tenant endpoint: the AADSTS700016 cause that is not in Entra at all

The most common cause in practice is a request sent to an authority the app was never meant to use. The fix is in the application’s configuration, not in the tenant.

The authority URL carries a tenant value. The OpenID Connect documentation lists four kinds: common for work, school and personal accounts, organizations for work or school accounts only, consumers for personal accounts only, and a specific tenant ID or domain for one tenant’s users. A single-tenant app registered in tenant A, configured with tenant B’s ID by mistake, produces AADSTS700016 in tenant B every time, while the registration in tenant A looks perfect.

The same applies when one codebase is promoted from a development tenant to production. The client ID moves with the configuration file and the tenant ID does not, or the other way round. The identifier in the error is genuine; it just belongs to an app registered somewhere else.

Guest users add a twist. A guest signing in to an app in the resource tenant must be sent to that tenant’s endpoint, not their home tenant’s. That overlap with guest accounts is covered in how AADSTS50020 handles accounts from the wrong tenant, and the two errors often appear together during the same troubleshooting session.

No service principal: not installed, not consented

If the request reached the right tenant and the identifier is correct, the service principal is missing. For a multitenant app, that usually means nobody in the tenant has consented yet.

Microsoft Learn’s guidance on converting an app to multitenant describes the mechanism: when a user from another tenant signs in for the first time and consents, a service principal is created in that user’s tenant and sign-in continues. If user consent is blocked in that tenant, nothing is created and the next attempt fails the same way. An administrator granting tenant-wide admin consent creates the service principal on behalf of everyone.

Two things to check on the registration first. The supported account types must allow other tenants, otherwise no consent in another tenant will ever create a usable service principal. And the request must not go to the home tenant’s endpoint by accident; the consent has to happen in the tenant where the users live.

Misconfigured identifier, including SAML Issuer

For OAuth 2.0 and OpenID Connect apps the identifier is the client ID. A trailing space, a swapped character or a value copied from the object ID instead of the application ID is enough. The object ID and the application ID are both GUIDs on the same blade, and they are not interchangeable.

For SAML apps the identifier is the Issuer in the authentication request. The SAML single sign-on protocol reference states that the Issuer element in an AuthnRequest must exactly match one of the service principal names in Microsoft Entra ID. In the enterprise application that value is shown as Identifier (Entity ID) under the basic SAML configuration. A vendor that changes its entity ID after an upgrade, or a test and production instance that share one enterprise application, will produce AADSTS700016 even though nothing in Entra changed.

Exact means exact. A trailing slash on one side and not the other is a different value.

Deleted app registrations and the 30-day window

An app that worked last week and fails today with AADSTS700016 may have been deleted. Check the recycle bin before you register a replacement, because a new registration gets a new application ID and every client still holding the old one will keep failing.

According to Microsoft’s guide to restoring a soft deleted enterprise application, soft deleted enterprise applications can be restored within the first 30 days after deletion, and after that they are permanently deleted. Restoring needs Cloud Application Administrator, Application Administrator or ownership of the service principal. The same page notes that Conditional Access policies that targeted the old service principal are not restored with it.

The documentation is not consistent on one point. The restore guide says that restoring a deleted app registration in its home tenant also restores its service principal. The apps and service principals overview says restoring the application object through the app registrations UI does not restore its service principal. Until those agree, I would check both recycle bins after any restore and not assume either page is right.

Checking an AADSTS700016 identifier with Microsoft Graph PowerShell

The portal works, but it searches one list at a time. This block looks up one client ID across the registration, the service principal and both recycle bins in the tenant you are connected to. I have not run it against a production tenant.

1# Look up one client ID in the connected tenant: app registration, service principal, and deleted items.
2# Replace the appId with the identifier from the AADSTS700016 message.
3Connect-MgGraph -Scopes 'Application.Read.All'
4$appId = '00000000-0000-0000-0000-000000000000'
5Get-MgApplication -Filter "appId eq '$appId'" | Select-Object DisplayName, AppId, SignInAudience
6Get-MgServicePrincipal -Filter "appId eq '$appId'" | Select-Object DisplayName, AppId, AccountEnabled
7Get-MgDirectoryDeletedItemAsApplication -All | Where-Object AppId -eq $appId | Select-Object DisplayName, AppId, Id
8Get-MgDirectoryDeletedItemAsServicePrincipal -All | Where-Object AppId -eq $appId | Select-Object DisplayName, AppId, Id

Read the four results together. A registration with no service principal in its home tenant points at a deletion or a broken restore. No registration but a service principal means the app is homed elsewhere and this tenant is a consumer of it. Nothing at all, in a tenant you are sure is correct, means the identifier is wrong or the request went to another tenant.

SignInAudience tells you whether the registration accepts other tenants at all. AccountEnabled set to false blocks sign-in for every user, which is a different failure, but worth reading while the object is on screen.

The failure modes

Consent granted in the wrong tenant. An administrator follows an admin consent link built with the home tenant’s ID instead of the customer’s. Consent succeeds, a service principal already existed there anyway, and the customer still sees AADSTS700016.

A new registration to replace a deleted one. The error stops for the person who updated their configuration and continues for every client, script and integration still holding the old client ID.

Object ID pasted as client ID. Both are GUIDs, both are on the overview page, and only one is the identifier Entra searches for.

SAML entity ID drift. The vendor changes the Issuer on an upgrade. The enterprise application still has the old Identifier, so the error appears for everyone at once with no change in Entra to explain it.

Mixing up 700016 and 500011. AADSTS500011 is about the resource the app asks a token for, not the app itself. If the identifier in the message is an API’s App ID URI rather than your client ID, you are looking at the wrong error.

For guest access between organisations, it is also worth reading how cross-tenant access trust settings shape what external users can do, because a blocked inbound setting fails earlier and with a different code, and it is easy to confuse the two in the sign-in logs.

What I would do differently

I would keep the tenant ID and the client ID next to each other in every configuration file and secret store, labelled with the tenant’s name. Most AADSTS700016 cases are two correct values from two different places.

I would never delete an app registration as a first step in a clean-up. Remove its credentials and disable sign-in on the service principal first, wait, and delete only when nothing has complained. Microsoft Learn now also describes deactivating an application, which stops new tokens while keeping both objects.

And I would treat consent as something done deliberately in the customer’s tenant, with the admin consent URL built from that tenant’s ID, rather than something a user is left to stumble into. If user consent is blocked, which it should be in most organisations, the first sign-in will fail until an administrator acts.

Assignment is the next gate after the service principal exists. If AADSTS700016 clears and the user then hits a different wall, AADSTS50105 and the assignment check is usually what follows.

Last verified: 31 October 2026.