How to Audit SharePoint Guest Access: A Safe Guide

How to audit SharePoint guest access

Audit SharePoint guest access by defining the exact sites and OneDrive locations in scope, generating Microsoft's sharing report for each location, preserving the source and observation time, separating direct access from link and group evidence, and matching named external users to an approved Microsoft Entra guest snapshot. Then send every exact, ambiguous, and unresolved case to an authorized owner for a keep, change, investigate, or no-action decision.

Do not label a site-level report collection a complete tenant audit. A sharing report describes the covered site or OneDrive and has documented omissions. An Entra guest object describes a directory identity, not every resource the person can reach. A defensible audit states those boundaries before presenting findings.

Microsoft's official SharePoint sharing-report guidance, last updated 7 May 2026 when reviewed, says a site administrator can generate a CSV of unique file, user, permission, and link combinations for a SharePoint site or OneDrive. It also documents important limitations that shape the audit method below.

Step 1: define scope and authority

Write down:

• tenant ID and display name;
• each SharePoint site and OneDrive location included;
• explicit exclusions;
• report generation date and time;
• whether the goal is entitlement review, migration preflight, policy readiness, or another bounded purpose;
• the data owner and reviewer authorized to decide access;
• the least-privileged role or permission used to collect each export;
• the secure storage and deletion rule for the evidence.

If the audit covers four sites, call it a four-site audit. If Teams, applications, security groups, or personal OneDrive locations are excluded, say so. Scope language is part of the control, not a footnote.

Step 2: generate a sharing report for every location

For a SharePoint site, Microsoft's documented interface is:

1. open the site;
2. open Settings and select Site usage;
3. under Shared with external users, select Run report;
4. choose where on the site to save the CSV.

For OneDrive, Microsoft documents a separate path through OneDrive settings and Run sharing report.

The report itself may contain access-sensitive information. Microsoft advises considering a folder with different permissions if site members should not see it. Treat that as a design requirement: do not leave an audit export in a broadly accessible library merely because the generation screen defaults there.

Keep each original export unchanged. Add a separate manifest containing:

• source URL or site ID;
• report file name and checksum;
• requested and completed timestamps;
• person or process that generated it;
• evidence-retention deadline;
• any error, delay, or known incompleteness.

Step 3: interpret rows by evidence type

Microsoft's current CSV description includes resource path, item type, permission, user name, user email, user or group type, link ID, link type, and the link used for access.

Classify each row before attempting a person match:

• Named direct access: a person is associated with a resource and permission.
• Group evidence: a SharePoint, security, or Microsoft 365 group appears.
• Specific-people link evidence: the row refers to a constrained sharing link and may also identify a recipient or user.
• Organization link evidence: the link is intended for people in the organization under the configured conditions.
• Anonymous-link evidence: evidence from another source may show an Anyone link, but the sharing report has a documented limitation here.
• Unresolved link: the report identifies a sharing link rather than a confirmed individual.

Do not expand a group by guessing. Microsoft's report guidance says the report shows SharePoint groups but not the individual users inside them. Group membership needs a separately authorized evidence source and observation time.

The same documentation says the report does not include links emailed directly but not clicked, or Anyone links. Therefore, “not present in the CSV” does not mean “does not exist.”

Step 4: collect the directory evidence separately

An approved Microsoft Entra snapshot can help resolve named guests. Useful fields may include:

• object ID;
• display name;
• userType;
• mail and alternate mail values where available;
• user principal name;
• identities;
• invitation or external-user state;
• sponsor;
• creation and state-change timestamps.

Microsoft's B2B guest user properties, last updated 20 March 2026 when reviewed, explains that B2B collaboration creates a user object in the resource directory and that external users can have Guest or, in specific scenarios, Member relationships. It also states that UserType does not determine how the person signs in.

That means a filter for userType = Guest can be useful but is not a complete definition of every external identity. Record the directory extraction rule and preserve out-of-scope states as unknown.

Step 5: join cautiously

Normalize comparison keys in a documented way, but preserve original values. A practical sequence is:

