App Registration vs Enterprise Application vs Service Principal (Entra ID)
Three names, one idea, and a portal that shows you two of them under labels that do not match the docs. Here is the picture that makes it stick — and stops you editing the wrong blade at three in the morning.
New to cloud? CAMPUX is a free, build-first course. Start here →
The short version: an app registration is one blueprint, a service principal is one local instance of that blueprint per tenant, and Enterprise Applications is the Portal blade that lists those instances. Everything confusing about these three objects comes from the same source — Microsoft defines an application once and then lets many tenants use it, so it needs a global object and a local one, and the Portal renames the local one. Get that split and the rest is just knowing which screen to open.
Most people meet these terms out of order. You create an app registration, and moments later the same app shows up under Enterprise Applications with the same name, and a script you copied talks about a service principal you never made. Nothing is broken. You are looking at one thing from three angles. Let me draw the angles.
Direct answer: one blueprint, one local instance per tenant, one portal view of those instances
Say it as a sentence you can keep in your head. One app registration is the blueprint for an application. One service principal per tenant is the working copy that tenant actually uses. Enterprise Applications is the Portal blade that lists those working copies. The blueprint is written once, in the tenant where the app is born. A copy is stamped out in every tenant that uses the app, including the home tenant. And when you browse Enterprise Applications, you are reading the list of copies your tenant holds.
That is the whole model. The app registration defines what the app is and what it may ask for. The service principal is your tenant's identity for that app, the thing that actually holds permissions and signs in. Enterprise Applications is just where you go to see and manage those identities. Two objects, one of them viewed under a different name.
App registration = the global app object
When you register an application, Entra ID creates an application object — the app registration. It is the blueprint, and it lives in exactly one place: the home tenant, the directory where the app was created. There is only ever one of it. Think of it as the design document for the software, signed and filed once.
Because it is the definition, the app registration is where the app's own settings live:
- Client secrets and certificates — the credentials the app uses to prove it is itself when it authenticates.
- Redirect URIs — the URLs Entra is allowed to send sign-in responses back to.
- API permissions (scopes and app roles) — the list of permissions the app is allowed to request, such as reading a user's profile from Microsoft Graph.
- The application ID (client ID) — the stable identifier that ties every copy back to this one blueprint.
Notice the word "request." The app registration says what the app can ask for. It does not, by itself, hand your tenant's data to anyone. Granting is a separate act, and it happens on the other object.
Service principal = the tenant-local identity that gets permissions
A service principal is the local instance of the app inside a specific tenant. It is created from the blueprint, and it is the object that actually does things: it is the identity that signs in, that you assign roles to, and that consent is recorded against. If the app registration is the design document, the service principal is the concrete account your tenant runs the app under.
The key fact people miss: there is one service principal per tenant that uses the app. Register the app in your tenant and a service principal for it is created in your tenant too. When a second organization consents to your app, Entra creates a separate service principal in their tenant. Same blueprint, many local instances — one for each directory the app touches. This is why role assignments and consent are always tenant-local: you are granting to a specific service principal, not to the global app.
The app registration says what the app may ask for. The service principal is what your tenant actually grants. One is a request; the other is an answer.
Enterprise Application = the Portal blade that lists service principals
Here is the rename that trips everyone. In the Entra admin center, the Enterprise Applications blade is simply the list of service principals in your tenant, shown in a management-friendly view. Open an enterprise application and you are editing the underlying service principal. Microsoft Graph and the audit logs call the same object a servicePrincipal; the Portal calls it an enterprise application. Two names, one object.
Because the enterprise application is the service principal, it is where you manage how your tenant uses the app:
- User and group assignment — who in your tenant is allowed to use the app.
- Single sign-on (SSO) configuration — SAML or OIDC settings for that app in your directory.
- Enable or disable sign-in — a switch that turns the app on or off for your tenant without touching the blueprint.
- Consent and permission grants — the record of what your tenant actually agreed to give the app.
This is also why a SaaS app you did not build still appears under Enterprise Applications with no app registration in sight. Its blueprint lives in the vendor's tenant. Your tenant only ever gets the local copy — the service principal — so the blade shows it and the registration does not exist for you to edit.
Which blade to use for which task
The practical question is never "what are these three things" — it is "which screen do I open." The rule holds up: if you are changing the app, go to the app registration; if you are changing how your tenant uses the app, go to the enterprise application. The table lines the three up side by side.
| App registration | Service principal | Enterprise application | |
|---|---|---|---|
| What it is | The application object — the global blueprint that defines the app. | The tenant-local identity built from that blueprint; the thing that gets permissions. | The Portal blade that lists and manages service principals; the same object under a friendlier name. |
| Where it lives | Once, in the home tenant only. | Once per tenant that uses the app. | Shows your own tenant's service principals. |
| What you configure there | Secrets, certificates, redirect URIs, API permissions the app can request, exposed scopes. | Role assignments, granted permissions, credentials for daemon apps (via Graph or CLI). | User and group assignment, SSO, enable or disable sign-in, review consent. |
| Portal blade | Entra ID → App registrations. | No dedicated blade; managed via Enterprise Applications, Graph, or Azure CLI. | Entra ID → Enterprise applications. |
Adding a client secret or a redirect URI, or declaring a Graph permission the app needs. That is the blueprint changing — App registrations. Assigning a group to the app, wiring up SAML SSO, or switching the app off for your staff. That is your tenant's use of the app changing — Enterprise applications. If the change would affect every tenant that uses the app, it belongs on the registration. If it only affects yours, it belongs on the enterprise application.
The gap: multi-tenant apps and where managed identities fit in
Two cases make the model click all the way, and both are where the single-tenant picture leaks.
Multi-tenant apps. A single-tenant app has its registration and its service principal in the same directory, so they feel like one thing. A multi-tenant app breaks that illusion cleanly: the registration stays in the publisher's home tenant, and a fresh service principal is created in each customer tenant the first time that tenant signs in or an admin consents. So a customer admin who wants to assign users or disable the app edits their own enterprise application — never the publisher's registration, which they cannot see. This is the same reason your tenant has a service principal for well-known Microsoft apps you never registered: their blueprints live elsewhere, your copies live here.
Managed identities. A managed identity is a service principal that Azure creates and manages for you, with no app registration and no secret to rotate. You attach it to an Azure resource — a VM, a Function, a container app — assign it roles, and it authenticates on its own from inside Azure. It shows up in Enterprise Applications like any other service principal, but there is no blueprint blade behind it, because Azure owns the lifecycle. When a workload runs on an Azure resource, a managed identity is almost always the better choice than a hand-built app registration with a secret, precisely because there is no credential for you to leak. We pull that comparison apart in a separate note on managed identity vs service principal.
If the parent object is still fuzzy, start with what Microsoft Entra ID actually is. Once identities hold permissions, they need roles — see Owner, Contributor, and Reader explained. And to stop putting secrets on service principals in your pipelines, read OIDC for pipelines with no stored secrets.
Questions people also ask
What is the difference between an app registration and an enterprise application?
The app registration is the application object — the global blueprint that holds secrets, redirect URIs, and the API permissions the app can request. It lives once, in the tenant where the app was created. The enterprise application is the Portal blade that shows the service principal — the tenant-local identity built from that blueprint. You edit the app itself on the registration; you edit how your tenant uses it on the enterprise application.
Is an enterprise application a service principal?
Effectively, yes. Enterprise Applications is the Portal blade that lists your tenant's service principals in a friendly view. When you open an enterprise application, you are editing the underlying service principal object. Microsoft Graph and the audit logs call the same object a service principal; the Portal calls it an enterprise application.
When should I use app registration vs enterprise application?
Use the app registration when you are changing the application itself: adding a client secret or certificate, setting redirect URIs, or declaring the API permissions the app requests. Use the enterprise application when you are changing how your tenant uses the app: assigning users and groups, configuring single sign-on, or disabling sign-in. One is the blueprint; the other is your tenant's local instance.
Does every app registration create a service principal?
Not automatically in every tenant, but yes in its home tenant in the normal case. Creating an app registration in the Portal also creates a service principal for it in that same tenant. A separate service principal is created in every other tenant when that tenant consents to or installs the app. So one app registration can map to many service principals — one per tenant that uses it.
How is a managed identity different from a service principal?
A managed identity is a special kind of service principal that Azure creates and manages for you, with no app registration and no secrets to handle. You assign it roles and it authenticates automatically from inside Azure. A plain service principal usually comes from an app registration and needs a secret or certificate you rotate yourself. Prefer a managed identity whenever the workload runs on an Azure resource.