Entra ID Guest Conditional Access Policy External Collaboration Settings — the Six Defaults That Work Against You

Your Entra ID guest conditional access policy external collaboration settings are actually two separate control surfaces that most tenants configure once, during initial setup, and never revisit. Conditional Access decides whether a signed-in guest gets challenged for MFA, a compliant device, or a stronger authentication method. External Collaboration Settings decide who is allowed to become a guest in the first place, what a guest can see once they're in, and how long that guest account is allowed to exist. A tenant can have excellent MFA coverage for employees and still leave every one of these guest-specific defaults exactly where Microsoft ships them — which, for several of them, is the permissive option.

This article walks through six specific gaps in that guest control surface, each mapped to a documented Microsoft default or mechanism: no Conditional Access policy actually evaluates guest sign-ins, guests can invite other guests, guests can browse the directory, guest accounts never expire, nobody notices a guest who never signed in, and guests can reach enterprise apps that were never assigned to them. None of these require an attacker to exploit a vulnerability — they only require an admin to have accepted the tenant's out-of-the-box configuration. For the full picture of how to audit a tenant end to end, see How to Audit Microsoft Entra ID Security.

Entra ID Guest Conditional Access Policy External Collaboration Settings, Defined

Guest access in Entra ID starts with an invitation — B2B collaboration creates a user object with UserType set to Guest in your directory, backed by credentials in the guest's own home tenant or identity provider. From that point, two independent settings groups govern what the guest can do.

External Collaboration Settings, under Entra ID > External Identities, control guest invite permissions, guest directory visibility, self-service sign-up, and domain allow/block lists. Conditional Access is a separate policy engine that evaluates every sign-in, including guest sign-ins, against assignment rules that can target specific guest and external user types — B2B collaboration guest users, B2B collaboration member users, B2B direct connect users, local guest users, service provider users, and other external users — each of which can be included or excluded independently, for one tenant or all tenants.

These two systems don't talk to each other. A guest can be invited under the most permissive collaboration settings and still get blocked by a strict Conditional Access policy, or invited under strict collaboration settings and still sail through a Conditional Access policy that never evaluates guests at all. Reviewing one without the other is only half the picture — see Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant for the broader guest exposure model this article's six gaps sit inside.

How Guests Escape Conditional Access Coverage

GUEST_NO_CA_POLICY [HIGH] fires when no enabled Conditional Access policy explicitly includes a guest or external user type. The check reads the include-users assignment of every enabled policy, so an "All users" baseline doesn't register as guest coverage — which is exactly the distinction the rest of this section turns on.

Microsoft's own documentation says the All users assignment option in Conditional Access includes "all users in the directory, including B2B guests" — so in theory, a single baseline MFA policy scoped to All users already covers every guest. In practice, the same documentation set explains three ways that coverage quietly disappears.

Exclusions override inclusions, unconditionally

Microsoft states plainly: "When organizations both include and exclude a user or group, the user or group is excluded from the policy. The exclude action overrides the include action in a policy." If any exclusion group that happens to contain guests gets attached to a policy — for any reason, at any point — that policy stops protecting them, silently, with no warning in the admin center. A policy that still shows as "On" in the admin center while quietly excluding your guest population looks identical, at a glance, to the report-only policies covered in Conditional Access Report-Only Mode, Stale Exclusions — both leave a tenant with a false sense of enforced coverage.

User-risk policies can't be resolved for external users, so Microsoft's own guidance is to build an exclusion

User risk requires a password reset the resource tenant can't perform on an external identity, so Microsoft's documented fix is: "You can prevent risk-based policies from affecting external users by creating a group in Microsoft Entra ID that contains all of your organization's external users. Then, add this group as an exclusion for your user risk and sign-in risk based Conditional Access policies." Note how far that recommendation reaches: only the user-risk policy is unresolvable for an external identity — Microsoft is equally explicit that "The Sign-in risk policy is enforced if the external guest user satisfies the grant control." Following the guidance literally therefore drops working sign-in-risk coverage alongside the broken user-risk one. That "all external users" group, once it exists for a legitimate reason, is the easiest lever to reach for the next time a guest sign-in breaks something — and reusing it against the MFA or device-compliance baseline (not just the risk policy it was built for) is how a tenant ends up with zero policies actually evaluating guest sign-ins, even though "All users" technically includes them.

Scoping to roles or groups instead of All users

