How to Audit Guest and External User Accounts

Guest and external accounts are created in seconds by anyone with an invite button, and almost nobody removes them. Every collaboration platform lets staff bring in partners, contractors and customers, and each one keeps its own list of outsiders that never appears in the HR feed. This guide is a repeatable audit procedure: build one inventory of external users across your main platforms, find the stale ones, find the ones holding more access than a guest should, and put expiry and ownership on everything that remains. It is written for identity governance, IT and security teams who run the audit, and for auditors who need to know what good evidence looks like. Platforms are listed alphabetically, and the order is not a ranking.

Key takeaways

Inventory first, platform by platform. Directory guests, repository collaborators, chat guests and external group members live in different places, so the audit starts by pulling each list into one register.
Stale means no recent sign-in or never accepted. A guest with no sign-in for 90 days, or an invitation still pending after 30, is the first removal candidate; tune the window to your collaboration patterns.
Privilege is the second filter. A guest in an admin role, an owner group or a repository with admin rights is a priority finding regardless of activity.
Every external account needs a sponsor and an end date. Accounts with neither are how guests outlive contracts by years.
Turn the audit into a control. Recurring reviews with automatic removal on no response, and invite restrictions, keep the numbers from growing back.

Why external accounts drift

Workforce accounts have a joiner-mover-leaver process driven by HR. External accounts usually do not. Microsoft's access review documentation makes the point directly: automated lifecycle processes based on HR data typically do not cover invited guests, so group owners have to confirm that guests still have a business need. The same is true of every platform that allows self-service invitations.

Self-service invitations: in Microsoft Entra ID the default guest invite setting lets anyone in the organisation, including guests, invite external users. A guest can therefore invite another guest.
Sharing creates accounts: sharing a file or adding someone to a channel often creates an external identity as a side effect, with no ticket and no owner.
Contracts end silently: when a supplier engagement finishes, nobody tells the identity team, and the contractor's home employer keeps their credentials alive.
Attackers use them: external accounts are valid accounts (MITRE ATT&CK T1078) reached through a trusted relationship (T1199). In the Uber breach the attacker started from an external contractor's password, then pushed MFA prompts until one was accepted.

For the full contractor lifecycle, including sponsorship and onboarding, see the Contractor Identity Lifecycle Guide. This page is the audit that checks whether that lifecycle is working.

Step 1: define what counts as external

Agree the definition before you pull data, or the numbers will not reconcile. Use four categories and record which applies to each account.

Category	What it looks like	Audit concern
Federated guest	A guest object in your directory that signs in with the partner's own identity provider	Partner controls credentials and leaver handling; you control access and expiry
Local external account	A full account in your directory or a SaaS app issued to a non-employee	You own the credential, MFA and offboarding; often missed by HR feeds
Platform collaborator	Access granted inside one application (repository, channel, workspace) without a directory object	Invisible to directory reports; must be pulled from each platform
External member of a group	An outside email address added to a group, distribution list or shared space	Inherits whatever the group grants, including files and app access

Exclude workload and service identities from this audit and review them separately: see How to Run an Access Review for Service Accounts. Do include external accounts that are marked as members rather than guests; Microsoft documents that userType is a relationship indicator only and has no relation to how the user signs in or what roles they hold.

Step 2: pull the inventory from each platform

The table lists where each platform keeps its external users and the fields that matter for the audit. Pull each list, normalise to one row per account, and keep the raw export as evidence.

Platform	Where external users are listed	Fields to capture
GitHub (organisations)	Organisation, People tab, Outside collaborators	Login, repositories, permission level per repository, 2FA status, date added
Google Workspace	Groups with external members, Drive files shared outside the domain, visitor sharing	Group, external address, role in group, files or shared drives reached
Microsoft Entra ID	Users filtered by user type Guest, plus external accounts marked Member	UPN, userType, externalUserState, identities (issuer), creation date, last sign-in, sponsor
Slack	Directories, People, Filters, Account type Guests	Guest type (multi-channel or single-channel), channels, inviter, scheduled deactivation date

GitHub

An outside collaborator is a person who is not a member of the organisation but has access to one or more of its repositories, and anyone with admin access to a repository can add one. List them from the organisation's People tab under Outside collaborators, then record each repository and permission. If the organisation requires two-factor authentication, collaborators must enable it before accepting an invitation, so check the requirement is on. On GitHub Enterprise Cloud the organisation can restrict who may add outside collaborators. See the GitHub Organisation Security Checklist.

