Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant

What Are Azure Guest Accounts?

Azure Entra ID guest accounts (B2B collaboration) allow external users - partners, contractors, vendors, auditors - to access your Microsoft 365 resources without having an account in your tenant. Guest accounts authenticate through their home tenant but are granted access to your resources based on the permissions you assign.

Guest accounts are a legitimate and widely used feature. The problem is governance. Organizations invite external users for short-term projects and never remove them. Invitation settings are left at their default, which lets every user in the tenant - including existing guests - invite anyone. MFA is not required for guests. The result is a growing population of external identities with varying levels of access - many forgotten, some belonging to people who left their organization years ago.

How It Works

Guest accounts differ from member accounts in two key ways:

1. Authentication happens in the guest's home tenant - you don't control their MFA policies, password requirements, or security posture. You can still force them through your own MFA: by default, cross-tenant access settings do not trust MFA or device claims from other Microsoft Entra organizations, so your Conditional Access policy still applies to them. What you cannot do is inherit any assurance from how their home tenant authenticated them.
2. Lifecycle governance is opt-in - Entra ID does have a native mechanism that removes guests automatically (Access Reviews with Auto apply results to resource, and Block from signing in for 30 days then remove user from the tenant as the action on denied guests), but it is off by default and requires a Microsoft Entra ID Governance or Entra ID P2 subscription. A tenant that never turns it on has no automatic offboarding at all.

Invitation rights are open by default. Microsoft's documented behaviour is that "all users in your organization, including B2B collaboration guest users, can invite external users to B2B collaboration" - so it is not only your members: an existing guest can invite the next one, with no IT oversight or approval. In organizations with active B2B collaboration, it is common to find hundreds of guest accounts with a significant percentage having no activity in the past year.

The Attack Chain

Step 1 - Enumerate Guest Accounts

# signInActivity needs AuditLog.Read.All AND an Entra ID P1/P2 licence.
# Directory.Read.All alone returns the guests but not their sign-in data.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

# List all guest accounts with last sign-in date.
# -All is required: without it only the first page comes back (max 500 when
# signInActivity is selected) and the rest of the guests are silently missed.
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

# Find guests inactive for 180+ days.
# signInActivity is NOT returned by default: drop -Property and every guest
# looks like it never signed in, so this filter matches all of them.
$cutoff = (Get-Date).AddDays(-180)
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity" |
  Where-Object { $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff }

Step 2 - Exploit Unrestricted Invitation Settings

If guest invitation rights are not restricted, any compromised member account can invite attacker-controlled external identities for persistent access:

