Control App Access to Exchange Online with Microsoft 365 RBAC

Introduction

The Microsoft Graph application permissions for Exchange Online are powerful. Sometimes they are too powerful.

Imagine a room-booking application that needs to update calendars for 50 meeting rooms. Granting the Microsoft Graph Calendars.ReadWrite application permission in Microsoft Entra ID normally gives the application access to all calendars across the organization. The application needs 50 mailboxes, but the permission can cover 50,000.

Exchange Online Role Based Access Control (RBAC) for applications addresses this problem. It separates two questions that are often mixed together:

• What may the application do? For example, read mail, update calendars, or send messages.
• Where may it do it? For example, only room mailboxes in Prague, only shared mailboxes used by Finance, or only members of an administrative unit.

Microsoft Graph exposes the Exchange Online RBAC provider under the beta endpoint:

/beta/roleManagement/exchange

Through this endpoint, your applications can discover Exchange roles, create and inspect role assignments, and manage custom application scopes. This makes Exchange application access easier to automate and govern without depending only on interactive Exchange Online PowerShell which is being deprecated.

Be aware that the Microsoft Graph role-management endpoints are currently available under beta, so Microsoft officially doesn't recommend that beta APIs for production applications even if the role managements work pretty well from my current experience.

Exchange Online as a Microsoft 365 RBAC provider

The Microsoft Graph roleManagement resource provides one entry point to several Microsoft 365 RBAC systems. These include Microsoft Entra, Intune, Defender, Cloud PC, entitlement management, and Exchange Online, but I will focus only on the Exchange provider.

The Exchange provider is represented by a unifiedRbacApplication. Despite its name, it isn't your business application or app registration. It is a Microsoft Graph container for the RBAC objects owned by the Exchange provider.

Four objects are important:

Object	Purpose
Service principal	The enterprise application identity receiving Exchange access
unifiedRoleDefinition	Describes what operations a role permits
customAppScope or directory scope	Describes the Exchange resources covered by an assignment
unifiedRoleAssignment	Connects one principal, one role, and one scope

In a simple sentence, an assignment says:

This service principal may perform this Exchange role against these recipients.

This follows the same basic RBAC idea that Exchange administrators already know: a role defines allowed work, an assignment grants it to a principal, and a scope limits where the grant applies. The difference is that the principal is an application rather than a human administrator.

Management permissions and workload permissions are different

It is useful to distinguish two application identities, even when one solution happens to use both responsibilities.

The RBAC management application calls /roleManagement/exchange to read or change the authorization configuration. Its least-privileged Microsoft Graph permissions are:

• RoleManagement.Read.Exchange for reading role definitions, assignments, and scopes.
• RoleManagement.ReadWrite.Exchange for creating, updating, and deleting assignments or custom scopes.

Both permissions are available in delegated and application forms. RoleManagement.Read.All can also read Exchange RBAC, but it is broader and should not be the first choice.

The workload application is the service principal receiving a role such as Application.Calendars.Read or Application.Mail.Send. It then calls the relevant Microsoft Graph interface.

Why use Exchange RBAC instead of a direct application permission?

Microsoft Entra application permissions remain useful when an application needs organization-wide access. Exchange RBAC is preferred when access should be narrower, easier to explain, or independently managed by Exchange administrators.

Resource scoping is part of the grant

A directly consented Graph application permission is normally unscoped at the Exchange resource level. Mail.Read means mailboxes across the tenant unless another control, such as an Application Access Policy, constrains it.

An Exchange RBAC assignment combines the permission and resource scope in one authorization statement. For example:

• Application Calendars.ReadWrite for room mailboxes in the Czech Republic.
• Application Mail.Read for direct members of a Finance mail-enabled security group.
• Application Mail.Send for one notification mailbox.
• Application Contacts.ReadWrite for users in a sales administrative unit.

This supports least privilege in both dimensions: action and target.

It replaces Application Access Policies

Microsoft describes RBAC for Applications as the replacement for Exchange Online Application Access Policies. Application Access Policies constrain permissions already consented in Microsoft Entra ID. RBAC assignments are an independent authorization mechanism and can grant the permission together with its scope.

RBAC also offers more natural Exchange scoping choices: recipient-filter-based management scopes, individual users, groups, administrative units, or the whole organization. Dynamic recipient filters are especially useful in larger environments because access can follow mailbox attributes instead of a manually maintained list.

It scales as a governance model

Roles, assignments, and scopes are separate resources. One scope can be reused by several assignments, and each assignment can be queried by principal, role, or scope. That model is friendly to inventory tools, approval workflows, infrastructure-as-code processes, and periodic access reviews.

It gives Exchange administrators stronger ownership

The authorization is stored in the Exchange RBAC system. Exchange administrators can use familiar Exchange concepts and recipient filters, while central identity administrators continue to own app registrations, credentials, and service principal lifecycle.

This creates a clearer division of responsibility:

• Identity teams establish who the application is.
• Exchange teams decide what Exchange access it receives.
• Application owners explain why the access is needed.
• Security teams review the resulting assignments.

