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

Exchange Online application access policies constrain an app at the mailbox level and can either allow a defined group or deny a defined group. SharePoint Online uses Sites.Selected to grant an app access only to specific sites that are explicitly approved. Exchange provides built-in policy testing, while SharePoint relies on Graph-based configuration and manual validation.

Mailbox Scoping Versus Site Scoping

Exchange Online application access policies and sharepoint online Sites.Selected solve a similar governance problem in different places. Exchange is about whether an app can reach mailboxes, so the policy is evaluated against mailbox membership and can either permit or block a defined set. SharePoint is about whether an app can reach specific sites, so access is granted only after each site is explicitly approved.

The practical difference is the trust boundary. Exchange policies are strongest when the sensitive unit is the mailbox and the organisation wants a central allow or deny decision. Sites.Selected is stronger when the sensitive unit is the site collection and the organisation needs per-site approval before the app can act. In both cases, the app may still exist and authenticate successfully; what changes is where authorisation is narrowed.

For teams managing non-human identities, the distinction matters because coarse app registration control is not the same as resource-level restriction. One policy can limit mailbox access without telling you anything about SharePoint site access, and the reverse is also true. In practice, many security teams discover this separation only after an app has already been granted more resource reach than intended.

How the Controls Work in Practice

Exchange Online application access policies are typically used when a daemon app, integration, or service principal must access only a subset of mailboxes. The organisation defines the target group and then tests whether the app is permitted or denied. That built-in validation is useful because it lets administrators confirm policy behaviour before relying on it operationally. The model still depends on clean group membership and disciplined app registration ownership, because a policy is only as narrow as the mailbox set it actually covers.

SharePoint Online OWASP Non-Human Identity Top 10 guidance is relevant here because this pattern is fundamentally about limiting machine access to a specific resource surface. Sites.Selected requires explicit site-by-site approval through Graph-based configuration, which is more manual but also more precise. It is often used when the app should interact with only a small number of collaboration sites rather than an entire tenant-wide content area.

That difference changes administration. Exchange can be validated as a policy decision, while SharePoint often needs a separate approval workflow, configuration step, and post-change check to confirm that the app can reach only the intended sites. When those controls are mixed up, teams may think they have created least privilege when they have only reduced access in one workload. NHIMG’s NHI lifecycle guidance is useful because this is a lifecycle problem as much as an access problem: approval, review, and revocation all have to be handled per workload, not just per app registration. Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

Use Exchange application access policies when the control objective is mailbox boundary enforcement.
Use Sites.Selected when the control objective is explicit approval for a small set of SharePoint sites.
Verify that the app’s granted scope matches the business workflow, not just the tenant owner’s expectation.

These controls tend to break down in large, fast-changing environments because membership drift, site sprawl, and duplicate app registrations make it easy to lose sight of the actual access path.

Where Teams Misread the Difference

Tighter scoping often increases administration overhead, so organisations have to balance precision against operational friction. Exchange policies are sometimes treated as if they automatically protect SharePoint content, but they do not. Sites.Selected is sometimes treated as if it protects all Microsoft 365 content for the app, but it only governs approved SharePoint sites. Those are separate authorisation planes, and the app can be restricted in one while still being overexposed in the other.

The most common mistake is assuming that “app restricted” means “app safe.” An app can still carry excessive privilege, use long-lived credentials, or remain approved for more resources than necessary. NHIMG research shows that excessive privileges are widespread across NHIs, which is why resource-specific scoping should be paired with ownership review and periodic revalidation rather than treated as a one-time setup. Ultimate Guide to NHIs

Another edge case is exception handling. If a workload genuinely needs both mailbox and site access, teams should document those approvals separately so they can revoke one without breaking the other. That separation becomes especially important during incident response, when the first question is often which resource plane needs to be cut off immediately.

Risk and Threat Considerations

The main risk is overbroad machine access across two different Microsoft 365 resource planes. If mailbox and site authorisation are confused, an app can retain more access than intended even after one control is tightened, which increases the blast radius of compromise or misuse.

Failure mechanism: Attackers or abusive insiders typically exploit granted app permissions rather than bypassing the policy itself. If a service principal has wider mailbox scope than expected, or if Sites.Selected approvals are left broad or stale, the app becomes a trusted path into content that defenders believe is protected.

Impact: The result can be unauthorised mailbox reading, sensitive document exposure, and delayed revocation because teams assume a single policy layer covers both services when it does not.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Mailbox/site app access depends on machine identities and their granted scope.
	NHI-03 — Privilege and Access Management	The question is about constraining non-human access to specific resources.
Recommendation — Scope app credentials to the minimum mailbox or site access needed. Apply least privilege to each app grant and separate mailbox from site approval.
CIS Controls v8	6 — Access Control Management	This compares two resource-specific access control mechanisms for apps.
Recommendation — Review and revoke unnecessary app access paths on a workload-by-workload basis.
NIST CSF 2.0	PR.AC-4 — Access Permissions Management	Both controls manage how applications are authorised to specific resources.
Recommendation — Enforce resource-level permission reviews for each app and service boundary.
MITRE ATT&CK	T1098 — Account Manipulation	Abuse of granted app permissions can be used to expand or retain access.
Recommendation — Hunt for suspicious changes to app permissions and delegated resource access.

Practitioner Guidance

What to prioritise: Treat Exchange and SharePoint as separate approval and review paths. If the app touches both workloads, validate each path independently and do not let one control be used as evidence that the other is narrow enough.

What to verify: Confirm the exact protected object, not just the app registration. For Exchange, verify the mailbox group and policy outcome; for SharePoint, verify the specific site grants and who approved them. The control is only trustworthy when the granted scope can be named precisely.

Decision rule: If the business requirement is mailbox-centric, use Exchange application access policies; if it is site-centric, use Sites.Selected. If the app needs both, accept that you are managing two distinct blast radii and document revocation steps for each.

Practitioner takeaway: Least privilege here is not “one Microsoft 365 restriction,” but two different resource-scoping decisions that must stay aligned with how the app actually behaves.