🚨 Azure Error Guide: 'AADSTS700016' App Not Found & 'AADSTS50076' MFA Required

Overview

AADSTS700016 and AADSTS50076 are two distinct Entra ID (formerly Azure AD) sign-in failures that often surface during automation and az login. AADSTS700016 means the application identifier presented in the token request does not exist in the directory being queried — almost always a wrong-tenant or wrong-client-ID problem. AADSTS50076 means authentication itself is fine but a Conditional Access policy now requires multi-factor authentication that the current flow cannot satisfy.

You will see AADSTS700016 like this:

AADSTS700016: Application with identifier '8f3b2c1d-aaaa-bbbb-cccc-1234567890ab' was not found in the directory 'Contoso (99999999-aaaa-bbbb-cccc-dddddddddddd)'. 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.
Trace ID: 1c2d3e4f-...

And AADSTS50076 during an interactive or device-code flow:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000003-0000-0000-c000-000000000000'.
Trace ID: 7a8b9c0d-...
Correlation ID: ...

Both are returned by the token endpoint with a stable AADSTS code, so the code itself tells you which problem you have. The fix differs entirely: 700016 is a directory/identity lookup failure, 50076 is a policy enforcement.

Symptoms

• az login or a service-principal login fails with AADSTS700016: Application ... was not found in the directory.
• An interactive or device-code login fails with AADSTS50076: ... you must use multi-factor authentication.
• The same client ID works in one tenant but not another.
• CI/CD pipeline service-principal logins suddenly fail after a Conditional Access change.

az login --service-principal -u 8f3b2c1d-aaaa-bbbb-cccc-1234567890ab -p "$SP_SECRET" --tenant 99999999-aaaa-bbbb-cccc-dddddddddddd

ERROR: AADSTS700016: Application with identifier '8f3b2c1d-aaaa-bbbb-cccc-1234567890ab' was not found in the directory 'Contoso (99999999-...)'. You may have sent your authentication request to the wrong tenant.

az account show --query "{tenantId:tenantId, user:user.name, type:user.type}" -o table

TenantId                              User                                  Type
------------------------------------  ------------------------------------  -----------------
11111111-aaaa-bbbb-cccc-dddddddddddd  8f3b2c1d-aaaa-bbbb-cccc-1234567890ab  servicePrincipal

A successful prior login shows the tenant where the app actually lives — compare it to the tenant in the error.

Common Root Causes

1. App registration in the wrong tenant

The application object (az ad app) exists only in its home tenant. If you request a token from a different tenant, the directory lookup fails with 700016.

# Where does the app registration actually exist?
az ad app show --id 8f3b2c1d-aaaa-bbbb-cccc-1234567890ab \
  --query "{name:displayName, appId:appId, homeTenant:publisherDomain}" -o table

Name              AppId                                 HomeTenant
----------------  ------------------------------------  --------------------
ci-deployer       8f3b2c1d-aaaa-bbbb-cccc-1234567890ab  fabrikam.onmicrosoft.com

The app is registered in the fabrikam tenant, but the login targeted the contoso tenant — wrong tenant in --tenant.

2. Service principal not provisioned in the tenant

An app registration (the application object) is global, but you sign in against its service principal in a given tenant. For multi-tenant apps, if the SP was never created (consented) in the resource tenant, 700016 results.

# Is there a service principal for this appId in the current tenant?
az ad sp show --id 8f3b2c1d-aaaa-bbbb-cccc-1234567890ab \
  --query "{name:displayName, appId:appId, oid:id}" -o table

ERROR: Resource '8f3b2c1d-aaaa-bbbb-cccc-1234567890ab' does not exist or one of its queried reference properties object cannot be resolved.

No SP exists in this tenant. An admin must consent/provision it (az ad sp create --id <appId> or admin-consent) before logins succeed here.

3. Wrong client / app ID

A copy-paste error, a swapped object ID vs application ID, or pointing at the wrong app entirely all produce 700016 because the identifier genuinely is not found.

# List apps by display name to confirm the correct appId
az ad app list --display-name "ci-deployer" \
  --query "[].{name:displayName, appId:appId, objectId:id}" -o table

