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
- 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.
- 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.
- 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.
- 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.
- 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.
- Or set the MFA trust in Graph PowerShell. Connect-MgGraph -Scopes Policy.ReadWrite.CrossTenantAccess, then run Update-MgPolicyCrossTenantAccessPolicyDefault -BodyParameter @{ inboundTrust = @{ isMfaAccepted = $true } }.
- 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.
| Framework | Control |
|---|---|
| NCSC CAF | B2.d Identity and access management (IdAM)A4.a Supply chain |
| DSPT | Standard 10: Accountable suppliers |
| DORA | Art. 9(4)(c) Limiting logical access to what is required |
| NIS2 | Art. 21(2)(d) Supply chain security |
| Microsoft Cloud Security Benchmark | IM-7 Restrict resource access based on conditions |
| Zero Trust | Identities |
| SOC 2 | CC6.6 Protection against threats from outside the system boundaries |
| NIST SP 800-171 | 3.1.20 Verify and control connections to external systems |
| CMMC Level 2 | AC.L2-3.1.20 External Connections |
| ISO 27001:2022 | A.5.14 Information transfer |
| CIS Controls v8.1 | 6.7 Centralize access control (IG2) |
| NIST CSF 2.0 | PR.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 Steps | Identity and access managementSupply chain security |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Cross-tenant access overview (Microsoft Learn)
- Teams external access (Microsoft Learn)