AADSTS500011: The resource principal was not found in the tenant

What does AADSTS500011 mean?

Microsoft’s description:

InvalidResourceServicePrincipalNotFound: The resource principal named {name} wasn’t found in the tenant named {tenant}. This can happen if the application hasn’t been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. If you expect the app to be installed, you might need to provide administrator permissions to add it. Check with the developers of the resource and application to understand what the right setup for your tenant is.

The full message users see reads “AADSTS500011 - The resource principal named [resource URL] was not found in the tenant named [tenant ID]”.

The missing object is the resource: the API the app wants a token for. If the missing object is the client app itself, the error is 700016 instead.

Microsoft explains why the object must exist: “A service principal must be created in each tenant where the application is used.” An API registered in another tenant has no service principal in yours until an admin provisions it or someone consents to it.

Reproduced in the lab

On 25 October 2026 an automated lab run sent a token request for a scope on a resource that doesn’t exist in my lab tenant. Entra returned AADSTS500011 with this first line:

AADSTS500011: The resource principal named https://does-not-exist.brambrinkmeier.com was not found in the tenant named {tenant-id}.

That confirms the code and its wording at the token endpoint.

The same attempt in the lab tenant’s sign-in log (Entra admin center, interactive user sign-ins), with identifiers left out:

Field	Value in the lab row
Status	Failure
Sign-in error code	500011
Failure reason	The resource principal named {name} was not found in the tenant named {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.
Authentication requirement	Single-factor authentication
Conditional Access	Not Applied
User type	Member

The log shows Microsoft’s template text with placeholders; the actual resource name appears only in the error returned to the client, so keep the client’s error message when you troubleshoot. The KQL below was run on the lab rows (how). The first query found both lab rows. The second query reads AADServicePrincipalSignInLogs, and the lab rows are user sign-ins, so it is not tested yet.

Is it an attack?

No. Microsoft’s troubleshooting article lists four causes, all configuration:

• “The resource application isn’t provisioned by the administrator in the tenant.”
• “The resource application isn’t consented to by any user in the tenant.”
• “The resource URL is not configured correctly.”
• “The tenant ID is not correct.”

Pattern	Likely meaning
500011 for one app, every user, starting at a deployment	A typo or wrong value in the resource URL or scope. Developer error.
500011 for a vendor’s multitenant app after onboarding	The vendor’s API was never provisioned or consented in your tenant. Setup step missing.
500011 naming a resource you don’t recognise, from an app or IP you don’t recognise	Someone asking your tenant for tokens to an API you never set up. Our interpretation, not a documented detection: the request failed, but the client and IP are worth a look.

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

User flows, grouped by client and the resource in the request:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "500011"
| summarize Attempts = count(),
            Users = dcount(UserPrincipalName),
            Resources = make_set(ResourceIdentity, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppDisplayName, AppId
| sort by Attempts desc

App-only flows (client credentials):

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "500011"
| summarize Attempts = count(),
            Resources = make_set(ResourceIdentity, 10),
            IPs = make_set(IPAddress, 10)
          by AppId, ServicePrincipalName
| sort by Attempts desc

The resource in the error doesn’t exist in your tenant, so ResourceIdentity and ResourceDisplayName may be empty on these rows. That isn’t documented either way. If they are, the resource URL is in the error text, so look at ResultDescription or open one event in the portal. Silent token requests for a missing resource can also land in AADNonInteractiveUserSignInLogs; swap the table name in the first query to check.

For app-only rows, confirm in your workspace that ResultType carries "500011" and not “Failure”. The Azure Monitor reference for AADServicePrincipalSignInLogs describes it as “Success or Failure”. If so, filter on ResultSignature.

How does Conditional Access affect it?

• 500011 happens before any Conditional Access decision on the resource. There is no resource in your tenant for a policy to target.
• Once the resource is provisioned, it gets a service principal and appears as a target in Conditional Access like any other app. Check that your policies cover it before users start using it.

How do I fix AADSTS500011?

For developers:

1. Compare the resource URL or scope in the error with the API’s App ID URI or application ID. A wrong value here is the most common cause.
2. Check that the request goes to the right tenant, not a tenant where the API was never set up.

For admins:

1. Look under Enterprise applications for the resource named in the error. If it isn’t there, it was never provisioned in your tenant.
2. If the API should be used, provision it and grant consent. For a vendor app, ask the vendor for their admin consent link. Microsoft documents an admin consent endpoint (https://login.microsoftonline.com/{tenant}/v2.0/adminconsent) that apps use to “grant permissions to an entire tenant”.
3. Before consenting, check what the API’s permissions allow. Provisioning a resource creates a service principal in your tenant that “defines what the app can actually do in the specific tenant”.