Fundamentals of External Guest Access to M365

Guide and overview of guest access to M365.

Before you look at how to add external guests to your M365 tenant, let's first look at the basics.

What is Guest access?
Guests are a special category of users and their main attributes are:
  • People who are outside your organisation. They are not "Members" in your Azure Entra and instead have the tag "Guests".
  • They can be added into Azure Entra through the "Invitation" process which requires them to validate themselves and the site they are assigned to access.
  • They are added on request and not automatic. Though this is technically possible, it isn't recommended.
  • Their access is short term.
  • The can have any email and does not need to adopt the email used by your organisation.
From a security point of view, the way we would implement and permit guests into our M365 instance is through the following:

Always require guests to be added through Azure Entra
This means that users should not use the "Share" function on documents unless the guests are already registered in Azure and have both accepted the invitation, and have agreed the terms and conditions of both Microsoft (for using their Cloud), and the company (in using their content).

Guests should be granted access to new Site Collections or Team Sites
This practice keeps departmental and company files completely separate from shared files. This endures a lower risk of data leakage and oversharing. Fresh sites can be created and removed without affecting other content, as well, the Site Owner has more control over who has access in a new site and users are both more visible and more easily purged when the collaboration is completed.

Request for guest access should be through a bespoke form and details vetted.
First, you will want to create a form for end users to submit with the following details.

  • Site Owner (internal staff requesting guest) - Preferably two. At least one of these should be administration staff since the duties are administrative in nature. i.e. adding/removing users.

  • Site Name - Include a suitable prefix to show that these are externally accessed sites. Something like "EXT - ..."

  • Business Justification - The business needs to justify why they are requiring external guests and the nature of the collaboration. Mostly for audits, but also to find out if the request is legitimate or if it could be done by a separate system.

  • Guest Emails and Names - These are needed to add to Azure Entra, and also for confirmations to be sent to their emails during the Invitation process.

  • Duration of the collaboration - How long do you need guests to be active for? This is to help cull expired users at a later date and to prevent overstaying.

  • Classification of the content shared - To flag high risk sharing, though this is the responsibility of the Site Owners who are requesting the site and guests.

  • Will content contain records? - Flag for records or information management teams to retain the site content before site is deleted.

Request for guest access should be approved by Security, Risk and Information teams
Rather than the form become an automatic process, the various teams need to do their due diligence to vet out potentially risky or unauthorised access.

External guests details are vetted through identity and risk screenings
Guests added to your tenant need to go through systems like WorldCheck, LexixNexis and ComplyAdvantage to properly screen guests in case they are Politically Exposed People (PEP), have sanctions against them, have sanctions against their company and/or their country of operation, and other KYC checks.

Best Practices for adding Guests - Security

Though Azure Entra does not natively vet out expired guest, nor does it even produce a basic report for this! However, in order to keep your guest list lean and to maintain a good compliance score, you will want to make the following rules when deciding on how long to keep guests around on Entra and allow them access to your content.

1) Remove guests if they have not accepted the invitation by 1 month (Status = Pending Acceptance) - Many companies actually keep this to 2 weeks, so I'm being overly generous here. Typically, when users are added as guests, their time to complete the invitation process is between 1 hour to 24 hours. The need is urgent, they strike the iron while hot. Anything beyond this indicates non-urgency, but also tells us that the users is unlikely to ever log in. This is just empirical evidence.

2) Remove guests if they have been inactive for more than 6 months - This is with the assumption that guests will generally have a space of time where they will be constantly accessing the system, generally the initial hour to end first week. After this, they will either not require it and I've very rarely had requests to remove guests, so automatic removal after 6 months inactivity just makes sense. Worst case scenario, if users are removed in error, adding them back is very simple but does require the guest to go through the invitation process again.

3) Use the user-filled request form mentioned previously to determine guest deletion dates - Another use of the previous form is to time guest deletions. But this would need to be set manually. If you were to create the previous as a Microsoft Form and combine it with Power Automate to delete automatically, then I would appreciate you sharing the flow with me.

Set expiry dates for your guests

Things to watch out for in terms of granting guests access.

  • During the invitation process, divert guests to the site URL instead of leaving them to go to the default Apps page. it will be empty and likely confuse them.

  • I generally prefer to add guests to SharePoint only sites (non-Teams) since a) the guest may not have the MS Teams app and they will need to download if not b) Guests only need an internet connection and a web browser to access c) Guests who are already members of other tenants will need to "switch over" to the guest tenant which isn't easy for all users and isn't obvious. d) Guests can be put as View Only, whereas Teams requires that all users have Edit rights as a minimum.

  • Guests who have been removed or disabled from Entra are not automatically removed from all sites that they are members. Removal is manual unless you have Tenant Management tools such as ShareGate.

  • Preference to add guests as Members/Visitors to a site as whole, rather than shared to folders/files. This is just for the practicality of managing what guest can see or not see.

  • Known issues include: browser issues (flush cache and/or try a different browser), blank app page (redirect them to actual site), forbidden access error (user in added to Entra but not to the site itself), site does not load or not found on Teams (switch tenant), user cannot access site (invitation not complete, connection issues, java issues, etc).

Caveats

Adding guests to your tenant shouldn't need to be risky. Just keep on top of who has access to what and ensure that your overall guest list is kept as lean as possible.

Microsoft is constantly making changes to the guest access mechanism, including the discontinuation of OTP (one time passcode) method with the MFA (multi-factor authentication) process.

Education and communication for your users and guests will be key, especially for troubleshooting issues with access. Keeping a set of FAQs is also good practice, especially for your first line support to use.

Final thoughts