B2B Collaboration

Microsoft Entra B2B collaboration is the mechanism for inviting external partners — users from other Microsoft 365 tenants, Google accounts, personal Microsoft accounts, or even ad-hoc email addresses — into your tenant as guest users. The guest signs in with their home identity provider, your tenant trusts the authentication, applies its own Conditional Access on top, and grants whatever access you've configured. No new password is created in your tenant; if the user leaves their home company, their guest access naturally breaks. Configuration lives in Cross-Tenant Access Settings (CTAS). The right pattern for ongoing collaboration with people who aren't employees.

The guest object, and why "naturally breaks" matters

When a B2B invitation is accepted, Entra ID creates a guest user object in your directory — it looks similar to a normal member account in most admin views, but its authentication is delegated entirely to the guest's home identity provider rather than to a password your tenant manages. This has a specific, useful consequence: if the guest leaves their employer and their home-tenant account is disabled, they lose the ability to authenticate into your tenant too, even though their guest object here is untouched — access naturally lapses without your organisation needing to know the guest changed jobs or was offboarded elsewhere. This is a meaningfully different risk profile from creating a separate local account for an external partner, which keeps working until someone on your side remembers to disable it.

Worked example

A company invites an external auditor to review specific SharePoint sites during an annual audit. The auditor is invited as a B2B guest using their own firm's Microsoft 365 email address; they accept the invitation and sign in using their own firm's credentials and MFA — nothing new is created in the auditor's own tenant, and the receiving company never sees or manages the auditor's password. Access is scoped to exactly the SharePoint sites relevant to the audit via group membership, and a Conditional Access policy specific to guest users requires the guest's own tenant to have already enforced MFA (via cross-tenant access trust settings) before granting access. Three months later, the auditor changes firms; their old firm disables their account as part of normal offboarding, and the guest object in the audited company's tenant — never explicitly revoked by anyone there — simply stops being able to authenticate, closing the access gap without the audited company needing to have tracked the auditor's employment status at all.

Guest access reviews are still necessary

Natural lapsing when a guest's home account is disabled is a safety net, not a substitute for active governance — a guest can remain employed at their own organisation for years after a specific project or engagement with your tenant has actually ended, in which case their access here doesn't lapse on its own at all. Entra ID access reviews scoped to guest users, run periodically, are the standard mechanism for catching that case: a resource owner (not IT) attests whether a given guest still needs access, independent of whether the guest's home account is still active.

Common pitfalls

The most common misconfiguration is granting guests broader access than intended by adding them to groups meant for internal employees, rather than to purpose-built guest-access groups scoped to only what the external relationship requires — because a guest object resembles a member object in many views, it's easy to add one to the wrong group without a second thought. The second is not configuring Cross-Tenant Access Settings' inbound trust at all, which means every guest sign-in is challenged by your own Conditional Access from scratch even when the guest's home tenant has already enforced equivalent or stronger requirements.