Zero Trust - Application Context and Consent

Licensing note

Entra ID

Most of the controls described in this post (Conditional Access, authentication context, the consent framework, application assignment, token protection) are available with Microsoft Entra ID P1. Risk-based Conditional Access require Entra ID P2.

Microsoft Defender for Cloud Apps

Conditional Access App Control with session policies requires Microsoft Defender for Cloud Apps and Microsoft Entra ID P1. Defender for Cloud Apps is included in Microsoft 365 E5 / A5 / G5 Security and is also available as a standalone product.

Understanding the Application Access Model

In Microsoft Entra ID, applications are represented through app registrations and enterprise applications.

An app registration defines the application globally. It contains configuration such as redirect URIs, supported account types, certificates, secrets, and requested API permissions.

An enterprise application represents the application inside your tenant. It is the local service principal object used to control access, assignments, permissions, consent, sign-in activity, and Conditional Access targeting.

In practice, when an application is used in your tenant, you should review:

• Who can access the application
• Which permissions are granted
• Whether admin consent was granted
• Whether the application is still used
• Whether the publisher is verified
• Whether the application uses secrets, certificates, or managed identities

This is important because application access is not always interactive. Some applications act on behalf of users, while others act independently without a user present.

Delegated vs Application Permissions

Before discussing consent, it is important to understand the difference between delegated permissions and application permissions.

Delegated permissions are used when an application acts on behalf of a signed-in user. For example, if a user signs in to an application that has the delegated permission Mail.Read, the application can read mail as that user, limited by what the user can access. This model is common for user-facing applications.

Application permissions are used when an application acts as itself, without a signed-in user. For example, an application with the application permission Mail.Read can potentially read mailboxes across the tenant. This model is common for automation, integrations, daemons, and backend services.

Application permissions are usually more sensitive because they are not constrained by an interactive user session. Microsoft's guidance also highlights that tenant-wide admin consent is a sensitive operation, because permissions may allow highly privileged actions, including broad mailbox, site, role, or impersonation access.

In a Zero Trust model, applications must therefore be treated as identities with their own risk, permissions, and lifecycle. A compromised or over-permissioned application can access Microsoft Graph, read mailbox data, read or modify files, persist access through delegated refresh tokens or long-lived application credentials, operate without user interaction, abuse previously granted consent, and bypass user-focused controls such as MFA. In incident response, OAuth abuse is often difficult to detect because attackers do not necessarily need to steal passwords or session tokens; they can abuse legitimate authorization flows and valid tokens.

Consent and Consent Phishing

Microsoft Entra ID uses OAuth 2.0 and OpenID Connect to allow applications to request access to resources. When an application requests permissions, a user or administrator may be prompted to grant consent. If that consent is granted, the application can receive tokens for the requested permissions.

A typical OAuth consent phishing scenario looks like this:

1. An attacker registers a malicious application.
2. The application requests permissions such as reading user profile, mailbox, or files.
3. The attacker sends a phishing link to the victim.
4. The victim signs in on the legitimate Microsoft login page.
5. The victim grants consent to the application.
6. The attacker receives tokens and can access data through Microsoft Graph.

This attack is powerful because:

• The user authenticates on a legitimate Microsoft page.
• MFA may be completed successfully.
• No credentials need to be stolen.
• Access can persist until consent is revoked or the tokens are invalidated.
• Security teams may initially see "normal" OAuth activity.

Microsoft documents consent phishing as an application-based attack path and recommends restricting user consent, reviewing applications, and investigating suspicious consent grants. It is worth noting that while user consent is now restricted by default in most tenants (we cover this below), many organisations still have legacy applications that were consented to before these defaults were introduced and were never reviewed afterwards. Auditing existing consents is therefore as important as restricting new ones.

OAuth abuse has continued to evolve. More recent campaigns, such as ConsentFix, no longer rely on a malicious third-party application at all. Some public reporting has linked observed activity to state-sponsored threat actors, but the defensive lesson is broader than a single actor: attackers can abuse trusted first-party Microsoft applications that follow a different trust and consent model than third-party applications. These applications are not governed by the same user consent restrictions discussed below, so the mitigations are different. They rely primarily on Conditional Access targeting CLI tools, Token Protection, and Global Secure Access compliant network checks rather than on the consent framework itself.

