Entra ID B2B guest access

Entra ID B2B is the mechanism by which external users — partners, customers, contractors — sign into your tenant using their own identity, rather than getting a new account from you. They appear in your directory as guests, and you grant them access to apps, files, and Teams as if they were internal users (with appropriate controls).

How B2B sign-in works

When you invite an external user (an email address from another organisation, a personal Microsoft account, or a Google or Facebook account):

1. Entra ID creates a guest user object in your directory.
2. The user signs in using their home identity provider — most commonly another Entra ID tenant.
3. Authentication happens at the home tenant; your tenant trusts the result.
4. Your tenant applies its own Conditional Access, app role assignments, and access controls on top.

The user doesn't get a new password. Your tenant doesn't store their credentials. If they leave their home company, their account there is disabled and access to your tenant breaks naturally.

Cross-Tenant Access Settings

For B2B with other Microsoft 365 tenants, Cross-Tenant Access Settings (CTAS) give you fine-grained control over both inbound and outbound trust:

• Which other tenants are allowed.
• Which users/groups from them can be invited.
• Which apps they can access.
• Whether the trust covers MFA and device compliance (so the home tenant's MFA satisfies yours).
• Whether shared channels in Teams are enabled with that partner.

CTAS is the modern surface for designing partnership trust — it replaces older per-app or per-user configurations.

Inviting guests

Methods:

• A user clicks Share on a SharePoint file or Teams channel and types an external email.
• An admin invites from the Entra admin center.
• An app provisions guests via the Microsoft Graph.
• An entitlement management access package automates invitations and approvals.

Lifecycle

Guests can drift. Practical hygiene:

• Access reviews for guests, periodically — ask owners to confirm continued need.
• Guest inactivity policies — auto-disable or auto-delete guests not active for N days.
• Sponsorship — make sure every guest has an internal sponsor who's accountable.
• Default user permissions — restrict what guests can see (default is "limited access").

Differences from federation

In B2B, the guest is in your directory as a separate object. In federation (Entra ID's older same-trust model), users live entirely in another directory. B2B is more granular, easier to operate, and the modern default.

For ongoing collaboration, B2B is the right answer for most external relationships. Reserve full account creation for actual employees and long-term contractors.

What "limited access" actually restricts

The default guest experience — limited directory access — is easy to under-appreciate: a guest can see the people and groups relevant to resources explicitly shared with them, but can't browse the full company directory, see other users' profile details beyond basic contact info, or enumerate groups they aren't a member of. This matters when deciding whether a partner needs to be a guest at all versus reachable through a shared channel (B2B direct connect) instead — a guest object, even with limited access, still represents some standing directory footprint and needs the same lifecycle attention (access reviews, inactivity cleanup) that any other guest does, where a shared-channel relationship governed entirely through Cross-Tenant Access Settings creates no local guest object to manage at all.

Frequently asked questions

Can a guest user be assigned Entra ID admin roles? Technically yes for some roles, but it's strongly discouraged and blocked by policy in most well-run tenants — administrative roles assume a level of ongoing accountability and background checking that an external identity, authenticated by a home tenant your organisation doesn't control, doesn't meet; guest role assignment should be treated as an exception requiring explicit sign-off, not a routine grant.

How is guest MFA actually enforced if the guest's home tenant already required it? Cross-Tenant Access Settings' inbound trust configuration lets your tenant accept the home tenant's MFA claim as satisfying your own Conditional Access MFA requirement, avoiding a redundant second challenge — but this trust has to be explicitly configured per partner tenant; without it, your own Conditional Access policies still challenge the guest directly regardless of what their home tenant already enforced.