What this check looks at
Summarises guest accounts, how many are dormant, and how widely they are spread across groups.
A guest is a user object of type Guest in your Microsoft Entra directory, created when someone invites an outside person to a team, a group, a site or an app. It signs in with the person’s own organisation’s account or a personal one, so your password rules, and often your MFA and device rules, do not decide how it is protected. Microsoft 365 never removes guests by itself: they stay, with all the access they were given, until someone deletes them.
The check counts guests and how many have been idle for more than 90 days (the default threshold), using each guest’s last interactive sign-in, or its creation date if it has never signed in. It fails when a quarter or more of guests are dormant, warns when some but fewer than a quarter are, and passes when every guest has signed in within the period. Without sign-in activity, which needs Microsoft Entra ID P1 and the AuditLog.Read.All permission, it reports not checked rather than call every guest dormant.
A dormant guest is access nobody is using but anybody could. If the person’s home account is compromised, or their email domain lapses and is registered by someone else who can then receive the one-time codes, the attacker inherits every team and site that guest was given. Nobody notices the sign-in, because nobody expects that guest to sign in at all.
Why it matters
Guest accounts rarely get removed when a project ends or a supplier contract lapses. Each dormant guest is an external identity, outside your MFA and device controls, still holding access to whatever it was invited to.
A typical case: a marketing agency worked with the business on a rebrand two years ago and five of its staff were added as guests to the Marketing team. The agency has since closed and its domain was bought by someone else, who requests a sign-in code for one of the old guest addresses and opens two years of plans, customer lists and pricing.
The cost is the data exposure itself, a likely UK GDPR breach assessment, and the time it takes afterwards to work out what the guest could reach. Clearing out dormant guests every quarter costs a fraction of that.
ISO 27001 controls A.5.16 (identity management) and A.5.18 (access rights) ask for accounts and access to be reviewed and removed when no longer needed, PCI DSS 7.2.4 asks for user accounts and access to be reviewed every six months, and the NCSC Cyber Assessment Framework’s B2.d asks for the same.
How to fix it
Where: Entra admin centre → Identity → Users → All users (filter: Guest)
Before you start
- Check the dormant guests with the teams that invited them; some are occasional collaborators.
- Set up a quarterly access review for guests so this does not build up again.
Step by step
- Export guests with their last sign-in. In Graph PowerShell, Connect-MgGraph -Scopes User.Read.All,AuditLog.Read.All, then run Get-MgUser -Filter "userType eq 'Guest'" -All -Property Id,DisplayName,Mail,CreatedDateTime,SignInActivity,AccountEnabled | Select-Object Id, DisplayName, Mail, CreatedDateTime, @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}} | Export-Csv guests.csv -NoTypeInformation. Mark everyone with no sign-in in the last 90 days, or none at all.
- Check the list with the owners who invited them. Send each team owner the dormant guests in their teams (Get-MgUserMemberOf -UserId <guest id> shows a guest’s groups). Keep occasional collaborators the owner vouches for; everyone else goes.
- Disable the dormant guests first. In the Microsoft Entra admin centre, go to Entra ID > Users > All users, filter on User type Guest, open each guest and set Account enabled to off under its properties. For many guests, loop over the CSV with Update-MgUser -UserId <id> -AccountEnabled:$false. Disabling first lets anyone who still needs access ask for it back.
- Delete them after a few weeks. Once nobody has asked for an account back, delete the disabled guests (Users > select > Delete, or Remove-MgUser -UserId <id>). Deleted users can be restored from Deleted users for 30 days.
- Set up a recurring access review where Entra ID P2 or ID Governance is licensed. In the Entra admin centre, go to ID Governance > Access reviews > New access review. Choose Teams + Groups, All Microsoft 365 groups with guest users, and Guest users only. Set the reviewers to Group owner(s) with a fallback reviewer, recurrence Quarterly, and under Upon completion settings tick Auto apply results and set "If reviewers don’t respond" to Remove access. Select Create.
- Without P2, schedule the export instead. Put the first step in the MSP’s quarterly checklist. In the SharePoint admin centre, Policies > Sharing > More external sharing settings, you can also tick "Guest access to a site or OneDrive will expire automatically after this many days" so guests’ SharePoint access lapses on its own.
- Confirm the change. Rerun the export: guests idle for more than 90 days should be gone or be the ones owners chose to keep. The next assessment shows the dormant count falling, and the access review appears under ID Governance > Access reviews with its next run date.
What users will notice
Removed guests lose access to shared files and Teams. They can be invited again if needed.
How to confirm it worked
The dormant guest count in the evidence falls at the next assessment, and an access review is scheduled.
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 |
| DORA | Art. 9(4)(c) Limiting logical access to what is required |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | PA-4 Review and reconcile user access regularly |
| Zero Trust | Identities |
| SOC 2 | CC6.2 User registration, authorisation and removal |
| PCI DSS 4.0.1 | 7.2.4 User accounts and access privileges are reviewed every six months |
| 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.18 Access rightsA.5.16 Identity management |
| CIS Controls v8.1 | 5.1 Establish and maintain an inventory of accounts (IG1)6.2 Establish an access revoking 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 dutiesPR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Review guest access (Microsoft Learn)