Microsoft Entra external identity trust architecture

Microsoft Entra Cross-Tenant Access Settings Guide

Q: What is the difference between inbound and outbound cross-tenant access?

Inbound controls external identities accessing your resources; outbound controls your identities accessing external resources.

Q: Does B2B direct connect require both organizations to configure access?

Yes. Both tenants must enable the intended direct-connect access.

Q: What does trusting an external MFA or device claim mean?

The resource tenant accepts the specified home-tenant claim for Conditional Access evaluation; it does not copy the partner's policy.

Q: Does configuring tenant restrictions v2 in the portal enforce it automatically?

No. The cloud policy needs supported enforcement signaling on the relevant traffic.

Q: What should be tested before production?

Test both directions, identities, apps, guest and direct-connect paths, trust claims, Conditional Access, restrictions, synchronization, logs, offboarding, and rollback.

Govern who can collaborate across Microsoft Entra organizations, which resources they can reach, which home-tenant MFA and device claims you trust, and how partner exceptions, B2B collaboration, direct connect, synchronization, and tenant restrictions are tested and reviewed.

Inbound and outbound accessB2B collaborationB2B direct connectTrust claimsTenant restrictions

Request a cross-tenant review Review external collaboration

Microsoft Entra cross-tenant access settings architecture with inbound and outbound policy lanes, partner-specific gates, trust claims, direct connect, and tenant restrictions — Cross-tenant access is bilateral: the resource tenant, home tenant, user, application, trust claim, and enforcement path all affect the outcome.

Operating model

Read every setting from the direction of the identity and the resource

Cross-tenant access settings determine how your workforce tenant collaborates with other Microsoft Entra organizations. Inbound settings control external identities accessing your resources. Outbound settings control your identities accessing resources in another organization. Default settings apply to partners without organization-specific customization; partner settings can narrow or expand selected users, groups, applications, trust, synchronization, and tenant-restriction behavior.

These controls do not stand alone. External collaboration settings govern guest invitation, directory visibility, and domain restrictions. Conditional Access evaluates the actual sign-in and can require MFA, device state, or other controls. Teams, SharePoint, Exchange, applications, entitlement management, and cross-tenant synchronization add service-specific authorization and lifecycle.

Direction test: name the home tenant, resource tenant, identity type, target app, and policy direction in every change ticket. “Allow the partner” is not a testable requirement.

Minimum partner record

Verified legal name, tenant ID, domains, cloud, privacy/security contacts, sponsor, business purpose, contract, and review date
Inbound and outbound B2B collaboration, B2B direct connect, trust, tenant restrictions, automatic redemption, and sync settings
Included/excluded users, groups, applications, object IDs, owner, sensitivity, Conditional Access, and data-governance dependencies
Test identities in both tenants, invited guest/direct-connect state, claims, devices, target resources, expected allow/block results, and sign-in evidence
Change approval, partner confirmation, incident contact, disable/remove plan, guest cleanup, synchronization stop, and failback

Policy layers

Separate collaboration, direct connect, trust, synchronization, and tenant restriction controls

Layer	Purpose	Critical boundary	Evidence
B2B collaboration	Controls whether selected external users/groups can access selected internal applications and whether your users can access partner resources.	Creates or uses guest representations; invitation, guest permissions, app authorization, and lifecycle remain separate.	Tenant and object IDs, inbound/outbound scope, guest state, app assignment, Conditional Access, sign-in, and removal.
B2B direct connect	Provides mutual cross-tenant access for supported experiences such as Teams shared channels without conventional guest creation.	Both organizations must enable access; Microsoft initially blocks inbound and outbound direct connect by default.	Mutual partner confirmation, shared-channel owner, users/groups, app scope, trust claims, sign-in, channel, and offboarding.
Inbound trust	Lets the resource tenant accept MFA, compliant-device, or hybrid-joined-device claims from the external user’s home tenant.	Trusting a claim does not copy or validate the partner’s policy design, operational quality, or device-management standard.	Claim type, partner assurance, contract, Conditional Access result, device/authentication detail, exception, and reassessment date.
Cross-tenant synchronization	Automates one-way creation, update, and deletion of B2B collaboration users across tenants.	Synchronization is provisioning, not permission or security-policy equivalence; source scope and attributes control downstream identities.	Source/target configuration, scope/filter, attributes, automatic redemption, provisioning logs, ownership, deletion, and rollback.
Tenant restrictions v2	Controls which external tenants and apps identities can access from managed networks/devices, including alternate external identities.	A cloud policy requires an enforcement signal through Universal Tenant Restrictions, proxy header, or supported Windows signaling.	Default/partner policy, policy ID, signaling path, users/apps, blocked/allowed tests, anonymous gaps, client coverage, and rollback.

Default inheritance: removing a partner from Organizational settings does not necessarily block it; the default cross-tenant access settings then apply. Capture defaults before deleting any organization-specific policy.

Inbound and outbound scope

Design partner exceptions with explicit identities, applications, and reciprocal expectations

