Enterprise Applications vs. App Registrations in Microsoft Entra ID

What is the difference between App Registrations and Enterprise Applications in Microsoft Entra ID? An App Registration manages the Application Object—that is, the definition of an application in its home tenant. Under Enterprise Applications, the Service Principal is managed, which is the local instance of that application in a specific tenant. An application can have an Application Object but can have Service Principals in multiple tenants.

This separation is critical: API permissions, Redirect URIs, or App Credentials are typically managed at the registration level; user assignments, Single Sign-on, Conditional Access, and tenant-specific usage are managed at the Service Principal level. Confusing these two objects may result in deleting the wrong instance or searching for a setting in the wrong portal area.

The four most important terms

Application object

The Application Object describes an application in its home tenant. It includes identity properties, supported account types, Redirect URIs, requested API permissions, and its own credentials.

App registration

App registrations is the management view for Application Objects. Developers or administrators register their own application there and configure its identity integration.

Service principal

The Service Principal is the local representation of an application in a tenant. It describes how the app is used in that tenant, which assignments exist, and which tenant-specific permission consents have been granted.

Enterprise application

In Microsoft Entra, Application Objects, Service Principals, and Managed Identities are now grouped under the umbrella term Workload Identities. Therefore, not every Workload Identity appears as a classic App Registration; Managed Identities are typically visible as an Azure resource and as a Service Principal.

Enterprise applications is the management view for Service Principals. It includes self-registered apps as well as SaaS applications, Microsoft applications, managed identities, and other Service Principal types.

Object relationship illustrated with an example

A software provider registers a multi-tenant application in its tenant. There, the Application Object resides. A customer grants consent and uses the application. As a result, a Service Principal is created in the customer's tenant.

• Manufacturer Tenant: Application Object and its own Service Principal
• Customer Tenant A: Service Principal
• Customer Tenant B: Service Principal

If the manufacturer changes the app definition, this can affect multiple tenants. However, user assignment, Conditional Access, or local consent are managed in the respective customer tenant.

Single-tenant and multi-tenant applications

Single tenant

Only accounts from the home tenant should be able to sign in. This is often suitable for internal business applications.

Multi tenant

Accounts from other Microsoft Entra tenants can use the application if the app and the respective resource tenant allow it. A Service Principal is created in each tenant that uses the application.

Personal Microsoft accounts

App registrations can also support personal Microsoft accounts, depending on the configuration. This selection affects endpoints, tests, and the security model.

Do not change the supported account type without review. Expanding from single to multi-tenant changes the potential user and consent surface.

Where each setting is managed

Setting: Application/Client ID

Typical management location: App Registration

Note: identifies the app definition

Setting: Redirect URI

Typical management location: App Registration

Note: must match the authentication flow

Setting: API Permissions – requested

Typical management location: App Registration

Note: actual consent is also relevant

Setting: Client Secret/Certificate

Typical management location: App Registration or specific SP case

Note: workload credential

Setting: User/Group assignment

Typical management location: Enterprise Application

Note: tenant-based access

Setting: User assignment required

Typical management location: Enterprise Application

Note: affects who can sign in

Setting: Single Sign-on

Typical management location: Enterprise Application

Note: SAML/OIDC or application-specific

Setting: Conditional Access

Typical Management Location: Service Principal as Target Resource

Note: Policy in Conditional Access

Setting: Provisioning

Typical Management Location: Enterprise Application

Note: SCIM or Gallery Integration

Setting: Admin Consent

Typical Management Location: Tenant-Specific Permission State

Note: Check in the context of App/SP

The interface may change, and some properties are linked in both views. What matters is the underlying object model.

Do not confuse object ID and application ID

The Application/Client ID identifies the application logically and is linked across tenants to the app. The Object ID identifies a specific directory object. Application Object and Service Principal have different Object IDs.

Therefore, when using Microsoft Graph or PowerShell, it must be clear which object is expected. A common error is passing the Object ID of the App Registration to an operation that expects the Service Principal.

Test

1. Open App Registration and note the Client ID.
2. Search for this Client ID under Enterprise Applications.
3. Compare the Object IDs of both objects.
4. Query application and servicePrincipal separately via Microsoft Graph.

User and group assignment

For many Enterprise Applications, the Assignment required setting can be enabled. Then, consent alone is not sufficient; users or groups also need an assignment.

Check:

