Application Identity: Enterprise Apps, App Registrations…

Why application identity is its own topic

Simple explanation

Apps need identities too. When a user signs in, the directory knows who they are. But when an application — a SaaS tool, a custom web app, an AI agent — needs to read calendar data, send email, or query SharePoint, the app also has to identify itself and prove it’s allowed.

Microsoft Entra has two related but separate objects for this, and the exam keeps tripping people up:

App registration — the global “definition” of an app: client ID, secrets/certificates, redirect URIs, the permissions it requests. Lives in the home tenant of the developer.
Enterprise application (service principal) — the local “instance” of an app in your tenant. When a SaaS app is installed (or a user consents to it), a service principal is created in your tenant. It’s the object your tenant grants permissions to and your tenant manages.

On top of that, OAuth permissions come in two flavours: delegated (the app acts as the signed-in user, limited to what that user can do) and application (the app acts as itself with broad rights, no user required). Application permissions are powerful and dangerous if granted to the wrong app.

Consent is the act of granting an app the permissions it asks for. By default, users can consent to low-risk delegated permissions on their own. High-risk and application permissions require an admin to consent. Configuring this consent surface is much of what Domain 1 tests on app identity.

App registration vs enterprise application

This is the single most-confused pair on SC-500 Domain 1. Internalise it once and the rest is easy.

App registration vs enterprise application — when to use which surface
Feature	App registration (Application object)	Enterprise application (Service principal)
What it is	The global definition of the app — its manifest, identifier, permissions it requests	The local instance of the app in YOUR tenant
Where it lives	Entra > App registrations (in the home tenant of the developer)	Entra > Enterprise applications (in YOUR tenant)
Who creates it	The developer / publisher of the app	Auto-created when the app is consented to or added from the gallery
What it holds	Client secrets, certificates, redirect URIs, required permissions, app roles, federated credentials	Consented permissions, sign-in logs, sign-in policies, CA scope, custom claims, group/user assignments
How many per app	One — globally	One per tenant where the app is consented to
Security controls	Manage secrets/certs, redirect URIs, requested permission list	Restrict sign-in via 'User assignment required', revoke consented permissions, expire sessions, apply CA
Who manages day-to-day	The application developer / owner	Tenant admins (security + identity admins)

A worked example: 'Foundry Insights' SaaS app

Maple Genomics buys Foundry Insights, a SaaS dashboard that reads Foundry usage telemetry from multiple subscriptions.

The publisher (Foundry Insights Pty Ltd) has an app registration in their own Entra tenant. It declares “I need Application.Read.All and AuditLog.Read.All Microsoft Graph permissions, plus reader access on Azure subscriptions.”
When Ravi installs Foundry Insights into Maple Genomics’ tenant, an enterprise application (service principal) for Foundry Insights is created in Maple Genomics’ tenant.
Ravi sees Foundry Insights under Entra > Enterprise applications. He can scope which permissions are consented, set “User assignment required” so only the analytics team can sign in, attach CA policies, audit sign-in logs, and revoke the entire app’s access with one switch.
The publisher’s app registration is unchanged by what Ravi does. Each customer tenant has its own enterprise application instance.

OAuth permissions: delegated vs application

When an app asks for permission to access an API, the permission falls into one of two categories:

Delegated vs application permissions — the most-tested distinction on app identity
Feature	Delegated permission	Application permission
Who 'acts'	The signed-in user, via the app — app is restricted to what the user can do	The app itself — no user context required
Effective access	Intersection of user's permissions AND consented scope	The full consented scope, unrestricted by any user
Token flow	Authorization Code flow (with PKCE) or similar with a user sign-in	Client Credentials flow — app authenticates with a secret/cert
When to use	Apps that always run with a signed-in user (web apps, SPAs, mobile apps)	Background services, daemons, automation, agents, AI workloads
Consent risk	Lower — bounded by the user's own access	Higher — typically tenant-wide read or write, must be admin-consented
Typical scope name	Microsoft Graph: `User.Read`, `Mail.Send`, `Calendars.ReadWrite`	Microsoft Graph: `Application.Read.All`, `Mail.Send`, `Directory.ReadWrite.All` (note: same scope name often exists in both flavours — read carefully)

A common exam trap: a permission like Mail.Send exists in both delegated and application flavours. The delegated version lets a signed-in user send mail through the app, as themselves. The application version lets the app send mail as any user in the tenant, with no user context. The names are identical; the consequences are not.

Microsoft Entra has a tenant-wide user consent setting that controls what users can self-consent to. The four options:

Do not allow user consent — only admins can consent to anything.
Allow user consent for apps from verified publishers, for selected permissions — recommended default for many orgs.
Allow user consent for apps — users can self-consent to any low-risk delegated permission.
Allow user consent for all permissions — broad self-consent (not recommended).

The classification of “low-risk delegated permission” is controlled by permission classifications that admins set per tenant. Common low-risk: User.Read, email, openid, profile. Anything not classified is treated as requiring admin consent.

When a user encounters an app whose requested permissions exceed self-consent, the user can submit an admin consent request. Designated reviewers (configured under Entra > Enterprise applications > User settings > Admin consent requests) receive an email, review the request in the portal, and approve/deny. Approved consent grants the permissions tenant-wide for that app.

Why illicit consent grant attacks matter on SC-500

An attacker can build a malicious app, host it anywhere, and phish your users into clicking a link that takes them to the standard Microsoft Entra consent dialog. If user consent is too permissive — or if an admin is phished into approving — the attacker’s app gains long-lived OAuth tokens. No password, no MFA prompt, no obvious sign-in event for the user.

The SC-500 mitigations are:

Restrict user consent to verified publishers and a small list of classified permissions only.
Enable the admin consent workflow so users have a sanctioned path that goes through review.
Audit consented permissions regularly — Entra surfaces consented permissions per enterprise app, and Defender XDR detects unusual consent grants.
Revoke service principal sign-ins / delete the enterprise app to immediately cut off a malicious app. The app registration in the attacker’s tenant is unaffected by revocation in yours.

This is one of the most common modern attack patterns against M365 tenants — and one of the most tested control surfaces on the exam.

For enterprise apps, two switches control who can use the app at all:

User assignment required — when set, only users (or groups) explicitly assigned to the enterprise app can sign in. Combined with PIM-eligible group membership, this becomes a powerful per-app access control.
Visible to users — controls whether the app appears in the My Apps portal. Hidden apps still work; they just don’t get a tile.

Conditional Access then layers on top: CA policies can target specific enterprise apps, requiring MFA, device compliance, or session controls per app.

Scenario: Esme audits sprawl at Northwind Bank

Esme runs an audit of enterprise applications in Northwind Bank’s tenant and finds 247 consented apps — many of them dormant SaaS tools from years past. Her remediation plan:

Tighten user consent. Switch the user consent setting to Allow user consent for apps from verified publishers, for selected permissions — and narrow the classified permissions list to only User.Read, email, openid, profile.
Stand up admin consent workflow. Add herself and two delegated reviewers as admin consent request reviewers. Now any new request that exceeds the user-consent floor enters a reviewable queue.
Audit application permissions. Filter enterprise apps to those with consented application permissions (the high-risk class). For each, validate the app is still in use; revoke or delete inactive apps.
Force user assignment on sensitive apps. For the in-house “Payments Console” SaaS, set User assignment required and assign only members of a PIM-eligible group, so the user must be PIM-active to access the app.
Schedule access reviews. Configure quarterly access reviews on the consented app permissions for high-risk apps; reviewers are app owners or security.

The 247 enterprise apps become 89 after the audit. Future sprawl is choked at the consent dialog.