Microsoft 365 Application Access Policies and RBAC for Applications Guide: Scoping App Permissions to Mailboxes and Sites

A Microsoft Graph application permission such as Mail.Read, once consented in Microsoft Entra ID, applies to every mailbox in the tenant unless something else narrows it. Most integrations need a handful of mailboxes or one SharePoint site, yet they are routinely granted tenant-wide access because that is the default shape of an app role. Exchange Online offers two scoping mechanisms, the older Application Access Policies and the newer RBAC for Applications, and SharePoint offers the Sites.Selected family of permissions. This guide explains how each works, how they interact with Entra consent, how to migrate between them and how to prove the scoping is effective. It is for Microsoft 365 administrators, identity engineers and anyone reviewing app registrations that touch mail, calendars or documents.

Key takeaways

• Grants are additive. Microsoft documents a union model: an unscoped Mail.Read in Entra plus a scoped Mail.Read in Exchange RBAC gives unscoped access, so the Entra grant must be removed.
• RBAC for Applications replaces Application Access Policies. The cmdlet reference says not to create new policies, because they will eventually need migrating.
• Scoping is set in Exchange, not Entra. Management scopes and administrative units define which mailboxes an app reaches; Test-ServicePrincipalAuthorization proves it.
• Sites.Selected starts with no access. The app gets nothing until a site, list or file permission is explicitly granted through Graph.
• Logs show whether scoping holds. Microsoft Graph activity logs record the AppId, roles and request URI for every call, which is how you catch an app reaching outside its intended scope.

How identity and access work in Microsoft 365 application permissions

An application in Microsoft 365 is represented by an app registration (the definition) and a service principal (its instance in your tenant). It can call Microsoft Graph in two modes. In delegated mode it acts for a signed-in user and can never exceed that user's rights. In application-only mode there is no user, and the app's effective access is whatever app roles have been consented. Microsoft's own Selected-permissions documentation calls application-only mode higher risk and prefers delegated mode where possible.

Three places can now grant or constrain application-only access to mailbox and site data:

The critical rule is how Exchange combines them. Microsoft states that RBAC grants and Entra consent are a union, each authority acting independently. Application Access Policies can only constrain Entra-assigned permissions, not RBAC assignments. Microsoft's own edge case: an app with Entra Mail.Read restricted by a policy to Group 1, plus an RBAC Mail.Read over a scope that excludes mailbox A, can reach every mailbox, because the two grants together cover "A or not A". Microsoft recommends keeping organisation-wide permissions in Entra and resource-scoped permissions in RBAC for Applications, and not mixing policies with RBAC. For the Entra side of consent and app registration, see the Entra ID Applications and Consent Guide.

RBAC for Applications in practice

1. Create the service principal pointer. Exchange cannot create service principals; it points to the Entra one: New-ServicePrincipal -AppId <AppId> -ObjectId <ObjectId> -DisplayName <name>. Take both IDs from Enterprise applications, not App registrations, which show different values.
2. Define the resource scope. Either a management scope with a recipient filter, for example New-ManagementScope -Name "Canadian users" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'", or an Entra administrative unit passed directly with -RecipientAdministrativeUnitScope, which Microsoft recommends over embedding an AU in a management scope.
3. Assign the role. New-ManagementRoleAssignment -App <ObjectId> -Role "Application Mail.Read" -CustomResourceScope "Canadian users".
4. Remove the unscoped Entra grant for the same permission, or the scope has no effect.
5. Test. Test-ServicePrincipalAuthorization -Identity <app> -Resource <mailbox> returns InScope True or False per permission. It excludes Entra grants and bypasses the permission cache, so it can report the intended state before production calls reflect it.

Changes are cached for 30 minutes to two hours depending on how active the app is. Plan cut-overs and rollback windows around that range.

Exchange application roles available

The full list also includes MailboxFolder, MailboxItem.Read and ReadWrite, MailboxConfigItem, MailTips.ReadBasic.All and Mail-Advanced.ReadWrite.All roles. Run Get-ManagementRole to see the current set in your tenant.

SharePoint and OneDrive: Selected permissions

For document access the equivalent pattern is the Selected scope family: Sites.Selected (site collection), Lists.SelectedOperations.Selected, ListItems.SelectedOperations.Selected and Files.SelectedOperations.Selected. Microsoft documents three required steps: consent to the Selected scope, grant a role (read, write, owner or fullcontrol) on the resource with POST /sites/{siteId}/permissions or the list, item or drive item equivalent, then obtain a token containing the scope. Skip any step and the app has no access. Granting at site level requires Sites.FullControl.All, so the granting tool is itself highly privileged and should not be the app being scoped. Grants on lists, items or files break permission inheritance, which counts against SharePoint's unique security scope limits. See the SharePoint and OneDrive Security Guide for the wider site controls.

Admin roles and privileged access

• Exchange side: managing RBAC for Applications requires the Organization Management role group in Exchange (or a delegated Exchange RBAC assignment) and the Exchange Administrator role in Entra. Anyone with these can widen an app's scope or assign Application Exchange Full Access, so treat the assignments as privileged.
• Entra side: Microsoft's admin consent documentation states that only the Privileged Role Administrator (or a custom role with the right permission) can grant tenant-wide consent for Microsoft Graph application permissions. Cloud Application Administrator, Application Administrator and AI Administrator can consent to other APIs and to delegated Graph permissions.
• App owners: owners of an app registration can add credentials to it. An owner who adds a secret to an app holding Mail.Read gains tenant-wide mail access. Restrict ownership and monitor credential changes.
• SharePoint granting tool: whatever identity calls /sites/{id}/permissions needs Sites.FullControl.All. Run it as a separate, tightly owned admin app, ideally invoked only during change windows.