Question	Inbound decision	Outbound decision	Validation
Who?	Which external users/groups from the partner may enter your resource tenant?	Which internal users/groups may access that partner’s resources?	Use verified object IDs; test an allowed identity and a blocked control identity in each direction.
What resource?	Which applications in your tenant accept those external identities?	Which applications in the external tenant may your identities access?	Confirm enterprise-app IDs, service dependencies, Teams/SharePoint/Exchange audiences, and app-side authorization.
Which path?	B2B collaboration guest, direct connect, synchronized guest, invitation, entitlement package, or another supported flow?	Home identity, external guest, alternate external identity, Teams shared channel, or cross-cloud path?	Record identity type, user type, home/resource tenant, redemption state, authentication flow, and target resource.
What trust?	Will you accept partner MFA, compliant-device, or hybrid-joined-device claims?	Which claims does the partner accept from your tenant, and what user experience follows?	Use Conditional Access and sign-in details to prove claim presence, policy evaluation, failure, and fallback behavior.
How removed?	Disable partner policy, remove app/user scope, revoke guest/resources, stop sync, and validate residual access.	Remove outbound permission, shared channels, guest assignments, app access, sessions, and owner dependencies.	Run bilateral offboarding with partner contacts, resource owners, logs, guest cleanup, and documented default-state result.

Licensing: targeting selected external users/groups or selected applications in certain cross-tenant configurations requires appropriate Microsoft Entra ID P1/P2 capabilities. Cross-tenant synchronization also has licensing and External ID billing considerations. Confirm current product terms before deployment.

Trust claims

Accept partner evidence only after defining the assurance you expect

MFA trust

When enabled, your resource tenant can accept an MFA claim satisfied in the user’s home tenant. Document eligible users, methods/strength expectations, exceptions, incident notification, and periodic verification.

Compliant-device trust

Accepts the home tenant’s compliant-device claim for Conditional Access. Understand the partner’s device platforms, enrollment, compliance criteria, exceptions, stale-device handling, and response process.

Hybrid-joined trust

Accepts the partner’s Microsoft Entra hybrid joined device claim. Confirm ownership, directory lifecycle, registration quality, device identity, Conditional Access design, and support responsibilities.

Trust is not transitive: trusting a partner’s claim does not automatically extend trust to that partner’s partners, prove device health beyond the claim, or override your app authorization and other applicable Conditional Access policies.

Tenant restrictions v2

Pair the cloud policy with a tested enforcement signal and known coverage limits

Policy architecture

Define a default posture for external tenants and Microsoft accounts, then create narrow partner-specific users, groups, and app exceptions
Choose enforcement through Universal Tenant Restrictions with Global Secure Access, supported Windows signaling, or proxy header insertion
Record tenant ID, cross-tenant policy ID, users/groups, external tenants/apps, device/network coverage, and administrators
Coordinate Teams federation controls and Office 365 service dependencies where required
Test corporate identity, alternate external identity, Microsoft account, browser, native app, remote user, managed device, and anonymous paths

Coverage cautions

Without the required signal, the tenant-restriction cloud policy is not enforced on the intended traffic
Proxy-based signaling primarily covers authentication-plane scenarios; Universal Tenant Restrictions expands platform and network coverage
Anonymous sharing, meetings, third-party accounts, copied tokens, unsupported apps, and non-Microsoft resources need separate controls
Tenant restrictions govern external-tenant access from your environment; they do not replace outbound B2B settings, Conditional Access, DLP, app control, or sharing governance
Preserve current proxy/GPO/GSA configuration and validate rollback before migration or broad enablement

Partner lifecycle

Pilot the relationship bilaterally and make offboarding part of onboarding

Stage 1

Verify

Confirm legal entity, tenant ID/cloud, domains, sponsors, security/privacy contacts, use case, data, contract, and incident channel.

Stage 2

Design

Choose collaboration path, inbound/outbound scope, app IDs, trust claims, Conditional Access, guest/sync lifecycle, and restrictions.

Stage 3

Configure

Add the verified tenant, customize minimum settings, exchange object IDs, preserve defaults/exports, and document reciprocal work.

Stage 4

Validate

Test allowed and blocked identities/apps both ways, claims, clients, shared channels, guest state, logs, restrictions, and rollback.

Stage 5

Operate

Review sign-ins, guests, claims, sync, partner policies, owners, app use, incidents, contract status, and offboarding evidence.

Failback: export default and organization-specific policies, tenant IDs, object IDs, trust settings, synchronization, tenant-restriction policy/signaling, Conditional Access, guests, shared channels, and app assignments. A rollback must state what default access applies after customization is removed.

Top risks and common misconfigurations

Prevent a partner exception from becoming unbounded trust or invisible data movement

Cross-tenant control is dependable only when direction, identity, resource, claim, enforcement, and lifecycle evidence stay aligned.

Wrong tenant onboarded

A domain name or display name is trusted without independently verifying the immutable tenant ID and legal organization.

Direction reversed

Inbound settings are changed for an outbound business requirement, or the resource tenant is misidentified.

All users and apps allowed

