By default, every one of your users can be invited into any external tenant, and no external MFA is trusted.
Those are the two halves of the default position, and both are usually wrong for a UAE business with real partner relationships. Cross-tenant access settings give granular control over inbound and outbound access, and let you decide whose MFA and device claims you accept.
- No limitOrganisations you can add settings for
- BlockedB2B direct connect, by default
- Not trustedExternal MFA and device claims, by default
- Entra ID P1Needed for trust settings and granular scoping
Eight settings that define your partner trust boundary.
Inbound and outbound as separate decisions
Outbound settings control whether your users can access resources in an external organisation. Inbound settings control whether users from external organisations can access yours. Both can apply to everyone or to specified users, groups and applications, and they are configured independently.
Default settings, and organisational settings that override them
Default settings apply to all external Entra organisations except those with custom settings, and organisational settings take precedence over defaults. There is no limit to the number of organisations you can add, so a per-partner posture is genuinely achievable rather than theoretically available.
Trusting external MFA and device claims
Inbound trust settings determine whether your Conditional Access policies trust MFA, compliant device and Entra hybrid joined device claims from an external organisation where their users already satisfied those requirements at home. Your policies still apply, the user just does not repeat the step.
What the defaults actually are
All internal users are enabled for B2B collaboration, so they can invite guests and be invited elsewhere. MFA and device claims from other organisations are not trusted. B2B direct connect is blocked entirely in both directions. No organisations are in organisational settings and no cross-tenant sync is configured.
Automatic redemption, and why it needs both sides
Automatic redemption removes the consent prompt the first time a user accesses the resource tenant. The critical detail is that it suppresses the prompt and the invitation email only if selected on both the home tenant outbound setting and the resource tenant inbound setting.
Redemption order and fallback identity providers
You can customise which identity providers a guest can redeem with. Fallback providers are Microsoft account, email one-time passcode, or both, and you cannot disable both, though you can disable all primary providers. That is how you stop guests redeeming with a personal Microsoft account.
Tenant restrictions, which sit outside all of this
Tenant restrictions control which external accounts your users can use on devices you manage, including accounts in unknown tenants. Microsoft states they are independent of other cross-tenant access settings, so your inbound, outbound and trust configuration does not affect them at all.
Changes here are protected actions
Any action that modifies cross-tenant access settings is a protected action and can be additionally protected with Conditional Access policies. Changes are captured in audit logs under the CrossTenantAccessSettings category, which is what makes this configuration governable rather than merely configurable.
Block all applications and your users stop being able to read encrypted email.
Microsoft documents three specific traps in restricting cross-tenant access, and each one produces a failure that looks unrelated to the change you made.
- If you block access to all apps by default, users are unable to read emails encrypted with Microsoft Rights Management Service, also known as Office 365 Message Encryption. The fix is to allow application ID 00000012-0000-0000-c000-000000000000 in outbound settings. Allowing only that one leaves everything else blocked by default.
- Conditional Access policies requiring MFA or Terms of Use can prevent users from completing MFA registration or ToU consent in the first place. The documented workaround is allowing application ID 0000000c-0000-0000-c000-000000000000 for the Microsoft App Access Panel and d52792f4-ba38-424d-8140-ada5b883f293 for Entra Terms of Use. Inbound settings for those must be configured through Microsoft Graph because of a current interface limitation.
- If you trust MFA from an external organisation, consider excluding external users from the Entra ID Protection MFA registration policy. Microsoft states plainly that when both policies are present, external users are not able to satisfy the requirements for access. That is a full block produced by two individually sensible settings.
- Finally, access settings for users and groups must match those for applications, and conflicting settings are not allowed. Blocking inbound access for all external users means access to all your applications must also be blocked, and allowing outbound access for your users means at least one application must be allowed.
Four things that keep this from becoming an outage.
We establish current usage before changing anything
Microsoft warns that changing default inbound or outbound settings to block access could break existing business-critical access, and notes sign-in logs are sometimes retained for only 30 days. So we combine log analysis with actually asking the business, rather than treating the logs as complete.
We handle the documented traps up front
Blocking all applications breaks Office 365 Message Encryption unless a specific application ID is allowed. MFA registration and Terms of Use need two more. Trusting external MFA without excluding external users from the ID Protection MFA registration policy blocks them entirely. All three are avoidable and none are obvious.
We design per partner rather than globally
There is no limit on the number of organisations you can add, and organisational settings take precedence over defaults. That means a restrictive default with specific trust for the partners you actually work with, which is a far better posture than either a permissive default or a blanket restriction.
We protect the settings themselves
Any action that modifies cross-tenant access settings is a protected action and can be additionally protected with Conditional Access. Combined with audit monitoring on the CrossTenantAccessSettings category, that turns your partner trust boundary into something governed rather than something anybody with the role can quietly widen.
Four phases across roughly four to six weeks.
- 01Weeks 1 to 2
Find out who is actually collaborating with whom
Microsoft is emphatic about this step, and notes that in some cases sign-in logs are retained for only 30 days, so it strongly recommends speaking with business stakeholders as well. Cross-tenant sign-in activity, inbound and outbound, established before any setting changes.
- Inbound and outbound cross-tenant sign-in activity mapped
- Partner organisations identified with tenant IDs
- Business stakeholders consulted on required access
- Log retention limitation accounted for in the analysis
- 02Week 3
Design the default and per-partner posture
What the default should be for organisations you have no relationship with, and which partners warrant their own organisational settings. Since there is no limit on the number of organisations, the constraint is maintenance effort rather than the platform.
- Default inbound and outbound posture agreed
- Partner list with per-organisation settings designed
- Trust settings decided per partner, not globally
- Application scoping aligned with user and group scoping
- 03Week 4
Handle the known traps before applying anything
The message encryption application, the MFA registration and Terms of Use applications, and the ID Protection MFA registration policy exclusion where external MFA is trusted. Each of these produces a block that looks unrelated to the change that caused it.
- Message encryption application allowed where needed
- MFA registration and ToU application IDs handled
- ID Protection policy exclusion applied where trusting external MFA
- Inbound application settings configured via Graph where required
- 04Weeks 5 to 6
Apply, protect and monitor
Settings applied progressively rather than at once, changes protected as protected actions with Conditional Access, and audit monitoring established using the CrossTenantAccessSettings category so future changes are visible.
- Settings applied in a staged sequence
- Protected actions configured for the settings themselves
- Audit monitoring on CrossTenantAccessSettings established
- Redemption order and fallback providers configured
Six situations where the default position is the wrong one.
A business with a small number of deep partner relationships
The classic case for per-organisation settings. A restrictive default combined with specific inbound and outbound settings and trusted MFA for the handful of partners you genuinely work with gives both a tighter boundary and a smoother experience than the default.
A regulated firm asked who can access its tenant
The honest default answer is that any external Entra organisation is enabled for B2B collaboration, which tends not to satisfy anyone. Moving to an explicit allow list of partner organisations with documented settings turns that into an answer with a list behind it.
An organisation whose partners keep repeating MFA
MFA and device claims from other organisations are not trusted by default, so a partner who has already completed MFA at home does it again in your tenant. Trusting those claims for specific partners removes real friction without weakening your policy, because your policies still apply.
An operator whose staff use personal accounts on managed devices
Tenant restrictions control which external accounts users can use on devices you manage, including accounts created in unknown tenants. They are independent of the other cross-tenant settings, which means an organisation can have a tight collaboration posture and still leave this open.
A company that wants guests off personal Microsoft accounts
Redemption order settings let you turn off Microsoft accounts as a fallback identity provider so guests use an email one-time passcode instead. At least one fallback must remain active, and existing guests continue with their Microsoft account until their redemption status is reset.
A group operating across different Microsoft clouds
Microsoft cloud settings allow mutual B2B collaboration between the commercial cloud and Azure Government including GCC-High and DoD, and between commercial and Azure operated by 21Vianet. The constraint to design around is that B2B direct connect is not supported across different Microsoft clouds.
How UAE organisations manage the partner boundary.
| Feature | Per-partner settings designed | Defaults tightened globally | Defaults untouched |
|---|---|---|---|
Who can be invited out | Scoped | Restricted | Everyone |
Who can come in | Scoped per partner | Restricted | Any Entra tenant |
Partner MFA trusted | Per partner | Rarely | Never |
Partner device claims trusted | Per partner | Rarely | Never |
Guest sign-in friction | Low for trusted partners | High | High |
B2B direct connect available | Where designed | No | Blocked |
Redemption identity providers controlled | Yes | Sometimes | Default order |
Known lockout traps handled | Yes | Discovered the hard way | Not applicable |
Changes audited and protected | Yes | Audited | Audited |
Effort to maintain | Moderate | Low | None |
What your tenant does today if nobody has configured this.
| Setting | Default behaviour | |
|---|---|---|
| B2B collaboration, outbound | All internal users can be invited to external organisations | |
| B2B collaboration, inbound | All external Entra organisations are enabled | |
| External MFA claims | Not trusted | |
| External compliant device claims | Not trusted | |
| External hybrid joined device claims | Not trusted | |
| B2B direct connect | Blocked inbound and outbound for all external tenants | |
| Organisational settings | No organisations added | |
| Cross-tenant synchronisation | No users synchronised in | |
| Precedence | Organisational settings override defaults | |
| Number of organisations you can add | No limit |
Five steps, and the first two are discovery rather than configuration.
- 1
Map inbound and outbound cross-tenant activity
Which external organisations your users sign into, and which sign into you. Microsoft notes sign-in logs are in some cases retained for only 30 days, and strongly recommends speaking with business stakeholders so required access is not lost. We do both rather than one.
- 2
Confirm the partner list and obtain their identifiers
To apply settings to specific users, groups or applications in an external organisation, you need their user object IDs, group object IDs or application IDs. That means contacting the partner, which is the step most likely to set the timeline for the whole engagement.
- 3
Design defaults and per-organisation settings
A default posture for organisations you have no relationship with, and organisational settings for the partners you do, since those take precedence. Trust settings for MFA and device claims decided per partner rather than as a single global switch.
- 4
Pre-empt the documented lockout cases
Message encryption, MFA registration and Terms of Use application IDs allowed where needed, with inbound settings configured through Graph where the interface does not yet support it. External users excluded from the ID Protection MFA registration policy wherever external MFA is trusted.
- 5
Apply in stages, then govern the settings
Changes applied progressively with monitoring between stages, redemption order and fallback identity providers configured, protected actions enabled on the settings themselves, and audit monitoring established on the CrossTenantAccessSettings category.
What organisations ask about cross-tenant access.
Fifteen questions about your own tenant boundary.
Current state
- Has anyone configured cross-tenant access?Often nobody has.
- Which external tenants do we sign into?Outbound activity.
- Which external tenants sign into us?Inbound activity.
- Do we know our partner tenant IDs?Needed for organisational settings.
- How far back do our sign-in logs go?Sometimes only 30 days.
Trust
- Do we want to trust partner MFA?Not trusted by default.
- Do we want to trust compliant device claims?Same default.
- Is that per partner or global?Per partner is usually right.
- Have we excluded external users from ID Protection MFA registration?Required if trusting MFA.
- Do we need B2B direct connect anywhere?Blocked by default, needs P1 both sides.
Guardrails
- Have we allowed the message encryption app?Or encrypted mail breaks.
- Have we allowed MFA registration and ToU apps?Two specific app IDs.
- Do our user and application settings agree?Conflicts are rejected.
- Can guests redeem with personal Microsoft accounts?Configurable.
- Are changes here protected actions?They can be.
Open cross-tenant access settings and look at the organisational settings tab.
If it is empty, every external Entra organisation is enabled for B2B collaboration with you and none of their MFA is trusted. That is the default, and it is rarely the position anybody would choose deliberately.
Related Services
Explore more solutions that work great with this service
Entra External ID
Guests, partners and customer identity, governed
Entra Entitlement Management
Access packages that expire on their own
Entra Conditional Access
The control that decides who reaches your data
Entra Access Reviews
Recurring recertification of groups, apps and roles
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
Microsoft Entra
Identity and access management solutions
Entra ID Governance
Joiner mover leaver, access packages and guests that expire on their own
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own