Beware: with B2B sharing enabled on SharePoint tenant level, all new provisioned Modern sites are by default open for non-constrained sharing

The governance of B2B sharing of SharePoint Online is setup on 2 levels: at first, on tenant level the SharingCapability must be configured in an enabled state (SharingCapabilities enumeration), otherwise all sharing in the full collection of sites in the tenant will be disallowed / blocked. Also on tenant level, SharePoint admin can configure allowed (whitelisted) and disallowed (blacklisted) domains of invited organizations. On the 2nd level, the SharingCapability of individual site collection must also be configured to same enabled state, to enable sharing of that particular site. Plus also on this level, SharePoint admin can specify both allowed and disallowed domains.

With this 2-step configuration, the inviting organization is enabled with explicit (IT) control on which of the site collections, their business owner(s) can invite (authorize for access) guests of targeted invited partner organizations.

Something to be aware of in this SharePoint Online B2B governance is that on site collection level of Modern / Group-enabled sites, the default setting of the SharingCapability property follows the tenant-configured value. This means that in the situation where sharing is enabled on tenant level, all new provisioned Modern sites by default are also direct configured to allow sharing.

In the 2-step B2B governance process this is not compliant; individual site collections may only be configured for sharing on explicit business request and approval, and potential for identified domain(s) only.

To get back into compliant state, each new provisioned site collection must be configured via an after-step to reset the SharingCapability into ‘Disabled’. This after-step can be executed via Site Designs, or in case a site provisioning solution is used (e.g. PnP provisioning) as post-processing provision step. Another approach is via a scheduled automation job (e.g. Azure Automation, or remote PowerShell).

Note: remarkable is the difference with classic sites: these are by default always provisioned with disabled 'SharingCapability', independent of the setting on tenant level.

Inconsistency within MS Teams External Sharing activation

A special case is with the SharePoint sites that are created underneath MS Teams instances (for the ‘Files’ capability). Also on the tenant level of MS Teams, the external / guest capability is configured. However, there is an inconsistency in the context of the MS Teams B2B configuration when external sharing is enabled on SharePoint tenant level, but not on MS Teams tenant level: the underlying SharePoint sites follow the SharePoint tenant setting, not that of their ‘owning’ MS Teams. The effect is that external guests may be authorized for access to the SharePoint site underneath a MS Teams instance, despite that on MS Teams tenant level external sharing is explicit disabled.

To correct this inconsistency, any of the above sketched set of ‘compliance’ approaches can be applied on the SharePoint sites that are created 'underneath' MS Teams instances.