An app registration is the application object: the single, global definition of an app that lives in its home tenant. An enterprise application is a service principal: the local instance of that app in one tenant, where you control who can sign in and what the app can access. In the Microsoft Entra admin center, you find them under App registrations and Enterprise applications respectively, and both share the same Application (client) ID.
Who this is for and what you will have
This guide is for administrators and developers who see the same app in two places in Entra ID and are not sure which blade to use. By the end you will know what each object stores, how they relate in single-tenant and multitenant scenarios, how to jump from one to the other, which tasks belong to which, and how to troubleshoot common confusion such as missing enterprise applications or mismatched IDs.
The short version
| App registration | Enterprise application | |
|---|---|---|
| Object type | Application object | Service principal |
| Scope | Global, one per app, in the home tenant | Local, one per tenant that uses the app |
| Role | Template or blueprint | Instance of the template |
| Admin center page | Entra ID > App registrations | Entra ID > Enterprise applications |
| Typical owner | Developer | Tenant administrator |
| Holds | Redirect URIs, secrets and certificates, API permissions requested, app roles, scopes | User and group assignment, consent, sign-in on/off, SSO configuration, visibility |
Microsoft compares the relationship to a class and an instance in object-oriented programming: the application object has static properties applied to every service principal created from it.
How the two objects relate
When you register an application, you get a globally unique instance of the app, the application object, in your home tenant. You also get a globally unique ID for it, the application (client) ID. The documentation says the application object describes three things: how the service can issue tokens to access the application, the resources the application might need to access, and the actions the application can take.
To access resources secured by a tenant, the app must be represented by a security principal in that tenant. For apps that is a service principal. It defines what the app can actually do in that tenant, who can access it, and what resources it can reach.
The relationship is:
- An application object has a one-to-one relationship with the software application.
- An application object has a one-to-many relationship with its service principals, one per tenant where the app is used.
Single-tenant apps
A single-tenant app has one service principal, in its home tenant, created and consented for use during registration. In this case both blades show the same app and it is easy to treat them as one thing.
Multitenant apps
A multitenant app also gets a service principal in every tenant where a user from that tenant has consented to its use. Microsoft's example is a multitenant "HR app" built in one tenant and used by two others. The developer's tenant holds the application object and its own service principal. When an administrator in each customer tenant completes consent, a service principal is created in that tenant and assigned the permissions the administrator granted. Each tenant's service principal represents that tenant's use of the app and is governed by the permissions consented there.
For more on designing multitenant apps, see Multi-tenant SaaS app design with Entra ID.
What to configure where
In App registrations (the application object)
Use the app registration for settings that describe the app itself:
- Application (client) ID and supported account types (single tenant or multitenant).
- Redirect URIs and authentication settings.
- Client secrets, certificates and federated credentials.
- The API permissions the app requests, and the scopes and app roles it exposes.
- Branding and the homepage URL. The enterprise application properties page says the homepage URL cannot be edited within enterprise applications and must be edited on the application object.
For secret and certificate hygiene, see Entra app secrets and certificates expiry report.
In Enterprise applications (the service principal)
Use the enterprise application for how the app behaves in your tenant:
- Users and groups: who is assigned to the app.
- Single sign-on: SAML or OpenID Connect configuration for the app.
- Provisioning: automatic creation of user identities in the app.
- Permissions: review and grant admin consent, and see user-consented permissions and who consented.
- Conditional Access and sign-in logs for the app.
- Properties: the settings described next.
Enterprise application properties that matter
The documented properties page lists these:
| Property | What it does |
|---|---|
| Enabled for users to sign in? | If No, no users can sign in even if assigned, tokens are not issued, and service principals cannot access the app with application permissions. Maps to the service principal's accountEnabled. |
| Assignment required? | If Yes, only assigned users and apps can obtain a token. If No, all users can sign in, including external users who could be invited. |
| Visible to users? | Controls whether the app shows in My Apps and the Microsoft 365 launcher for assigned users. A homepage URL is needed or the app cannot be launched from My Apps. |
| Application ID | The identifier of the app, shared with the app registration. |
| Object ID | The ID of the service principal. It differs from the application object's ID and is the one used to assign users and groups or configure SSO through APIs. |
| Notes | Free text up to 1,024 characters. |
By default, all users can access enterprise applications without being assigned. A Global Administrator can sign in to applications regardless of the assignment required setting. When an application receives tenant-wide admin consent, all users can sign in unless you configure it to require user assignment.
How each object gets created
This is the source of most confusion, so it is worth being precise.
- Register an app in the portal: an application object and a service principal are both created automatically in your home tenant.
- Register an app with Microsoft Graph: creating the service principal is a separate step.
- Consent to a multitenant app: a service principal is created in the consenting tenant.
- Add a gallery app: an enterprise application is added to your tenant from the Microsoft Entra gallery of preintegrated applications. The application object normally belongs to the app's publisher, not to you.
- Select Create your own application in Enterprise applications: the documentation says this is another way to register your own app, besides App registrations.
- Enable a managed identity: a service principal of type managed identity is created, and it has no associated application object.
The three service principal types
| Type | Has an app object? | Notes |
|---|---|---|
| Application | Yes (global app object, maybe in another tenant) | The usual enterprise application |
| Managed identity | No | Represents an Azure managed identity; can be granted access but cannot be updated or modified directly |
| Legacy | No app registration | Created before app registrations existed or through legacy experiences; only usable in the tenant where it was created |
For managed identities in practice, see Azure OpenAI keyless access with managed identity.
Step-by-step: find the matching object
From the app registration to its enterprise application
- Sign in to the Microsoft Entra admin center at entra.microsoft.com.
- Go to App registrations and open the app.
- On the Overview page, select Managed application in local directory.
With PowerShell
Microsoft Graph PowerShell finds the service principal for an application ID:
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -Filter "appId eq '00000000-0000-0000-0000-000000000000'"Replace the zero GUID with your application (client) ID.
With Azure CLI
az ad sp list --filter "appId eq '00000000-0000-0000-0000-000000000000'"Creating a missing service principal
If an app was registered through Graph or the service principal was deleted, you can create it from the application ID. With Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppId '00000000-0000-0000-0000-000000000000'The documentation states that service principals can be created with Azure PowerShell, Azure CLI, Microsoft Graph and other tools. Check the cmdlet help in your installed Graph module version before relying on parameter names.
Deleting and deactivating
Changes to the application object are reflected in its service principal in the home tenant only. Deleting an application object deletes its home-tenant service principal too, but restoring the app registration from the app registrations page does not restore the service principal. If you need a temporary suspension rather than permanent deletion, you can deactivate the application. Deactivation stops new tokens being issued while preserving both objects for investigation or later reactivation.
The enterprise application's Activation status shows Deactivated if any of these apply: sign-in is disabled on the service principal (accountEnabled=false), the app registration is deactivated, or Microsoft has disabled the application. The label alone does not say which condition applies. Check Enabled for users to sign in? on the Properties page, the app registration state in its home tenant, and the service principal's disabledByMicrosoftStatus property in Graph.
Which one do I use? Common tasks
| Task | Where |
|---|---|
| Add a redirect URI or change supported account types | App registration |
| Create or rotate a client secret or certificate | App registration |
| Add or change requested API permissions | App registration |
| Grant admin consent for those permissions | Enterprise application > Permissions |
| Assign users or groups | Enterprise application > Users and groups |
| Require assignment before sign-in | Enterprise application > Properties |
| Configure SAML SSO for a gallery or custom app | Enterprise application > Single sign-on |
| Block an app from signing anyone in | Enterprise application > Properties: Enabled for users to sign in = No |
| Review who consented to an app | Enterprise application > Permissions |
| Hide an app from My Apps | Enterprise application > Properties: Visible to users = No |
For consent-related risk, see Illicit consent grants and user consent settings.
Troubleshooting
I registered an app but cannot find it under Enterprise applications
The enterprise applications list may be filtered. Remove the default filter, search by name or application ID, and check the application type filter. If you created the app through Graph APIs, the service principal may never have been created; create it with New-MgServicePrincipal -AppId as shown above.
I deleted and restored an app registration and users cannot sign in
Restoring the application object does not restore its service principal. Recreate the service principal and reassign users, groups and consent.
The IDs do not match
The Application (client) ID is the same on both objects. The Object ID differs: the app registration has the application object's ID and the enterprise application has the service principal's ID. Use the one that the API or cmdlet expects. For assigning users and groups or configuring SSO against the service principal, use the enterprise application's Object ID.
Users sign in even though I did not assign them
Assignment required is probably set to No, which is the default. Set Assignment required to Yes under the enterprise application's Properties and assign the intended users or groups. Global Administrators can still sign in regardless.
An app shows as Deactivated
Work through the three conditions listed above. Re-enabling tenant sign-in does not override app registration deactivation or Microsoft disablement, and reactivating the registration does not turn on a service principal whose accountEnabled is still false.
An unfamiliar enterprise application appeared in my tenant
Someone consented to it, or a gallery or managed identity was added. Open its Permissions page to see who consented and what was granted, and check sign-in logs. Review tenant consent settings so that users cannot approve risky apps.
Checklist
- Use App registrations for the identity and configuration of an app you build.
- Use Enterprise applications for access control, SSO, consent and sign-in in your tenant.
- Remember one application object can have many service principals across tenants.
- Copy the correct ID: Application ID is shared, Object ID differs.
- Set Assignment required to Yes for apps that should be limited to specific users.
- Give every enterprise application at least two owners.
- After restoring a deleted app registration, recreate the service principal.
References
- Apps and service principals in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals
- What is application management: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-application-management
- Properties of an enterprise application: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/application-properties
Comments
Questions and tips are welcome. Comments are checked by the EpiFive team before they appear; please do not share passwords, phone numbers or other private details.