The problem

If you've spent more than five minutes inside Microsoft Entra ID,
you've probably seen these two menus:

• App registrations
• Enterprise applications

At some point you probably asked yourself:

Why are there two things that look like the same thing?

You create an app.
Then suddenly you see another app with the same name somewhere else.

Did Azure duplicate it?
Did someone clone it?
Did you break something?

No.

You're just looking at two different perspectives of the same application.

The short explanation

In Entra ID terms:

Mental model

• App Registration → what the app is
• Enterprise Application → where the app exists

One application can live in many tenants.
Each tenant gets its own Enterprise Application.

How they are connected

  graph LR

    A[App Registration
Application Object]
    B[Enterprise Application
Service Principal
Tenant A]
    C[Enterprise Application
Service Principal
Tenant B]
    D[Enterprise Application
Service Principal
Tenant C]

    A --> B
    A --> C
    A --> D

    style A fill:#DF6155,stroke:#333,stroke-width:2px,color:#fff

A single App Registration can create multiple Service Principals.

That’s why the same application can appear across tenants.

What happens when you create an app

  graph LR

    A[Create App Registration]
    B[Application Object]
    C[Service Principal]
    D[Enterprise Application]

    A --> B --> C --> D

    style B fill:#DF6155,stroke:#333,color:#fff

Every App Registration automatically creates a Service Principal in the same tenant.

That Service Principal is what you see as the Enterprise Application.

Why Microsoft split this

• Developers manage App Registrations
• Administrators manage Enterprise Applications

This allows one shared definition with tenant-specific control.

Where people get confused

"Why do I see the app twice?"
Because it's two different objects.

"Where do I assign users?"
Enterprise Application.

"Where do I configure Conditional Access?"
Enterprise Application.

"Where do I configure API permissions?"
App Registration.

Rule of thumb

• Tenant-specific → Enterprise Application
• App definition → App Registration

Real world analogy

One blueprint.
Many installations.

Working without the App Registration

Sometimes you don’t own the app.

Typical scenarios:

• Multi-tenant applications
• Managed Identities
• Third-party integrations

But you still need to assign permissions.

Important

Permissions are assigned to the Service Principal (Enterprise Application) — not the App Registration.

Assign permissions directly to an Enterprise Application

Sometimes you don’t own the App Registration.

This typically happens with:

• Multi-tenant applications
• Managed Identities
• Third-party integrations

But you still need to assign permissions.

Here’s the key thing most people miss:

Permissions are assigned to the Service Principal (Enterprise Application) — not the App Registration.

So even without access to the App Registration, you can still grant permissions.

Example

Below is a simple example where we assign a Microsoft Graph permission directly to an Enterprise Application.

$graphScopes is just an example — use any valid Graph permission.

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All","RoleManagement.ReadWrite.Directory"

Select-MgProfile Beta

$managedIdentityId = "Enterprise app Object ID "

# Microsoft Graph Service Principal
$graphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

$graphScopes = @(
  'ReportSettings.Read.All'
)

foreach($scope in $graphScopes){
  $appRole = $graphApp.AppRoles | Where-Object {$_.Value -eq $scope}

  New-MgServicePrincipalAppRoleAssignment `
    -PrincipalId $managedIdentityId `
    -ServicePrincipalId $managedIdentityId `
    -ResourceId $graphApp.Id `
    -AppRoleId $appRole.Id
}

What this script actually does

Let’s break it down step by step.

1. Connect to Microsoft Graph

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All","RoleManagement.ReadWrite.Directory"

Grants your session permission to:

• Read applications
• Assign app roles
• Modify directory roles

2. Select beta profile

Select-MgProfile Beta

Some endpoints (like app role assignments) are more flexible in beta.

3. Identify your Enterprise Application

$managedIdentityId = "GUID"

This is the Service Principal you want to assign permissions to.

4. Get Microsoft Graph

$graphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

This ID:

00000003-0000-0000-c000-000000000000

is the well-known AppId for Microsoft Graph.

You are not targeting your own app —
you are targeting the Microsoft Graph Enterprise Application.

5. Define the permission

$graphScopes = @(
  'ReportSettings.Read.All'
)

This is just an example.

You can replace it with any valid application permission exposed by Graph.

6. Find the matching App Role

$appRole = $graphApp.AppRoles | Where-Object {$_.Value -eq $scope}

This looks up the internal ID of the permission.

7. Assign the permission

New-MgServicePrincipalAppRoleAssignment

This is the important part.

You are effectively saying:

"Give this Service Principal access to this permission on Microsoft Graph"

What this means in practice

After running the script:

• The Enterprise Application now has the permission
• The App Registration (if it exists elsewhere) is unchanged
• You have granted access locally in your tenant

Mental model

App Registration = What the app can request
Enterprise Application = What the app actually has

This script operates entirely on the second part.

That’s why it works — even when you don’t control the app.