Cross-tenant access settings: controlling who comes in, who goes out, and to which tenants
By default, an Entra ID tenant collaborates with any other tenant, in both directions. Cross-tenant access settings let you distinguish trusted partners from strangers, and even stop your users signing in to foreign tenants.
Inbound and outbound: two directions to configure
Cross-tenant access settings (External Identities > Cross-tenant access settings) separate two flows. Inbound determines which external users can reach your resources; outbound determines which tenants your users can access as guests. For each, B2B collaboration and B2B direct connect are configured separately, and you can filter by users, groups and applications.
Default settings and per-organisation settings
Default settings apply to every tenant that is not listed. Out of the box, B2B collaboration is open and B2B direct connect is blocked. Organisational settings add exceptions for a specific tenant and take precedence over the defaults. A cautious approach is to tighten the defaults, then explicitly open access for real partners. That requires an inventory first: sign-in logs show which tenants your users actually work with.
Trusting MFA and device claims
Without configuration, a guest has to register an MFA method in your tenant on top of the one in their own organisation. Inbound trust settings let you accept:
- multifactor authentication performed in the home tenant;
- devices marked compliant by the home tenant;
- the partner's Microsoft Entra hybrid joined devices.
These options improve the experience and let your Conditional Access policies require MFA for guests without friction. They should only be granted to organisations whose standards you know, because you are delegating part of your control.
B2B direct connect and Teams shared channels
B2B direct connect lets an external user reach a resource without a guest account in your directory. Its main use today is Teams shared channels. It requires mutual configuration: both organisations must allow it, one outbound and the other inbound. Because no guest object is created, visibility comes from logs and Teams reporting, so enable it organisation by organisation, never as a default.
Key point. Blocking outbound access in cross-tenant settings does not stop a user signing in to another tenant with an account created there. That is what tenant restrictions v2 are for.
Tenant restrictions v2
Tenant restrictions v2 address exfiltration through foreign tenants: an employee using a corporate device to sign in to a personal tenant, or a third party's, and uploading data there. The policy is defined in cross-tenant access settings and then has to be enforced on the network or the endpoint: a header injected by the corporate proxy, Global Secure Access, or a policy on managed Windows devices. Scope and enforcement options continue to evolve, so check the current prerequisites before deploying.
Where to start
- export the current settings and list the organisations already configured;
- identify partner tenants from sign-in logs;
- tighten the defaults and open access per organisation;
- grant MFA and device trust only to assessed partners;
- pilot tenant restrictions v2 with a small group before a wider rollout.