For broader tenant role design, see the Entra ID Security Guide.

Integrations, API tokens and service accounts

Different integration types map to different scoping strategies. Choose the one that matches who must be reachable.

Scoping limits what a stolen credential can reach, but the credential still matters. Prefer certificate credentials or workload identity federation over client secrets, store any secret in a vault, and expire it. The Microsoft Midnight Blizzard breach is the reference case: Microsoft reported that the actor used a legacy test OAuth app to grant itself the Exchange Online full_access_as_app role and read senior leadership mailboxes without needing any user's password or MFA. A scoped role assignment and an alert on the grant would have narrowed and exposed that path. See the Consent Phishing and Illicit OAuth Grants Guide for the user-consent variant.

Logging and detection

Graph activity logs need an Entra ID P1 or P2 licence and a diagnostic setting to Log Analytics, storage or Event Hubs; Microsoft says events usually arrive within 30 minutes and occasionally up to two hours. A useful detection is to join Graph activity for each scoped app with the set of mailbox identifiers in its management scope and alert on any successful request outside it, which should be impossible if the Entra grant was removed. MailItemsAccessed is part of Audit (Standard) and on by default for E3 and E5 users.

Relevant MITRE ATT&CK techniques are T1098.003 Additional Cloud Roles and T1098.001 Additional Cloud Credentials for grant and credential changes, and T1114.002 Remote Email Collection for the mailbox access itself. See the Microsoft Sentinel Guide for analytics rule patterns.

Metrics:

• Unscoped mail permissions: number of service principals holding Mail.*, Calendars.* or EWS.AccessAsApp as Entra app roles without a documented organisation-wide justification.
• Migration progress: remaining Application Access Policies (target zero).
• Selected adoption: share of SharePoint integrations using Sites.Selected rather than Sites.*.All.
• Out-of-scope success: successful Graph requests by scoped apps to resources outside their scope (target zero).
• Credential hygiene: apps with mail or file permissions that use client secrets rather than certificates or federation.

Hardening baseline

1. Inventory. List every service principal with Graph application permissions for mail, calendars, contacts, files and sites, plus every Application Access Policy (Get-ApplicationAccessPolicy) and RBAC assignment.
2. Classify. Mark each as genuinely organisation-wide or resource-scoped. Organisation-wide stays in Entra with compensating controls; everything else moves to RBAC or Selected.
3. Pilot one app. Pick a low-impact app, create the pointer, scope and assignment, run Test-ServicePrincipalAuthorization against an in-scope and an out-of-scope mailbox, then remove the Entra grant.
4. Migrate policies. For each Application Access Policy follow Microsoft's sequence: management scope using MemberOfGroup with the group's distinguished name, service principal pointer, scoped assignment, remove the Entra consent, then remove the policy. Nested group members are out of scope in RBAC, unlike policies, so flatten groups first.
5. Move SharePoint integrations to Selected. Grant only the role needed (read before write) on the specific site or list.
6. Harden credentials. Certificates or federation, short expiry, ownership restricted to a named team.
7. Turn on detection for grants, credential changes and out-of-scope access, and verify with a deliberate test grant.

Rollback: if an app breaks after the Entra grant is removed, re-add the Entra consent for that single permission (restoring the old behaviour), then fix the scope and retry. Allow for the two-hour cache before deciding a change has failed.

Small versus large tenants: a small tenant can usually manage with a handful of management scopes built on mail-enabled groups. A large or multi-region tenant benefits from administrative units, because the same AUs can also scope human admin roles, keeping one model for people and apps. Note that RBAC for Applications supports up to 10,000 applications per organisation.

Framework mapping

Common misconfigurations

• Scoping in RBAC but leaving the Entra grant: the union model means the app keeps tenant-wide access. This is the most common and least visible failure.
• Mixing policies and RBAC: the "A or not A" case Microsoft documents turns two partial restrictions into full access.
• Relying on exclusive management scopes: Microsoft states that exclusive scopes do not restrict app access, so they cannot be used to protect VIP mailboxes from apps.
• Wrong object IDs: using App registration IDs instead of Enterprise application IDs when creating the service principal pointer, producing an assignment that never matches.
• Nested groups after migration: a policy that covered nested members silently loses them when converted to a MemberOfGroup scope.
• Sites.Selected granted from the app itself: giving the scoped app Sites.FullControl.All so it can grant itself permissions defeats the purpose.

Practitioner checklist

• Export all Graph application permissions for mail, calendar, contacts, files and sites, with owner and justification.
• Stop creating Application Access Policies; record a migration date for each existing one.
• Build management scopes or administrative units for each resource-scoped app and assign Exchange application roles.
• Remove the matching unscoped Entra grant and confirm with Test-ServicePrincipalAuthorization.
• Move SharePoint integrations to Sites.Selected or the finer Selected scopes, granted by a separate admin tool.
• Restrict Privileged Role Administrator and Exchange Organization Management membership and use just-in-time activation.
• Replace client secrets with certificates or federation on apps holding mail or file permissions.
• Stream Graph activity logs to your SIEM and alert on out-of-scope success, new app role assignments and new credentials.

Standards and references

• Microsoft Learn: Role Based Access Control for Applications in Exchange Online
• Microsoft Learn: New-ApplicationAccessPolicy
• Microsoft Learn: Overview of Selected permissions in OneDrive and SharePoint
• Microsoft Learn: Grant tenant-wide admin consent to an application
• Microsoft Learn: Microsoft Graph activity logs
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Additional Cloud Roles

Related NHI Mgmt Group resources: Entra ID Applications and Consent Guide · Exchange Online Security Guide · Microsoft 365 Security Guide · Microsoft Midnight Blizzard Breach