Lesson 13 — Enterprise Applications in Microsoft Entra
Every application that relies on Microsoft Entra ID must be represented inside the tenant before users, groups or workloads can access it.
Enterprise applications provide the tenant-side view of those applications. They expose service principals, user and group assignments, permissions, single sign-on settings, provisioning, Conditional Access targeting and sign-in activity.
This lesson explains how enterprise applications work, how they differ from app registrations, and how Agent Foskett investigates an application that has been granted more access than the business intended.
What you will learn
This lesson explains how enterprise applications represent and control application access inside Microsoft Entra.
Learning objectives
After completing this lesson, you should be able to explain, configure and investigate Microsoft Entra enterprise applications.
- Describe the purpose of an enterprise application.
- Explain how service principals represent applications in a tenant.
- Differentiate enterprise applications from app registrations.
- Control access through assignments, permissions and Conditional Access.
- Investigate suspicious or excessive application access.
The problem this solves
Users and workloads need a controlled way to authenticate to applications and request access to organisational data.
Enterprise applications provide the tenant-local identity, access and policy surface required to manage that relationship.
What is an enterprise application?
An enterprise application is the Microsoft Entra tenant representation of an application or service. In technical terms, it is usually backed by a service principal object.
The service principal
A service principal is the security identity used by an application inside a specific tenant.
It allows Microsoft Entra to identify the application, evaluate permissions, apply policies and record sign-in activity.
Why tenant-specific objects matter
A multi-tenant application may exist once as an application definition but have a separate service principal in every customer tenant that uses it.
This separation lets each tenant decide who may use the application and what permissions it receives.
Enterprise applications and app registrations compared
| Object | Primary purpose | Typical administrator question |
|---|---|---|
| App registration | Defines an application, its identifiers, redirect URIs, credentials and exposed permissions. | How is this application built and configured? |
| Enterprise application | Represents the application in a tenant through a service principal. | Who can use it, what can it access and what policies apply? |
| Managed identity | Provides an automatically managed workload identity for an Azure resource. | How can this workload authenticate without storing credentials? |
Gallery applications
The Microsoft Entra application gallery contains pre-integrated software-as-a-service applications with known sign-on and provisioning patterns.
Gallery applications can simplify configuration, but they still require deliberate assignment, ownership and review.
Non-gallery applications
Administrators can add custom or internally developed applications that are not present in the gallery.
These often require more careful configuration because sign-on, claims, certificates and provisioning may be organisation-specific.
Common enterprise application types
| Type | Typical use | Security focus |
|---|---|---|
| SAML application | Federated single sign-on to business software. | Claims, signing certificates, reply URLs and assignment. |
| OpenID Connect or OAuth application | Modern web, mobile and API authentication. | Redirect URIs, consent, scopes and tokens. |
| Password-based SSO | Legacy applications without federation support. | Credential storage, browser extension use and access ownership. |
| Application proxy | Secure remote access to on-premises web applications. | Connector health, pre-authentication and Conditional Access. |
| Workload service principal | Automation, daemon applications and service-to-service access. | Application permissions, credentials and sign-in monitoring. |
User assignment required
When assignment is required, only explicitly assigned users and groups can access the application.
This can reduce unnecessary exposure, but administrators must understand how group membership and nested access patterns affect effective assignment.
Direct and group assignment
Users may be assigned directly or receive access through a group.
Group-based assignment is easier to manage at scale, provided the group has a clear owner and membership lifecycle.
The application access path
Delegated permissions
Delegated permissions allow an application to act on behalf of a signed-in user.
The application can normally perform only operations permitted by both the granted scope and the user's own access.
Application permissions
Application permissions allow a workload to act without a signed-in user.
Because these permissions can provide broad tenant-wide access, they require strong approval, credential protection and monitoring.
Consent and permission risk
| Consent type | What it means | Risk consideration |
|---|---|---|
| User consent | An individual user approves requested delegated access within tenant policy. | Users may approve applications without understanding the data impact. |
| Admin consent | An administrator approves permissions for the organisation. | A single approval may grant access across many users or resources. |
| Application permission grant | A workload receives direct access without user interaction. | Compromised credentials can enable unattended data access. |
| Publisher verification | Microsoft has verified the publisher identity. | Verification improves confidence but does not prove the application is safe or necessary. |
Application owners
Every enterprise application should have accountable technical and business owners.
Owners should understand the application's purpose, users, permissions, credentials and retirement plan.
Certificates and secrets
Service principals may authenticate using certificates, client secrets, federated credentials or managed identities.
Certificates and federated credentials are generally preferable to long-lived shared secrets, but all credentials require expiry monitoring and secure lifecycle management.
Conditional Access for enterprise applications
Enterprise applications are common targets in Conditional Access policies.
| Control | Application use | Common caution |
|---|---|---|
| Require MFA | Protect access to business applications. | Service accounts and workload identities must be handled separately. |
| Require compliant device | Restrict sensitive applications to managed endpoints. | External users and non-interactive scenarios may require different policy design. |
| Authentication strength | Require phishing-resistant methods for privileged or sensitive applications. | Confirm supported authentication methods before enforcement. |
| Session controls | Limit session duration, persistence or unmanaged-device access. | Application behaviour may vary by protocol and integration method. |
| Block access | Prevent use of deprecated or unauthorised applications. | Test exclusions and emergency access before enabling broadly. |
Single sign-on configuration
Enterprise applications can use SAML, OpenID Connect, password-based SSO, linked sign-on or integrated Windows authentication.
Administrators should document identifiers, reply URLs, claims, certificates and ownership before production deployment.
Provisioning
Automated provisioning can create, update and remove user accounts in connected applications.
Provisioning improves lifecycle consistency, but failed jobs, attribute mappings and accidental scope expansion must be monitored.
Enterprise application investigation process
Real-world scenario: the application had mail access nobody remembered approving
Investigate user sign-ins
Review application, user, IP address, device, authentication requirement, Conditional Access result and session details.
Confirm that successful sign-ins match the expected user population, geography and business process.
Investigate service-principal sign-ins
Service-principal sign-ins show non-user authentication performed by applications and automation.
Look for unfamiliar source addresses, unexpected resources, unusual frequency, failed authentication and credentials that should have expired.
Common mistakes
| Mistake | Why it creates risk | Better practice |
|---|---|---|
| No application owner | Nobody can confirm whether access is still required. | Assign technical and business owners and review them regularly. |
| User assignment is not required | Any tenant user may be able to access the application. | Require assignment where the application supports a defined user population. |
| Broad admin consent is granted without review | The application may access large amounts of organisational data. | Use a documented consent-review and approval process. |
| Long-lived client secrets | Stolen credentials may remain useful for months or years. | Prefer managed identities, federated credentials or short-lived certificates. |
| Conditional Access excludes the application | Users may bypass expected authentication or device controls. | Include the application deliberately in policy design. |
| Unused enterprise applications remain enabled | Old permissions and credentials create hidden attack paths. | Review sign-in activity and disable or delete retired applications. |
Key takeaways
- Enterprise applications are the tenant-side representation of applications and are usually backed by service principals.
- App registrations define applications, while enterprise applications control their tenant-specific access.
- User and group assignments should reflect an approved business requirement.
- Delegated permissions act with a user, while application permissions allow unattended access.
- Admin consent, credentials and service-principal sign-ins require ongoing monitoring.
- Conditional Access can protect user access to enterprise applications.
- Unused applications, stale credentials and ownerless service principals should be investigated and removed.
Related Agent Foskett resources
Continue learning
Microsoft Entra Enterprise Applications and Service Principals
Microsoft Entra enterprise applications represent applications inside a tenant through service principals and provide controls for user assignment, permissions, single sign-on, provisioning and Conditional Access.
Microsoft Entra Academy Lesson 13 — Enterprise Applications in Microsoft Entra
This Agent Foskett lesson explains enterprise applications, service principals, consent, application permissions, user assignments, sign-in logs and application-access investigations.