1. use immutable object identifiers when both sources provide them;
2. compare exact normalized mail values;
3. inspect alternate mail or invited identity values only when the approved schema supports them;
4. keep multiple candidates ambiguous;
5. keep link-only rows unresolved rather than manufacturing a guest match;
6. record the rule and evidence fields behind every match.

Useful match states are:

• Exact: one supported identity match.
• Ambiguous: more than one plausible directory object or conflicting fields.
• No match in supplied snapshot: a named sharing identity has no candidate in the complete supplied directory evidence.
• Link only: the sharing evidence does not identify a person.
• Group unresolved: individual membership was not in scope.
• Directory only: a guest object exists but has no matching row in the supplied site reports.

“No match in supplied snapshot” is narrower and more accurate than “no guest exists.”

For the evidence-model differences behind these states, read SharePoint sharing report vs Entra guests.

Step 6: add ownership and purpose

Identity and permission evidence still do not answer whether access is appropriate. For each reviewable relationship, seek:

• resource owner;
• business sponsor;
• stated purpose;
• expected review or end date;
• recent evidence relevant to the audit goal;
• decision owner;
• decision and reason;
• follow-up task, if separately authorized.

An absent sponsor is a finding to investigate, not an instruction to delete the guest. The sponsor may be recorded in another system or need reassignment.

Synthetic audit example

Assume the invented site Supplier Portal produces these observations:

The audit must not recommend deletion solely from this table. A site owner may confirm that Supplier A still needs access, resolve Supplier B's identity, inspect the link through supported tools, obtain group membership evidence, and decide whether the directory-only guest has access through another site, group, application, or no current resource.

Step 7: review settings as context

Record the organization-level and site-level external sharing setting, relevant link defaults, domain restrictions, guest expiration rules, and Microsoft Entra external collaboration settings. These settings affect what sharing is allowed; they do not by themselves enumerate every current entitlement.

Microsoft's SharePoint and OneDrive sharing-settings guide, last updated 30 June 2026 when reviewed, explains that a site can be more restrictive than the organization setting and that Microsoft Entra collaboration settings also affect supported sharing paths.

Use SharePoint Online guest access settings as the configuration checklist. Keep configuration evidence separate from report and identity evidence.

Audit checklist

Collection

• Confirm every site and OneDrive in scope.
• Generate one official sharing report per location.
• Store exports in a restricted evidence location.
• Preserve originals and checksums.
• Record generation time, source, and errors.
• Obtain a complete, authorized Entra snapshot for the defined boundary.

Analysis

• Separate named access, groups, and links.
• Preserve report limitations beside the findings.
• Normalize identifiers without overwriting source values.
• Classify exact, ambiguous, absent-in-snapshot, link-only, group-unresolved, and directory-only states.
• Attach the comparison rule to every match.
• Mark unavailable evidence unknown.

Review

• Identify the resource owner and guest sponsor.
• Confirm purpose and expected duration.
• Keep evidence findings separate from access decisions.
• Require an authorized reviewer for keep or change decisions.
• Track follow-up without making an automatic access change.
• Re-run affected evidence after approved remediation.

What this audit cannot prove

This method cannot prove that:

• every tenant site, OneDrive, group, Team, or application was included;
• all group members were expanded;
• all Anyone links or unclicked emailed links were discovered;
• a directory-only guest has no access elsewhere;
• a named identity can successfully sign in now or after a policy change;
• the current access is appropriate without an owner decision;
• a matching identity is the same human without sufficient evidence;
• every permission path is secure or compliant.

Reports and admin interfaces can change. Verify the current Microsoft documentation, licensing, roles, tenant configuration, and data handling requirements before collection. This guide is an operational methodology, not a compliance certification.

Official sources reviewed

Microsoft platform facts were checked on 23 July 2026 against the SharePoint sharing-report documentation, SharePoint and OneDrive sharing-settings guide, and Microsoft Entra B2B guest user properties.

For a read-only join of supplied site reports and directory evidence, review the GuestPreflight sample and request one paid bounded guest-access audit. It does not invite, approve, deny, or remove a user.