There’s one topic in Azure I kept revisiting until it finally clicked: the relationship between App Registrations, Enterprise Applications, and how access to Microsoft 365 data works in the cloud. If you’re also trying to untangle this knot, don’t worry—you’re not alone. What helped me most was looking at the issue from different angles and working through plenty of real-world examples. Let’s break it all down.

The Basics: What Is the M365/Azure Cloud Anyway?

Microsoft 365 (M365) operates as a closed cloud system—meaning, it doesn’t just serve up your data to the public internet. To access that data from outside (e.g., through apps, scripts, or services), there are specific pathways:

• The most common method is using a user login with the necessary permissions.
• But applications and services also need to authenticate. This is where App Registrations in Microsoft Entra ID (formerly Azure AD) come into play.

App Registrations – The Entry Point

When you create an App Registration in Entra ID, you’re essentially defining a global application identity. During registration , you’ll be asked to choose the account type, which determines who can access the app:

1. Single-tenant: Only users from your Entra tenant can use the app.
2. Multi-tenant: Users from any Entra tenant can use the app.
3. Accounts in any identity provider: Including Microsoft personal accounts.

Tip: If your app only needs to access data within your own tenant (e.g., for automation scripts or internal tools), Single-tenant is enough. Go multi-tenant only if you’re building for other organizations.

you can do the creation here

Redirect URIs – Why and When You Need Them

A redirect URI tells Entra ID where to send the authentication response after a successful login. This is required only for delegated permissions—that is, when a user signs in and the app performs actions on their behalf.

For example:

• If your app pops up a login window and waits for the user to sign in, it needs a redirect URI.
• But if your app uses application permissions (i.e., acting as itself, not a user), no redirect URI is needed.

App Registration Settings

Once your app is registered, you can configure:

• Branding & Properties: What users see during login.
• Certificates & Secrets: For app authentication (especially in app-only scenarios).
• API Permissions: What resources your app can access.
• Token Configurations, App Roles, and more.

This setup allows the app to interact with Microsoft APIs via PowerShell, scripts, or custom code—either as itself (application context) or on behalf of a user (delegated context).

Wait, What’s an Enterprise Application Then?

When you create an App Registration, you’re defining what your application is—its identity, permissions, and capabilities—at a global level. But for that app to exist and function inside a specific Entra tenant, it needs a local representation. That’s where Enterprise Applications come in.

An Enterprise Application is the tenant-specific instance of your app. It acts as the Service Principal—the security identity your app uses to sign in and access resources within that tenant.

You can think of it this way: The App Registration is the master template of your application. The Enterprise Application is the actual deployment of that app inside a particular tenant.

Each tenant that interacts with your app (either because you built it or because they’ve granted consent) will have its own Enterprise Application for it.

Why Does Azure Create Enterprise Applications?

Because Entra ID (Azure AD) is multi-tenant by design. Azure needs a separate object in each tenant that:

• Stores tenant-specific roles and permissions
• Logs sign-ins and tracks usage
• Supports Conditional Access policies
• Can be assigned to groups or users

In short: The Enterprise Application is your app’s avatar in each tenant it lives in.

Why Do I Have So Many Enterprise Applications?

Even if you’ve only created a few App Registrations yourself, your tenant might still be full of Enterprise Applications. Here’s why:

1. Every time you register an app, an Enterprise Application is created.

2. Every time you consent to use a third-party app (e.g., a SaaS backup or CRM tool), an Enterprise Application is created in your tenant—even if the App Registration lives in someone else’s tenant.

Each visible Enterprise Application has some level of access to your tenant. Managing this access is crucial for security—I’ll cover that in an upcoming post.

Example: From App Registration to Multi-Tenant Usage

Let’s walk through a typical scenario: You build an app called MyCoolApp and register it in contoso.com. This creates:

1. An App Registration in contoso.com
2. An Enterprise Application (Service Principal) in contoso.com

Now, a client from fabrikam.com wants to use it: An admin at fabrikam.com consents to the app.

• An Enterprise Application is automatically created in fabrikam.com.

So now:

• There’s 1 App Registration (in contoso.com)
• And 2 Enterprise Applications (one in each tenant)

This is a classic 1:N relationship: one app registration can result in many Enterprise Applications.

If you’re building internal tools, Enterprise Applications may not be something you deal with daily. But if you start supporting external tenants—or using third-party apps—understanding this architecture becomes critical. In the end, it all comes down to this: App Registrations define what an app is, and Enterprise Applications define what it does in your tenant. Stay tuned—next time I’ll show you how to analyze permissions and reduce risks from third-party Enterprise Applications in your environment.