Verify Exchange App RBAC Mailbox Scope

A booking service may need a few calendars. An invoice integration may need one mailbox. Giving either application access to every mailbox creates a larger permission boundary than the business task requires.

Exchange Online application RBAC can attach an application permission to a mailbox scope. The useful test is whether the application can perform its intended operation and is denied the same operation against an excluded mailbox.

Start with the operation and the identity

Write down the smallest business operation the integration needs. Reading message metadata, reading message bodies and sending mail are different requirements. Ask the supplier to identify the API operations it actually calls rather than accepting “Microsoft 365 access” as a complete permission request.

Microsoft’s app-only access guidance explains that the application acts with its own identity. Its rights are not limited by the rights of an interactive user.

Record the tenant, application ID, enterprise application service principal and responsible owner. A display name alone is poor evidence: similar names make it easy to inspect one application while the live workload uses another.

For Exchange’s pointer to the service principal, use the enterprise application’s object identity. Microsoft warns against substituting the application registration’s different object ID in the application RBAC setup.

Inspect both places that can grant access

The critical detail is that Exchange application RBAC and Entra application permissions are additive. An unscoped Entra Mail.Read grant can leave access broad even when the Exchange assignment is narrow.

Review the Entra grants, Exchange role assignments and any existing application access policies together. Capture their current state before changing them. The migration must remove the unwanted broad route as part of a planned change; adding a scope does not by itself remove another grant.

Create an explicit expected-access table:

Use test data and accounts authorised for the exercise. Do not read an uninvolved employee’s messages merely to demonstrate that a permission was too broad.

Use the diagnostic with a specific resource

After connecting with an appropriately authorised Exchange administrator account, Microsoft provides Test-ServicePrincipalAuthorization for inspecting application RBAC. Replace both quoted placeholders with your test identities:

Test-ServicePrincipalAuthorization -Identity "<application-service-principal-id>" -Resource "<test-mailbox-identity>"

This is a documentation-checked example, not output from your tenant. Include the resource parameter: without a mailbox, the cmdlet does not evaluate that mailbox’s scope membership.

Keep the role, scope and InScope result for each test. A role may be correct while its recipient filter includes the wrong population. Have the mailbox owner review that population in business terms.

Then test the real application path

The diagnostic excludes permissions independently granted through Entra. It also bypasses the permission cache used by live requests. Microsoft documents that permission changes can take between 30 minutes and two hours to settle, depending on recent application use.

That makes the diagnostic a useful check, but an incomplete acceptance test.

Run the agreed read-only operation using the application’s own configured identity and credential path. Do not use the administrator’s delegated session as a substitute. Keep sensitive content out of the test record; status, target identity and a harmless known test value are usually more useful than a mailbox dump.

Repeat for the allowed and excluded mailbox after propagation. If the excluded test succeeds, stop rollout and reconcile the grants. If both tests fail, check authentication, the required operation and scope separately before widening anything.

Keep the scope correct after deployment

Assign an owner to the mailbox population and the integration identity. A filter based on a mailbox attribute is only dependable if someone maintains that attribute when people or services move.

Include a removal test in the next review. Confirm that a mailbox removed from the approved population actually loses access after the change settles. Also review credential ownership and the supplier’s ongoing need for each operation.

Add the resulting evidence to the OAuth application consent audit: intended purpose, effective scope, successful allowed test, successful denial test and review owner.

References

• Microsoft — Role Based Access Control for Applications in Exchange Online. Accessed 17 October 2026.
• Microsoft — Test-ServicePrincipalAuthorization. Accessed 17 October 2026.
• Microsoft — Application-only access in the Microsoft identity platform. Accessed 17 October 2026.