What Is an Enterprise Application in Entra ID?
An enterprise application in Microsoft Entra ID (formerly Azure Active Directory) is the tenant-specific representation of an application that allows administrators to manage user access, single sign-on (SSO), and security policies for that app within their organization. This concept is central to cloud identity and access management (IAM) as it enables precise control and governance over who can access applications—whether these are third-party SaaS offerings (like Salesforce), custom-developed line-of-business (LOB) apps, or on-premises applications integrated with the cloud directory.
When you add an application to your Entra tenant—by selecting a pre-integrated SaaS app from the Entra application gallery or by integrating your own custom app—an enterprise application object is created in your directory. This object forms the basis for access assignment, SSO configuration, Conditional Access, and ongoing governance across your user base.
Suppose your organization needs to enable SSO for Salesforce. You add Salesforce from the application gallery in the Entra admin center. Entra ID creates an enterprise application object that lets administrators assign users, set up SSO, and enforce security controls—all without requiring you to register a new application from scratch.
Enterprise Applications, App Registrations, and Service Principals: The Architecture Decoded
A common source of confusion is the relationship and distinction between app registrations, enterprise applications, and service principals within Entra ID. The following model clarifies these roles:
App Registration: This is the application's master definition—its global identity. It describes how the app can authenticate with Entra ID, what permissions it requires, and which APIs it can access. App registrations are typically created only once, in the application's "home" (owning) tenant.
Enterprise Application (Service Principal): When you add an application to your tenant—whether from the gallery or by registering a custom app—Entra ID creates a service principal. In the context of application management, the terms "enterprise application" and "service principal" are synonymous: both refer to the tenant-local instantiation of the application's identity.
Multi-Tenant and SaaS Patterns: For custom or multi-tenant applications:
- The app registration lives in one tenant ("publisher" or "home").
- Each consuming tenant, when integrating the app, gets its own enterprise application (service principal) object, allowing each tenant to manage access and policy independently.
Mental Model:
Think of the app registration as the global application blueprint. The enterprise application (service principal) is a tenant-local, concrete deployment of that blueprint, through which all user assignments, policy, and management occur.
Example:
If you build and register a line-of-business web app in your organization's tenant, Entra ID creates:
- An app registration (global definition, API scopes, authentication details).
- A service principal (enterprise application) in your tenant, which is the managed identity your admin teams interact with for assigning users and policies.
How Enterprise Applications Are Onboarded and Managed
Onboarding Applications
There are two primary ways to onboard enterprise applications in Entra ID:
SaaS/Gallery Applications:
Select from thousands of preintegrated applications in the Entra application gallery (such as Salesforce, ServiceNow, or Workday). Adding one creates an enterprise application (service principal) in your tenant, ready for configuration.Custom/Internal Applications:
When you register and publish your own app via app registrations, Entra ID creates both the application definition and a service principal (enterprise application) in your tenant. This enables you to manage your own applications with the same controls as external SaaS apps.
Access Assignment and SSO Provisioning
Once an enterprise application is present in your tenant, you can:
- Assign access to users, groups, or roles—ensuring only authorized identities can authenticate to the application.
- Configure single sign-on using standards such as SAML, OpenID Connect, OAuth 2.0, or password-based SSO (for compatible applications).
- Define role-based access so fine-grained permissions within the target application can be aligned with Entra groups/roles.
Example:
After adding Salesforce from the gallery, assign the "Sales Users" group access to the enterprise application and configure SAML SSO. Only members of this group can access Salesforce with their organizational credentials.
Ongoing Management
Entra ID provides lifecycle features for ongoing governance, including:
- Periodic access reviews to ensure entitlements remain current.
- Automated provisioning (where supported) to sync user accounts into the SaaS application.
- Visibility into usage and re-certification requirements.
Security and Governance for Enterprise Applications
Enterprise applications are the primary surface for enforcing identity security policies in Entra ID. Key security controls include:
- Conditional Access: Apply rules to restrict access to enterprise applications based on user, group, device compliance, network location, or sign-in risk. For example, require multi-factor authentication (MFA) or allow access only from managed devices.
- Multi-Factor Authentication (MFA): Per-application enforcement ensures high-assurance authentication where risk or sensitivity justifies it.
- Access Reviews: Regularly validate that only legitimate users retain access to critical applications.
- Policy-Driven Governance: Use entitlement management to automate and standardize access assignments, requiring approval workflows and periodic reviews.
Example:
For your financial reporting app, you can apply a Conditional Access policy requiring all users to complete MFA and block access from outside the corporate network.
These controls are enforced at the enterprise application (service principal) object, making it the focal point for Zero Trust implementations and ongoing compliance needs.
Critical Misconceptions (and the Real Story)
Misconception 1: App registrations and enterprise applications are standalone—you only need one or the other.
Reality:
They serve distinct but related roles. Most applications need both: the app registration defines the global app, while the enterprise application (service principal) is where you manage who can use it and which policies apply in your tenant.
Misconception 2: You must register every SaaS app your organization uses as an app registration.
Reality:
Gallery applications—preintegrated SaaS offerings—are added directly as enterprise applications. No custom app registration is needed; you use the existing global registration provided by the app vendor, and your enterprise application (service principal) is created automatically in your tenant.
Misconception 3: Service principal and enterprise application are different objects in practice.
Reality:
In Entra ID, the terms are interchangeable for the purposes of tenant-local app management. The enterprise application is the service principal object in your directory.
Summary Table: Distinguishing Objects
| Object Type | Definition | Example Use |
|---|---|---|
| App Registration | Global blueprint/definition of app | Defines appID, permissions |
| Enterprise App SPN | Tenant-local app instance (service principal) | Access assignments, policies |
Practical Scenario Walkthroughs
SaaS (Gallery) Application Onboarding
- Admin selects ServiceNow from the gallery in the Entra admin center.
- Entra ID creates an enterprise application (service principal) in the tenant.
- Admin configures SAML SSO and assigns the "IT Support" user group.
- Conditional Access enforces device compliance for this app.
- Access reviews are scheduled quarterly to ensure valid assignments.
Custom Application Registration
- Developer registers "Intranet Portal" in 'App registrations'.
- Entra ID creates the application (definition) and local service principal (enterprise application).
- Admin assigns user groups, enabling SSO.
- Conditional Access policy requires MFA for all "Intranet Portal" users.
Best Practices, and Reference Links
Best Practices:
- Use the enterprise application (service principal) as the control plane for all access and policy assignments.
- Apply Conditional Access and MFA to high-risk or sensitive applications.
- Use groups and roles for scalable access assignment.
- Schedule regular access reviews and entitlement recertification.
- For SaaS/gallery apps, onboard via the gallery whenever possible for support and compatibility.
- Maintain clarity between app registration (blueprint) and enterprise application (tenant-local instantiation).
Enduring Principle:
Effective cloud IAM in Entra ID focuses your access, governance, and security practices around the enterprise application (service principal)—the touchpoint for managing how identities interact with cloud and on-premises apps at enterprise scale.