Entra ID Applications and Consent Guide: Enterprise Apps

In Microsoft Entra ID, one click on a consent prompt can give an application standing access to a user's mailbox and files, and one admin consent can extend that access to every user in the tenant. Those grants survive password resets and MFA changes, they are held by a service principal that most identity teams never review, and attackers have learned to request them through consent phishing. This guide covers Entra ID applications and enterprise application security in depth: delegated and application permissions, Microsoft Graph permissions, user consent settings, app consent policies, the admin consent workflow, publisher verification, detection and how to revoke app consent after an illicit consent grant. It is for Entra ID administrators, Microsoft 365 security teams and SOC analysts. For the cross-platform view of SaaS integrations see the SaaS and OAuth App Governance Guide.

Key takeaways

• Every consent creates a non-human identity. A multitenant app gets a service principal in your tenant the moment someone consents, with the permissions that were granted.
• Application permissions are the dangerous ones. Microsoft calls them "highly privileged because they allow applications to access and modify resources without requiring a signed-in user."
• Default user consent is too open. By default "all users are allowed to consent to applications for permissions that don't require administrator consent." Restrict it to verified publishers and low-impact permissions, or turn it off.
• Give users a route to yes. The admin consent workflow sends requests to named reviewers, so restricting consent does not push people to workarounds.
• Password resets do not evict an app. Microsoft notes that resetting passwords or requiring MFA is not effective against an illicit consent grant; you must remove the grant and the service principal.

Entra ID applications, service principals and enterprise apps

Entra ID applications have two halves. The application object lives only in the app's home tenant and acts as "a template or blueprint." A service principal is "created in every tenant where the application is used," and it is the service principal that holds permissions, consent grants, credentials and sign-in history. The Enterprise applications page in the Entra admin center lists the service principals in your tenant; App registrations lists the application objects your tenant owns.

• Third party and outbound app consent: when users consent to a multitenant application homed in another organisation's tenant, data flows outbound to a publisher you do not control. These are the grants that need the most scrutiny, and the ones attackers create.
• Microsoft first party apps: Microsoft's own services also appear as enterprise applications. Microsoft's illicit consent guidance and app governance in Defender for Cloud Apps both focus review on non-Microsoft apps; filter first party apps out of consent reviews but not out of sign-in and credential monitoring.
• Who can register apps: CISA's SCuBA baseline MS.AAD.5.1v1 says "Only administrators SHALL be allowed to register applications." User-registered apps become unowned service principals with their own secrets.

Delegated permissions, application permissions and Microsoft Graph

• Delegated permissions (scopes): the app acts on behalf of a signed-in user and "isn't able to access anything the signed in user couldn't access." The effective access is the intersection of the permission and the user's own rights.
• Application permissions (app roles): the app acts as itself with no user present and "is able to access any data that the permission is associated with." Mail.Read as an application permission means every mailbox in the tenant.
• Consent rules: "Application permissions and many high-privilege delegated permissions can only be consented to by an administrator." Microsoft Graph documentation adds that only Privileged Role Administrator and Global Administrator can consent to Graph application permissions.

Microsoft Graph permissions follow the pattern resource.operation.constraint. With no constraint the permission covers the signed-in user's own data; .All means every instance in the tenant, while .OwnedBy, .Shared and .Selected narrow it. Some Graph API permissions deserve a standing alert whenever they are granted:

Where an app genuinely needs mailbox access, scope it. Exchange Online RBAC for Applications grants application permissions against a management scope or administrative unit, but Microsoft warns that combined with an unscoped Entra grant the result is "no effective resource scoping", so remove the tenant-wide Entra permission when you scope it in Exchange. For Teams and chats, resource-specific consent grants access to one team or chat instead of all of them.

User consent settings and app consent policies

User consent settings decide which consent prompts an ordinary user can approve. They are implemented as app consent policies (permission grant policies) assigned to the default user role. Changes only affect future consent: "Existing consent grants remain unchanged," so tightening the setting must be followed by a review of what was already granted.

