AADSTS700016 - Application Not Found In Tenant
Microsoft Entra ID returns `AADSTS700016` when the client application identifier cannot be found in the target tenant directory.
Last reviewed: April 10, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Application Not Found In Tenant Mean?
Token issuance fails because the requested application identity is unknown in the tenant being queried.
Common Causes
- -Client application ID is wrong or copied from a different app registration.
- -Auth request is sent to wrong tenant authority where the app is not registered.
- -App registration or service principal was deleted, disabled, or never provisioned in that tenant.
- -Multi-tenant consent/provisioning flow did not complete for target tenant.
How to Fix Application Not Found In Tenant
- 1Verify client ID and tenant authority pair in runtime configuration.
- 2Confirm application registration exists and is enabled in the intended tenant.
- 3Provision or consent the service principal in the resource tenant when required.
- 4Retry token request after correcting tenant/app registration alignment.
Step-by-Step Diagnosis for Application Not Found In Tenant
- 1Capture token request payload and confirm client ID plus authority host/tenant path.
- 2Inspect app registration and enterprise app objects in target tenant for existence/state.
- 3Validate signInAudience and multi-tenant support settings match usage model.
- 4Replay auth flow with known-good tenant/app combination to isolate configuration drift.
Application Identity and Tenant Alignment
- -Validate client ID maps to expected app registration in target tenant (example: production config still points to staging app ID).
- -Confirm authority path targets tenant where app/service principal is provisioned (example: app exists in home tenant but auth request sent to customer tenant without consent).
Provisioning and Consent State Validation
- -Inspect enterprise app/service principal presence in target tenant (example: multi-tenant app registration exists but service principal not created yet).
- -Audit recent tenant migration or app cleanup events (example: app registration deleted and recreated with new client ID not propagated to all services).
Seen in Production
Service deployed with wrong client ID after app registration swap
Frequency: common
Example: Token requests fail because referenced app ID does not exist in tenant.
Fix: Update client ID from authoritative registry and redeploy auth configuration.
Multi-tenant app not consented in customer tenant
Frequency: rare
Example: Auth call to customer tenant returns app-not-found error despite valid home tenant app registration.
Fix: Complete service-principal provisioning/consent in target tenant before token requests.
Debugging Tools
- -Entra sign-in and token failure logs
- -App registration and enterprise app inventory
- -Authority/client-ID configuration diff checks
- -Tenant onboarding automation logs
How to Verify the Fix
- -Request token again and confirm
AADSTS700016is resolved. - -Validate downstream API calls succeed using tokens from corrected app/tenant config.
- -Monitor auth logs for absence of app-not-found failures after rollout.
How to Prevent Recurrence
- -Maintain authoritative app identity registry with environment-specific client IDs.
- -Add CI checks that validate authority tenant and client ID pairing before deploy.
- -Automate tenant onboarding to provision/consent required service principals.
Pro Tip
- -run startup auth smoke tests that validate token issuance for every critical app identity before accepting production traffic.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.