Ask any Microsoft 365 auditor for their top three risk domains and guest access will be on the list. External collaboration is essential to how modern businesses work — and it is also one of the easiest ways for sensitive data to end up somewhere nobody intended.
This post covers how to audit guest access and external sharing: who can invite, what guests can reach, and which defaults quietly leave the door open.
The two halves of external access
External access in Microsoft 365 is really two related problems:
1. Who can get in (identity side). Guest accounts in Entra ID, who is allowed to invite them, what they can be assigned, and how they are reviewed.
2. What they can reach (data side). SharePoint and OneDrive external sharing settings, link defaults, and site-level overrides that determine what external users — or anyone with a link — can actually open.
An audit has to cover both, because a locked-down identity side with permissive sharing still leaks, and vice versa.
What to check on the identity side
- Guest invite permissions. Can any user invite guests, or is it restricted to admins and designated inviters? The permissive default lets anyone create external identities in your directory.
- Guest inventory. How many guests exist, how many are stale, and who owns them? Unreviewed guests accumulate access.
- Cross-tenant access defaults. Do you allow inbound B2B collaboration by default, or only with named partners?
- Guest access to specific workloads. Which guests can reach Teams, SharePoint, and specific resources?
These map to the identity frameworks — CISA SCUBA's guest-access policy and EIDSCA's external collaboration controls both target exactly these settings. See our EIDSCA page for the identity coverage.
What to check on the data side
- Tenant-level external sharing scope. This is the ceiling: SharePoint and OneDrive sites can be restricted below it, never above. If the tenant allows "Anyone with the link," every site is one setting away from anonymous access.
- Default sharing link type. Are new links internal-only, or anonymous by default? Anonymous defaults make oversharing the path of least resistance.
- Default link permission. View vs Edit. Edit-by-default is an integrity risk.
- Site-level overrides. Sites that were loosened for a project and never tightened back.
- External re-sharing. Whether guests can extend access to further external parties.
The anonymous link type is the one to watch most closely: it lets unauthenticated users open content, bypassing every identity control you have.
Why this drifts faster than anything else
External sharing settings change constantly, often with good intentions:
- A project needs to share a folder externally, so a site is loosened.
- A guest is invited for a one-off meeting and never removed.
- A link is set to "anyone" for convenience and forgotten.
None of that shows up in a one-time review. It shows up when a client, an insurer, or an incident forces the question — which is why external access deserves a place in a recurring audit.
How to audit it practically
Pull the tenant sharing settings, the guest inventory, the invite policy, and the site-level exceptions, and evaluate them against the guest-access controls in the benchmarks. By hand that is a tour through Entra ID, SharePoint, and Teams admin centers. Automated, it is a set of read-only checks that produce findings tied to controls.
A hosted audit runs external-sharing checks as part of every audit, alongside identity, Exchange, Teams, and Defender — see the sample report.
The short version
Guest access and external sharing are a top risk domain because they are both essential and easy to loosen. Audit who can invite, what guests can reach, and what your sharing defaults actually allow. Then audit it again, because it drifts.
Run an audit to see your guest access and external sharing posture in minutes.