Cross-tenant access settings decide how well B2B collaboration works

When I look into Microsoft Entra tenants, cross-tenant access settings are one of the areas where people are often unsure what they're doing. Most organisations now need structured collaboration with partners and suppliers, but they don't want to open the doors too wide either. Defaults that are too restrictive get in the way of people's work. Rules that are too permissive bring risk and cause headaches later. With Entra ID External ID for B2B collaboration, how you configure cross-tenant access settings largely decides whether guests have a smooth experience or your helpdesk gets flooded.

Cross-tenant access settings control the trust you exchange with partner tenants

The principle itself is simple. Cross-tenant access settings in Entra ID let you control, inbound and outbound, which authentication and device trust claims you accept from partner tenants or send to them (see docs). This applies to classic B2B guest accounts, to B2B direct connect (for Teams shared channels) and to automatic invitation redemption. Global defaults apply to all unknown tenants, and on top of that you can add tenant-specific rules for partners you explicitly trust.

In practice, that split matters a lot. For "everyone else", restrictive defaults (often: block guest sign-in, don't accept device or MFA claims) keep you on the safe side. For a small set of vetted partner tenants you can then grant inbound and outbound trust that fits the relationship. One example is accepting inbound MFA or compliant device claims for guests, so your policies do what they're meant to without prompting people over and over.

Trusting partner MFA and device claims ends the double prompts

I run into this one again and again. A guest wants to open a Teams shared channel or a SharePoint site and gets asked for MFA or device compliance in their home organisation, then again in yours. For the guest, that's pointless friction. If you configure cross-tenant access settings to trust the partner tenant's MFA and device compliance status (assuming their policies are up to par), Entra Conditional Access policies can treat those claims as if they came from your own users.

You set this trust per partner tenant: open the partner and select what you want to accept. The Microsoft documentation walks through it in detail. In my experience, this one configuration step makes a big difference for regular B2B guests, and it doesn't lower your security bar. The flow usually looks like this:

flowchart TD
    GuestUser["Guest user signs in"] --> HomeTenant["Home tenant enforces MFA & device"]
    HomeTenant --> PartnerTenant["Partner tenant trusts claims"]
    PartnerTenant --> CondAccess["Conditional Access checks claims"]
    CondAccess --> Access["Resource access granted"]

Figure: How MFA and device compliance claims are passed on for guest access

B2B direct connect and multi-tenant setups need explicit partner rules

Teams shared channels (B2B direct connect) require explicit partner tenant rules. Leave this too open and you can overshare without meaning to, which I've written about in /blog/copilot-for-microsoft-365-tenant-readiness. The cross-tenant access settings determine exactly which organisations can use shared channels and whether guests can redeem invitations automatically.

If you run a multi-tenant organisation, meaning you operate several tenants yourself, cross-tenant synchronization becomes relevant. It lets you sync user identities across tenants from a central point, and the same cross-tenant access settings keep access, trust and claims under control.

Tenant Restrictions v2 controls where your accounts can sign in

Tenant Restrictions v2 (in public preview as of today, see docs) adds another layer. It limits which tenants your users can sign into from corporate devices, so company identities don't end up in shadow IT or in environments nobody knows about. Enforcement happens via proxy or client, and the integration with Entra ID gives you far finer control than the old v1 model did.

A basic example that allows only specific partner tenants:

{
  "AllowedTenants": [
    "contoso.com",
    "partnercompany.com"
  ],
  "DefaultPolicy": "Block"
}

Tip from experience: Before you roll out Tenant Restrictions v2, get a clear, documented picture of your actual partner tenants and cross-tenant access settings. Otherwise you'll block legitimate collaboration by mistake.

Default deny with explicit allows and regular reviews works best

After working with dozens of tenants, this is the approach I've seen work best:

• Default cross-tenant settings: as restrictive as possible (block guest access, don't accept external claims)
• For trusted partners: create explicit rules that grant only the trust actually needed (MFA/devices), and write down why
• Don't trust MFA or device claims unless you know the partner's security posture
• Keep documentation for every cross-tenant and tenant restrictions policy
• Review and clean up guest and partner access regularly (more on that here)

This is rarely something you configure once and leave alone. New partners, projects and features keep coming, so you need to repeat the reviews.

The review cycle matters more than any single setting

No single configuration fits every organisation. What I've come to see clearly, though, is that secure and smooth B2B collaboration comes from cross-tenant access settings that are set up carefully and documented well, combined with regular access reviews. Entra ID External ID gives you plenty of capability. Whether it works out depends on handling it with a steady hand and a clear structure rather than just ticking boxes.