A narrow collaboration need becomes broad organization-wide access with no app or group boundary.

Trust claim accepted blindly

MFA or device claims are trusted without partner assurance, contract terms, incident notification, or reassessment.

Direct connect assumed unilateral

One tenant enables Teams shared-channel access but the reciprocal partner configuration is missing or broader than expected.

Default policy forgotten

Deleting a partner customization silently returns the relationship to permissive defaults.

Restriction signal missing

Tenant restrictions v2 is configured in the portal but GSA, Windows, or proxy signaling does not enforce it.

Guest and sync drift

Cross-tenant synchronization, invitations, direct assignments, and resource permissions create identities or access outside the intended path.

No bilateral offboarding

The contract ends but shared channels, guests, app roles, sessions, sync, claim trust, and partner exceptions remain.

Evidence and measures

Make every partner access decision explainable from both tenants

Minimum evidence package

Verified tenant identity, cloud, domains, legal/privacy/security contacts, sponsor, purpose, contract, and review date
Default and partner inbound/outbound B2B collaboration, direct-connect, trust, tenant-restriction, sync, and cloud settings
User/group/app IDs, guests, shared channels, app/resource assignments, Conditional Access, external collaboration, and entitlement dependencies
Allowed/blocked test matrix, sign-in/audience/claim/device details, provisioning logs, errors, tickets, and partner confirmations
Change approvals, incidents, exceptions, periodic attestations, offboarding, cleanup, failback, residual risk, and next review

Review cadence

Daily or alert-driven review for failed/high-risk external sign-ins, sync failures, policy changes, claim anomalies, and restriction bypass
Monthly reconciliation of partner settings, guests, sync scope, shared channels, apps, users/groups, direct grants, and owners
Quarterly bilateral attestation of business need, tenant identity, app scope, claim trust, contracts, privacy/security posture, and tests
Event-driven review after merger, partner incident, tenant/domain change, app launch, policy change, contract end, or owner departure

Scope accuracyIntended versus actual partners, identities, groups, applications, guests, shared channels, and sync objects.

Trust qualityMFA/device claim use, Conditional Access outcomes, partner assurance, exceptions, and overdue reassessments.

Access outcomeAllowed, blocked, failed, unexpected, restricted, anonymously bypassed, and unresolved cross-tenant events.

Lifecycle healthActive sponsors, contract status, stale guests/apps, sync deletion, offboarding time, and rollback readiness.

Related ecosystem guides

Connect cross-tenant policy to guests, collaboration, access packages, Conditional Access, and Teams

External Collaboration ReviewCoordinate Entra invitation, guest permissions, domains, Teams, SharePoint, OneDrive, lifecycle, and evidence.Guest User Access ReviewReconcile home tenants, sponsors, sign-ins, app/group/site access, stale guests, removal, and evidence.Access Packages LifecycleGovern catalogs, partner request policies, approvals, assignments, reviews, expiration, and guest cleanup.Conditional Access ReviewValidate external-user targeting, trust claims, grant controls, exclusions, report-only results, and recovery.Teams Channel GovernanceManage standard, private, and shared channels, membership, ownership, external collaboration, and lifecycle.Microsoft 365 Managed ServicesGet operational support for Entra, Microsoft 365, endpoints, monitoring, and change control.

Authoritative resources

Use current Microsoft guidance for every partner, claim, synchronization, and restriction design

What is the difference between inbound and outbound cross-tenant access?

Inbound settings control external identities accessing resources in your tenant. Outbound settings control identities from your tenant accessing resources in another organization. Always identify the home and resource tenant.

Does B2B direct connect require both organizations to configure access?

Yes. It is a mutual trust relationship. Both tenants must enable the intended direct-connect access; Microsoft initially blocks inbound and outbound B2B direct connect by default.

What does trusting an external MFA or device claim mean?

Your resource tenant can accept the specified claim from the user’s home tenant for Conditional Access evaluation. It does not copy the partner’s policy or prove every aspect of its security program.

Does configuring tenant restrictions v2 in the portal enforce it automatically?

No. The cloud policy must be signaled on the relevant traffic through a supported method such as Universal Tenant Restrictions, supported Windows signaling, or proxy header insertion.

What happens if an organization-specific partner setting is removed?

The default cross-tenant access settings apply to that organization. Review and preserve the defaults before removing customization so the resulting access is understood.

What should be tested before production?

Test allowed and blocked identities and apps in both directions, B2B guest/direct-connect paths, trust claims, Conditional Access, clients, tenant restrictions signaling, synchronization, service dependencies, logging, offboarding, and rollback.

IT Perfection Microsoft 365 identity operations

Build cross-tenant collaboration with clear direction, bounded trust, and tested removal

IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California verify partner tenants, design inbound/outbound settings, validate B2B collaboration and direct connect, govern trust claims, test tenant restrictions and synchronization, monitor evidence, and preserve failback.

Discuss a cross-tenant access review Meet Ali Hassani, CISO

Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.

This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, Microsoft licensing review, legal/privacy review, partner risk assessment, or tested change-management process.