AADSTS700016 'Application with Identifier Was Not Found': Microsoft Entra ID Fix Guide

Every instance of AADSTS700016 falls into one of five categories. The error message itself is identical across all five, so determining which applies requires checking specific configuration details.

Cause 1: Client ID or Tenant ID mismatch in application configuration The application configuration (app settings, environment variables, web.config, or appsettings.json) contains a client ID that does not match the Application ID shown in the Entra ID app registration. This is the most common cause in production incidents and usually happens when a new app registration is created but the old client ID is still in the config, or when the application is promoted between environments (dev, staging, prod) with the wrong client ID propagated.

Cause 2: Missing service principal -- multi-tenant consent not completed For multi-tenant applications, a service principal must exist in each tenant that uses the application. The service principal is created when an administrator grants admin consent or when the first user from that tenant signs in and consents. If this step was skipped, the target tenant has no service principal for the application, and Entra ID returns AADSTS700016. This is the most common cause in B2B SaaS deployments where the application is registered in a vendor's home tenant but deployed to customer tenants without completing the admin consent step.

Cause 3: App registration deleted or disabled The app registration the application references was soft-deleted or hard-deleted from Entra ID. Soft-deleted registrations are recoverable for 30 days via the Deleted Applications view in the portal or via Graph API. After 30 days, the app registration is permanently purged and must be recreated. App registrations can also be disabled in certain tenant policies, which produces the same error behavior.

Cause 4: Single-tenant app accessed by external users The app registration is configured as single-tenant (supported account types: 'Accounts in this organizational directory only'), but the token request is coming from a user whose home tenant is different from the app's home tenant. Entra ID evaluates the clientId against the tenant specified in the token request, not the app's home tenant, and finds no matching registration in the external tenant.

Cause 5: Wrong authority endpoint in CIAM, B2C, or external tenant config Applications using Azure AD B2C or Entra External ID (CIAM) must specify the correct B2C or CIAM tenant authority URL. If the authority URL points to the wrong tenant -- for example, to the workforce Entra ID tenant instead of the CIAM tenant -- the client ID will not be found in the directory the authority URL resolves to.

Before applying a fix, confirm which cause applies. The sign-in log correlation ID in the error message is your starting point.

Step 1: Retrieve the error details The AADSTS700016 error response contains a correlation ID. In Azure portal, go to Microsoft Entra ID > Monitoring > Sign-in logs and filter by the correlation ID or by the application client ID. Confirm the error code is 700016, not 700011 or 70001 (similar codes with different meanings).

Step 2: Check whether the client ID exists in the target tenant Open Entra ID > App registrations > All applications. Search for the client ID from your application config. If no result appears, the app registration does not exist in that tenant (Causes 2, 3, or 4).

Alternatively, query Graph API:

GET https://graph.microsoft.com/v1.0/applications?$filter=appId eq '{clientId}'

A 200 response with an empty value array means the app registration is not in the current tenant.

Step 3: Check for a service principal separately from the app registration For multi-tenant apps, the app registration lives only in the home tenant, but a service principal should exist in every tenant using the app. In the target tenant, go to Enterprise Applications and search by application ID. If no service principal exists, Cause 2 applies.

PowerShell equivalent:

Get-MgServicePrincipal -Filter "appId eq '{clientId}'"

An empty result in the target tenant confirms the missing service principal.

Step 4: Check for soft-deleted app registrations In Entra ID > App registrations > Deleted applications, search for the app by name or scroll the list. Soft-deleted registrations retain their original client ID.

Graph API query for soft-deleted apps:

GET https://graph.microsoft.com/v1.0/directory/deletedItems/microsoft.graph.application?$filter=appId eq '{clientId}'

Step 5: Verify the authority URL in your application config For CIAM or B2C apps, compare the authority URL in your application config against the tenant's B2C or CIAM domain. The URL should match one of these patterns:

• B2C: https://{tenantName}.b2clogin.com/{tenantId}/{policyName}/
• Entra External ID (CIAM): https://{tenantSubdomain}.ciamlogin.com/