Scoping a policy to directory roles or specific groups instead of All users structurally excludes guests whenever those roles or groups are populated from internal HR or role data that guest objects don't carry.

For related baseline-coverage failure modes that aren't guest-specific, see Conditional Access Baseline Policy Coverage Gaps, Entra ID and the wider exclusion-and-scope review in Entra ID Conditional Access Gaps.

The External Collaboration Settings That Ship Wide Open

Two of the six gaps sit entirely in External Collaboration Settings, and both of them default to the permissive end of a four- or three-option scale.

GUEST_TO_GUEST_INVITE — guests can invite guests by default

Guest invite settings have four options, from "Anyone in the organization can invite guest users including guests and non-admins (most inclusive)" down to "No one in the organization can invite guest users including admins (most restrictive)." Microsoft's documentation is explicit about which one a tenant starts on: "By default, all users in your organization, including B2B collaboration guest users, can invite external users to B2B collaboration." That is the most inclusive option on the list. Unless an admin has manually restricted it, every guest you have ever invited has always had standing permission to invite more guests into your tenant — no approval, no notification to you, no record beyond the audit log entry for the invitation itself. Azure Tenant Hardening: Fix Insecure Default Settings covers this alongside the other collaboration defaults tenants leave untouched.

GUEST_DIRECTORY_VISIBILITY — the default is not the restrictive option

Guest user access has three levels: same access as members, limited access, or restricted to only their own profile. Microsoft marks the middle option as the default: "Guest users have limited access to properties and memberships of directory objects: (Default) This setting blocks guests from certain directory tasks, like enumerating users, groups, or other directory resources. Guests can see membership of all non-hidden groups." The out-of-the-box behavior lets any guest enumerate the membership of every non-hidden group in your directory — including, if you haven't separately locked this down, groups with role-assignable or privileged membership; see Entra ID Nested Privileged Groups, Role-Assignable Groups, and Guests in Security Groups for what a guest can learn from that visibility alone.

Both settings live on the same admin center page (External Identities > External collaboration settings). Microsoft documents a propagation delay for the guest access level specifically: after you save the restricted setting, "The changes can take up to 15 minutes to take effect for guest users."

Guests Nobody Is Governing

GUEST_NO_EXPIRATION_POLICY — a directly-invited guest has no expiration attached at all

A guest invited directly by email, outside of entitlement management, is what Microsoft's own terminology calls ungoverned. Microsoft's entitlement management documentation draws the line precisely: guests who request access through an access package can be converted to governed, meaning "their account will be deleted or disabled in specified days after their last access package assignment expires." But "guest users that already existed in your tenant by being invited are ungoverned," and once an ungoverned guest loses their last access package assignment, "they'll remain in the tenant indefinitely." A directly-invited guest that was never attached to an access package at all has no expiration mechanism sitting on it whatsoever — not a long default, not a short one, none. It persists until a human notices it and removes it by hand, or until an admin retroactively builds a lifecycle process to catch it.

GUEST_NEVER_SIGNED_IN — invisible to a standard access review until it clears the inactivity window

Entra ID's inactive guest report (ID Governance > Dashboard > Guest access governance) is the tool built to catch this, and it treats never-signed-in guests as their own category: the report explicitly separates "guests who have never signed in or signed in at least once," and for the never-signed-in group, "the inactive days are calculated based on creation date" rather than last sign-in, since there isn't one. The default inactivity threshold is 90 days. Two catches matter operationally: this report requires an Entra ID Governance or Entra Suite license, so tenants without that license can't open it at all, and access reviews built to remove inactive guests deliberately skip any guest created more recently than the configured inactivity window — "this ensures that guests can sign in once before being removed" — so a fresh, never-signed-in guest is invisible to cleanup for as long as that window runs.

Application Access Guests Were Never Assigned

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — Microsoft states the default plainly, in its guidance on restricting an app to a set of users: "Applications registered in a Microsoft Entra tenant are, by default, available to all users of the tenant who authenticate successfully." The control that changes this is Require user assignment, and it is opt-in per application, not on by default. Once a guest has been invited — for one project, one shared document, one meeting — they are "a user of the tenant" for every other application that hasn't turned assignment on, whether or not anyone intended that.

Why this gap survives a portal review

