AADSTS700016: Application not found in the directory

What does AADSTS700016 mean?

UnauthorizedClient_DoesNotMatchRequest: The application wasn’t 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 might have misconfigured the identifier value for the application or sent your authentication request to the wrong tenant.

The application that is missing is the client (the app asking for a token). If the missing object is the API being called, the error is 500011 instead.

Is it an attack?

Almost always not. Typical causes:

• A typo or copy-paste error in the client ID.
• The request goes to the wrong tenant (wrong tenant ID or domain in the authority URL).
• A single-tenant app used from another tenant.
• A multi-tenant app that nobody in your tenant has consented to yet.
• An app registration that was deleted while a script or service still uses it.

Pattern	Likely meaning
One internal app ID, failing since a deployment	Wrong client ID or tenant in config. Benign.
An app you deleted recently, still failing	Something still uses it. Find and update the caller.
An app you removed during an incident (for example after an illicit consent grant), still failing	The attacker’s tooling is still trying. Note the IPs and times.
Client IDs you don’t recognise, from external IPs, across your tenant	Someone checking whether their app exists in your tenant. Investigate.

The last two rows are our reasoning, not Microsoft statements. Microsoft’s illicit-consent guidance describes removing a malicious app’s access; it doesn’t describe the 700016 rows that follow. If you remove the service principal, a client that still uses that app ID against your tenant would match the description above. Two neighbouring codes may show instead: 700011 (“Application with identifier {appIdentifier} was not found in the directory”) for a removed app, and 7000112 (“The application is disabled”) while the service principal is disabled. Which one a removed app returns isn’t documented; the consent phishing guide treats all three as the aftermath to watch for.

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

700016 grouped by the client app ID, so you can check each one against your app registrations:

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == "700016"
| summarize Attempts = count(),
            Users = dcount(UserPrincipalName),
            IPs = make_set(IPAddress, 10),
            AppNames = make_set(AppDisplayName, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppId
| sort by Attempts desc

AppDisplayName may be empty on these rows, since the tenant has no object for the app. Look up the AppId yourself.

After an incident: has a removed app ID tried again?

let removedApp = "<app-id-you-removed>";
union
    (SigninLogs | where AppId == removedApp),
    (AADServicePrincipalSignInLogs | where AppId == removedApp)
| where TimeGenerated > ago(30d)
| project TimeGenerated, Type, ResultType, ResultDescription, IPAddress, UserPrincipalName,
          ServicePrincipalName
| sort by TimeGenerated desc

The AppDisplayName behaviour and the presence of 700016 in AADServicePrincipalSignInLogs are not verified against a live workspace. Microsoft’s table reference for the service principal table describes ResultType as Success or Failure, so check whether the numeric code appears there before you build a rule on it.

How does Conditional Access affect it?

• 700016 is not a Conditional Access result. There is no application object in the tenant for a policy to target.
• Once the app is added or consented, your policies apply as normal. Conditional Access targets the resource being requested, not the client application, so a policy on “All resources” or on the specific API covers the tokens this client asks for.
• The control that matters here is consent. Microsoft’s illicit-consent guidance notes that resetting passwords or requiring MFA isn’t effective against an app that already holds consent. Removing the app’s grants and service principal is what ends that access, and 700016 can be what the attacker’s tool sees afterwards.

How do I fix AADSTS700016?

For developers:

1. Compare the client ID in your code or config with the Application (client) ID on the app registration.
2. Check the authority URL. The tenant in it must be the tenant where the app is registered, or the app must be multi-tenant and consented in the target tenant.
3. If the app was deleted, restore it or register a new one and update every caller.

For admins:

1. Check each unknown AppId from the first query. If it is a third-party app nobody asked for, leave it out of the tenant.
2. If the app ID belongs to something you removed during an incident, keep the evidence (IPs, times, user agents) and don’t re-add the app.