How It Works

1. On the Hub site
   The hub owner enables the feature and designates who the “Hub Visitors” are (individuals or groups).
   These people receive Read access to the hub itself and become eligible to receive Read access on associated sites that opt in.
2. On each Associated site
   The site owner (or admin) decides whether to accept the sync.
   If accepted, the Hub Visitors group is added to that site with Read permissions.
3. Result
   Users in the Hub Visitors group can browse the hub and any associated sites that have opted into the sync. Sites that do not opt in remain private (only users with direct permissions can access them).

Steps to Enable Hub Permission Sync

Step 1: Enable on the Hub Site

1. Go to the hub site.
2. Select Settings (gear icon) → Site permissions.
3. Select the Hub tab/pivot.
4. Toggle Sync hub permissions to associated sites to On.
5. Add up to 10 individuals or Microsoft 365 / security groups as Hub Visitors.
6. Save.

Recommendation: Prefer Microsoft 365 Groups or security groups rather than individual users for easier long-term management.

Step 2: Accept on Each Associated Site

1. Go to the associated site.
2. Select Settings → Site permissions.
3. Select the Hub tab.
4. Toggle Sync hub permissions to this site (or similar wording) to On.

You can turn this off at any time on an individual site without affecting other sites or the hub.

Important Notes & Limitations

• Association does not require sync — A site can be associated with a hub without ever enabling permission sync. This is useful for sensitive sites that should appear in the hub navigation/search but remain restricted.
• Only Visitors are synced — There is no built-in way to push Members or Owners from the hub to associated sites.
• Hub Visitors group — When the feature is active, a SharePoint group named Hub Visitors appears in the advanced permissions of the hub and of any synced associated sites.
• Security trimming still applies — Even with sync enabled, users only see content (news, web parts, search results, etc.) they have permission to view on each individual site.
• Not hierarchical like classic subsites — Permissions do not flow the other way (associated site → hub).

When to Use (and When Not To)

Good use cases:

• Departmental or project hubs where most content is meant to be broadly readable.
• Intranet scenarios where you want a consistent “everyone can browse” experience across related sites.
• Reducing the administrative burden of granting the same Read access repeatedly.

Avoid or use carefully when:

• Associated sites contain sensitive or restricted content (site owners can simply refuse to sync).
• You need to sync Contribute/Edit/Owner permissions (this feature cannot do that).
• You want automatic two-way permission inheritance.

Related Behaviors

• When a site is disassociated from the hub, any Hub Visitor permissions granted via sync are removed from that site.
• Updating the list of Hub Visitors can take up to 4 hours to fully propagate.
• The feature is independent of hub-to-hub associations (parent/child hubs).