Cross-tenant access settings: the safe defaults

Keep B2B direct connect blocked by default and allow it only for named partner organisations; trust inbound MFA from partners you work with.

Every Microsoft 365 security check · Collaboration & Sharing · NL-COL-008

What this check looks at

Checks the default cross-tenant access settings: whether any other organisation can connect to Teams shared channels (B2B direct connect), and whether MFA done in a guest’s home tenant is trusted.

Cross-tenant access settings in Microsoft Entra decide how your tenant works with other Microsoft Entra organisations, before any guest is invited. The default settings apply to every organisation you have not set up individually. Two parts matter here: B2B direct connect, which lets people in another organisation join your Teams shared channels (and yours join theirs) without guest accounts, and inbound trust, which decides whether your Conditional Access accepts the MFA a guest already did in their home tenant. Microsoft’s defaults block direct connect both ways and do not trust other tenants’ MFA.

The check reads the default settings. It fails when inbound B2B direct connect is open to all users of any organisation, and warns when outbound direct connect is open to all your users, or when MFA from guests’ home tenants is not trusted, listing every issue found. Teams external access (chat and calls) is set elsewhere and covered by the Teams checks.

Inbound direct connect open to every tenant means your users can add any outside person to a shared channel, with no guest object in your directory to review, remove or include in an access review. Not trusting partner MFA is less obvious: guests are asked to register MFA again in your tenant, they complain, and the usual response is to exclude guests from the MFA policy, which leaves them with no MFA at all.

Why it matters

Cross-tenant defaults decide who from outside can reach your people and data before any guest review happens. Direct connect open to every tenant lets any organisation share channels with your users; not trusting partner MFA means guests either get prompted twice or, worse, policies get loosened to stop the complaints.

A typical case: a project manager at a housing provider creates a Teams shared channel with a contractor. Because direct connect is open by default, a colleague adds someone from a third company the organisation has never vetted. The channel’s files include tenants’ repair records, and the organisation has no guest account to show who that person was or to remove.

The MFA trust problem plays out differently: after complaints about double prompts, guests are excluded from the MFA policy. Months later a partner employee’s password leaks, and the attacker signs in to your tenant as that guest with nothing more than the password.

This supports ISO 27001 A.5.14 (information transfer), and the NCSC Cyber Assessment Framework’s B2.d on identity and access management and A4.a on supply chain. Trusting the MFA of partner tenants is Microsoft’s own recommendation for B2B collaboration.

How to fix it

Where: Entra admin centre → External Identities → Cross-tenant access settings

Before you start

  • List the partner organisations you share Teams channels with, and check whether they enforce MFA.

Step by step

  1. List the partners that need shared channels. Ask Teams owners which outside organisations they share channels with, and note each organisation’s domain or tenant ID. Those get their own organisational settings; everyone else gets the blocked default.
  2. Block inbound direct connect by default. In the Microsoft Entra admin centre, go to Entra ID > External Identities > Cross-tenant access settings and open the Default settings tab. Select Edit inbound defaults, open the B2B direct connect tab, set External users and groups to Block access for all external users and groups, and Applications to Block access for all applications. Select Save.
  3. Trust MFA from other Microsoft Entra tenants. Still in the inbound defaults, open the Trust settings tab, tick "Trust multifactor authentication from Microsoft Entra tenants" and select Save. Guests then satisfy your MFA policy with the MFA they did at home.
  4. Block outbound direct connect by default. Back on the Default settings tab, select Edit outbound defaults, open B2B direct connect, set Users and groups to Block access for all users, and External applications to Block access for all. Select Save.
  5. Allow named partners. Open the Organisational settings tab, select Add organisation, enter the partner’s domain or tenant ID and select Add. In its row, open the inbound access settings, choose to customise them, and on B2B direct connect allow all external users (or a group) and all applications; do the same for outbound. Save, and ask the partner to make the matching change in their tenant.
  6. Or set the MFA trust in Graph PowerShell. Connect-MgGraph -Scopes Policy.ReadWrite.CrossTenantAccess, then run Update-MgPolicyCrossTenantAccessPolicyDefault -BodyParameter @{ inboundTrust = @{ isMfaAccepted = $true } }.
  7. Confirm the change. On the Default settings tab, inbound and outbound B2B direct connect show as blocked and inbound trust shows MFA accepted, and your partners appear on the Organisational settings tab. A guest signing in is no longer asked to register MFA in your tenant.

What users will notice

None for existing collaboration. Shared channels work only with the partners you allow.

How to confirm it worked

Entra ID, External Identities, Cross-tenant access settings: default B2B direct connect is blocked and named partners are configured.

Frameworks and controls

This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The frameworks and controls NL-COL-008 maps to
FrameworkControl
NCSC CAFB2.d Identity and access management (IdAM)A4.a Supply chain
DSPTStandard 10: Accountable suppliers
DORAArt. 9(4)(c) Limiting logical access to what is required
NIS2Art. 21(2)(d) Supply chain security
Microsoft Cloud Security BenchmarkIM-7 Restrict resource access based on conditions
Zero TrustIdentities
SOC 2CC6.6 Protection against threats from outside the system boundaries
NIST SP 800-1713.1.20 Verify and control connections to external systems
CMMC Level 2AC.L2-3.1.20 External Connections
ISO 27001:2022A.5.14 Information transfer
CIS Controls v8.16.7 Centralize access control (IG2)
NIST CSF 2.0PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
NCSC 10 StepsIdentity and access managementSupply chain security

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

The full Microsoft 365 security checklist, worst first

Check this in every tenant.

ConfigCheckup runs this check on every tenant you connect and offers an approved fix. You see a dry run of exactly what will change, approve it, and can roll it back.

14 days of daily monitoring and alerts, every finding with its fix guide, and reports on up to 3 tenants, from your first connected tenant. No card. Then choose the plan that fits.Where this check fits: Microsoft 365 security assessment for MSPs