Consent Controls

Once you understand consent and how it can be abused, the first practical control is to define who can grant consent to which applications.

Restricting user consent

In Microsoft Entra ID, user consent settings can be configured under:

Microsoft Entra admin centre → Enterprise applications → Consent and permissions → User consent settings.

The available options are:

• Do not allow user consent. All consent requests require admin approval. The most restrictive option.
• Allow user consent for apps from verified publishers, for selected permissions. Users can consent only when both conditions are met: the app comes from a verified publisher (or is registered in your own tenant), and the requested permissions are classified as low impact.
• Let Microsoft manage your consent settings. Applies the Microsoft-managed recommended policy, whose contents are maintained and updated by Microsoft as the threat landscape evolves. We cover this option in detail in the next section.

Note that the legacy "Allow user consent for all apps" option is no longer offered in the Entra ID Admin centre. Microsoft has removed it from the UI and migrated tenants that were still on it to the Microsoft-managed policy.

For most organisations, the practical baseline is either Allow user consent for apps from verified publishers, for selected permissions or Let Microsoft manage your consent settings. The choice between the two comes down to whether you want full control over the list of low-impact permissions (option 2) or want Microsoft to keep that list current for you (option 3).

In addition, review permission classifications. Permission classifications allow you to classify delegated permissions based on organisational risk, for example low, medium, or high. These classifications can then be used in consent policies to determine which permissions users are allowed to consent to.

Examples of permissions that should usually require careful review:

• Mail.Read, Mail.ReadWrite
• Files.Read.All, Files.ReadWrite.All
• Sites.Read.All
• Directory.Read.All, Directory.ReadWrite.All
• User.ReadWrite.All, Group.ReadWrite.All

The exact classification depends on your environment, but the principle is simple: users should not be able to approve broad or persistent data access without review.

Admin Consent Workflow

If user consent is restricted, users still need a way to request legitimate applications. This is where the admin consent workflow becomes useful. Reviewers can evaluate the application, permissions, publisher, and business justification before approval.

A practical configuration pattern is:

• Enable the admin consent workflow
• Assign reviewers (a group of administrators)
• Define request expiration
• Require justification from users
• Approve only if there is a clear business need

When reviewing consent requests, avoid approving simply because "many users requested it." Microsoft explicitly recommends carefully evaluating tenant-wide admin consent because it can grant permissions on behalf of the entire organisation. A useful checklist when reviewing a request:

• Is the publisher verified?
• Is the application known and expected?
• Who requested the application?
• Which permissions are requested?
• Is offline_access requested? (can allow persistent access)
• Does the application need tenant-wide consent?
• Can user assignment be required?
• Is there a less privileged alternative?

A good internal rule of thumb:

If you do not understand why an application needs the permission, do not approve the consent request.

For approved applications, consider assigning owners, requiring user assignment, documenting the business justification, reviewing permissions periodically, and removing unused applications.

The Email Clients Exemption

Under the Microsoft-managed default consent policy, end users can no longer self-consent to most mailbox, calendar, Teams chat, and Online Meetings permissions, including the legacy mail protocol scopes (EAS.AccessAsUser.All, EWS.AccessAsUser.All, IMAP.AccessAsUser.All, POP.AccessAsUser.All).

To preserve user experience, Microsoft introduced a built-in app consent policy named microsoft-user-default-allow-consent-apps. When this policy is enabled (which is the case by default), end users can still consent to a small, fixed list of popular mail clients for the legacy mail scopes, even though the broader Microsoft-managed policy would otherwise require admin approval.

The current list of exempted apps, with App IDs, is:

• Apple Mail: f8d98a96-0999-43f5-8af3-69971c7bb423
• Spark Email: b50c1dbd-1855-4e54-b07c-d3c3029e93d3
• eM Client: e9a7fea1-1cc0-4cd9-a31b-9137ca5deedd
• Android-Samsung: 8acd33ea-7197-4a96-bc33-d7cc7101262f
• Android-Mail: 2cee05de-2b8f-45a2-8289-2a06ca32c4c8
• Thunderbird: 9e5f94bc-e8a4-4e73-b8be-63364c29d753

