Microsoft 365 guest access review is the Type II problem hiding in SharePoint links and Teams. A partner was invited for a project, added to a security group that gates a site, and never removed. Entra ID (Azure AD) B2B guests accumulate because invitation is easy and offboarding stops at the employee's IdP. Auditors sample guests. A screenshot of "we have guest access enabled" is not the control.
Rutagon builds a campaign that lists guests, last sign-in, group and Team membership, a named owner, and a revoke that actually deletes or disables the guest. Microsoft documents guest access, access reviews, and Graph APIs for this population (Microsoft Entra B2B). We do not administer your tenant as a product. We do not claim Rutagon holds a SOC 2 attestation. We make the guest population sampleable across the observation window.
Why Guests Survive the Window
Guests are not in the HRIS join that makes employee reviews work. There is no termination date unless someone put one on the invitation. Group owners change jobs. A SharePoint "anyone in the org plus guests" link outlives the channel it was meant for. Entitlement Management and Microsoft's built-in access reviews help when you turn them on and complete them. Mid-market tenants often have the feature and an empty last-run date.
NIST SP 800-53 Rev. 5 AC-2 still wants accounts reviewed and removed when they are no longer required (NIST SP 800-53 Rev. 5). A guest account is an account. CC6.2 does not say "employees only."
Stale guests are also a data-path. A guest in a Team with files is standing access to customer or employee content. Last sign-in of 400 days is not "they might come back." It is a revoke candidate with an owner exception if a contract says otherwise.
Microsoft 365 Guest Access Review We Ship
We snapshot via Microsoft Graph:
- Users with
userType eq 'Guest' signInActivitylast successful sign-in- Transitive group membership and Team roles
- Invitation / redeemed status
- Sponsors or owners if you populated them
def guest_row(user, memberships, signin):
return {
"id": user["id"],
"mail": user.get("mail"),
"created": user.get("createdDateTime"),
"last_sign_in": (signin or {}).get("lastSuccessfulSignInDateTime"),
"groups": [m["displayName"] for m in memberships],
"redeemed": user.get("externalUserState") == "Accepted",
"suggested": suggest_guest(signin, memberships),
}
Suggestions: never-redeemed invitations past a short TTL → delete. Redeemed, no sign-in in the lookback, no named sponsor → escalate then revoke. Redeemed, active sign-in, member of a privileged group (SharePoint admin-adjacent, security group that gates prod docs) → human review, tighter cadence.
Revoke is Graph: remove from groups, then delete the guest user (or disable, if your legal hold says so). A Teams "remove from chat" without deleting the guest leaves the Entra object for the next sample.
This pairs with OAuth app access review and access deprovisioning / joiner-mover-leaver. Capability: security automation. Human campaigns stay in SOC 2 access review evidence shape.
Owners and Auto-Remove
Every guest needs a sponsor. If Entra Entitlement Management or a custom attribute already has one, we use it. If not, we infer from the group owner of the largest membership and we require that human to confirm. Unowned guests do not auto-retain.
Auto-remove is a policy you write down: unused for N days, unused invitation for M days, contract end date if you store it. Microsoft can expire guests natively in some SKUs. We will turn that on when it matches the policy. When the SKU does not, the job we ship is the expiration. Do not tell the auditor you have auto-remove if the tenant setting is off.
Privileged guests — guests in groups that grant admin or finance-site access — get a separate track, same as privileged employees. Monthly, not quarterly.
Type II, Not a One-Time Cleanup
A heroic cleanup the week before fieldwork is Type I energy. Type II needs the job to have run in each period of the window. We seal a quarterly (or monthly) snapshot, decisions, and deletes. If you skip a quarter because "we cleaned last time," guests came back through a new SharePoint link. The pipeline is the control.
We export the sealed artifact into the GRC tool you already run. We do not pitch ripping out Microsoft's access review product. If that product already completes on a schedule and we can pull the decision log, we attach that. If it is a shelf feature, we build the campaign.
Cross-tenant access settings and inbound B2B collaboration restrictions sit next to the campaign. A wide-open inbound policy is how guests appear faster than you can review them. We do not turn the tenant into a fortress on day one. We list the domains you actually do business with and we put a ticket on "any tenant can be invited." That policy change is a separate change ticket from the first guest delete batch.
Teams shared channels and SharePoint sharing links create guests indirectly. The campaign will keep rediscovering them until sharing defaults change. We put that on the diagnostic so the CTO is not surprised when the guest count rebounds two weeks after a cleanup. The review is the backstop. The sharing default is the prevention.
What We Will Not Do
We will not publish a tenant-hardening playbook for attacking B2B. We will not manage your Entra tenant as an MSP. We will show you the guest count, the oldest last-sign-in, and how many have no owner.
See what an Access & Credential Governance Diagnostic finds in your environment →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Does Microsoft 365 guest access review include SharePoint "anyone" links?
Those are a related control, not the same population. Guests are Entra objects. Anyone-links are anonymous or org-wide sharing. We inventory both; we do not pretend a guest campaign closes sharing links.
Can we keep a vendor guest forever?
Yes, as a dated exception with a sponsor and a review cadence. Forever-without-review is the finding.
What Graph permissions does the job need?
Least privilege to read users, sign-in activity, and groups, plus delete or disable on guests. We use an app registration with admin consent you own, not a standing user password. See workload identity for how that app should authenticate into AWS if evidence lands there.
Do we need Entra ID Governance licenses?
They help if you will actually complete Microsoft's reviews. They are not required to snapshot via Graph and revoke. Buy the SKU for the UX; buy engineering for the leftover and the seal.
Will this remove guests from on-prem AD sync?
Hybrid identities need a defined source of authority. We do not delete on-prem objects from a cloud job without that map. The residual is written down.