• Permission classifications: the low option only works once you classify permissions as low impact. Start with sign-in and basic profile scopes such as openid, profile, email, offline_access and User.Read, and decide deliberately whether offline_access belongs there.
• Condition sets: a consent request passes a policy if it matches at least one include set and no exclude set. Conditions include permission type, permission classification, resource application and ClientApplicationsFromVerifiedPublisherOnly.
• Assignment-required apps: when an enterprise app requires user assignment, its permissions must be consented by an administrator even if user consent policy would allow it.
• Do not rely on policy lists alone: Microsoft warns not to treat principals with consent policies "as an exhaustive list of what can grant consent"; administrative roles can also grant.

SCuBA MS.AAD.5.2v1 requires that "User consent to applications SHALL be restricted." Small organisations can usually choose the verified publisher, low impact option and be done. Large tenants often disable user consent entirely, route everything through the workflow and use custom policies for a small set of pre-approved publishers.

Admin consent and the admin consent workflow

Admin consent grants permissions for the whole organisation, recorded as a delegated grant with consent type AllPrincipals or as app role assignments. Treat every admin consent request as an access request for a privileged non-human identity.

The admin consent workflow lets a user who cannot consent send an admin consent request to designated reviewers by email. Configure it under Enterprise apps, Consent and permissions, Admin consent settings by setting "Users can request admin consent to apps they are unable to consent to" to Yes, then choose reviewers, notifications, reminders and an expiry in days. Two details matter:

• Reviewers are not approvers by default: designating a reviewer "doesn't elevate their privileges"; they can only approve permissions they could grant anyway.
• Graph application permissions need Global Administrator: "only Global Administrators can approve admin consent requests for apps requesting for Microsoft Graph app roles (application permissions)."

For each request, reviewers should check: the publisher and whether it is verified, the exact delegated and application permissions, whether offline access is requested, the reply URLs, the business owner and purpose, and whether a narrower permission or scoped Exchange RBAC would work. SCuBA MS.AAD.5.3v1 requires that "An admin consent workflow SHALL be configured for applications."

Publisher verification and unverified apps

Publisher verification means the publisher has linked a verified Microsoft AI Cloud Partner Program account to the app, and a blue verified badge appears on the consent prompt. Microsoft is explicit about its limits: the badge "doesn't imply or indicate quality criteria," and verified status "is only one of the several criteria to consider." With risk-based step-up consent, users cannot consent to most multitenant apps registered after 8 November 2020 from unverified publishers that request more than basic sign-in. Unverified apps are not automatically malicious, but they should require admin review.

Verification can also be abused. In the Microsoft Verified Publisher OAuth phishing campaign, fraudulent partner accounts gave malicious apps a verified badge and then mailbox access. Restricting consent to verified publishers raises the bar; it does not replace review of high-risk permissions.

Consent phishing, illicit consent grants and enterprise application backdooring

Microsoft defines an illicit consent grant as an attacker registering an application that "requests access to data such as contact information, email, or documents" and tricking a user into consenting, after which the app has access "without the need for an organizational account." ATT&CK records the lure under T1566.002 Spearphishing Link ("a malicious OAuth 2.0 request URL") and the outcome under T1528 Steal Application Access Token. OAuth app consent phishing needs no password theft, so phishing-resistant MFA does not stop it; consent policy does.

• User-targeted: a convincing app name and logo, delegated Mail, Files and offline access scopes, sent to many users at once.
• Admin-targeted: a request for application permissions or tenant-wide consent sent to an administrator, often framed as a vendor integration.
• Enterprise application backdooring: instead of a new app, an attacker with Application Administrator rights or Application.ReadWrite.All adds a new secret or certificate to an existing, already-trusted service principal and inherits its permissions. ATT&CK tracks this as T1098.001 Additional Cloud Credentials. The Malwarebytes breach showed an attacker abusing an existing Azure AD application identity to read internal email.
• Dormant privileged apps: the Microsoft Midnight Blizzard breach began with a legacy test OAuth application that still held elevated access, which the attacker used to grant further apps access to corporate mailboxes.

Implementing consent governance