Permissions from both systems are additive

Be aware that Exchange RBAC assignments don't reduce an equivalent organization-wide permission already granted in Microsoft Entra ID. The effective permissions are the union of both authorization sources.

Suppose a service principal has:

• Microsoft Entra application permission Mail.Read, covering the organization.
• Exchange RBAC role Application Mail.Read, scoped only to Finance.

The result is still organization-wide mail read access. The narrow RBAC assignment doesn't override the broad Entra grant.

When migrating a resource-scoped workload to Exchange RBAC, remove the equivalent unscoped Entra application permission after the RBAC assignment is ready. Also review any remaining Application Access Policies. Mixing the two systems can be valid, for example organization-wide Mail.ReadBasic plus scoped Mail.Send, but the combined result must be evaluated deliberately.

The Exchange application role catalog

A unifiedRoleDefinition describes a role and its allowed resource actions. To find the roles that can be assigned to service principals, filter the allowedPrincipalTypes value for servicePrincipal.

GET /beta/roleManagement/exchange/roleDefinitions?$filter=allowedPrincipalTypes eq 'servicePrincipal'

It will give the following roles:

Role	Main capability	Typical use
Application Mail.ReadBasic	Read basic message properties, excluding body, preview, attachments, and extended properties	Message inventory, routing analytics, or lightweight discovery
Application Mail.Read	Read email	Scoped archiving, classification, or case-management ingestion
Application Mail.ReadWrite	Create, read, update, and delete email; doesn't include send	Shared-mailbox processing or mailbox workflow automation
Application Mail.Send	Send mail as a mailbox	Notifications, statements, or business-process messages
Application Mail Full Access	Mail.ReadWrite and Mail.Send	A tightly scoped service that must process and send mail
Application MailboxSettings.Read	Read mailbox settings	Configuration inventory and compliance reporting
Application MailboxSettings.ReadWrite	Read and modify mailbox settings	Standardizing time zones, language, or automated-reply configuration
Application Calendars.Read	Read calendar events	Availability dashboards or room-utilization reporting
Application Calendars.ReadWrite	Create, read, update, and delete events	Room booking, shift scheduling, or field-service planning
Application Contacts.Read	Read mailbox contacts	Scoped CRM synchronization
Application Contacts.ReadWrite	Create, read, update, and delete contacts	Two-way CRM or line-of-business contact synchronization
Application MailTips.ReadBasic.All	Read MailTips metadata without email content	Pre-send checks and recipient guidance
Application MailboxFolder.Read	Read mailbox folders	Folder discovery for migration or records tools
Application MailboxFolder.ReadWrite	Read and modify mailbox folders	Provisioning or reorganizing application-managed folders
Application MailboxItem.Read	Read mailbox items	Item-level discovery or migration preparation
Application MailboxItem.ReadWrite	Create, read, and delete mailbox items	Item-level migration and mailbox processing
Application MailboxItem.Export	Export mailbox items	Controlled export or archival solutions
Application MailboxItem.ImportExport	Import and export mailbox items	Migration and restore tooling
Application MailboxConfigItem.Read	Read UserConfiguration objects	Inspect application configuration stored in mailboxes
Application MailboxConfigItem.ReadWrite	Read and modify UserConfiguration objects	Manage application-specific mailbox configuration
Application SMTP.SendAsApp	Submit mail using app-only SMTP authentication	Existing SMTP-based notification services
Application EWS.AccessAsApp	Full mailbox access through EWS	Legacy or specialist EWS integrations
Application Exchange Full Access	Mail read/write/send, mailbox settings, calendars, and contacts	Exceptional integrations needing several Exchange workloads

Choosing an Exchange resource scope

The role is only half of the decision. The assignment must also identify its scope.

Directory scopes

When creating an Exchange role assignment, directoryScopeId supports several useful forms:

Scope	directoryScopeId
Entire Exchange organization	/
One user or mailbox	/Users/{object-id}
An administrative unit	/AdministrativeUnits/{object-id}
Direct members of a group	/Groups/{object-id}

Group scope is practical during migration from Application Access Policies, but direct membership matters. Nested group members are treated as out of scope. Microsoft documents support for Microsoft 365 groups, mail-enabled security groups, and distribution lists in the related management-scope scenario.

Administrative units are useful where the organization already uses them for regional or business-unit delegation. For a single mailbox, the /Users/{object-id} form is simple and explicit.

Custom application scopes

A customAppScope maps to an Exchange management scope. Its customAttributes can contain an Exchange recipient filter.

For example, the following scope selects room mailboxes marked for a booking application:

POST /beta/roleManagement/exchange/customAppScopes
Content-Type: application/json

{
  "type": "RecipientScope",
  "displayName": "Prague booking rooms",
  "customAttributes": {
    "Exclusive": false,
    "RecipientFilter": "CustomAttribute1 -eq 'Booking-Prague'"
  }
}

The response contains the scope id. Use this value as the assignment's appScopeId.

Recipient filters make scopes dynamic. If the Exchange team adds Booking-Prague to another room mailbox, that mailbox can enter the scope without changing the role assignment. This is powerful, but it also means that mailbox attribute governance becomes part of application security.