The exemption permits exactly these scopes: EAS.AccessAsUser.All, EWS.AccessAsUser.All, IMAP.AccessAsUser.All, POP.AccessAsUser.All.

Note that Outlook for iOS / Android and Outlook for Windows / macOS are not on this list. These are first-party Microsoft applications and follow a separate trust path; they are not affected by these consent changes.

In the Entra ID Admin centre, this policy maps to the "Enable user consent for popular Mail clients" checkbox under "Let Microsoft manage your consent settings". Ticking the box assigns the policy to the default user role; unticking removes it.

A trade-off worth being aware of

The flip side of this exemption is that the same legitimate clients have been abused by attackers as a persistence mechanism, sometimes referred to as "traitorware". The pattern is straightforward: after compromising an account (typically through Adversary-in-the-Middle), the attacker connects the victim's mailbox to a legitimate exempted client, which silently obtains its own OAuth tokens. The consent grant itself survives password reset and MFA enforcement. Unless sessions are revoked and the consent grant is removed, the application may continue to regain access through legitimate OAuth flows. eM Client has been the most-documented example in incident response reports, but the technique generalises to any of the exempted apps.

This does not mean the exemption is wrong; it means the exemption shifts the burden of detection onto monitoring. Organisations keeping the exemption in place should specifically watch for sign-ins to the exempted App IDs from users or geographies where those clients are not expected, and treat new consent grants to these apps as worth investigating. We come back to this in the Monitoring and Detection section.

Inspecting the current state in your tenant

The relevant policies can be enumerated with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All"

# List all built-in and custom permission grant policies
Get-MgPolicyPermissionGrantPolicy |
    Select-Object Id, DisplayName, Description |
    Format-Table -AutoSize

