What this check looks at
Checks whether guests can only be invited from a list of allowed domains, rather than any domain.
The external collaboration settings in Entra ID include collaboration restrictions: guest invitations may go to any domain (the default), to any domain except a deny list, or only to an allow list of specified domains. The restriction applies to every new invitation, whether it is sent from Teams, SharePoint or the Entra admin centre.
The check passes when nobody can invite guests at all, or when invitations are limited to an allow list. It fails when guests can be invited from any domain, or from any domain except a deny list, because the CIS benchmark asks for an allow list.
Every invitation creates an account in the directory that can then receive shared files and Teams channels. With no allow list, anyone who can invite can invite any address: a personal webmail account, a mistyped partner domain, or an address an attacker supplied in a convincing email asking for access to the project folder.
Why it matters
Inviting a guest grants a stranger a foothold in the directory. An allow list of partner domains means a mistyped or attacker-supplied address cannot be invited, and every guest belongs to an organisation someone approved.
An attacker posing as a new contact at a client asks a project manager to share tender documents with their "new email address", on a look-alike domain registered the week before. Without an allow list the invitation goes straight through and the attacker has a guest account with access to the files and the team. With one, the invitation fails and the request stands out as unusual.
An allow list also records which organisations the business actually works with, which helps with supplier assurance and with UK GDPR questions about whom personal data is shared with. Its cost is adding a new partner’s domain when one arrives, a few minutes each time.
The CIS Microsoft 365 Foundations Benchmark (5.1.6.1) and the CISA SCuBA baseline (MS.AAD.8.3v1) both ask for guest invitations to be limited to allowed domains. The rule maps to NIST CSF 2.0 PR.AA-05.
How to fix it
Where: Entra admin centre → External Identities → External collaboration settings
Before you start
- List the domains of the partners guests come from today (Entra ID, Users, filter User type Guest) and agree the allowed list.
Step by step
- List the domains guests come from today. In the Microsoft Entra admin centre, go to Entra ID > Users > All users, filter User type on Guest and download the list. Group the guests by the domain of their email address; that is the starting point for the allow list.
- Agree the allowed domains with the client. Go through the domains with the client: keep current partners, suppliers and customers, and drop domains from finished work. Decide what to do about personal addresses such as gmail.com and outlook.com; leaving them off is safest.
- Set the allow list. Go to Entra ID > External Identities > External collaboration settings. Under Collaboration restrictions, select Allow invitations only to the specified domains (most restrictive), enter the agreed domains under Target domains and select Save.
- Review who can invite. On the same page, check Guest invite settings matches what the client wants; limiting invitations to members, or to people with the Guest Inviter role, is common. The check also passes if nobody can invite guests, but most clients need some invitations.
- Set up the route for new partners. Tell staff that invitations to new organisations will fail, and how to ask IT to add a partner’s domain. Add a line to the service desk procedures so requests are checked and added quickly.
- Confirm. Reload External collaboration settings and check the allow list is selected with the agreed domains. Inviting a test address on a domain not on the list should fail. Re-run the assessment to confirm.
What users will notice
Invitations to addresses outside the allowed domains fail. Guests already in the tenant are unaffected.
How to confirm it worked
Entra admin centre, External Identities, External collaboration settings: "Allow invitations only to the specified domains" with the agreed list.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.d Identity and access management (IdAM) |
| DSPT | Standard 4: Managing data access |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | IM-7 Restrict resource access based on conditions |
| Zero Trust | Identities |
| SOC 2 | CC6.2 User registration, authorisation and removal |
| NIST SP 800-171 | 3.1.20 Verify and control connections to external systems |
| CMMC Level 2 | AC.L2-3.1.20 External Connections |
| ISO 27001:2022 | A.5.14 Information transferA.5.16 Identity management |
| CISA SCuBA | MS.AAD.8.3v1 Guest invitations only to authorised domains |
| CIS M365 | 5.1.6.1 Ensure that collaboration invitations are sent to allowed domains only |
| CIS Controls v8.1 | 6.1 Establish an access granting process (IG1) |
| NIST CSF 2.0 | PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Allow or block invitations to specific organisations (Microsoft Learn)