🌐🧑💼XT - Cross-Tenant Access Defaults
What this policy is about 🌐
Out of the box, an Entra tenant trusts every other Entra tenant on the planet for B2B collaboration. Microsoft chose that default in the early B2B days because it was lonely otherwise. In 2026 it is the identity-equivalent of leaving the back door propped open with a wedge that says "ALL VENDORS WELCOME". 🚪
The Cross-Tenant Access Settings policy is how you change that default to "I don't trust anyone, here is the short list of tenants I have actually agreed to work with." Then you add the customer's accountant, the customer's lawyer, the customer's main supplier, and stop. 📋
This is the policy that turns B2B from "global trust" into "explicit allowlist." On a docs site whose target audience is MSPs serving MKB, this is one of the highest-impact 30 minutes you'll spend.
Why this matters 🎭
The default Cross-Tenant Access state has three failures of imagination:
- Inbound trust = allow. Any user from any other Entra tenant can be invited as a guest into yours. The "invitation" looks like a normal Outlook email. A user who clicks through ends up as a directory object in your tenant. Now they're internal.
- Outbound trust = allow. Any user in your tenant can be invited into any other tenant. The first time you find out is when a vendor's "we'd like to collaborate" workflow auto-provisions Karen-from-accounting as a guest in three external tenants. Karen had no idea. 🤷
- MFA / compliant device trust = not asserted. Even when B2B works, you don't trust the other tenant's MFA. So a guest from your trusted partner has to do MFA again in your tenant, even though they did it in theirs five minutes ago. Either friction or shortcuts; both are bad.
The fix is a default-deny stance plus per-partner allow rules with trust assertions. Three logical sections:
- Default inbound: block. Per partner: explicit allow.
- Default outbound: block. Per partner: explicit allow.
- Trust settings on the partners you do allow: trust their MFA, trust their compliant device claim. Don't make people re-do MFA across tenant boundaries when you've explicitly agreed to trust the other side.
🛠️ Configuration Settings
Configured under Entra admin center → Identity → External Identities → Cross-tenant access settings. Tenant-wide defaults, then per-partner overrides.
Default inbound (from external tenants → your tenant)
| Setting | Value | Why |
|---|---|---|
| B2B collaboration | Block all | Default deny. Per-partner allow follows. |
| B2B direct connect | Block all | Direct connect is for Teams shared channels with another tenant. Block by default. Allow per partner if a shared-channel collaboration is actually agreed. |
| Tenant restrictions v2 | Configure with the same allowlist as B2B | Stops your users from signing in to other tenants from your managed devices unless those tenants are on your allowlist. |
Default outbound (from your tenant → external tenants)
| Setting | Value | Why |
|---|---|---|
| B2B collaboration | Block all | Your users can't be invited into random external tenants. Per-partner allow follows. |
| B2B direct connect | Block all | Same. |
Per-partner allow rules
Each customer maintains an allowlist of partner tenants. For the typical MKB tenant, this is 3 to 8 entries:
- The customer's accountant (their tenant)
- The customer's lawyer (their tenant)
- The customer's main supplier(s) (their tenant)
- A handful of long-running project partners
For each allowlisted partner, configure:
| Setting | Value | Why |
|---|---|---|
| B2B collaboration | Allow | The partner's users can be invited as guests. |
| B2B direct connect | Allow if Teams shared channels are agreed; otherwise Block | Most MKB collaborations don't use shared channels. |
| Trust settings | Trust MFA + Trust compliant device | If the partner's tenant did MFA, accept it. If the partner's tenant says the device is compliant, accept that. No double-MFA, no double-compliance. The partner is on the allowlist; the whole point is to treat their security as adequate. |
| Trust hybrid Entra-joined devices | Allow if the partner has them | Niche; default off. |
Automatic redemption
| Setting | Value | Why |
|---|---|---|
| Automatic guest redemption from allowlisted partners | Enabled | If a partner is on the allowlist, redeeming an invitation as a guest doesn't require a "click this email" dance. The guest just lands. Reduces friction for the legitimate flow. |
Caveats ⚠️
License fit. Cross-Tenant Access Settings are included in Entra ID Free. Trust settings (MFA + compliant device) require Entra ID P1, which is included in Business Premium. ✅
The transition is the hard part. A tenant that's been running "allow all" for years has guest accounts that were created under the old default. Switching to "block all + allowlist" does not retroactively kick existing guests out. You have to audit existing guests, decide who stays, and remove the rest. Allow a separate week for the audit before tightening the default. 📅
Customer-controlled allowlist. The allowlist is per-customer data. It changes when the customer onboards a new supplier or ends a partnership. SuperVision should expose this list as a customer-editable artifact, not bake it into the Golden Master.
Trust MFA is a trust. When you set "Trust MFA from allowlisted partner", you're explicitly accepting that the partner's MFA setup is adequate. If a partner has a weak MFA configuration (SMS-only, or no MFA at all), you should not trust their MFA. The allowlist itself is a partial security check; the trust settings are the rest. Be deliberate. 🤝
Tenant restrictions v2 affects user behavior. A user whose home tenant blocks sign-in to non-allowlisted external tenants will get a "your IT admin has blocked this" message when they try to log into, say, a vendor's portal. Document this for the helpdesk. The "I can't log into our supplier's portal" ticket has an obvious fix (allowlist the supplier) but the user-facing error is opaque. 📣
Direct connect is not B2B collaboration. They are two different surfaces and have to be configured separately. Many people configure B2B and forget direct connect, which leaves Teams shared channels still open. Configure both, even when the answer is "block both."
Reversibility. Cross-Tenant Access Settings are clean-revert. Changes apply on next sync. Existing guest accounts persist regardless of policy changes; clean those up separately as part of the transition audit.
💡 SuperVision tip
Baseline policy. Golden Master → Entra → External Collaboration → Cross-Tenant Access Defaults. The defaults are universal (block inbound, block outbound, MFA + device trust enabled when allowlisted). The allowlist itself is per-tenant.
Tag candidates:
- Partner tenant allowlist: per-tenant. This is the variable. Each customer has 3-8 entries.
- Shared-channel partners: per-tenant. The subset of allowlisted partners that also get B2B direct connect (usually 0-2 per tenant).
Everything else (default deny stance, automatic redemption from allowlist, trust settings format) is fleet identity.
Onboarding. When taking over a customer's tenant, run a one-time existing guest audit before tightening defaults. Pull the full guest list, classify each by source tenant (the partner they came from), categorize as keep / archive / remove. Then implement the defaults + allowlist. Doing it in the other order means tightening the defaults takes effect immediately while the existing guests sit in the directory in an undefined state. Order of operations matters. 📋
Drift detection. Watch two things:
- New entries on the allowlist that weren't added through the SuperVision workflow. Someone with admin rights flipped a partner to "allow" without going through change control.
- Trust settings reverting to defaults. Less common; usually only happens after a Microsoft schema update that resets the setting to the new default. Worth a quarterly check after any major Entra release.
Multi-tenant scaling. Policy is identical across customers. Allowlist composition is per-customer. The MSP-side tooling should support batch import (a customer onboarding sends a CSV of their 5 partner tenants; SuperVision applies it).
👥 Assignment scope
Tenant-wide defaults plus per-partner-tenant overrides. No user-scope. No groups. The "members can invite guests" question is settled in the Default User Permissions policy (the answer is no, only admins).
🔗 Related
- 🏢🧑💼TS - Default User Permissions (the policy that restricts who can invite guests in the first place)
- 🔐🧑💼AMP - Authentication Methods (MFA trust assumes the partner's MFA is adequate; your own MFA is governed here)
- 🔐🧑💼AS - Authentication Strengths (Strengths apply to guest sign-ins via inbound CAs)
Block-by-default plus a short, intentional allowlist. The opposite of how Entra ships. ☑️