Sites.Selected

Expanded Definition

Sites.Selected is a SharePoint Online authorization model that narrows an application’s access to only the sites that have been explicitly granted. It is best understood as a site-scoped permission boundary, not a general SharePoint identity model. The practical effect is to replace tenant-wide reach with discrete approval per site, which materially changes how app consent is reviewed, documented, and revoked.

This matters because the term is often mistaken for a simple convenience setting. In practice, it is a control choice about blast radius: the application can still be powerful, but only within the approved site set. That makes it especially relevant where administrators want to keep application access aligned to business need without assuming that every app should inherit broad SharePoint visibility. The model is narrower than tenant-level access and more operationally specific than generic “least privilege” language.

Microsoft documents the broader SharePoint permission patterns in its own guidance, and the distinction is important because site approval is the unit of control here, not the user, group, or tenant. For a security team, the boundary to watch is whether approval remains site-specific in practice, or whether repeated exceptions recreate the broad access pattern it was meant to replace.

Examples and Use Cases

Sites.Selected commonly appears when an organization needs an application to operate on only a few SharePoint sites instead of all content in the tenant. The implementation tradeoff is straightforward: tighter scope usually means more administrative coordination, but it also gives clearer ownership over where the app can read or write.

• A records-management application is approved for a single departmental site that contains its working documents.
• A reporting integration can read data from a project site without seeing unrelated collaboration spaces.
• An automation service is granted write access only to a controlled publishing site used for approved content updates.
• A migration tool receives temporary access to a defined set of sites during a transition, then is removed afterward.
• A security review rejects tenant-wide app access and instead approves site-by-site scope because the business need is limited.

For teams governing applications, the key use case is not just access reduction. It is creating a reviewable permission inventory that maps app purpose to specific content locations, which makes access decisions easier to justify and easier to retire when the use case ends.

Security Implications

Misunderstanding Sites.Selected can leave organizations with a false sense of containment. If an app is approved broadly by habit, or if site approvals are expanded without review, the model stops delivering its main benefit: limiting what a compromised or over-permissioned application can reach. That can turn one application trust decision into a tenant-wide exposure problem.

In SharePoint environments, the most visible failure condition is privilege creep. Over time, the app’s approved site list may expand beyond the original business purpose, or approvals may persist after the integration is retired. When that happens, sensitive content that was assumed to be isolated can become reachable through a still-active app pathway. This is especially important for automation and document-processing services, where access is often granted once and then left in place.

NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, a reminder that app access paths are often less visible than human permissions. In that environment, scoped authorization is only effective if the approved set is continuously known and reviewed.

Domain and Governance Relevance

Sites.Selected matters in identity and access governance because it is a machine-access boundary, not a user-experience feature. Security teams use it to make application authorization more explicit, more reviewable, and easier to align with ownership of the underlying site. That shifts the governance question from “does this app need SharePoint?” to “which exact sites does this app need, and who approves that scope?”

In NHI-heavy environments, that distinction is operationally important. Applications, service principals, and automation workflows often accumulate standing access that humans never revisit. A site-scoped model helps reduce that drift, but only if site approval, periodic recertification, and removal after use are treated as part of the access lifecycle. The control is therefore strongest when paired with clear ownership and a removal process that matches the business lifecycle of the integration.

For practitioners, the real value is governance clarity. Sites.Selected does not eliminate access risk by itself, but it gives security teams a narrow, auditable unit for managing application reach across SharePoint content.

Related resources from NHI Mgmt Group

• Why do identity governance projects stall even after the platform is selected?
• How can teams keep remote access auditable across many customer sites?
• How should health systems govern shared care record access across multiple sites?
• How should organisations govern access when shared workflows span multiple trusts or sites?