AADSTS650052: the app needs a service your tenant has not subscribed to

Fix it now

AADSTS650052 is Microsoft telling you “The app needs access to a service that your organization hasn’t subscribed to or enabled”. There is no service principal in your tenant for the workload the application asked for, so no token can be issued against it. It is not a consent or permissions problem.

1. In the Entra admin centre open Monitoring and health, Sign-in logs, find the failed sign-in and read the resource it was trying to reach.
2. In Enterprise applications, All applications, set the Application type filter to All applications and search for that resource by name. Nothing returned means there is no service principal.
3. In the Microsoft 365 admin centre open Billing, Your products and check whether that workload sits on a subscription you actually own.
4. If the tenant does not own it, start the trial or buy the plan that contains it. The service principal is provisioned when the subscription lands.
5. If the principal does exist, open Properties and confirm it is enabled for users to sign in, then grant admin consent under Permissions.

Retry in a private browser window afterwards so a cached token is not reused and read as a continuing failure.

If sign-in works you can stop here. If not, the next section separates this from the four codes it is most often confused with.

Why it happens

Entra ID issues tokens for resources, and a resource has to exist in your tenant as a service principal before a token can be minted against it. Service principals for Microsoft workloads are provisioned when the tenant acquires the subscription that contains them. If the tenant never had that subscription, the object was never created, and the request fails before consent, permissions or roles are even considered.

Microsoft’s published text is unusually plain for an AADSTS code: “The app needs access to a service (\”{name}\”) that your organization \”{organization}\” hasn’t subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions.” The name in that message is the resource, and it is the single most useful thing on the screen – it tells you exactly what to go and look for.

The neighbouring codes describe the same shape of failure at different points. AADSTS500011 is InvalidResourceServicePrincipalNotFound: the resource principal was not found in the named tenant, which can mean the application was never installed by an administrator, never consented to by any user, or – the one people forget – that the authentication request went to the wrong tenant altogether. AADSTS500014 is InvalidResourceServicePrincipalDisabled: the service principal exists but is disabled, which Microsoft says indicates either a subscription within the tenant having lapsed or an administrator having deliberately disabled the application’s service principal.

That distinction is worth holding on to. 650052 means the object was never there. 500014 means it is there and switched off, and one of the two causes for that is a licence that used to be paid for and no longer is. AADSTS50001, InvalidResource, is blunter still – “The resource is disabled or doesn’t exist” – and Microsoft’s remedy points at the application’s own code and the exact resource URL it is requesting. AADSTS650054 is the tidying-up case: the application is still asking for permissions to a resource that has been removed or is no longer available.

Full reference

Five codes, five different situations

Reading the sign-in log properly

• Filter to failures and find the exact entry by time and username rather than by error text.
• Open the entry and read the Resource name and Resource ID. The resource is what is missing, not the application.
• Check the Application ID as well. A supplier’s application and its resource are often different objects.
• Look at the Conditional Access tab on the same entry. A policy failure produces a different code, and ruling it out takes seconds.

Confirming a service principal exists

The Enterprise applications list defaults to a filtered view that does not show everything. Set the Application type filter to All applications before concluding an object is absent, otherwise you will buy a subscription for a workload the tenant already owns.

What will not fix this

• Granting admin consent. Consent applies to an object that exists; it cannot create one.
• Adding API permissions in the app registration. Same reason.
• Registry changes, client reinstalls or cache clearing. This decision is taken in the directory, not on the device.
• Adding the user to a role. Roles govern what a principal may do, not whether a resource exists.
• Assigning a licence to the user, if the tenant does not hold the subscription at all. The subscription has to exist before seats can be assigned from it.

Before you buy

Two checks save money here. First, confirm the resource is genuinely a Microsoft workload sold on a plan rather than a third-party application that simply needs consent – the error text names it, so this takes a minute. Second, check whether an existing subscription already contains it under a different name; Microsoft workloads move between bundles and are frequently already owned. Start a trial before a purchase where one is available, because the trial provisions the same service principal and proves the diagnosis for nothing.

Every code this article covers

Confirm the fix worked

1. The resource named in the error now appears under Enterprise applications, All applications with the type filter set to All applications.
2. Billing, Your products shows an active subscription containing that workload.
3. The application’s service principal shows Enabled for users to sign-in set to Yes.
4. A test sign-in in a private browser window completes without AADSTS650052.
5. The sign-in log records a success for the same user, application and resource.

Questions people ask about this