Policies to Safely Enable External Sharing & Guest Access in Microsoft 365

We’ve previously seen guidance from Microsoft and the community telling us to simply turn on external sharing in Microsoft 365 because its “safer” than not.  Those arguments often (not always) hinge on points about getting visibility on where and how people share content externally and that it’s better than users simply (and blindly to the org) emailing documents as attachments.  Although these points are valid and important, I feel that they are a little too all-encompassing and often miss key points about data protection.  In this blog I’m sharing some of my common recommendations for safely, securely and confidently enabling external sharing and guest access in Microsoft 365. 

IMPORTANT: These recommendations may not work for everyone’s environment and you should test them in your own tenant to ensure they meet your requirements before rolling them out org-wide to Production – they may not work in all scenarios or use cases, and your mileage may vary.

Data protection is not about closing every possible hole or avenue in which someone might share content externally or in which content might leave the org.  Its not about locking everything down. Its also not about opening everything up simply so you can have visibility.

Data protection is about understanding your risks, reducing your risks, making decisions about which risks you’re willing to accept and putting in place controls/measures to help you mitigate risks that you are not willing to accept. Its also about putting in place protocols and tools to monitor and regularly assess your risks over time.

As a result, safely enabling external sharing and guest access in Microsoft 365 is more subtle than simply turning it on.  It requires understanding the risks and understanding the controls you have available in the platform.  It requires enabling and managing those controls according to your policies, regulations and risk tolerance. Organizations can enable controls so that they’re confident in how, where, when and who is sharing content externally or collaborating with external guests.

Leverage Controls at the Team/Site Level

When external sharing and guest access is enabled, I like to think of it at a Microsoft Team or SharePoint Site level because this level provides a built-in method for managing “owners” of the space through the associated M365 Group, and the site provides hard security boundary between other sites. 

This means that if a user or business group needs a new space to share externally or to collaborate with external guests, they get a new Microsoft Team or a SharePoint Site so that we can leverage those built-in controls.  For me, it also means that if that internal group needs to share or collaborate with multiple external partners, and those partners should not access each others content, then a different Team or Site is created for each external partner.

When dealing with external business partners in a B2B capacity, creating a separate Team or Site for each external partner is often feasible depending on if a hard separation between partners is needed.  However, in a B2C scenario, where the organization may have a very large number external customers, this may or may not be feasible – in this case you might need additional controls at the library or folder level.  I often try to avoid this, but I have seen it be necessary.

Overall, designing the Information Architecture that you are going to use define an external partner or customer’s “space” is important. Some important questions to consider are:

• Am I using Microsoft Teams, SharePoint Sites or both for external sharing spaces?
• Do I create a new Team or Site every time I need an externally shared space with a new audience?
• When a request for an externally shared Team or Site is submitted, assuming you have a Team/Site request process, does it need to go through an approval process?  Who approves?
• If you want to create a default structure within the space, what type of library, list or folder structure within the Site should I have by default?
• What type of permissions should be assigned, both for internal and external users, of the space?
• What affect will sensitivity labels that are already applied to files which are uploaded to the space have on the end user experience?  Will be external users be able to easily open them or will they be blocked?

Categorizing your Teams and Sites with Sensitivity Labels

This section builds on a recent blog I published called Protect your Collaboration Spaces with Sensitivity Labels which you can find here:  https://antonio365.com/protect-your-microsoft-365-collaboration-spaces-with-sensitivity-labels/.

As I’ve blogged about before, I highly recommend using a Team/Site level Sensitivity Label to:

• Identify the spaces that are shared externally and with guests, and
• Automatically enforce the organizations security controls on that space

Sensitivity Labels for Teams and Sites are sometimes called labels for M365 Groups because many of the controls are enforced at the group level, but users really feel the impact of these labels on our Teams and Sites, which is why I use that terminology.

Firstly, you need to choose display names for the Sensitivity Labels you are going to apply to your Teams and Sites.  This could be a blog in and of itself, but I’ll try to paraphrase my recommendations here:

