How to Audit Entra ID Guest Accounts in Australian Organisations

Auditing Entra ID guest accounts supports an organisation's Privacy Act safeguards where those guests can access personal information. Unreviewed access can create an unauthorised-access or disclosure risk under APP 11. This guide walks through five structured steps to discover, assess, remediate, and continuously govern your external identity population.

This post is a practitioner companion to Auditing Entra ID for the Australian Privacy Act, the pillar guide that sets the broader context. For a scored baseline of your current guest posture, the free identity assessment measures guest governance as a dedicated pillar.

Why Guest Accounts Are a Priority Audit Target

Guest accounts are Entra ID identities your organisation does not own. The external person authenticates with their own identity provider — Microsoft, Google, or a federated corporate IdP — and your tenant trusts the resulting token. When that trust is extended too broadly or not revoked when the relationship ends, you have a standing access risk tied to credentials you cannot control.

Three patterns drive most Australian findings:

• Former contractor accounts that were never deprovisioned when the engagement ended.
• Partner organisation accounts whose staff have changed but whose access was never reviewed.
• Vendor accounts granted broad SharePoint or Teams access for a project, left in place long after project close.

Under Australian Privacy Principle 11, organisations must take reasonable steps to protect personal information from unauthorised access. A former contractor with standing guest access to a SharePoint site holding customer records is not a reasonable-steps posture.

Step 1 — Discovery: Know What You Have

Begin with a complete inventory. Do not rely on the Entra admin centre's default view — it shows a subset. Use Microsoft Graph for a complete extract.

Graph query to run:

GET https://graph.microsoft.com/v1.0/users?$filter=userType eq 'Guest'&$select=id,displayName,mail,userPrincipalName,createdDateTime,externalUserState,signInActivity

Export to CSV using Graph Explorer, the Entra admin centre export function, or a PowerShell script using the Microsoft.Graph module. The PowerShell equivalent:

Connect-MgGraph -Scopes "User.Read.All", "AuditLog.Read.All"
Get-MgUser -Filter "userType eq 'Guest'" -Property Id,DisplayName,Mail,UserPrincipalName,CreatedDateTime,ExternalUserState,SignInActivity -All | Export-Csv -Path ".\guests.csv" -NoTypeInformation

For each guest, capture:

1. Display name and email domain.
2. Account creation date (when were they invited?).
3. Last sign-in date from signInActivity (accounts with no sign-in recorded have never authenticated).
4. External user state (Accepted vs PendingAcceptance — pending invitations that were never accepted).
5. Group memberships that grant SharePoint, Teams, or application access.

The size of the stale population varies by tenant, so measure it rather than relying on an industry percentage. Treat guests with no recorded sign-in, long inactivity, or a pending invitation as review candidates. Confirm sponsorship and resource access before removal; a pending invitation may still relate to an active business process.

Step 2 — Assess Risk: Prioritise by Access Scope

Not all guests carry equal risk. Triage by what they can access.

High priority (immediate review):

• Guests who are members of Microsoft 365 groups that provide access to SharePoint sites holding personal information.
• Guests who are owners of any Microsoft 365 group, Team, or SharePoint site.
• Guests with direct Entra ID directory role assignments (rare but catastrophic when present).
• Guests from domains with no documented business relationship.

Medium priority (review within 30 days):

• Guests with no sign-in in 90 or more days.
• Guests invited more than 12 months ago with no access review on record.
• Guests whose external domain has changed (company acquisition, domain change — the original identity provider no longer exists).

Lower priority (include in quarterly cycle):

• Active guests with documented business relationships and recent sign-in activity.

Use the signInActivity.lastSignInDateTime field in your CSV export to drive this triage. Any null value means the account has never been used — these are safe to delete regardless of when they were created.

Step 3 — Remediation: Remove and Restrict

For accounts identified as high-priority or stale, remediation is straightforward:

1. Delete guests with no sign-in ever. These invitations were never accepted. They carry no legitimate business value.
2. Disable then delete stale guests. For accounts inactive for 90 or more days, disable first, wait 14 days, then delete. This gives the business a window to raise an exception before permanent removal.
3. Remove group memberships before deleting. Audit which groups the guest belongs to and communicate removal to the group owner before deletion, so business owners are not surprised.
4. Revoke pending invitations. In Entra admin centre, filter for external user state = PendingAcceptance and delete the pending guest objects.

Bulk deletion can be scripted using Microsoft Graph. This is a destructive, irreversible operation, so the script below runs in -WhatIf (preview) mode by default — it only reports what would be deleted. Manually review the CSV and the preview output before you run it for real. Deletion happens only when you explicitly re-run with -Live, and each account still prompts for confirmation.

# REVIEW FIRST. Deletes guest accounts listed in the CSV — this cannot be undone.
# Default is a dry run (-WhatIf). To actually delete, re-run with:  .\remove-guests.ps1 -Live
param(
    [string]$CsvPath = ".\guests-for-removal.csv",
    [switch]$Live
)

