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 open, allowing any member of the tenant to 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
2. Access reviews are often absent - there is no native mechanism that automatically removes guests after their project ends

When invitation settings are unrestricted, any member of your tenant can invite any external user without 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

Connect-MgGraph -Scopes "Directory.Read.All"

# List all guest accounts with last sign-in date
Get-MgUser -Filter "userType eq 'Guest'" `
  -Select "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

# Find guests inactive for 180+ days
$cutoff = (Get-Date).AddDays(-180)
Get-MgUser -Filter "userType eq 'Guest'" |
  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
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.

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.

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

SIEM Detection Queries (Elastic KQL)

Guest invitations from non-admin accounts:

azure.auditlogs.operation_name: "Invite external user" AND
NOT azure.auditlogs.properties.initiated_by.user.roles: "*Admin*"

Guest accounts accessing admin portals:

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):

azure.auditlogs.operation_name: "Invite external user" |
  stats count() by azure.auditlogs.properties.initiated_by.user.userPrincipalName |
  where count > 5

💡 Tip: Perform a quarterly review of all guest accounts using Entra ID Access Reviews. Any guest with no sign-in in 90+ days should be reviewed and likely removed.

Remediation

💡 Quick Win: Restricting guest invitation rights to admins is a single setting change that eliminates uncontrolled guest proliferation immediately.

1. Restrict Invitation Rights

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

This ensures all guest invitations require admin approval, creating an audit trail and preventing invitation abuse.

2. Require MFA for Guest Users

Conditional Access Policy:
Name: Require MFA - Guest Users
Users: Guests or external users > All guests and external users
Cloud apps: All cloud apps
Access controls: Require multifactor authentication
Enable: On

3. Remove Stale Guest Accounts

$cutoff = (Get-Date).AddDays(-90)
$staleGuests = Get-MgUser -Filter "userType eq 'Guest'" |
  Where-Object { 
    $null -eq $_.SignInActivity.LastSignInDateTime -or 
    $_.SignInActivity.LastSignInDateTime -lt $cutoff 
  }

Write-Host "Found $($staleGuests.Count) stale guest accounts"
# Review list first, then remove
$staleGuests | ForEach-Object { 
  Write-Host "Removing: $($_.UserPrincipalName)"
  Remove-MgUser -UserId $_.Id 
}

4. Configure Quarterly Access Reviews

Entra ID > Identity Governance > Access Reviews:
Create recurring quarterly reviews for all guest accounts
Auto-apply: Remove access if no response within the review period
Reviewers: Resource owners or group owners

5. Implement Guest Access Tiers

Use Entra ID Entitlement Management to automate guest lifecycle with automatic expiration dates.

How EtcSec Detects This

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

GUEST_INVITATION_UNRESTRICTED identifies tenants where invitation rights are not restricted to administrators - 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 enumerates all guest accounts with no sign-in in 90+ days, providing a prioritized list for access review and cleanup.

ℹ️ Note: EtcSec automatically audits guest account governance on every Azure scan. Run a free audit to see how many unreviewed guest accounts exist in your tenant.

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 recommends quarterly access reviews at minimum. Entra ID Access Reviews can automate this with auto-removal workflows for non-responses, making the process manageable even for large tenants.

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.

Related Reading

Review this topic together with Azure Conditional Access: MFA Bypass With Stolen Passwords, 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.

• Azure Conditional Access: MFA Bypass With Stolen Passwords
• 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.