• Some organizations feel they should use the same labels for Teams and Sites that they do for emails and documents.  I tend to disagree, especially if one of the key purposes of those spaces is to share externally.  Calling a space “Confidential” tells you that you should store information classified as Confidential or lower there, but it tells you nothing about if that space can be shared externally or you can or if you should invite guests into it.  Yes, you can and should use communications and change management methods to inform users of that, but I feel we can make it more obvious by picking a different name for the label assigned to a space.  Personally, I like to have a different set of labels for my Teams and Sites than I do for Emails and Document.  There might be some overlap, but not 100%.  Some of my favorite labels are:
  • Emails and Documents
    • Public
    • General
    • Confidential
    • Highly Confidential (or Restricted)
  • Teams and Sites
    • Internal (Alternative: Internal Use Only)
    • External (Alternative: External Collaboration)
    • Confidential
    • Restricted
• Financial organizations will sometimes use the term “Data Room” when creating a space that is intentionally shared externally with customers or partners, where sensitive data may be legitimately shared.  A consulting company might call such a space a “Client Room” or “Partner Room) if they are inviting their external clients or partners to collaborate.
  • I like these words because, as long as you’ve educated your internal users, it is different from an internal collaboration space and it immediately tells internal users that its a space that is shared externally and they should be careful with what they share within it.
• If you configure different labels for Teams and Sites than those which you use for Emails and Files, you need to consider how are users going to relate to the 2 sets of labels.
  • User Education – How will you educate users on what the different labels mean to the organization?  This is critical to a successful rollout.
  • Order your Labels Correctly & Consider the Classification Mismatch Email – Sensitivity Labels have a priority “Order” in Microsoft Purview Information Protection.  Remember, the higher the order number the more sensitivity label to the organization.  The order is based on the order in which they are listed in the configuration page, and Admins can move them up and down in their priority. 

• By default, if a user uploads a higher classified document to a lower classified space (for example, if I upload a Confidential document to a Public space) this action is not blocked.  The action however is added to the Microsoft 365 audit log with the action name “Detected document sensitivity mismatch”.  As well, the user who uploaded it and the site admin will receive an automated email telling them they may have a “Classification Mismatch”.  You cannot customize the content of this email, other than a troubleshooting hyperlink contained within.  I tend to recommend turning off this Classification Mismatch email, depending on the organization, as it can result a numerous false positives and confuse users – you can turn it off through PowerShell:

Set-SPOTenant -BlockSendLabelMismatchEmail $True

Policies to Safely Enable External Sharing and Guest Access

These are the policies I often suggest as controls for externally shared Teams or Sites, most of which can be configured through a combination of Sensitivity Labels applied to a Teams/Site as well as Conditional Access policies. Again, please keep in mind these recommendations might not fit every situation, policies or business use cases, and they may not work be right for your business. Please validate them in your environment before you move ahead with them in Production.

1. Require that externally shared spaces are “Private” so that only Team owners and members can access the space. 
   • As a result, new users must be invited in by owners.
   • If you are going to have externally shared Teams or Sites, I always recommend that any new members, including internal ones, should be invited in by owners as opposed to being able to discover and add themselves on their own.

2. Enable Microsoft 365 group owners to add external guests to the space. 
   • I often do not recommend that the ability to add external guests be centrally controlled by IT , due to the burden this can place on an IT team and the lack of ownership it gives to the business owners of the space.  I prefer that group owners be business users that understand the usage and intent of the space, that those owners are educated/trained on their responsibilities to the organization and that they understand how to manage external guests responsibility in the spaces that they own.
   • In my opinion, if you’re going to be a Team/Site owner, you should understand your responsibilities for that space.

3. Enable external sharing from a SharePoint Site with the setting “New and existing guests”.
   • I never recommend enabling external sharing with “Anyone” links as these are anonymous guest links and anyone you forward the link to can access the file or folder to which it is shared.  This goes way beyond my risk tolerance.
   • I often don’t often recommend “Existing guests” here because it usually centralizes the addition of external guests to your Azure AD and it means you need to have some other process to request new guests.
   • And the final option here is “Only people in your organization” which disables external sharing for the SharePoint space.

