External collaboration settings: keeping guests in check in Entra ID
Inviting a partner into Teams takes seconds. Behind that action, a guest account is created in your directory, with read rights that depend on settings few people ever look at. External collaboration settings determine who can invite, who can be invited and what a guest can see.
What a guest can see
The first setting is guest user access restrictions. There are three levels:
| Level | Effect |
|---|---|
| Same access as members | The guest can enumerate the directory like an employee. Avoid. |
| Limited access to properties and memberships of directory objects | The default: the guest cannot freely enumerate users and groups, but keeps some read access. |
| Restricted to properties and memberships of their own directory objects | The most restrictive: the guest only sees what concerns them. |
The most restrictive level suits most organisations. Test it against your Teams and SharePoint scenarios before rolling it out, and check the current Microsoft documentation for any functional limitations.
Who can invite
By default, anyone in the organisation can invite guests, including guests themselves. The options go as far as limiting invitations to holders of specific admin roles, such as Guest Inviter, or blocking them entirely.
The right choice depends on how you collaborate. A common compromise is to let members invite, prevent guests from inviting, and wrap invitations in a process with an internal sponsor. If external sharing in SharePoint, OneDrive and Teams is wide open, remember that those services can also trigger invitations.
Domain allow and deny lists
Collaboration restrictions let you either allow invitations to any domain (the default), deny a list of domains, or allow only a list of domains. Only one approach can be active at a time.
- An allow list is the safest but needs upkeep: every new partner has to be added.
- A deny list is mostly used to block consumer email providers or competitor domains; it is easy to get around.
Cross-tenant access settings. Domain lists are only part of the picture. Cross-tenant access settings let you configure inbound and outbound B2B collaboration organisation by organisation, and decide whether you trust MFA or device compliance from the home tenant.
Email one-time passcode
When a guest has no Entra ID account, no Microsoft account and no configured federation, they can sign in with a passcode sent by email. This is on by default in recent tenants. It avoids unmanaged accounts being created, but the guest account's security then depends on their mailbox. Require MFA for guests through Conditional Access: they will register it in your tenant.
Additional settings
- Guest self-service sign-up through user flows, to be turned off if unused;
- Whether external users can leave the organisation on their own;
- A Conditional Access policy dedicated to guests and external users;
- Regular access reviews of guests, covered in a separate article.
In the tenants we audit, guests often keep the default access level and can invite other external users themselves.
What an audit checks
- The guest user access restriction level.
- Invitation rights and assignments of the Guest Inviter role.
- Domain-based collaboration restrictions and cross-tenant access settings.
- The state of email one-time passcode and self-service sign-up.
- Whether a Conditional Access policy requires MFA for guests.