Locking Down Guest-to-Guest Invitations in Microsoft Entra: A Strategic Look at Identity Sprawl

Most identity risk does not arrive as a breach headline. It accumulates quietly, through defaults nobody revisited. Microsoft Entra ID has one of those defaults sitting in plain sight: out of the box, every user in your tenant can invite external guests, and that includes the external guests themselves. A vendor you onboarded last quarter can bring in their subcontractor, who can bring in another party, and none of those secondary accounts are tied to anyone on your staff who can vouch for them.

This is a configuration decision worth treating as a governance decision, not a checkbox. For organisations running a zero trust strategy, leaving invitation rights wide open contradicts the entire premise. Below is what the default actually exposes, how the major cloud identity providers handle the same problem, and the practical steps to close the gap in Entra.

What changed, and what the default really grants

Nothing changed in Entra itself here. What changes is your awareness of a setting that has always been permissive. The reason it matters now is that hybrid and multi-tenant collaboration has become the norm, and the volume of B2B guest accounts in a typical tenant has grown well beyond what most identity teams track manually.

By default, an external guest user can see considerably more than the file or Teams channel they were invited to. Guests can read directory objects, search for other users, and read the membership and ownership of any non-hidden group. In practice, that means an external partner, a customer, or a malicious actor who gains a foothold can map your internal org structure quickly: who reports to whom, which groups exist, who owns them.

Here is the contrast between the default guest permission set and the restricted set Entra can enforce:

Area	Default guest permissions	Restricted guest permissions
Users & Contacts	Read display name, email, sign-in name, photo, UPN, and user type of other users; read manager and direct report info; search for users by object ID; read and change own properties	Read and change only their own properties; manage their own mobile number
Groups	Read properties, membership, and ownership of non-hidden groups, including non-joined ones; search groups by name or object ID	Read object ID and membership only for groups they have joined
Applications	Read properties of registered and enterprise apps; list granted permissions	Read properties of registered and enterprise apps; list granted permissions
Organization	Read company name, all domains, certificate-based auth config	Read company name and all domains

The sharing dimension compounds the visibility problem. Standard tenant profiles let guests share files, Teams, and SharePoint sites outward. Combine outbound sharing with guest-to-guest invitations and you get a self-propagating access chain. The internal sponsor who approved the original guest has no line of sight to the secondary and tertiary accounts that follow.

How this compares across providers

If you are running a multi-cloud identity strategy, it helps to see that this is not a Microsoft-specific quirk. Every major provider has a model for external collaboration, and each draws the default line in a different place.

Microsoft Entra ID is the most permissive by default. The B2B guest model is designed around frictionless collaboration, which is excellent for adoption and poor for governance until you tighten it. The invitation control is a tenant-wide toggle, which makes remediation fast but also means the default applies to everyone equally. Documentation lives at Microsoft Learn for External Identities.

AWS takes a structurally different approach. There is no direct equivalent to a guest who can invite further guests, because cross-account access is handled through IAM roles and trust policies, or through AWS IAM Identity Center for workforce federation. External access is explicit and role-scoped, so the sprawl risk shifts from "who can invite whom" to "who can assume which role." That is arguably harder to reason about for non-specialists, but it removes the viral-invitation pattern entirely. The trade-off is friction: every external relationship is an engineering artifact, not a self-service invite.

Google Cloud and Google Workspace sit between the two. External sharing in Workspace is governed centrally through admin policies, and Google has historically defaulted to more restrictive external sharing for enterprise tiers, with domain allow-listing as a common control. Cloud Identity does not hand end users a built-in mechanism to invite arbitrary external accounts into the directory the way Entra's guest invite default does. Details are in the Cloud Identity documentation.

The pattern across all three: AWS forces explicit role-based external access and avoids the invitation chain by design, Google centralises the policy and defaults conservatively, and Entra optimises for ease of collaboration and asks you to opt into the stricter posture. None of these is wrong, but if your team carries assumptions from one provider into another, Entra's open default is exactly the kind of thing that slips through.

Why the guest lifecycle makes this urgent

The deeper problem is that you do not control the home organisation of your guests. When an external collaborator leaves their employer, their account can remain active and valid in your tenant indefinitely. Their former employer has no reason to tell you, and frequently no idea the account exists as a guest elsewhere. If that home organisation has weak joiner-mover-leaver processes, the dormant guest becomes a standing, unmonitored entry point into your data.

Guest-to-guest invitations turn a manageable problem into an untraceable one. A single approved guest can seed a tree of downstream accounts, each inheriting access, none anchored to an accountable internal owner. Over months, these orphaned identities accumulate and degrade your overall identity posture in ways that are difficult to audit after the fact. Cutting off the ability for guests to invite other guests keeps every external identity tied back to a responsible internal sponsor, which is the precondition for any meaningful access review later.

Closing the gap in Entra

The change itself takes under a minute and applies going forward only. Existing guests are unaffected, so this is a low-risk adjustment you can make without a change-freeze conversation.

1. Sign in to the Microsoft Entra admin center with at least User Administrator privileges.
2. Expand Entra ID, go to External Identities, and select External collaboration settings.
3. Find the Guest invite settings section.
4. Select Member users and users assigned to specific admin roles can invite guest users. This blocks guests from inviting anyone while still letting your internal staff collaborate. For tighter control, choose Only users assigned to specific admin roles can invite guest users to route every invitation through a defined administrative channel.
5. Click Save at the top of the portal.

While you are in this screen, it is worth also reviewing the guest permission level discussed above and restricting it to own-profile objects, which stops guests from browsing your directory and group memberships.

Business impact

The cost of this change is effectively zero, and the return is a clear, enforceable boundary on who introduces external identities into your environment. For a regulated organisation, that boundary is also an audit story: you can demonstrate that external access flows through authorised channels rather than self-service propagation, which matters for frameworks that expect documented onboarding and accountable ownership of every identity.

Treat this as one control in a larger program rather than a fix on its own. Pair the invitation restriction with scheduled access reviews so that the guest accounts you do approve are revalidated and expired on a cadence. The invitation toggle stops new sprawl; access reviews clean up what already accumulated. Together they bring external collaboration back under the same lifecycle discipline you apply to employees, which is where any serious zero trust effort needs it to be.