Name         AppId                                 ObjectId
-----------  ------------------------------------  ------------------------------------
ci-deployer  d4d4d4d4-1111-2222-3333-444455556666  6a6a6a6a-bbbb-cccc-dddd-eeeeeeeeeeee

The real appId is d4d4..., not the 8f3b... used at login (which may be the object ID or a stale value). Use the appId column, not objectId.

4. MFA required by Conditional Access (AADSTS50076)

A Conditional Access policy now requires MFA for the resource. Non-interactive flows (device code, some service-principal scenarios) cannot complete the MFA challenge and fail with 50076.

# Confirm what account/flow you are using
az account show --query "{user:user.name, type:user.type, tenant:tenantId}" -o table
# Retry forcing an interactive browser flow that can satisfy MFA
az login --tenant 11111111-aaaa-bbbb-cccc-dddddddddddd --use-device-code

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ABCD-EFGH to authenticate.
AADSTS50076: ... you must use multi-factor authentication to access '00000003-0000-0000-c000-000000000000'.

A user account hitting a CA-protected resource must complete MFA in a browser; automation should use a service principal or workload identity exempt from interactive MFA.

5. Conditional Access blocking the sign-in

Beyond MFA, a CA policy can block sign-in by location, device compliance, or client app. The token endpoint returns a related AADSTS code (e.g., 53003 blocked by CA), and the sign-in shows up in the Entra sign-in logs with the failing policy.

# Identify the service principal so you can correlate it in sign-in logs
az ad sp show --id <APPID> --query "{name:displayName, appId:appId, oid:id}" -o table

Name              AppId                                 Oid
----------------  ------------------------------------  ------------------------------------
ci-deployer       d4d4d4d4-1111-2222-3333-444455556666  6a6a6a6a-bbbb-cccc-dddd-eeeeeeeeeeee

Use this object ID to find the failed sign-in (Entra portal > Sign-in logs > Service principal sign-ins) and read which CA policy applied.

6. Expired or wrong client secret

A wrong client ID gives 700016, but a wrong/expired secret for the right app gives AADSTS7000215 (invalid client secret) or AADSTS700024 (expired credential). Confirm the credential is current.

az ad app credential list --id <APPID> \
  --query "[].{keyId:keyId, end:endDateTime}" -o table

KeyId                                 End
------------------------------------  --------------------------
9c9c9c9c-1111-2222-3333-444455556666  2026-05-01T00:00:00+00:00

The only secret expired on 2026-05-01 (before today) — generate a new one with az ad app credential reset --id <APPID> and update the pipeline.

Diagnostic Workflow

Step 1: Read the AADSTS code and the directory it names

# The error text contains the code and the tenant it queried, e.g.:
# AADSTS700016 ... was not found in the directory 'Contoso (99999999-...)'
echo "Code = 700016 (app not found) or 50076 (MFA required)?"

700016 = directory/identity problem; 50076 = MFA/policy problem. Note the tenant GUID in the message.

Step 2: For 700016, confirm where the app actually lives

az ad app show --id <APPID> --query "{name:displayName, appId:appId, publisher:publisherDomain}" -o table
az ad app list --display-name "<NAME>" --query "[].{name:displayName, appId:appId, objectId:id}" -o table

Verify you are using the appId (not object ID) and the tenant where it is registered.

Step 3: Confirm the service principal exists in the target tenant

az ad sp show --id <APPID> --query "{name:displayName, appId:appId}" -o table

A “does not exist” error means the SP is not provisioned in this tenant — consent/create it.

Step 4: For 50076, retry an MFA-capable flow and identify the account

az account show --query "{user:user.name, type:user.type, tenant:tenantId}" -o table
az login --tenant <TENANT> --use-device-code

If a user account is being used for automation, switch to a service principal that CA policies exempt or scope appropriately.

Step 5: Validate the credential and tenant for the final login

az ad app credential list --id <APPID> --query "[].{keyId:keyId, end:endDateTime}" -o table
az login --service-principal -u <APPID> -p "$SP_SECRET" --tenant <CORRECT_TENANT>
az account show -o table