# Using a compromised member account to invite an attacker-controlled external identity
# Least-privileged delegated permission: User.Invite.All
New-MgInvitation `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage $false

Step 3 - Access Resources Without MFA

If guests are not subject to a Conditional Access policy requiring MFA, a compromised guest account provides direct access to all shared resources without additional verification - SharePoint files, Teams channels, OneDrive content. The worst case is a guest that also holds an Entra directory role, where wide-open cross-tenant B2B trust becomes a path to Global Administrator - see Entra Guest Admin Role Cross Tenant B2B Trust: How External Users Reach Global Administrator.

Step 4 - Lateral Movement via Shared Resources

Guest accounts often have access to sensitive shared content that can be exfiltrated directly. Project documents, contracts, customer data - all visible to appropriately permissioned guests. Group membership is the sharper path: a guest added to a role-assignable or nested privileged group inherits far more than file access, as covered in Entra ID Nested Privileged Groups, Role-Assignable Groups, and Guests in Security Groups.

Step 5 - Persist via Forgotten Accounts

Stale guest accounts persist indefinitely. An attacker who compromises a forgotten guest account has persistent, low-visibility access that is rarely reviewed or revoked.

Detection

Entra ID Audit Log Events

These are the activity names as they appear in the Microsoft Entra audit log. Guest sign-ins are not audit events - they live in the sign-in logs, which is a separate source.

SIEM Detection Queries (Elastic)

Field names below follow the Elastic Azure Logs integration.

Guest invitations (KQL):

azure.auditlogs.operation_name: "Invite external user"

The audit event records who invited (initiated_by), not that person's directory roles - the integration exposes initiated_by.user.id, .displayName, .ipAddress and .userPrincipalName, and nothing else. "Invitations from non-admin accounts" therefore has to be resolved by comparing the initiator's UPN against your current admin role holders, not by a single filter on a roles field.

Guest accounts accessing admin portals (KQL):

azure.signinlogs.properties.user_type: "Guest" AND
azure.signinlogs.properties.app_display_name: ("Azure Portal" OR "Microsoft Azure Management")

Bulk guest invitations (>5 in 1 hour) - ES|QL: KQL only filters; it has no role in aggregating, transforming, or sorting data, so a burst rule cannot be written in KQL at all. Use ES|QL:

FROM logs-azure.auditlogs-*
| WHERE azure.auditlogs.operation_name == "Invite external user"
| STATS invites = COUNT(*)
    BY inviter = azure.auditlogs.properties.initiated_by.user.userPrincipalName,
       window = DATE_TRUNC(1 hour, @timestamp)
| WHERE invites > 5

Remediation

1. Restrict Invitation Rights

Entra ID > External Identities > External collaboration settings:
Guest invite settings: "Only users assigned to specific admin roles can invite"

With this setting, only holders of the User Administrator or Guest Inviter role can send invitations, which creates an audit trail and prevents invitation abuse. Note what it is not: it restricts who can invite, it does not add an approval workflow. If you need approvals, front guest access with entitlement management access packages and named approvers.

2. Require MFA for Guest Users

Conditional Access Policy:
Name: Require MFA - Guest Users
Users > Include > Select users and groups > Guest or external users:
  select every applicable type (B2B collaboration guest users,
  B2B collaboration member users, B2B direct connect users,
  Local guest users, Service provider users, Other external users)
Target resources > Include: All resources (formerly 'All cloud apps')
Access controls > Grant: Require multifactor authentication
Enable policy: On

There is no single "All guests and external users" checkbox - you pick the external user types you want covered. Because cross-tenant trust settings do not trust home-tenant MFA by default, guests satisfy this policy by performing MFA against your tenant.

3. Remove Stale Guest Accounts

# Deleting a user needs a write scope - User.DeleteRestore.All is the
# least-privileged one. AuditLog.Read.All is what makes signInActivity readable.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","User.DeleteRestore.All"

$cutoff = (Get-Date).AddDays(-90)

# -All and -Property are not optional here. Without -Property the sign-in data
# is absent, every guest matches the $null test, and this script deletes the
# entire guest population.
$staleGuests = Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "id,displayName,userPrincipalName,signInActivity" |
  Where-Object {
    $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff
  }

Write-Host "Found $($staleGuests.Count) stale guest accounts"

# Export and review the list before deleting anything, then drop -WhatIf.
$staleGuests | Select-Object DisplayName, UserPrincipalName,
  @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Export-Csv .\stale-guests.csv -NoTypeInformation

$staleGuests | ForEach-Object {
  Remove-MgUser -UserId $_.Id -WhatIf
}

A guest deleted this way stays recoverable for 30 days before Microsoft Entra ID removes it permanently.

4. Configure Quarterly Access Reviews

Entra ID > ID Governance > Access reviews:
Create recurring quarterly reviews for all guest accounts
Reviewers: Resource owners or group owners
Auto apply results to resource: Enable
If reviewers don't respond: Remove access
Action to apply on denied guest users:
  Block from signing in for 30 days then remove user from the tenant

The last two lines are what turns a review into real offboarding: removing access alone leaves the guest object in the tenant. The delete-the-B2B-account action is available when the review targets selected teams and groups - it is not offered on the "All Microsoft 365 groups with guest users" review. Licensing: access reviews require a Microsoft Entra ID Governance or Microsoft Entra Suite subscription; some capabilities operate with Entra ID P2.

5. Implement Guest Access Tiers

Use Entra ID entitlement management to automate the guest lifecycle with automatic expiration dates. Like access reviews, it is a Microsoft Entra ID Governance capability and is licensed separately from Entra ID P1.

How EtcSec Detects This

EtcSec audits guest account governance on every Azure scan, identifying proliferation risks and uncontrolled access.

GUEST_INVITATION_UNRESTRICTED flags tenants whose guest invitation policy is still open to everyone - the default - instead of being narrowed to a controlled set of inviters. That is the root cause of uncontrolled guest proliferation.

GUEST_NO_MFA_REQUIRED flags tenants where guest users are not subject to a Conditional Access policy requiring MFA, leaving external identities with weaker authentication than internal users.

GUEST_STALE_90_DAYS lists enabled guest accounts whose last recorded sign-in is more than 90 days old, providing a prioritized list for access review and cleanup. Guests that have never signed in at all are a different case and are reported separately by GUEST_NEVER_SIGNED_IN.

Frequently Asked Questions

Are Azure guest accounts a security risk by default? Guest accounts themselves are not inherently risky, but poor governance creates significant risk. The main issues are: no MFA requirement for guests, unrestricted invitation rights, and stale accounts never being removed. A well-governed guest program is low risk; an unmanaged one becomes a major attack surface.

How often should I review guest accounts? Microsoft does not publish a single mandated cadence: Entra ID Access Reviews can be scheduled weekly, monthly, quarterly or annually, and the right interval depends on how sensitive the shared resources are. Quarterly is the EtcSec baseline. Access Reviews can automate the outcome with auto-removal for non-responses, which keeps the process manageable even for large tenants; it requires an Entra ID Governance or Entra ID P2 subscription.

Can a guest account be used to pivot inside the organization? Yes. A guest with Teams access can see all messages and files in those channels. If the guest also has SharePoint access, they can read and potentially exfiltrate documents. The damage is bounded by the guest's permissions, but over-permissioned stale guests are extremely common in the wild.

Review Priorities

Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant should be handled as a real exposure inside your Entra ID and Azure tenant, not as a single isolated setting. Start by defining the review perimeter: which admins, guests, service principals, app registrations, policy exclusions, and break-glass accounts are affected, which business workflows depend on them, which privileges they expose, and which emergency exceptions were added over time. That scoping step prevents shallow remediation, because the technical symptom is often smaller than the operational blast radius. By documenting the full path from configuration to privilege, the team can prioritize changes that reduce risk quickly without breaking production access. This also creates a defensible baseline for later validation and gives leadership a clear explanation of why the issue matters now.

Adjacent Controls to Review

When attackers reach your Entra ID and Azure tenant, they rarely stop at the first weak point. Around Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant, they normally test whether the exposed path can be chained with legacy authentication, weak guest governance, broad app consent, stale emergency accounts, and roles that were never reviewed. That means defenders should review not just the headline weakness but every nearby dependency that turns access into persistence or privilege escalation. Confirm which identities, roles, permissions, and trust assumptions can be reused by a motivated operator. If a fix closes only one object while leaving adjacent privilege paths untouched, the effective risk barely changes. A disciplined review of chaining opportunities is what turns this article topic into a practical hardening exercise rather than a one-time checkbox.

Evidence and Telemetry to Pull

A strong response to Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant needs evidence that can be reviewed by both engineering and detection teams. Pull sign-in logs, audit logs, role assignment changes, consent events, application credential changes, and risky sign-in signals, compare recent changes with known maintenance windows, and isolate accounts or systems that changed behavior without a clear business reason. Use that evidence to answer three questions: when the risky path appeared, who can still use it, and whether similar exposure exists elsewhere in your Entra ID and Azure tenant. Good telemetry review also helps you separate inherited technical debt from active misuse. That distinction matters, because the remediation plan for stale misconfiguration is different from the plan for a path that already shows attacker-like activity or repeated policy exceptions.

Azure Guest Accounts: Validation Before Sign-Off

A strong review of Azure Guest Accounts should end with production evidence, not with an assumption that the risky path disappeared. Before you close the finding, recheck role assignments, policy scope, app permissions, or guest settings, sign-in, audit, or risk evidence from the real tenant, and the exception path that could silently recreate the exposure. Confirm that the safer state applies to the scope that actually matters: the production OU, the effective role assignment, the application path, or the trust and delegation path an attacker would really abuse. Record the technical owner, the business dependency, and the rollback condition so the next review can tell whether the safer state was maintained.

Use a short sign-off checklist:

• verify the risky state is gone from the attacker's point of view, not only from an admin screenshot
• keep one before/after export or log sample that proves the affected scope changed
• document the owner and the exception decision if the control could not be fully enforced

For adjacent exposure, cross-check the result with Azure App Registrations: Over-Privileged Tenant Apps, Azure Tenant Hardening: Fix Insecure Default Settings, How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide, and AD and Azure Compliance: NIS2, ISO 27001, CIS Controls. The same control gap often reappears in nearby identity paths, logging gaps, or delegated permissions, which is why the final validation step matters as much as the initial finding.

Azure Guest Accounts: Evidence to Keep for the Next Review Cycle

The next reviewer should not have to rebuild the case from memory. Keep the evidence that originally justified the finding, the proof that the change was applied, and the note that explains why the final state is acceptable. For this topic, the most useful evidence usually combines the tenant export or screenshot that shows the affected scope, the sign-in, audit, or policy evidence proving the control now applies, and the owner, approval, and exception note for the final state. That compact pack makes quarterly or post-change reviews much faster and helps explain whether the issue was removed, reduced, or formally accepted.

If a later admin, policy, or application change reopens the path, this historical evidence also makes it easier to prove what drifted. That is what turns Azure Guest Accounts from a one-time check into a repeatable assurance process.

Sources

• Microsoft Learn - Configure external collaboration settings (default invite scope, guest invite options, Guest Inviter role)
• Microsoft Learn - List users (Microsoft Graph) (signInActivity requires Entra ID P1/P2 and AuditLog.Read.All)
• Microsoft Learn - Get-MgUser and Remove-MgUser
• Microsoft Learn - Manage guest access with access reviews and What are access reviews? (auto-apply, licensing)
• Microsoft Learn - Cross-tenant access overview (home-tenant MFA claims are not trusted by default)
• Microsoft Learn - Conditional Access: target resources and users and groups
• Microsoft Learn - Entra audit log activity reference (Invited users activity names)
• Elastic - Azure exported fields and KQL

Related Reading

Review this topic together with Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure, Azure Tenant Hardening: Fix Insecure Default Settings, Azure Privileged Access: Too Many Global Admins, Azure App Registrations: Over-Privileged Tenant Apps, and Azure Identity Protection: Blocking Leaked Credentials. Those adjacent posts show how the same identity weaknesses usually chain together in a real assessment instead of appearing as isolated findings.

• Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure
• Azure Tenant Hardening: Fix Insecure Default Settings
• Azure Privileged Access: Too Many Global Admins
• Azure App Registrations: Over-Privileged Tenant Apps
• Azure Identity Protection: Blocking Leaked Credentials

Using those references keeps the remediation discussion focused on the full attack path rather than a single control gap.

Validation Checklist

Before closing the review, rerun the same checks that exposed the issue and confirm the risky path no longer exists from the attacker perspective. Verify the relevant identities, privileges, inheritance paths, and compensating controls in production rather than only in staging or in documentation. Record the technical owner, the expected business dependency, and the evidence that shows the new configuration is both safer and operationally sustainable. That final validation step is what keeps the article grounded in how teams actually reduce identity risk.

Confirm Guest Lifecycle Controls in Practice

Guest account remediation should include a review of who sponsors external users, how access is recertified, and which collaboration paths still create long-lived guest identities with broad permissions. The most resilient programs combine invitation restrictions, periodic access reviews, and ownership checks so that guest access remains tied to an actual business need instead of lingering indefinitely after the project has ended.