• whether the application supports assignments as expected,
• whether group memberships are evaluated,
• whether nested groups exist,
• which App Roles are assigned,
• do administrators inadvertently gain access,
• how revocation is tested.

An assignment is not the same as API consent. A user can be assigned while the application lacks a required API permission—or vice versa.

App roles and scopes

A custom app can provide roles or OAuth scopes.

• App Roles are assigned to users, groups, or applications and appear as claims.
• Delegated Scopes allow an app to act on behalf of a signed-in user.
• Application Permissions allow app-only access without a user context, provided consent and authentication are in place.

The definition resides with the application object; the specific assignment or consent takes effect in the tenant.

Single sign-on and provisioning

Enterprise Applications can include SSO configuration and automatic provisioning. For SAML applications, for example, the identifier, reply URL, signature certificate, and claims are relevant. For provisioning, a SCIM endpoint, secret or token, and attribute mappings may also be added.

These technical credentials are independent of an app registration's OAuth client secrets. Expiry monitoring must therefore capture all credential types.

Owners and responsibilities

App Registrations can have owners. Additionally, every production application requires:

• a business owner,
• a technical owner,
• security and consent responsibility,
• operations and support contact,
• credential responsibility,
• documented purpose and data access,
• expiry and deletion process.

Having a single developer as owner is risky. If they leave the organization, the app may continue to run technically, but no one may or understands its configuration.

Typical failure patterns

App was registered but not found under Enterprise Applications

Check filters, tenant, and client ID. When an app registration is created in the Entra portal, a service principal is typically generated simultaneously in the home tenant. However, if the application object is created automatically, for example via Microsoft Graph, the service principal must be created or checked separately depending on its expiration. Additionally, views or filters may hide it.

App exists under Enterprise Applications but not under App Registrations

This is normal for external SaaS and multi-tenant applications. The application object resides in the manufacturer's home tenant; only the service principal exists in your own tenant.

User can sign in but receives no business access

Possible causes:

• missing user or group assignment,
• incorrect app role,
• application evaluates claims differently,
• conditional access blocks later access,
• provisioning did not create the target account,
• API consent is missing.

AADSTS700016 or app not found

Check client ID, tenant/authority, supported account type, deleted object, and used endpoint. The application may be registered in the wrong tenant or configured as single tenant.

Service principal accidentally deleted

This can interrupt assignments, consent, and SSO in the tenant. Restoring the application object does not automatically fully restore the service principal in every scenario. Before deletion, configuration and permission state must be exported.

Securely removing an application

1. Determine usage

• sign-in logs,
• service principal sign-ins,
• API usage and target system,
• group and user assignments,
• dependencies in flows, scripts, and services,
• owners and business team.

2. Block access initially

Depending on the application, sign-in or assignment can be controlled to be disabled. This creates an observation period before the object is deleted.

3. Handle credentials and consent

• prevent new tokens,
• remove secrets/certificates if safe,
• revoke consent,
• stop provisioning,
• consider sessions and existing tokens based on risk.

4. Export configuration

Document object IDs, client ID, redirect URIs, permissions, assignments, SSO, and provisioning.

5. Delete and monitor

After deletion, monitor sign-in errors, business processes, and audit logs. Restorability depends on the object and time period and should not serve as the sole rollback method.

Test catalog

1. internal user with direct assignment,
2. user via group,
3. user without assignment,
4. guest user, if supported,
5. admin consent present and revoked,
6. distinguish delegated and app-only access,
7. Conditional Access on target app,
8. expired credential,
9. disabled service principal,
10. multi-tenant sign-in from test tenant.

Operations register for applications

Recommended fields:

• Display name,
• Client ID,
• Application Object ID,
• Service Principal Object ID,
• Home tenant,
• Single-/Multi-tenant,
• Owner,
• Business purpose,
• User/group assignment,
• Permissions and consent,
• Credentials with expiration date,
• SSO/provisioning,
• Last usage,
• Review and deactivation date.

For the actual permission assessment, the article Check app permissions and admin consent applies. The ongoing operations of secrets, certificates, and federated credentials are then covered by Monitor secrets and certificates for Entra applications.

How to uniquely assign and manage applications in the Entra tenant

App Registration and Enterprise Application are two views of different objects. The Application Object defines the application; the Service Principal represents its usage in the tenant. If you document IDs, owners, consent, assignments, and credentials separately, you can analyze login errors specifically and change or remove applications in a controlled manner without confusing tenant-wide relationships.