Last week I posted an article (The difference between AzureAD App Registrations and Enterprise Applications explained) to which I received many responses. For many people, the difference between App Registrations and Enterprise Applications has become a lot clearer. I am therefore pleased that this was received so positively.

As a result of the above article I received quite a few questions, of which I will answer 1 in this new post:

I see various Enterprise Applications in my environment that I have not created myself. Where do they come from?

First of all, let me say that this does not necessarily mean something serious is going on. There are several reasons, and I will explain the most important one below.

Note: In my previous article, I always included both the Azure portal’s terminology and from within PowerShell. I have not done that here for simplicity reasons. The terms used in this article come from the Azure portal. Where App Registration and Enterprise Applications are mentioned, you can read Applications and Service Principals respectively.

Default Enterprise Applications

Do you remember the explanation from my previous article that an Enterprise Application is an App Registration instance? With the Enterprise Application in your tenant, the App Registration is able to offer a certain service that can communicate with the data that resides within your Azure AD directory. Perhaps the PowerShell terminology counterparts (Application and Service Principal) are a bit more descriptive of what functionality we are talking about here.

When a new tenant is created within Azure, there are several Enterprise Applications that must be present by default to make it possible for you to use them. These are also called Microsoft 1st party applications. A good example is the Azure portal. If you want to manage the new tenant, it might be handy that the application you’re using is allowed to do this. And the Enterprise Application for the Azure portal is necessary for this. Building on the example with the Azure portal, it basically works as follows: 

    1. You want to manage your Azure environment and decide to Sign in to the Azure Portal.
    2. The Azure Portal is an Application (that lives outside your own tenant) that can use the App Registration from the tenant Microsoft owns.
    3. In order for the Azure Portal to interact with your environment, an instance (the Enterprise Application) of the App Registration must be present in the tenant it wants to interact with.

DisplayName AppId
AAD Request Verification Service – PROD c728155f-7b2a-4502-a08b-b8af9b269319
Azure ESTS Service 00000001-0000-0000-c000-000000000000
Azure Portal c44b4083-3bb0-49c1-b47d-974e53cbdf3c
AzureSupportCenter 37182072-3c9c-4f6a-a4b3-b3f91cacffce
IAM Supportability a57aca87-cbc0-4f3c-8b9e-dc095fdc8978
MCAPI Authorization Prod d73f4b35-55c9-48c7-8b10-651f6f2acb2e
Microsoft App Access Panel 0000000c-0000-0000-c000-000000000000
Microsoft Graph 00000003-0000-0000-c000-000000000000
Microsoft Graph Change Tracking 0bf30f3b-4a52-48df-9a82-234910c4a086
Microsoft.SMIT 8fca0a66-c008-4564-a876-ab3ae0fd5cff
O365 Demeter 982bda36-4632-4165-a46a-9863b1bbcf7d
Office 365 Configure aa9ecb1e-fd53-4aaa-a8fe-7a54de2c1334
Signup b4bddae8-ab25-483e-8670-df09b9f1d0ea
Windows Azure Active Directory 00000002-0000-0000-c000-000000000000
Windows Azure Service Management API 797f4846-ba00-4fd7-ba43-dac1f8f63013

As some may already know, there are more Microsoft 1st party Applications. However, they are not immediately created when you request a new tenant. The moment you start using specific functionality that needs such an Enterprise Application, they will automatically be added to your directory. An example of this is Privileged Identity Management (PIM). As a result, there may be quite a few Enterprise Applications in your directory over time. You can find a more extensive list of these here: emilyvanputten/Microsoft-Owned-Enterprise-Applications (

Managed Identities

Lastly, you also have Enterprise Applications linked to a resource within your Azure environment, the so-called managed identities. The managed identities make it possible for an Azure resource (for example a Virtual Machine) to communicate with another Azure resource (for example a Storage Account) without storing login details on the virtual machine in this case. To make this possible, an Enterprise Application is required, so you have an identity to assign the required permissions to (via Azure AD and/or Azure RBAC). In a follow-up blog I will go deeper into how this works.