Cross-Tenant Access Settings

Cross-Tenant Access Settings (CTAS) in Microsoft Entra ID govern the trust relationship between your tenant and other Microsoft 365 tenants — for B2B collaboration, Teams shared channels, Multi-Tenant Organisations, and cross-tenant synchronization. Configured in the Entra admin center → External Identities → Cross-tenant access settings. Includes inbound controls (which external tenants' users can be invited or trusted with shared resources, with what conditions) and outbound controls (how your users can collaborate externally). Granular per-tenant trust lets you require external MFA / compliant device for some partners while blocking others entirely. The modern surface for designing partner-collaboration architecture.

Default vs per-organization settings

CTAS operates on two layers: a default configuration that applies to every external tenant not otherwise specified, and per-organization overrides for specific partner tenants identified by their tenant ID. A common pattern is a restrictive default (block B2B collaboration entirely, or require MFA and a compliant device from any external user before trusting them) combined with a small number of per-organization exceptions for tenants with an active, known business relationship — a parent company, a long-term outsourcing partner, a joint venture. This inverts the older, flatter model where B2B trust was largely all-or-nothing per feature.

Worked example

A company runs a joint venture with a partner organisation and wants employees on both sides to collaborate in Teams shared channels, while keeping its default posture closed to unknown external tenants. In CTAS, the default inbound and outbound settings block B2B collaboration and B2B direct connect entirely. A per-organization entry is added for the partner's specific tenant ID, enabling B2B direct connect for shared channels and B2B collaboration for guest invitations, with inbound trust settings requiring that the partner's own Conditional Access has already enforced MFA and a compliant device (Entra ID can trust another tenant's MFA claim rather than re-challenging the user, via the "trust settings" section) — so a partner employee who already passed their home tenant's own security requirements isn't forced through a redundant separate MFA prompt, while any tenant not explicitly listed remains fully blocked.

B2B direct connect and Teams shared channels

CTAS is also the configuration surface for B2B direct connect, the mechanism behind Teams shared channels: unlike ordinary B2B collaboration (which invites an external user as a guest object in your directory), direct connect lets an external user participate in a shared channel using their own home-tenant identity with no guest object created in your tenant at all. That distinction matters for lifecycle management — a guest object needs its own access reviews and offboarding process, while a direct-connect relationship's access is entirely governed by CTAS and disappears automatically the moment CTAS trust for that tenant is revoked.

Common pitfalls

The most common oversight is configuring outbound settings (how your users can collaborate elsewhere) far more loosely than inbound (who can come into your tenant), on the assumption that outbound risk is lower — but an employee joining an untrusted external tenant's shared channel can still expose your organisation's data if what they share there isn't otherwise governed by DLP or sensitivity labels. The second is forgetting that CTAS's per-organization list requires knowing the partner's actual tenant ID, not just their domain name, which needs to be obtained from the partner directly (their Entra ID overview page shows it) before an accurate per-organization override can be configured at all.