Google Workspace

Groups sharing settings decide whether group owners may add external members, and the default is that external members are not allowed. Where the setting has been turned on, list groups that contain addresses outside your domains and record what each group grants. Drive external sharing is controlled separately, including sharing with people who have no Google account through visitor sharing, which can be limited to trusted domains. Note that group-based settings take precedence over organisational unit settings. See the Google Workspace Security Guide.

Microsoft Entra ID

Filter users by user type Guest, then add accounts whose identities show an external issuer. Guest UPNs follow the pattern user_domain#EXT#@tenant.onmicrosoft.com. The identities property shows the home of each account: ExternalAzureAD for another Entra tenant, google.com, mail for email one-time passcode, or a SAML or WS-Fed issuer URI. Before redemption externalUserState reports pending acceptance. Last sign-in data comes from the signInActivity property in Microsoft Graph, which needs the AuditLog.Read.All and User.Read.All permissions, and lastSuccessfulSignInDateTime needs Entra ID P1 or P2. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

Slack

Guests are available on paid plans in two types: multi-channel guests, billed as regular members and limited to channels you choose, and single-channel guests, limited to one channel. Admins list them from Directories, People, filtered by account type Guests, and each profile shows the inviter, channels and any scheduled deactivation date. People whose own company uses Slack can instead be reached through Slack Connect, which keeps them in their own workspace; include Slack Connect channels in the review of what outsiders can see. See the External Collaboration and Federation Abuse Guide.

Step 3: find stale external accounts

Staleness is the cheapest finding to act on. Use these tests, in order, and record the rule that flagged each account.

Invitation never accepted: pending invitations older than 30 days (an NHI Mgmt Group recommendation) are removed. They grant nothing yet, but anyone who gets the invitation link later inherits the access.
No sign-in within the window: Microsoft suggests a window of 90 to 180 days for inactive accounts, allowing for legitimate absences. Entra ID's inactive guest insights default to a 90-day threshold and count days from creation for guests who never signed in.
Interactive and non-interactive activity: check both. A guest with no interactive sign-in may still be using a token through an app. Treat token-only activity as a question for the sponsor, not as proof of need.
Platform activity: where the platform has no sign-in date for collaborators, use its audit log for the last action by that account, and treat no recorded action in the window as stale.
Contract ended: match the sponsor's supplier records. An account with recent activity after the contract end date is a finding, and possibly an incident.

Keep a short exceptions list (for example, an annual audit partner who signs in once a year), each with a named sponsor and an expiry date, so the same accounts are not argued about every cycle.

Step 4: find external accounts with too much access

Privilege matters more than activity: a dormant guest with admin rights is a larger risk than an active guest in one project channel. Check these, highest first.

Check	Why it matters	Expected result
Directory admin roles, active or eligible	A guest administrator can change the tenant	Zero, or each one approved, time-bound and reviewed
Ownership of groups, teams, sites or applications	Owners can add members and change sharing	No external owners
Repository admin or maintain permission	Admins can change settings, secrets and collaborators	Write at most, and only where needed
Membership of broad internal groups	"All staff" style groups expose internal content	No external members
Guest directory visibility	Guests able to enumerate users and groups help reconnaissance	Entra guest user access at the default limited level or the most restrictive level
Ability to invite others	Guests inviting guests multiplies unowned accounts	Invitations limited to members or specific roles

For the Entra ID role check in detail, including PIM-eligible and group-based routes, follow How to find guest users with privileged roles in Entra ID.

Step 5: check sponsorship and expiry

An external account without an owner cannot be reviewed, and one without an end date never leaves. For each account confirm:

Sponsor: a named internal person or group who is still employed and still responsible for the relationship. Reassign sponsors when people move, and treat accounts whose sponsor has left as unowned.
Business reason: the project, contract or supplier it supports, recorded once and referenced in the review.
End date: use the platform's own expiry where it exists. Slack lets owners and admins set a time limit or custom deactivation date, with a reminder five days before. In Entra ID, access granted through entitlement management packages can carry an end date, and denied guests in an access review can be blocked from signing in for 30 days and then removed.
Authentication: MFA is enforced for the external account, either by your policy or a partner MFA you have assessed and chosen to trust.

Step 6: remediate safely, with rollback

Removal breaks real work if it is done in one pass. Stage it.

