What this check looks at
Checks what guest users can see in the directory: the same as members, limited, or only their own objects.
Entra ID gives guest users one of three levels of access to the directory. Same as members lets a guest browse users, groups and memberships like an employee. Limited access, the default, stops guests listing users and groups but still lets them look up people they know about and see memberships of groups they belong to. Restricted access limits guests to the properties and memberships of their own directory objects.
The check fails, at high severity, when guests have the same access as members, warns at low severity when they have the default limited access, and passes only at the most restrictive setting.
Every guest account is protected by someone else’s security. When a partner’s account is compromised, the attacker inherits whatever that guest can see in your tenant. With member-level access they can download the full staff list with job titles, managers and group memberships: everything needed to target finance staff or impersonate a director convincingly.
Why it matters
A guest with member-level access can list every user, group and their membership, which hands an attacker who compromises any partner account an organisation chart and a phishing list.
Supply-chain compromise is common among small UK firms: an accountant’s or consultant’s mailbox is taken over, and the attacker looks for useful access. A guest account with directory visibility hands over an organisation chart and a ready-made phishing list for the client, and the phishing then arrives from a trusted partner’s real address.
The directory also holds personal data (names, job titles, phone numbers), so exposing it to people outside the organisation without need sits badly with the UK GDPR principle of data minimisation. Guests keep working in the teams, sites and files shared with them under the restricted setting.
The CIS Microsoft 365 Foundations Benchmark (5.1.6.2) and the CISA SCuBA baseline (MS.AAD.8.1v1) both ask that guests do not have the same directory access as members; this check, like the strictest reading, asks for the restricted option. The NCSC 10 Steps include limiting access to what each person needs under identity and access management.
How to fix it
Where: Entra admin centre → Identity → External Identities → External collaboration settings
Before you start
- Ask whether any guests rely on browsing the directory, for example to look people up; most only need the teams and sites they were invited to.
Step by step
- Check whether any guest needs to browse the directory. Ask the client whether any partner relies on looking people up in the directory, for example to find colleagues in a people picker outside a team they belong to. Most guests only need the teams, sites and files they were invited to, which this setting does not affect.
- Change the guest access setting. In the Microsoft Entra admin centre, go to Entra ID > External Identities > External collaboration settings. Under Guest user access, select Guest user access is restricted to properties and memberships of their own directory objects (most restrictive) and select Save.
- Or make the change in PowerShell. In Microsoft Graph PowerShell, run Connect-MgGraph -Scopes Policy.ReadWrite.Authorization, then Update-MgPolicyAuthorizationPolicy -GuestUserRoleId 2af84b1e-32c8-42b7-82bc-daa82404023b. That ID is the restricted guest role.
- Test with a guest account. Sign in as a test guest, or ask a friendly partner, and check they can still open the team or site they were given, and that searching for other people in the organisation no longer lists the directory.
- Confirm. Reload External collaboration settings and check the most restrictive option is selected. Re-run the assessment: it passes only with that option.
What users will notice
Guests can no longer list users and groups. Teams, SharePoint and files shared with them keep working.
How to confirm it worked
Entra ID, External Identities, External collaboration settings: guest user access is the most restrictive option.
Frameworks and controls
This check maps to controls in 15 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.c Privileged user management |
| DSPT | Standard 4: Managing data access |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | PA-7 Follow just enough administration (least privilege) |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 7.2.2 Access is assigned by job function with least privilege |
| NIST SP 800-171 | 3.1.5 Employ the principle of least privilege3.1.2 Limit system access to the types of transactions and functions authorised users may execute |
| CMMC Level 2 | AC.L2-3.1.5 Least PrivilegeAC.L2-3.1.2 Transaction & Function Control |
| ISO 27001:2022 | A.5.15 Access controlA.5.18 Access rights |
| CISA SCuBA | MS.AAD.8.1v1 Guests have limited or restricted directory access |
| CIS M365 | 5.1.6.2 Ensure that guest user access is restricted |
| CIS Controls v8.1 | 6.8 Define and maintain role-based access control (IG3) |
| 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
- Restrict guest access permissions (Microsoft Learn)