What this check looks at
Checks the external collaboration setting controlling who may invite guests into the tenant.
Microsoft Entra’s external collaboration settings decide who can invite guests into the directory. There are four levels: anyone in the organisation, including guests and non-admins (Microsoft’s default); member users and users in specific admin roles; only users assigned to specific admin roles, which includes the Guest Inviter role; and no one. Microsoft Graph holds it as allowInvitesFrom on the tenant’s authorizationPolicy.
The check fails when the setting is everyone, so existing guests can invite more guests. It warns when any member can invite (adminsGuestInvitersAndAllMembers), because there is no approval step. It passes when only administrators and Guest Inviters can invite (adminsAndGuestInviters), or when nobody can.
When anyone can invite, guests appear as a side effect of everyday work: a member adds a supplier to a team or shares a file, and a new outside identity lands in the directory with nobody approving it. When guests can invite, one compromised guest account can invite further accounts the attacker controls, a foothold that survives the original guest being removed.
Why it matters
When everyone including guests can invite guests, the external population grows without any approval step and the organisation loses track of who has access to what.
A typical case: a 120-person charity finds its guest count has grown from 40 to 600 in three years, invited by dozens of people for one-off pieces of work. Nobody can say who most of them are. One, a volunteer’s personal Gmail account, still has access to the safeguarding team’s site.
Every guest is an identity the organisation does not manage but has to account for under UK GDPR when it holds personal data. Limiting invitations to a few trained people keeps the guest population small enough to review.
CIS Microsoft 365 Foundations Benchmark 5.1.6.3 and CISA SCuBA MS.AAD.8.2v1 ask that guest invitations are limited to the Guest Inviter role. It also supports ISO 27001 A.5.15 and A.5.16 and PCI DSS 7.2.1 (an access control model is defined).
How to fix it
Where: Entra admin centre → Identity → External Identities → External collaboration settings
Before you start
- Decide who can invite guests: administrators only, or people given the Guest Inviter role.
Step by step
- Decide who will invite guests. Agree a small number of people (one or two per department, or the IT team and the MSP) who will add outside people on request, and how staff ask them.
- Assign the Guest Inviter role to them. In the Microsoft Entra admin centre, go to Entra ID > Roles & admins > Roles & admins, search for Guest Inviter, select it, choose Add assignments, pick the people and select Add. If you use Privileged Identity Management, make the assignments eligible rather than active.
- Restrict guest invitations. In the Entra admin centre, go to Entra ID > External Identities > External collaboration settings. Under Guest invite settings, choose "Only users assigned to specific admin roles can invite guest users" and select Save.
- Or make the change in Graph PowerShell. Connect-MgGraph -Scopes Policy.ReadWrite.Authorization, then run Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom adminsAndGuestInviters.
- Test sharing as an ordinary user. Signed in as a member without the role, try to add a new outside person to a team and to share a file with a new outside address. Where SharePoint uses Entra B2B for sharing, the file share is also refused; make sure staff know to ask a Guest Inviter instead.
- Confirm the change. Run Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom: it should show adminsAndGuestInviters. In the Entra admin centre, Guest invite settings shows the restricted option.
What users will notice
Staff without the role ask an administrator or guest inviter to add external people.
How to confirm it worked
Entra ID, External Identities, External collaboration settings: guest invite restrictions are no longer "Anyone in the organization".
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 |
| Zero Trust | Identities |
| SOC 2 | CC6.2 User registration, authorisation and removal |
| PCI DSS 4.0.1 | 7.2.1 An access control model is defined |
| NIST SP 800-171 | 3.1.1 Limit system access to authorised users, processes and devices |
| CMMC Level 2 | AC.L2-3.1.1 Authorized Access Control |
| ISO 27001:2022 | A.5.16 Identity managementA.5.15 Access control |
| CISA SCuBA | MS.AAD.8.2v1 Only the Guest Inviter role can invite guests |
| CIS M365 | 5.1.6.3 Ensure guest user invitations are limited to the Guest Inviter role |
| 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
- Configure external collaboration settings (Microsoft Learn)