Notify sponsors with the list of their external accounts and a deadline to confirm need, giving a short response window (an NHI Mgmt Group recommendation is 10 working days).
Disable before delete: block sign-in or deactivate first. In Entra ID a deleted guest can be restored within 30 days; after that a new invitation is needed. On GitHub, removing an outside collaborator deletes their forks of private repositories, but they keep local clones, so the organisation remains responsible for asking them to delete confidential data.
Remove privilege before membership: strip admin and owner rights immediately even where the account itself stays.
Delete after the hold period with no reported breakage, and keep the before and after exports.
Rollback: restore from the platform's deleted-items window or re-invite through the approved process with a sponsor and end date, never by re-creating the old account as it was.

Step 7: make it a recurring control

A one-off clean-up returns to the same state within a year. Build the audit into the platforms.

Recurring reviews: Microsoft documents two patterns, a multi-stage review where guests attest to their own need and then group owners decide, and a review of inactive guests only. Both use auto-apply, with "remove access" when reviewers do not respond. These features need Microsoft Entra ID Governance or Microsoft Entra Suite licences. See the Access Reviews Guide.
Invite restrictions: in Entra ID move the guest invite setting from "anyone in the organisation" to member users and specific roles, or to admin roles and the Guest Inviter role only, and use collaboration restrictions to allow or deny partner domains.
Default expiry: set time limits for new chat guests and end dates on access packages so the default is to leave, not to stay.
Cadence: quarterly for accounts with privileged or sensitive-data access, twice a year for the rest (NHI Mgmt Group recommendation), aligned with your wider Access Review Checklist.

Detection and measurement

Between reviews, alert on events that change your external risk: a guest added to an admin role, a group owner change to an external address, an outside collaborator granted admin on a repository, a guest invitation sent by another guest, and sign-ins by external accounts after their sponsor has left. Track these metrics each cycle:

External accounts per platform: the trend should be flat or falling relative to active projects.
Stale rate: share of external accounts with no sign-in in 90 days or pending invitations over 30 days.
Unsponsored rate: external accounts with no current sponsor, target zero.
Expiry coverage: share of external accounts with an end date set.
Privileged externals: count of external accounts holding admin or owner rights, each with an approval.
Review completion: share of review decisions made by a human, not by the no-response default.

Common failure patterns

Auditing only the directory: repository collaborators, chat guests and external group members do not show up in a directory guest report.
Trusting userType: external accounts created as members are missed by a filter on Guest.
Rubber-stamp reviews: sponsors approve everything because the list has no last sign-in or access detail on it.
Deleting without warning: a mass deletion breaks a live supplier project, the business loses trust in the process, and the next review is blocked.
Ignoring the contractor's home account: a federated guest is only as secure as the partner's credentials and MFA, as the Uber breach showed with a contractor's password, which Uber said had likely been bought on the dark web.
No owner for the audit itself: IT, security and procurement each assume another team runs it.

Framework mapping

Framework	Reference	How this audit supports it
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-2(3) Disable Accounts	Inventory, review, and disabling of inactive external accounts
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; PS-7 External Personnel Security	Privilege checks and sponsorship of external personnel
NIST CSF 2.0	PR.AA-01, PR.AA-05	Identities managed and access permissions reviewed with least privilege
NIST CSF 2.0	GV.SC-05	Supplier requirements, including access ending with the contract
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management	Account inventory, disabling dormant accounts, access revocation
ISO/IEC 27001:2022 Annex A	5.16 Identity management; 5.18 Access rights; 5.19 Information security in supplier relationships	Lifecycle, periodic review of access rights, supplier access
MITRE ATT&CK	T1078 Valid Accounts; T1078.004 Cloud Accounts; T1199 Trusted Relationship	Removing the dormant and over-privileged external accounts these techniques rely on

Practitioner checklist

Agree the four external account categories and include externals marked as members.
Export external users from every collaboration platform into one register, keeping raw exports as evidence.
Flag pending invitations over 30 days and accounts with no sign-in or action in 90 days.
List every external account with admin, owner or repository admin rights and remove privilege first.
Confirm a current sponsor, business reason and end date for every remaining account.
Disable before deleting, and record the restore window for each platform.
Restrict who can invite guests and set default expiry for new external accounts.
Schedule recurring reviews with auto-apply and alerts on privileged changes to external accounts.

How to audit guest and external users: Find stale guests, excess privilege and missing expiry