# Show which permission grant policies are currently assigned to the default user role
(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.PermissionGrantPoliciesAssigned

# Inspect the include conditions of the email-clients exemption policy
Get-MgPolicyPermissionGrantPolicyInclude `
    -PermissionGrantPolicyId "microsoft-user-default-allow-consent-apps" |
    Format-List

You should see, among others, microsoft-user-default-low, microsoft-user-default-recommended, and /or microsoft-user-default-allow-consent-apps in the list of built-in policies, and the policies currently assigned to your tenant's default user role in the second command.

Application Assignment

Consent controls which permissions an application may use. Application assignment controls who is allowed to use the application.

For sensitive enterprise applications, you should avoid making the app available to all users by default. A practical pattern is:

1. Open the enterprise application
2. Go to Properties
3. Set Assignment required to Yes
4. Assign only required users or groups
5. Review application sign-in logs

This reduces unnecessary exposure and improves visibility, and makes it easier to decommission unused applications later. For high-impact applications, combine assignment with Conditional Access.

Authentication Context

So far, we discussed application permissions, consent, and assignment. The next step is to differentiate access based on the sensitivity of the application or action.

Not all applications require the same level of assurance. A low-risk SaaS application may only require standard MFA, while an HR application may require phishing-resistant authentication, an application exposing sensitive financial data may require a compliant device, and a privileged action may require step-up authentication.

This is where authentication context becomes useful. Authentication context allows resources to trigger a Conditional Access policy for specific sensitive actions or resources, even though those resources sit inside a broader application that the user already has access to.

It is worth being explicit about one nuance: authentication context must be invoked by something. It is not a setting that automatically applies to every action in an app. Currently, this can be done by Microsoft Purview sensitivity labels (for protected SharePoint sites), by SharePoint site-level Conditional Access integration, by Microsoft Defender for Cloud Apps and Conditional Access App Control, by Microsoft Entra protected actions, and by custom applications that opt in through the Conditional Access authentication context API. Most third-party SaaS applications do not natively consume authentication context.

Practical configuration

Example scenario: you want to require stronger authentication when users access a highly confidential SharePoint site.

1. Create an authentication context in Conditional Access (Protection → Conditional Access → Authentication contexts → New authentication context). Name it something meaningful, for example Sensitive documents.
2. Create a Conditional Access policy targeting this authentication context as the cloud app. Apply the desired grant controls, for example Require authentication strength: Phishing-resistant MFA and/or Require device to be marked as compliant.
3. Bind the authentication context to the SharePoint site through a Microsoft Purview sensitivity label, or through the SharePoint site-level Conditional Access policy.

Monitoring and Detection

After these preventive controls are in place, the next step is to continuously monitor which applications are being added, consented to, and used. Like Identity Protection and device compliance, application governance is not a one-time configuration. Administrators should regularly review enterprise applications, admin and user consent grants, applications with high privileges, unused applications, applications with expired or long-lived secrets, sign-in activity for service principals, and OAuth app activity in Defender for Cloud Apps.

Useful sources include Entra audit logs and sign-in logs, service principal sign-in logs, the Consent Insights workbook in Entra ID, Defender for Cloud Apps OAuth app governance, and Microsoft Defender XDR incidents involving OAuth applications.

Activities that should trigger investigation

• Consent granted to an unknown application
• Admin consent granted outside regular change process
• Application requesting mailbox, file, directory, or group permissions, especially combined with offline_access (which enables persistent refresh token access)
• New service principal with high-impact Graph permissions
• Application sign-ins from unusual locations
• Sign-ins to the exempted email client App IDs from users who do not normally use those clients

Example KQL hunting ideas

List service principals recently added to your tenant:

AuditLogs
| where OperationName in ("Add service principal",
                          "Add app role assignment to service principal",
                          "Consent to application")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources

List sign-in attempts to the exempted email clients:

// Hunt for sign-ins to the exempted email clients,
// useful for detecting traitorware-style persistence
let ExemptedMailClients = dynamic([
    "f8d98a96-0999-43f5-8af3-69971c7bb423",  // Apple Mail
    "b50c1dbd-1855-4e54-b07c-d3c3029e93d3",  // Spark Email
    "e9a7fea1-1cc0-4cd9-a31b-9137ca5deedd",  // eM Client
    "8acd33ea-7197-4a96-bc33-d7cc7101262f",  // Android-Samsung
    "2cee05de-2b8f-45a2-8289-2a06ca32c4c8",  // Android-Mail
    "9e5f94bc-e8a4-4e73-b8be-63364c29d753"   // Thunderbird
]);
SigninLogs
| where AppId in (ExemptedMailClients)
| summarize SignInCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Countries = make_set(Location, 10)
            by UserPrincipalName, AppDisplayName, AppId
| order by FirstSeen desc

List service principals that authenticated to Microsoft Graph in your tenant:

AADServicePrincipalSignInLogs
| where ResourceDisplayName == "Microsoft Graph"
| summarize SignInCount = count(),
            DistinctIPs = dcount(IPAddress)
            by ServicePrincipalName, AppId
| order by SignInCount desc

Baseline Recommendations

A practical starting point for the Applications pillar is:

• Restrict user consent to verified publishers and low-impact permissions.
• Enable the admin consent workflow with clear reviewers.
• Review whether the email clients exemption fits your risk profile.
• Review existing enterprise applications with high privileges and remove what is unused.
• Require user assignment for sensitive applications. User requests and assignments to approved applications can be managed using Access Packages, for example.
• Use authentication context for high-sensitivity applications or actions.
• Monitor consent and service principal activity, and tune detections for the activities listed above.

This baseline does not eliminate all application risk, but it significantly reduces uncontrolled OAuth access and the most common abuse paths.

Wrapping Up

In this fourth part of the Microsoft 365 Zero Trust roadmap, we moved from identity and device signals to application context. We explored how applications are represented in Microsoft Entra ID, how delegated and application permissions work, and how OAuth consent, when poorly governed, can be a persistence mechanism that bypasses MFA entirely.

We then covered the practical controls that give the Applications pillar its substance: user consent restrictions, the admin consent workflow, the Microsoft-managed default consent policy, application assignment, and authentication context. Together, these reduce OAuth abuse and apply stronger requirements to sensitive applications.

In the next post in the roadmap, we will move to the Network pillar: why named locations are useful as a signal but dangerous as a trust boundary, why IP allow-lists give a false sense of security, and how Microsoft Entra Global Secure Access changes the picture.