What is the difference between Exchange Online application access policies and SharePoint Online Sites.Selected permissions?

Why the Difference Matters Operationally

These two controls solve a similar problem, but at different control planes. Exchange Online application access policies govern app access to mailboxes, while SharePoint Online Sites.Selected scopes an app to explicitly approved sites. That means one control limits mailbox reach and the other limits site reach, so the review process, test method and blast radius are not interchangeable.

The practical difference is that Exchange policy decisions are mailbox-centred and include built-in testing, which helps validate the policy before rollout. SharePoint Sites.Selected is site-centred and depends on Graph-based configuration plus manual validation, so the operational burden shifts from policy simulation to configuration discipline and verification.

For a broader view of Microsoft 365 scoping patterns, the Microsoft 365 Application Access Policies and RBAC for Applications Guide shows how application access is narrowed across mailboxes and sites.

How the Authorization Models Differ

Exchange Online application access policies are designed around inclusion and exclusion logic for mailbox groups. That makes them suitable when you want a clear allowlist or denylist model over a defined mailbox population, especially for mail access patterns that need central review and predictable scoping.

Sites.Selected uses a more granular resource authorization model. Instead of granting broad tenant-wide site access, you approve only the specific SharePoint sites the app should touch. That is useful when the app must work across a small set of sites, but it also means each new site requires an explicit approval step.

If you are comparing these controls inside a wider Microsoft 365 access design, Exchange Online Security Guide is the best starting point for mailbox scoping, while SharePoint and OneDrive Security Guide covers the SharePoint side of app permissions and oversharing controls.

When the app needs a mailbox permission model that is easier to simulate and validate centrally, Exchange is usually simpler. When the app needs only a small set of explicitly approved sites, Sites.Selected is usually the tighter fit. The distinction matters because mailbox scope and site scope can look similar in a permissions inventory while behaving very differently in practice.

What to Validate Before You Grant or Approve Access

In Exchange, the key check is whether the app really needs mailbox-level access to a named group of mailboxes, or whether the use case can be narrowed further. In SharePoint, the key check is whether each approved site is truly required and whether the app should be blocked everywhere else by default.

• Confirm the target object type first: mailbox in Exchange, site in SharePoint.
• Verify whether the app should be allowed broadly with exclusions, or denied broadly with a short approval list.
• Test Exchange policy behaviour before production cutover, then manually validate SharePoint site grants through Graph configuration and observed access.
• Review whether the app permission set still matches the business use case after site or mailbox changes.

For teams managing app scoping at scale, the How to find high-privilege Microsoft Graph application permissions article helps identify when an app has drifted beyond its intended scope.

Risk and Threat Considerations

Both controls are about reducing overreach, so the main risk is scope drift: an app that was meant to touch a narrow mail or site set ends up with wider access than the business intended. The failure mode is different in each service, but the outcome is the same, unauthorized visibility or action across data the app should not reach.

Failure mechanism: Exchange policy misconfiguration can leave an app able to reach too many mailboxes, while SharePoint Sites.Selected misconfiguration can leave an app approved for sites that were never meant to be in scope. In both cases, weak change control or incomplete validation turns a least-privilege design into de facto broad access.

Impact: Excessive mailbox or site access increases exposure to data leakage, mailbox abuse, and unauthorized content collection. If the app is compromised, the scope boundary becomes the blast radius boundary, so a small approval mistake can become a tenant-wide investigation.

Practitioner Guidance

What to verify: Check whether your app governance process treats mailbox scope and site scope as separate approval paths. They should not share the same sign-off logic unless the control owner can prove the validation method is equally strong for both services.

Decision rule: If the application needs to read or process mail, use the Exchange scoping model and validate it with policy testing. If the application needs only a bounded set of SharePoint sites, use Sites.Selected and require explicit approval for each site rather than relying on implied inheritance.

Practitioner takeaway: The safest design is the one that matches the object being protected, because mailbox scoping and site scoping fail in different ways and must be validated with different operational evidence.

Related resources from NHI Mgmt Group

• Sites.Selected
• What is the difference between application permissions and application access policies in Exchange Online?
• What breaks when Exchange Online app permissions are left without an application access policy?
• Why do tenant-wide app permissions create more risk than scoped access in Exchange and SharePoint Online?