Exclusive management scopes don't restrict application access. Don't assume that an exclusive scope, which has special meaning in administrative RBAC, acts as a deny boundary for service principals.

Creating and managing a role assignment

A unifiedRoleAssignment joins the three authorization elements:

• principalId: the Exchange service-principal path, using the service principal object ID, not the app registration's client ID.
• roleDefinitionId: the selected Exchange role definition ID.
• appScopeId or directoryScopeId: the resources covered by the grant.

For an administrative-unit scope, a request has this shape:

POST /beta/roleManagement/exchange/roleAssignments
Content-Type: application/json

{
  "principalId": "/ServicePrincipals/{service-principal-object-id}",
  "roleDefinitionId": "{exchange-role-definition-id}",
  "directoryScopeId": "/AdministrativeUnits/{administrative-unit-object-id}",
  "appScopeId": null
}

For the custom scope created earlier, provide its returned ID in appScopeId and don't provide a competing directory scope. A successful create returns 201 Created and the new assignment, including its assignment id.

Assignments can be listed for one service principal:

GET /beta/roleManagement/exchange/roleAssignments?$filter=principalId eq '/ServicePrincipals/{service-principal-object-id}'

The API supports filtering by principalId, roleDefinitionId, or appScopeId. This is important for governance applications: query a specific principal or access relationship instead of treating the endpoint as an unrestricted tenant dump. A single assignment can be read or removed with:

GET    /beta/roleManagement/exchange/roleAssignments/{assignment-id}
DELETE /beta/roleManagement/exchange/roleAssignments/{assignment-id}

Deletion returns 204 No Content. There is no update method for unifiedRoleAssignment in this API model. To change its principal, role, or scope, remove the old assignment and create the intended one. Design automation so this replacement is controlled and auditable.

What you can built with these APIs?

The role-management endpoints are useful for more than a setup script. They provide the foundation for an Exchange application-access control plane.

An application access catalog

A portal can combine service principal metadata from Microsoft Entra with Exchange role assignments and scopes. For each integration, it can answer:

• Which Exchange roles does this app have?
• Is access tenant-wide, group-based, or filter-based?
• Which assignments use broad roles?
• Which scopes are shared by several apps?
• Does the app also hold equivalent unscoped Entra permissions?

That last question is essential because Exchange RBAC alone can't reveal the full effective permission when grants are additive.

A self-service onboarding workflow

An internal developer could request “calendar write for Czech room mailboxes.” The workflow can map this request to Application Calendars.ReadWrite, reuse an approved scope, collect owner and expiry metadata in the company's governance system, obtain approval, and create the assignment.

The provisioning identity needs RoleManagement.ReadWrite.Exchange, but the resulting workload identity receives only the selected Exchange role.

A least-privilege and drift scanner

A scheduled scanner can flag:

• Tenant-wide assignments where a scoped grant would be enough.
• Use of Application Exchange Full Access, Application Mail Full Access, or Application EWS.AccessAsApp.
• Assignments referencing unexpected service principals.
• Scopes whose recipient filters changed.
• Duplicate or overlapping assignments.
• Service principals that still have equivalent broad Entra application permissions.

This turns least privilege from a one-time design meeting into a continuously checked control.

Workload applications with narrow Exchange reach

The assigned roles also enable many practical workload designs:

• A booking assistant limited to room calendars in one country.
• A CRM connector limited to contacts in sales shared mailboxes.
• An invoice-processing service reading only accounts-payable mailboxes.
• A migration tool importing or exporting items only for a migration wave.
• A notification service sending only from approved functional mailboxes.
• A mailbox-settings service standardizing selected employee populations.
• A compliance exporter restricted to a legal case scope.

The important design improvement isn't a new mail API. It is safer authorization for the Graph, EWS, or SMTP operations the application already performs.

Operational limits to include in the design

Exchange RBAC for applications has several documented constraints:

• Application roles can be assigned only to service principals.
• Applications can't be members of Exchange role groups.
• Application roles can't be copied or derived.
• Exclusive management scopes don't restrict application access.
• Permission changes can take between 30 minutes and two hours to become effective because of caching, depending on recent application activity.
• Deleting a service principal in Microsoft Entra also removes its Exchange service-principal representation and assignments, but management scopes remain.
• Supported access protocols documented for the RBAC model include Microsoft Graph and EWS; the role catalog also includes app-only SMTP submission.
• The Microsoft Graph management surface covered in this article is beta.

The propagation delay matters for both deployment and incident response. Automation shouldn't report success only because the assignment object was created. It should distinguish control-plane completion from data-plane enforcement and allow for the documented cache window.

Conclusion

Use organization-wide Microsoft Entra application permissions when the business requirement is genuinely organization-wide. Use Exchange RBAC for Applications when a workload needs Exchange access that can be expressed as a role over a defined mailbox population.

Next time, I will show a practical example of how to implement Exchange RBAC for a room-booking application, including creating custom scopes and assigning roles to service principals.