A workforce Entra ID authority URL (https://login.microsoftonline.com/{tenantId}) in a B2C or CIAM application config is a common misconfiguration that produces AADSTS700016.

Apply the fix that matches your confirmed diagnosis from the diagnostics section.

Fix for Cause 1: Client ID or Tenant ID mismatch

1. Open Entra ID > App registrations > find the correct app registration.
2. Copy the Application (client) ID from the Overview tab.
3. Update your application configuration to use the correct client ID.
4. Verify the Authority or Tenant ID in your config matches the tenant where the app is registered. The tenant ID is visible on the Overview tab of the app registration under Directory (tenant) ID.
5. Redeploy or restart the application to pick up the config change.

Fix for Cause 2: Missing service principal (multi-tenant admin consent) Option A -- Admin consent URL (for tenant admins):

https://login.microsoftonline.com/{targetTenantId}/adminconsent?client_id={clientId}

Navigate to this URL as a Global Administrator or Cloud Application Administrator of the target tenant. After consent, Entra ID creates the service principal automatically.

Option B -- Invite via Gallery (for ISV applications published in the Microsoft Entra gallery): In the target tenant, go to Enterprise Applications > New application and find the application by name, then follow the provisioning flow.

Option C -- Programmatic provisioning via Graph API:

POST https://graph.microsoft.com/v1.0/servicePrincipals
Content-Type: application/json
{
  "appId": "{clientId}"
}

This creates the service principal in the calling tenant. Requires Application.ReadWrite.All permission.

Fix for Cause 3: Restore a soft-deleted app registration

1. Go to Entra ID > App registrations > Deleted applications.
2. Select the deleted app and click Restore. The original client ID is preserved.
3. Verify that any associated credentials (client secrets, certificates) are still valid; secrets created before deletion remain after restore.

Graph API restore:

POST https://graph.microsoft.com/v1.0/directory/deletedItems/{objectId}/restore

Fix for Cause 4: Single-tenant app accessed by external users If external user access is intentional:

1. In Entra ID > App registrations > Authentication > Supported account types, change to 'Accounts in any organizational directory (Any Azure AD directory -- Multitenant)'.
2. Save the manifest change. Entra ID does not require a code change for this.
3. External users will still need a service principal in their tenant via admin consent (see Fix for Cause 2 above).

If external user access is not intentional, enforce a Conditional Access policy restricting the application to specific users or groups from the home tenant only.

Fix for Cause 5: Correct the CIAM or B2C authority URL

1. Retrieve your CIAM or B2C tenant domain from Azure portal > External Identities > Overview or Azure AD B2C > Overview.
2. Update the authority URL in your application config to the correct format for your tenant type.
3. For B2C, also confirm that the policy name in the authority URL (e.g., B2C_1_signupsignin) matches an active user flow or custom policy in the B2C tenant.

After applying any of the fixes above, validate before marking the incident resolved:

1. Trigger a fresh authentication attempt: Clear browser cookies and session state, then attempt to authenticate through the application. For service-to-service flows, restart the service or force a token refresh.

2. Check sign-in logs: In Entra ID > Monitoring > Sign-in logs, filter to the application and confirm recent sign-in attempts show Success status and an empty Error code column. AADSTS700016 entries should stop appearing within 1-2 minutes of the fix.

3. Verify service principal state: For Cause 2 fixes, confirm the service principal now exists in the target tenant:

Get-MgServicePrincipal -Filter "appId eq '{clientId}'" | Select DisplayName, AppId, AccountEnabled

The AccountEnabled field should be True.

1. For multi-environment deployments: Confirm the fix is applied consistently across all environments (dev, staging, prod). Client ID mismatches frequently survive in environment-specific config files that were not updated consistently.

The service principal exists but users still see AADSTS700016 This typically means the app registration's Supported account types setting does not allow the user's account type. For example, a personal Microsoft account (MSA) user attempting to authenticate to an app configured for 'Accounts in this organizational directory only' will receive a variant of AADSTS700016. Check the sign-in log entry's error subcode for additional context.

Admin consent completes but the error persists for a specific user If the admin consent URL succeeds and the service principal is created, but specific users still see the error, the user's home tenant may differ from what was consented. In federated B2B scenarios, the user's UPN tenant and their authentication tenant can differ. Check the sign-in log's Home tenant ID against the tenant you consented.

App registration restore fails with 'Permission denied' Restoring soft-deleted app registrations requires Application Administrator or Global Administrator role. If the account performing the restore is a Cloud Application Administrator, verify that the role assignment is at the directory scope, not scoped to an administrative unit that excludes the deleted app.

The error appears only for external guest users, not internal users This pattern indicates Cause 4 (single-tenant app) even if the app registration's Supported account types appears to allow multi-tenant. Check that the app's manifest signInAudience property is set to AzureADMultipleOrgs and not AzureADMyOrg. Portal UI changes to this setting do not always save reliably -- verify via Graph API:

GET https://graph.microsoft.com/v1.0/applications/{objectId}?$select=signInAudience

Escalate outside the standard identity team to your Azure subscription owner or Microsoft Support when:

• The app registration has been permanently deleted (beyond 30-day soft-delete window) and you need to establish a new registration while maintaining the original client ID for integrations that cannot be reconfigured quickly.
• The sign-in logs show AADSTS700016 but the service principal exists in the target tenant and the client ID is confirmed correct -- this can indicate a tenant-level policy, an Entra ID platform issue, or conditional access configuration that is filtering out the sign-in before it reaches the authorization layer.
• You are operating a first-party Microsoft application (such as a managed identity or a Microsoft Graph application) and AADSTS700016 appears in service-to-service calls without any configuration change -- this is typically a Microsoft-side service outage or a managed identity token cache issue, and Microsoft Support is the appropriate escalation path.
• The application is registered in an Entra External ID (CIAM) tenant and the error persists after authority URL correction, which may indicate a CIAM tenant configuration issue requiring Microsoft support.

For ongoing visibility into service principal credential hygiene across your Entra ID tenant -- which can help catch registration issues before they cause production auth failures -- see this Entra ID service principal hidden credentials audit guide.