SharePoint: Restrict Page Access Now

Key insights

• Three supported approaches: Use Restricted Access Control (RAC) for site-level lockdown, set unique permissions by breaking inheritance on the Site Pages library or individual pages, or apply audience targeting to hide navigation links and web parts.
  Each method serves different needs: RAC for strict site gates, unique permissions for page-by-page control, and audience targeting for user experience (not security).
• Restricted Access Control (RAC): Enable RAC at the tenant first, then on sites to limit access to specified Microsoft 365 or Entra security groups.
  RAC prevents users outside the configured groups from opening the site even if they had prior permissions, making it ideal for sensitive content and scenarios where search or AI indexing must be restricted.
• Break inheritance and set unique permissions: Pages live in the Site Pages library by default and inherit site permissions.
  To lock a page or folder, open the Site Pages library settings, choose "Permissions for this library," click "Stop inheriting permissions," remove unwanted groups, and add the specific users or groups with View or Edit roles.
• Audience targeting is UI-only: Use audience targeting to hide navigation links or web parts from non-members for a cleaner experience.
  Do not rely on targeting for security: anyone with a direct URL can still access targeted content unless you also restrict permissions.
• PowerShell and admin controls: Turn on tenant RAC with Set-SPOTenant -EnableRestrictedAccessControl $True and enable RAC on a site with Set-SPOSite -Identity "" -RestrictedAccessControl $True (assign groups with -RestrictedAccessControlGroups using group GUIDs).
  Also limit sharing by changing site sharing settings so only owners can share files, folders, or the site.
• Best practices: Combine methods—use RAC for site-wide lockdown, unique page/library permissions for targeted control, and audience targeting for UX.
  Regularly audit permissions, test content access by signing in as representative users, apply least-privilege roles, and document permission changes for administrators.

Dougie Wood [MVP] published a clear, step-by-step YouTube tutorial that explains how to restrict access to pages in SharePoint Online within Microsoft 365. The video walks viewers through page creation, permission management, and practical options for locking down content so only intended users can view or edit pages. Importantly, Wood highlights the differences between site-level controls, page-level settings, and user interface hiding, and he demonstrates each approach with examples. As a result, administrators and site owners can see how theory maps to real-world actions.

What the video covers

First, Wood outlines three supported approaches to restrict access: enable tenant and site-level Restricted Access Control (RAC), apply unique permissions at the library or page level, and use audience targeting to hide links and web parts. Then he shows how pages inherit permissions from the Site Pages library and when you should break that inheritance to set unique rules. Moreover, the tutorial includes practical steps such as changing sharing settings and using PowerShell for tenant or site configuration when required. Together, these demonstrations give a full picture of the available controls.

How the main approaches work

Wood explains that RAC acts as a strict gate at the tenant and site level so only users in designated Microsoft 365 or Microsoft Entra groups can open a site. He clarifies that enabling RAC stops previously-permitted users from entering unless they remain in the configured groups, which is useful for highly sensitive sites. Alternatively, breaking inheritance on the Site Pages library or on individual pages gives granular control, allowing sites to remain broadly visible while protecting specific content. Meanwhile, audience targeting improves the user experience by hiding navigation and web parts, though Wood warns it is not a security boundary.

Step-by-step and practical commands

In his walk-through, Wood shows administrators how to enable RAC at the tenant level using a PowerShell command and then how to apply that setting to individual sites through the SharePoint admin center. He also demonstrates how to stop permission inheritance for the Site Pages library, remove unwanted groups, and add the specific users or groups who should have view or edit rights. Furthermore, Wood covers how to limit site sharing so only owners can invite others, which reduces accidental exposure. These clear examples help administrators adopt changes without guessing the right sequence of steps.

Tradeoffs and challenges

Wood stresses the tradeoffs between broad and granular controls. For example, implementing RAC reduces permission sprawl and protects sensitive content, but it can complicate collaboration and requires careful group management. Conversely, page-level permissions provide precision, yet they increase administrative overhead and can create a maintenance burden if applied inconsistently. In addition, relying on audience targeting improves clarity for end users but does not stop direct URL access, so teams must combine approaches to avoid false security assumptions.

Common pitfalls and administrative advice

He highlights common mistakes such as breaking inheritance too often, which leads to a web of unique permissions that are hard to audit and troubleshoot. Therefore, Wood recommends using groups rather than individual accounts, documenting permission changes, and testing configurations with non-admin accounts before locking sites in production. He also calls out propagation delays after toggling tenant-level settings and the need to use PowerShell responsibly to avoid accidental site-wide impacts. Consequently, careful planning and governance are essential when changing access models.

When to use each method

According to Wood, choose RAC when you need a strict site-level barrier for highly confidential content, and opt for page or library-level restrictions when only certain pages need protection while the rest of the site remains open. If you care mostly about user experience and not strict protection, use audience targeting to hide links and web parts, but pair it with permissions when security matters. Thus, a layered approach often provides the best balance between usability and protection.

Key takeaways for admins

Ultimately, the video gives practical steps and cautions so administrators can make informed choices. Wood’s recommendations emphasize testing, using groups, documenting changes, and applying the least complex model that meets your security needs. Moreover, by combining site-level controls, targeted permissions, and audience targeting where appropriate, organizations can control exposure while preserving collaboration. For SharePoint teams, the result is clearer governance and fewer surprises.

Keywords

restrict access SharePoint page, SharePoint page permissions, SharePoint Online restrict access, Microsoft 365 page access control, limit access to SharePoint pages, manage SharePoint page permissions, restrict editing SharePoint Online, SharePoint modern page access