What can a guest read in your directory by default?
Guest access in Microsoft Entra ID has three positions and a tenant ships on the middle one. The default is guest users have limited access to properties and memberships of directory objects, which stops a guest enumerating the full user list while leaving a great deal readable. The most restrictive position, guest user access is restricted to properties and memberships of their own directory objects, cuts a guest back to their own profile, and the third gives guests the same access as member users. All three sit under External Identities and then External collaboration settings.
On the restrictive position, a search by user principal name, object identifier or display name stops returning results and group membership stops being readable. Microsoft documents the change as taking up to fifteen minutes to reach guests. It does not do two things people assume it does. A guest can still be assigned an administrative role, which grants full read and write whichever position you choose, and the restriction does not remove a guest's view of groups they have joined inside Teams and some other Microsoft 365 services. Forms, Viva Engage and Project Online are listed as not supported under it, so test the workloads your partners use first.
The gap between those two positions decides what somebody gets when they take over a mailbox at a supplier and open a redeemed invitation. These are directory permissions, enforced through Microsoft Graph, PowerShell, the Azure portal and the My Apps portal. On the default setting a guest reads:
- Display name, email address, sign-in name, user principal name, photo and user type for other users and contacts.
- Manager and direct report relationships, which assemble into the organisation chart a payment redirection attempt needs.
- The properties of every non-hidden group, including its membership and ownership, whether or not the guest was ever added to it.
- The properties of registered and enterprise applications, and the permissions granted to them, which is where an attacker turns once passwords and prompts stop working.
Who is allowed to invite a guest?
In a default tenant the answer is everyone, including guests. Existing B2B collaboration guests can invite further guests, so the population grows without anybody in your organisation approving the last step. The setting has four positions: anyone including guests and non-admins, member users plus specific admin roles, only specific admin roles, and nobody at all. In Microsoft Graph, a tenant nobody has touched reports allowInvitesFrom as everyone.
The third position puts invitation behind the User Administrator and Guest Inviter roles. Guest Inviter is the useful one, because it can be granted to the people who run partner relationships and kept off the service desk. Treat it as a small application process where a team owner asks for the role and accepts that they own the review and the revocation for every guest they create. A blanket block with no delegated path pushes the work into personal email and consumer file sharing.
The Entra setting sits above the Microsoft 365 workload settings, so you can be more restrictive in SharePoint, OneDrive or Teams and never more permissive. Tightening invitations to admin roles only overrides a SharePoint site configured for new and existing guests, and the person sharing the file sees a sharing failure with no mention of the identity policy behind it. That reaches the service desk as a SharePoint fault and gets triaged by the wrong team.
The domain allow or block list on the same page is one policy per tenant and it is one list or the other. It is evaluated at the moment of invitation alongside your cross-tenant access settings, so a pending invitation to a domain you have just blocked fails on redemption while guests who already redeemed are untouched. It governs SharePoint and OneDrive site sharing in every case, and file and folder sharing wherever the Entra B2B integration is on, while SharePoint keeps a separate domain list that does not read it.
Where these settings live, and what to baseline
Two pages under External Identities get confused with each other in change requests. External collaboration settings carries guest access restrictions, guest invite restrictions, self-service sign-up, external user leave settings and the domain list. Cross-tenant access settings carries inbound access, outbound access, trust settings and tenant restrictions. The first applies to any external identity including social and email one-time passcode accounts, the second only to other Microsoft Entra organisations, and they take different roles to administer.
Each setting has a Microsoft Graph object behind it, which is what makes a baseline possible. Guest access and guest invite restrictions live on the authorizationPolicy resource, self-service sign-up on authenticationFlowsPolicy, external user leave settings on externalIdentitiesPolicy, and email one-time passcode on emailAuthenticationMethodConfiguration. Capture those objects, store the expected values and compare them on a schedule, because whether the tenant was configured correctly two years ago is not the question. Changes to cross-tenant access settings land in the audit logs under the CrossTenantAccessSettings category, so an alert there tells you when a partner organisation was added and by whom.
Measure before you tighten a tenant that has been open for years. The cross-tenant access activity workbook, under Monitoring and health then Workbooks, shows which external organisations are genuinely in use, and blocking on the defaults without that evidence takes down a business process on a Monday morning. It reads from logs exported to Azure Monitor, and inside Entra itself sign-in and audit logs are kept for seven days on the free tier and thirty days with a P1 or P2 licence, so the export has to be running well before the tightening starts.
One switch on the neighbouring user settings page gets mistaken for a boundary. Restrict access to the Microsoft Entra administration portal blocks neither Microsoft Graph nor PowerShell, and Microsoft's documentation says not to rely on it as a security control. What keeps external users off Azure management endpoints is a Conditional Access policy targeting the Windows Azure Service Management API.
Should you trust a partner's multi-factor authentication?
Cross-tenant access settings carry three inbound trust checkboxes: trust multifactor authentication from Microsoft Entra tenants, trust compliant devices, and trust Microsoft Entra hybrid joined devices. Ticking one does not remove your Conditional Access requirement, it changes who may satisfy it and where. With multi-factor trust on, Entra accepts a claim that the user completed the challenge in their home tenant and initiates the challenge there if the claim is absent. With it off, the external user has to register a method in your tenant and satisfy your policy there.
The device settings are less optional than they look. A device can be managed by one organisation only and that organisation is the user's home tenant, so a policy requiring a compliant device cannot be satisfied by an external user unless you accept the claim from their tenant. Organisations meet this the first time they scope a device policy to all users and find every partner locked out. The same mechanic sits behind shared channels, where a resource organisation requiring multi-factor authentication without inbound trust blocks the partner users it meant to admit.
Trust commits you to another organisation's factor strength, registration process, session lifetimes and speed of response when one of their users is compromised. That is a per-partner decision, and organisational settings exist to carry it, taking precedence over the defaults with no limit on how many organisations you list. Record the tenant identifier, what the trust covers, who owns the relationship at your end and when it is next reviewed.
Three mechanics catch people out. Sign-ins using granular delegated admin privileges, the path a managed service provider's technicians take, sit outside the trust setting entirely: multi-factor authentication is always required in the technician's home tenant and always trusted in yours, and the only lever you hold is removing the delegated relationship. If you trust multi-factor authentication while the Identity Protection registration policy still applies to external users, those users can satisfy neither requirement. Trust settings, and scoping access to named users, groups or applications, need an Entra ID P1 licence on your tenant, and B2B direct connect needs P1 on both sides.
The partner access that creates no guest object
B2B direct connect is the mechanism behind Teams shared channels with external participants, and B2B collaboration guests are not supported in shared channels at all. It is blocked in both directions by default and works only when both organisations configure it, which is a real control and part of why it gets waved through. What it does not do is create anything in your directory: no user object, no guest, no user type to filter on, because those people authenticate against their own tenant and hold a token in yours that lasts an hour.
Inventory that starts from the directory therefore returns nothing while the collaboration is live. A guest count is silent, a dynamic group filtering on the guest user type is silent, and the offboarding script that enumerates guest accounts at project close will not find these people. Access reviews are the exception worth knowing: a review of a group that is a team can be scoped to external direct connect users added directly to a shared channel, though it will not detect whole teams added to that channel, and only the channel owner can remove those from inside Teams.
Conditional Access reaches these users, but not as far as it reaches guests. Block, require multi-factor authentication, require a compliant device and require a hybrid joined device all work, with the last three depending on the inbound trust settings above. Terms of use, sign-in frequency, persistent browser session, app enforced restrictions and Conditional Access App Control do not apply at all, which removes the session controls you would want most when the identity is not in your directory.
The evidence lives in the logs. Sign-ins are recorded in both organisations, labelled with a cross-tenant access type of B2B direct connect, written when the user first reaches a resource and again when a refresh token is issued. Teams audit events in your tenant cover shared channel creation and deletion and every member added or removed, with no equivalent record in the external user's home tenant.
| Access path | Object in your directory | Conditional Access | Where you find it |
|---|---|---|---|
| B2B collaboration guest | Guest user object created | Grant and session controls apply, aside from approved client app and app protection policy | User list or Microsoft Graph, filtered on the guest user type |
| B2B direct connect user in a shared channel | No object created at all | Grant controls only, and the multi-factor and device ones need inbound trust | Sign-in logs filtered on the direct connect access type, and the Teams admin centre |
| Anonymous sharing link recipient | No object and no sign-in | Nothing to evaluate, because there is no authentication | SharePoint sharing reports, link expiry and link creation settings |
How each external access path shows up in your tenant
Sharing links are an identity source
External sharing in SharePoint and OneDrive is on by default and the organisation-level position is a ceiling. An individual site can be locked down below it and never opened above it, and the OneDrive setting cannot be more permissive than the SharePoint one. Underneath that ceiling, the position a site starts on depends on what kind of site it is, which is how guests arrive as a by-product of ordinary work.
Whether a directory object is created at all depends on one tenant switch. Where SharePoint and OneDrive are integrated with Entra B2B, a guest account is always created and your Entra settings apply to it, so Conditional Access and the invitation restrictions reach whoever opened the link. Where that integration is off, SharePoint's own external authentication is used and your directory holds no record of somebody who can open your files. Microsoft has closed that fork: tenants provisioned after June 2023 have the integration on by default, and from May 2026 it is enabled everywhere regardless of the local setting, with the ability to disable it removed. Enabling it invalidates previously issued one-time passcode links, so plan for content to be reshared.
Anonymous links are the part with no identity at all. Conditional Access has nothing to evaluate, and the controls that remain are link expiry, view-only permission, the default link type a site offers and who may create the links. Recipients who authenticate with a verification code reauthenticate on a period that defaults to thirty days, and the setting allowing guests to share items they do not own is off by default. Turning external sharing off removes guest access within about an hour, which is a containment step worth knowing during an incident.
| Site type | Default external sharing setting |
|---|---|
| OneDrive | Anyone, which permits links that need no sign-in |
| Root communication site on the tenant domain | Anyone |
| Group-connected sites, including those behind Teams | New and existing guests where group owners may add outsiders, otherwise existing guests only |
| Communication sites | No external sharing |
| Modern team sites with no group | No external sharing |
| Classic sites | No external sharing |
Where a site starts before anyone changes it, inside the organisation-level ceiling
A guest review that actually closes accounts
Start from the last time the account was used. Microsoft Graph exposes sign-in activity on the user object with the last interactive, non-interactive and successful sign-in, and reading it needs an Entra ID P1 or P2 licence plus audit log and directory read permissions. Use the successful sign-in property, because the interactive one records failed attempts as well, and allow for the value lagging by up to twenty-four hours. An empty value on a guest created two years ago means the invitation was never redeemed.
Check the licence position before you design around the tooling. Inactive guest insights work at tenant scale, and an access review can be scoped to guest users only, ask the guests themselves to attest in a first stage, put a named internal owner in a second, and apply an outcome that blocks sign-in for thirty days and then removes the account. Access reviews are an Entra ID Governance or Entra Suite capability with some functions still available under P2, scoping a review to inactive users requires Governance specifically, and governance actions on guests run through the ID Governance for guests add-on, billed per active guest against a linked Azure subscription and enforced since January 2026. Where that is out of reach, the manual equivalent is a dynamic group over guest accounts with an inactivity threshold and a named person who works the list.
Closing an account is a sequence: remove the guest from groups and site permissions, block sign-in, leave the disabled object in place for a defined period, then delete it, knowing the deleted object stays recoverable for thirty days. Deleting first destroys the record of what the account could reach, which is the exact question you will be asked if that partner is later breached. Every invitation needs a named internal sponsor, because a review with no owner defaults to keep.
For Australian organisations this is a Privacy Act question as well as a hygiene one. Where the content includes personal information, Australian Privacy Principle 11 requires reasonable steps to protect it from unauthorised access, and a guest population nobody can account for is hard to describe in those terms. It is harder after an incident, when the notifiable data breach scheme gives you thirty days to assess a suspected eligible breach and establish whose information was reachable. A guest holding a directory role is the first thing to hunt for, since that assignment overrides every restriction on this page.
What we look at in an Entra review
Guest and cross-tenant configuration is a fixed part of the Entra ID security reviews we run, and the order is deliberate. We read the external collaboration settings and the cross-tenant defaults before changing anything, list every organisation with individual settings and every trust that has been granted, then reconcile that list against the sign-in logs. The reconciliation is where the findings sit: partners in active use that nobody configured, and configurations serving nobody at all.
Direct connect gets its own pass, because a directory-based inventory cannot see it and shared channels tend to be agreed between two project teams before either identity team hears about it. Attack surface monitoring covers the same ground from outside and over time, since the guest population moves every week that people share files. Whether a partner should be trusted at all, and who sponsors that relationship, is vCISO work. Our approach page sets out how an engagement runs, and every finding names the setting, the object it sits on and the change that closes it.