The gap is easy to miss during a portal review because of how it fails: "When user assignment isn't required, unassigned users don't see the app on their My Apps, but they can still sign in to the application itself (also known as SP-initiated sign-on) or they can use the User Access URL." An app that looks locked down — because no guest shows up in its assigned-users list, and no guest sees it on their My Apps page — can still be reachable by any guest who has the direct sign-in link, which is often just the app's normal login URL. Assignment status and visibility are not the same thing, and only assignment actually gates access.

Guests with elevated directory roles compound this specific gap; see Entra Guest Admin Role Cross Tenant B2B Trust for what happens when an under-assigned guest also turns out to hold administrative permissions.

Detection

None of these six gaps show up as an attack signature — they're configuration states you have to query for directly.

Scoping a review to your guest population

To scope an access review to only your external population, the dynamic group rule Microsoft gives as its example is:

(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)

Swap the domain filter for your own, or drop it to catch all guest types.

Remediation

1. Restrict guest invitations

In External collaboration settings, move off the "Anyone... including guests" default. If a handful of people genuinely need invite rights without a full admin role, assign them the Guest Inviter role instead of leaving invitations open to everyone:

Import-Module Microsoft.Graph.Identity.DirectoryManagement

$roleName = "Guest Inviter"
$role = Get-MgDirectoryRole | where {$_.DisplayName -eq $roleName}
$userId = "<user object ID or UPN>"

$DirObject = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
  }

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

One gotcha before you run it: Get-MgDirectoryRole "only returns roles that have been activated," and "not all built-in roles are initially activated." In a tenant where Guest Inviter has never been assigned through the admin center, $role comes back empty and the last line fails. Assign the role once in the portal — which activates it implicitly — or activate it first with the Activate directoryRole API.

2. Tighten guest directory visibility

Move to "restricted to properties and memberships of their own directory objects" unless a specific collaboration scenario genuinely requires guests to browse group membership.

3. Give guests a dedicated, enabled Conditional Access policy

Target "Guest or external users" (all subtypes you use) explicitly, requiring at minimum MFA — don't rely on an "All users" baseline alone. Then audit every existing enabled policy's exclusion list for a "Guest or external users" or "all external users" group, and confirm each one is intentional and still needed, not a risk-policy exclusion that leaked into your MFA baseline.

4. Convert guests to governed access packages

Do this wherever a guest maps to a defined project or engagement, so the lifecycle policy actually attaches an expiration. For guests that will never go through entitlement management, build a recurring access review against the dynamic guest group above with an inactivity threshold and an auto-apply "block, then remove" decision.

5. Turn on the inactive guest report

This requires Entra ID Governance / Entra Suite licensing. Review the never-signed-in category on a schedule — those accounts are invisible to a standard access review until they clear your inactivity window.

6. Require assignment on enterprise apps

Set "Assignment required" to Yes on every enterprise application that shouldn't be open to the whole tenant, then explicitly assign the users or groups — not guests by default — who need it. Re-check apps added outside your standard onboarding process; SAML SSO apps, Application Proxy apps that use Microsoft Entra preauthentication, and OAuth 2.0/OpenID Connect apps that a user or admin has consented to all support this control.

How EtcSec Detects This

EtcSec checks every Azure/Entra audit against all six of these findings: GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN, and GUEST_APP_ACCESS_UNRESTRICTED. They don't all work the same way, and the difference matters when you're deciding what a clean result proves.

Three are evaluated against your tenant's actual state, so their result changes when you fix the underlying setting. GUEST_NO_CA_POLICY reads the include-users assignment of every enabled Conditional Access policy. GUEST_TO_GUEST_INVITE reads the tenant's guest invitation policy. GUEST_NEVER_SIGNED_IN enumerates guest accounts with neither an interactive nor a non-interactive sign-in and reports the count. Those three are the ones that tell you whether last quarter's fix is still in place after the next admin who touches External Collaboration Settings or Conditional Access.

The other three — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, and GUEST_APP_ACCESS_UNRESTRICTED — are raised as tenant-level advisories on every Azure audit rather than being toggled by a single tenant flag. Read them as a standing prompt to re-verify that control in the portal, not as evidence that it's currently misconfigured.

Primary References

• Configure external collaboration settings
• Conditional Access: Users, groups, agents, and workload identities
• Authentication and Conditional Access for B2B users
• Convert guest user lifecycle in entitlement management
• Monitor and clean up stale guest accounts
• Manage access to apps
• Restrict a Microsoft Entra app to a set of users
• Restrict guest user access permissions
• List directoryRoles (Microsoft Graph)
• Customize and filter activity logs in Microsoft Entra ID