Example Root Cause Analysis

A nightly deployment pipeline that ran for months suddenly fails at the az login step with AADSTS700016.

The pipeline log shows:

AADSTS700016: Application with identifier '6a6a6a6a-bbbb-cccc-dddd-eeeeeeeeeeee' was not found in the directory 'Fabrikam (11111111-...)'. You may have sent your authentication request to the wrong tenant.

The tenant is correct (Fabrikam), so this is not a wrong-tenant issue. Looking up the app by name reveals the problem:

az ad app list --display-name "ci-deployer" \
  --query "[].{name:displayName, appId:appId, objectId:id}" -o table

Name         AppId                                 ObjectId
-----------  ------------------------------------  ------------------------------------
ci-deployer  d4d4d4d4-1111-2222-3333-444455556666  6a6a6a6a-bbbb-cccc-dddd-eeeeeeeeeeee

The pipeline variable was updated to use 6a6a... — but that is the object ID, not the application (client) ID. Entra looks up the client ID at the token endpoint, finds nothing matching 6a6a..., and returns 700016.

Fix: point the login at the real appId and confirm the secret is still valid:

az ad app credential list --id d4d4d4d4-1111-2222-3333-444455556666 \
  --query "[].{keyId:keyId, end:endDateTime}" -o table
az login --service-principal -u d4d4d4d4-1111-2222-3333-444455556666 \
  -p "$SP_SECRET" --tenant 11111111-aaaa-bbbb-cccc-dddddddddddd

Using the application (client) ID, the login succeeds and the pipeline resumes.

Prevention Best Practices

• Always store and use the application (client) ID for logins — not the object ID. The two GUIDs are easy to swap and produce AADSTS700016.
• Pin the correct --tenant explicitly in automation; never rely on the default directory, which can differ from where the app is registered.
• For multi-tenant apps, confirm the service principal is provisioned (admin-consented) in every tenant you log in against.
• Use service principals or workload identity federation for automation so Conditional Access MFA (AADSTS50076) does not block headless flows meant for users.
• Track client-secret expiry with az ad app credential list and rotate before endDateTime, so logins fail open in your runbook, not in production.
• For ad-hoc triage, the free incident assistant can map an AADSTS code to its likely cause and next command. See more in Azure guides.

Quick Command Reference

# What account/tenant am I currently using?
az account show --query "{user:user.name, type:user.type, tenant:tenantId}" -o table

# Where is the app registered, and what is its real appId?
az ad app show --id <APPID> --query "{name:displayName, appId:appId, publisher:publisherDomain}" -o table
az ad app list --display-name "<NAME>" --query "[].{name:displayName, appId:appId, objectId:id}" -o table

# Does a service principal exist in this tenant?
az ad sp show --id <APPID> --query "{name:displayName, appId:appId, oid:id}" -o table
az ad sp list --display-name "<NAME>" --query "[].{name:displayName, appId:appId}" -o table

# Client-secret expiry
az ad app credential list --id <APPID> --query "[].{keyId:keyId, end:endDateTime}" -o table

# MFA-capable interactive login (for AADSTS50076)
az login --tenant <TENANT> --use-device-code

# Service-principal login with the correct appId + tenant
az login --service-principal -u <APPID> -p "$SP_SECRET" --tenant <TENANT>

Conclusion

AADSTS700016 and AADSTS50076 look similar but are unrelated — the code tells you which to fix. The usual root causes:

1. The app registration lives in a different tenant than the one you logged in against.
2. The service principal was never provisioned/consented in the target tenant.
3. The wrong client/app ID was used — frequently the object ID instead of the application (client) ID.
4. A Conditional Access policy requires MFA that the current flow cannot complete (AADSTS50076).
5. Conditional Access otherwise blocks the sign-in by location, device, or client app.
6. The client secret is wrong or expired (AADSTS7000215 / AADSTS700024).

Read the AADSTS number and the directory named in the message first — 700016 is an identity-lookup fix (right appId, right tenant, SP exists), while 50076 is a policy fix (use an MFA-capable or exempt flow).