4. Require that external users accept a Terms of Use policy when they access the externally shared space.
   • You can decide how frequently you want them to accept it, but I tend to recommend every 3 months.
   • This serves as a means of informing guests on their responsibilities when they are accessing this shared space and requiring them to accept those terms.

5. Require that external users always use MFA to access the space. This helps to protect users and the organization if a user’s username and password are stolen or compromised.

6. Limit an external user’s experience in the space to a web browser only.
   • This means that they can only access documents through a web browser (through online versions of Word, Excel and PowerPoint) and they cannot download documents to devices that are personal or not corporate managed devices. 
   • This means that they can view and edit documents, but they cannot access them through the desktop or mobile versions of those apps. 
   • It also means that sensitive data does not stay resident on those personal devices after the user’s session is done.

7. When sharing a SharePoint Online Site with external guests, if the Site contains sensitive information (for example, PII or PCI data) then consider using a Site Access Restriction Policy to restrict access to only members of the Microsoft 365 Group which is associated with the site.
   • The Site Access Restriction policy is a new capability that is part of Microsoft Syntex – SharePoint Advanced Management. You can learn more about that how to use it at my blog here: Govern and Secure SharePoint and OneDrive with Microsoft Syntex – SharePoint Advanced Management.
   • If you are going to make use of this policy, your external guest users must be added to the M365 Group which underlies the Site to continue to have access. Once this policy is enabled, any users with permissions to the Site (both internal and external, both current permissions and future permissions) will no longer have access to the Site if they are not part of the M365 Group.
8. Configure session timeouts for Guest users so that they must re-authenticate on a regular basis. 
   • I would usually recommend once per day.

9. Configure Microsoft Purview Data Loss Prevention (DLP) policies to specifically address external sharing use cases.
   • Configure DLP policies in Microsoft Purview which inspect the sensitivity label assigned to documents/emails and at minimum monitor/alert cybersecurity when your most sensitive content is shared externally.
   • Depending on your policies, you may want to configure DLP policies to block external sharing of your most sensitive content.
10. Configure access reviews for Guest users on some regular basis. 
    • This is a highly recommended control so that your team and site owners stay on top of the guests that they have invited into their spaces. 
    • I usually recommend that team and site owners are responsible for performing a quarterly review of guests that they invite into their spaces.

11. Review the External Access setting in Microsoft Teams (which is different from Guest Access) and set it either to ‘Allow only specific external domains’ or ‘Block all external domains’.
    • This setting allows external users to chat with your internal users over Microsoft Teams.
    • I never recommend ‘Allow all external domains’ due to inherent risks of attack such as this recent attack vector: Navy red team exposes Teams security flaws | PCWorld.
    • If you are going to enable only specific external domains to chat with your internal users, build and enable a process by which internal users can request a new external domain and that appropriate internal approvals are given before they are added. Also, review the list of domains regularly (at least annually) and remove domains that ar eno longer utilized or needed.
12. Review the Microsoft Teams capabilities that are available for Guest Users in the Teams Admin Center, and determine which you ones you want to enable or disable for Guest users.
    • The following settings are available

13. Finally, I also recommend learning and understanding the capabilities that are and are not inherently available to guest users in Microsoft Teams.
    • Microsoft has a great table available here:  Comparison of Team member and Guest capabilities.

External sharing and guest access in Microsoft 365 is a great collaboration capability that helps us to reduce duplicating content, have more visibility on content which is shared externally, helps us get to the content we need more quickly and helps us work together more efficiently. There are of course inherent risks, but Microsoft has built significant controls and capabilities to help reduce those risks. Understanding and utilizing those capabilities to reduce those risks can help us to safely and confidently enable external sharing and guest access in Microsoft 365.

I hope you found this blog helpful in understanding what those controls and capabilities are and how you can use them.

-Antonio