Browse all topics
Microsoft Entra (Identity)

Cross-Tenant Access Settings design

How to design Cross-Tenant Access Settings (CTAS) — the foundational trust controls for B2B and cross-tenant collaboration.

Cross-Tenant Access Settings (CTAS) in Microsoft Entra ID govern trust relationships between your tenant and other Microsoft 365 tenants. They're how you decide what B2B collaboration, shared channels, and multi-tenant access look like in your environment. For organisations doing meaningful cross-tenant work, designing CTAS deliberately is the right pattern.

The two directions

CTAS has two halves:

Inbound

How your tenant treats users coming in from other tenants:

  • Which other tenants' users you accept as B2B guests.
  • Which apps they can access.
  • Whether their home-tenant MFA / device-compliance satisfies your requirements.
  • Whether shared channels in Teams work with them.

Outbound

How your tenant treats your users going out to other tenants:

  • Which other tenants your users can access.
  • Whether they sign in to those tenants automatically.
  • Which apps in those tenants they can use.

Both halves matter; design them together.

Default posture

The default settings (out-of-the-box for new tenants) are typically:

  • Inbound: B2B allowed, no specific tenant trust.
  • Outbound: users can access any other tenant they're invited to.

This is permissive but reasonable for most organisations. Customise where specific requirements exist.

Per-tenant configuration

CTAS supports per-tenant configuration — different trust settings per partner tenant. Useful for:

Trusted partners

For frequent collaborators, configure:

  • Trust their MFA — their MFA satisfies yours (users don't double-prompt).
  • Trust their compliant device claim — their managed device satisfies yours.
  • Auto-redemption — invitations from your users to theirs auto-redeem.
  • Shared channels enabled both ways.

The user experience: from a trusted partner tenant, sign-in to your tenant feels almost like signing into their own.

Restricted partners

For high-risk relationships, configure:

  • No trust of partner MFA — require fresh MFA on every sign-in.
  • No trust of partner device compliance.
  • Restricted app access — only specific apps.
  • No shared channels.

The user experience: every sign-in requires fresh authentication.

Blocked tenants

For specific tenants you don't want any interaction with, block entirely.

Multi-Tenant Organisation

For organisations operating multiple Microsoft 365 tenants as one entity, Multi-Tenant Organisation (MTO) is a CTAS preset:

  • All MTO member tenants trust each other broadly.
  • Cross-tenant user synchronisation provisions guests automatically.
  • Shared channels work cleanly.
  • Unified people search.

Configured by joining tenants to an MTO; CTAS for those tenants is configured collectively.

Tenant Restrictions v2

For outbound, Tenant Restrictions v2 lets you restrict which tenants users on your network can sign into:

  • Block sign-in to non-trusted tenants from the corporate network.
  • Restrict OAuth consent to apps from non-trusted tenants.
  • Force user-specific allowlist for which external tenants are reachable.

Used by organisations wanting to prevent staff from logging into personal accounts or unsanctioned partner tenants while on the corporate network.

Configuration pattern

A pragmatic configuration:

Default

  • Inbound: B2B allowed with all features (MFA required).
  • Outbound: open.

Trusted partner tenants

  • Inbound: trust MFA, trust compliant device, auto-redeem.
  • Shared channels: enabled with specific shared channels.

Specific blocked tenants

  • Inbound: block entirely.
  • Outbound: block specific tenants if needed (Tenant Restrictions v2).

Operational considerations

  • Periodic review of CTAS configuration — partnerships change.
  • Document each tenant relationship — why this tenant has this trust level.
  • Communicate to users — they should understand which partners get smooth experience vs restricted.
  • Audit cross-tenant access — sign-in logs show cross-tenant authentication patterns.

Cross-tenant synchronization

A specific CTAS-enabled feature: cross-tenant synchronization auto-provisions B2B guests from one tenant to another based on rules:

  • Source tenant publishes specific users.
  • Target tenant auto-creates B2B guest objects for them.
  • Attribute sync keeps profile data current.

Used heavily in MTO scenarios; useful for any persistent multi-tenant relationship.

Shared channels specifically

For Teams shared channels with external tenants, both tenants must configure CTAS to enable shared channels for the partnership. Asymmetric configuration breaks shared channels. Coordinate explicitly with the partner organisation.

Cross-cloud (commercial vs government)

CTAS between commercial and government clouds is restricted:

  • GCC ↔ commercial — B2B works with limitations.
  • GCC High ↔ commercial — restricted further.
  • DoD ↔ commercial — most cross-cloud scenarios blocked.

For organisations spanning clouds, plan carefully.

Common pitfalls

  • Default open — no thought given to CTAS until something goes wrong.
  • One-sided configuration — shared channels need both ends configured.
  • No documentation — why specific partners have specific trust levels.
  • No periodic review — old partner trust persists when partnership ends.
  • CTAS confused with Conditional Access — different layers.

For Microsoft 365 customers with meaningful cross-tenant relationships, CTAS is foundational. Configure deliberately; document why; review periodically. Without it, partnerships are ad-hoc; with it, partnerships are governed.