1. Inventory first. Export all service principals with their delegated grants (oauth2PermissionGrants), application permissions (appRoleAssignments), owners, credentials, publisher and last sign-in. Flag every non-Microsoft app with application permissions or AllPrincipals grants.
2. Enable the admin consent workflow with reviewers and a service level, before restricting anything. It can take up to an hour to become active.
3. Classify permissions and switch user consent to verified publishers and low impact permissions, or to no user consent. Pilot by announcing the change and watching admin consent requests for two weeks.
4. Restrict app registration to administrators and assign owners to every app registration.
5. Remediate the backlog. For each high-risk grant, confirm the owner and need, narrow the permission or scope it, and remove dormant or unowned apps. Disable before deleting so you can roll back quickly.
6. Harden credentials. Block new client secrets where possible (SCuBA MS.AAD.5.5v1), limit secret lifetime to 180 days and certificate lifetime to 365 days, and prefer managed identities.
7. Roll back a too-strict consent setting by re-assigning the previous policy; existing grants were never touched, so the impact is limited to new consents.

Detection, app governance and metrics

Defender app governance in Defender for Cloud Apps covers OAuth-enabled apps registered in Entra ID, Google and Salesforce, shows "which user-installed OAuth applications have access to data" and what permissions they hold, and raises alerts with detection source App Governance. Without it, scheduled exports of grants plus SIEM rules on the audit events above give similar coverage. Microsoft suggests reviewing consent grants weekly in large organisations; audit events can take 30 minutes to 24 hours to appear.

• Exposure: non-Microsoft apps holding high-risk application permissions; trend down.
• Ownership: percentage of service principals with a named owner; target 100.
• Dormancy: apps with permissions and no sign-in in 90 days; remove them.
• Workflow health: median days to decide an admin consent request; keep it short so users do not seek workarounds.
• Unverified access: grants to unverified multitenant apps; target zero outside approved exceptions.

Consent phishing response: revoke app consent

1. Contain the app. Disable sign-in for the service principal (set "Enabled for users to sign-in?" to No) so its tokens cannot be renewed, before you delete anything.
2. Revoke grants. Revoke admin-consented permissions from the Permissions page; user consent grants can only be removed through Graph or PowerShell (Remove-MgOauth2PermissionGrant, Remove-MgServicePrincipalAppRoleAssignment).
3. Revoke user sessions for consenting users so existing refresh tokens are invalidated, and check their mailboxes for new inbox rules or forwarding.
4. Scope the impact from audit logs: which users consented, the period of access, and data the app read. Mailbox auditing must have been on beforehand.
5. Prevent re-consent. Microsoft notes that revoking a grant "doesn't stop users from re-consenting"; tighten user consent settings or delete the service principal and block the app.
6. Hunt for siblings. Search for other apps from the same publisher, reply URL or creation window, and for credentials added to existing apps.

For the wider playbook see the Phishing Incident Response Playbook.

Common failure patterns

• Default consent never changed: users approved hundreds of apps over years, and tightening the setting later left every old grant in place.
• Admin consent as a rubber stamp: administrators approve tenant-wide consent to make a prompt go away, without reading the permissions.
• Verified badge treated as safe: verification proves who the publisher is, not that its app or infrastructure is secure.
• Only new apps monitored: alerts fire on new consents but not on credentials added to old, trusted service principals.
• Password reset as remediation: responders reset the user's password and close the case while the malicious app keeps reading mail.
• Unscoped mailbox permissions: integrations hold Mail.Read as an application permission for every mailbox when they need a dozen.

Framework mapping

Practitioner checklist

• Restrict user consent to verified publishers and low impact permissions, or disable it.
• Enable the admin consent workflow with named reviewers and a response target.
• Allow only administrators to register applications and assign an owner to every app.
• Inventory all enterprise apps and review high-risk Graph application permissions and AllPrincipals grants.
• Scope mailbox access with Exchange RBAC for Applications and remove unscoped Entra grants.
• Alert on consent events, new app role assignments and credentials added to existing service principals.
• Remove dormant and unowned apps after a disable period.
• Keep a consent phishing runbook that revokes grants, sessions and blocks re-consent.

Standards and references

• Microsoft Learn: Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Detect and remediate illicit consent grants
• Microsoft Learn: Overview of Microsoft Graph permissions
• MITRE ATT&CK: T1528 Steal Application Access Token
• CISA: SCuBA Microsoft Entra ID Secure Configuration Baseline

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · OAuth 2.0 and OpenID Connect Guide · Microsoft 365 Security Guide · Active Directory and Entra ID Hardening Guide