if (-not (Test-Path $CsvPath)) {
    throw "CSV not found: $CsvPath. Review the export before proceeding."
}

$staleGuests = Import-Csv $CsvPath
Write-Warning "$($staleGuests.Count) guest account(s) are queued for removal. Review the CSV before continuing."

foreach ($guest in $staleGuests) {
    if (-not $guest.Id) {
        Write-Warning "Skipping row with no Id: $($guest.DisplayName)"
        continue
    }
    try {
        if ($Live) {
            # -Confirm forces a per-account prompt; remove it only once you fully trust the CSV.
            Remove-MgUser -UserId $guest.Id -Confirm -ErrorAction Stop
            Write-Output "Removed: $($guest.DisplayName) - $($guest.Mail)"
        }
        else {
            # Dry run: report only, delete nothing.
            Remove-MgUser -UserId $guest.Id -WhatIf
        }
    }
    catch {
        Write-Warning "Failed to remove $($guest.DisplayName) ($($guest.Id)): $($_.Exception.Message)"
    }
}

Retain the deletion log as audit evidence. OAIC expects organisations to be able to demonstrate what access was removed and when.

Step 4 — Prevent New Ungoverned Guests

Remediation without prevention is a losing cycle. These two controls stop ungoverned guests from re-entering the tenant.

B2B invitation restriction (Entra admin centre → External Identities → External collaboration settings):

• Set "Guest invite settings" to "Only users assigned to specific admin roles can invite guests". This prevents individual employees from self-service inviting external parties without IT oversight.
• Enable "Collaboration restrictions" and set an allow-list of approved external domains. Any invitation to a non-listed domain is blocked.

Cross-tenant access settings (Entra admin centre → External Identities → Cross-tenant access settings):

• Default inbound: block. Trusted partner organisations are added as explicit exceptions.
• Default outbound: block. Your users can only collaborate outbound with explicitly approved tenants.
• For each approved partner tenant, configure which Conditional Access claims (MFA, compliant device) you accept from their environment.

These two settings pages are where most Australian organisations have the largest gap. The default Microsoft configuration is permissive — it was designed for collaboration convenience, not for regulated-sector privacy governance.

Step 5 — Ongoing Governance: Access Reviews and Expiry

Discovery and remediation address the existing backlog. Ongoing governance prevents it from rebuilding.

Guest expiry policy:

The current ASD ISM control ISM-1404 disables unprivileged access after 45 days of inactivity. It does not name Entra guest accounts or prescribe a separate guest lifecycle. Use that control as an input to your risk decision, then document the interval you apply:

• For organisations on Entra ID P2 or Entra ID Governance: use Lifecycle Workflows. Create a workflow triggered by 90 days of guest inactivity that disables the account, notifies the sponsor, and removes the account after 14 days.
• For organisations on standard licences: schedule a monthly PowerShell runbook using Microsoft Graph that queries for guests with lastSignInDateTime older than 90 days and processes them through the disable-then-delete cycle.

Quarterly access reviews:

Schedule an Entra ID access review on the guest user population with the following settings:

• Scope: All guest users.
• Reviewers: Sponsor (the person who invited the guest, if recorded) or group owner.
• Duration: 14 days per cycle.
• If no response from reviewer: auto-remove. This is the critical setting — reviews that default to "approve if no response" are audit-theatre.
• Frequency: Quarterly.

The access review activity log provides evidence that the organisation governs third-party access on a documented cycle and can support its APP 11 safeguards.

Privacy Governance Evidence Package

When an OAIC investigation or security assessment asks you to demonstrate guest account governance, the evidence package should include:

1. The most recent guest discovery export (dated).
2. The remediation log from the most recent cleanup cycle (accounts removed, dates, reason).
3. Screenshot of B2B invitation settings showing allow-list and role-restricted invitations.
4. Screenshot of cross-tenant access settings showing default-block posture.
5. Entra ID access review report from the most recent quarterly cycle.
6. Lifecycle workflow or runbook documentation confirming the approved expiry interval is active.

This package helps demonstrate APP 11 reasonable steps and, where the ISM applies, evidence that the organisation governs inactive unprivileged access.

Bottom Line

Australian organisations should audit Entra ID guest accounts whenever those identities can reach personal or sensitive information. Plan the effort from the measured tenant size and access complexity rather than assuming a standard duration; discovery, risk triage, remediation, prevention, and ongoing governance all need owners and evidence.

The free identity assessment gives you a scored baseline of your current guest posture across all five governance pillars. If the remediation scope is large or the Privacy Act evidence requirement is urgent, the practitioner Identity and Access Review provides a fully documented audit report aligned to the Australian Privacy Principles.

Sources: Microsoft Learn — Entra ID External Identities, B2B collaboration, cross-tenant access overview, Lifecycle Workflows (learn.microsoft.com, accessed 28 June 2026). ASD Information Security Manual — guidance on time-limiting external and guest access (cyber.gov.au, accessed 28 June 2026). OAIC — Australian Privacy Principles 6 and 11, Notifiable Data Breaches scheme (oaic.gov.au, accessed 28 June 2026).