Cross-tenant synchronization in Entra ID

Cross-tenant synchronization is the Microsoft Entra ID feature that auto-provisions B2B guest users between Microsoft Entra ID tenants. Configured once at each end of a tenant pair, it keeps a defined set of users synchronised as guests between the tenants without manual invitation. It's most useful inside a Multi-Tenant Organisation (MTO) — where multiple Microsoft 365 tenants belong to the same organisation — but it works for any tenant-to-tenant pair you choose to configure.

What it provides

Once set up between Tenant A (source) and Tenant B (target):

• A defined set of users from Tenant A automatically appears as B2B guests in Tenant B.
• Attribute updates (job title, manager, department) propagate.
• Disabled or deleted users in Tenant A are removed from Tenant B.
• Group membership changes can drive scope changes.

The user experience: people from Tenant A can immediately sign into Tenant B's apps and Teams as guests, with no invitation acceptance step.

Why this matters

Without cross-tenant synchronization, B2B works like this:

• Someone in Tenant B invites a Tenant A user by email.
• The Tenant A user clicks the invitation, redeems it, becomes a guest.
• If they leave Tenant A, their account in Tenant B stays orphaned.

This is fine for ad-hoc external collaboration. For organisations that have multiple tenants belonging to the same group — acquisitions, subsidiaries, regional separation — the manual invitation model is operationally painful. Cross-tenant sync replaces it with automation.

Configuration

In each tenant, configure in Entra admin center → Identity → External Identities → Cross-tenant access settings → Organisation settings:

1. Outbound (source side) — choose which target tenants to sync to, and which users / groups are in scope.
2. Inbound (target side) — choose which source tenants you accept users from, and whether to auto-create user objects.
3. Set up the sync job — under Provisioning, configure attribute mappings.

The job runs every ~40 minutes (like other Entra provisioning jobs), with logs showing every action.

Trust requirements

For sync to work, both tenants must configure Cross-Tenant Access Settings (CTAS) to trust each other for the relevant scenarios:

• Trust the source tenant's MFA and device claims (so guests don't have to MFA again on the target).
• Allow automatic redemption of B2B invitations (so users don't see consent prompts).
• Allow the sync object types (user objects, group objects).

MTO simplification

Inside a Multi-Tenant Organisation, much of this configuration is template-driven. Once tenants join the MTO, cross-tenant sync is configured with a guided experience that sets up the trust and sync simultaneously.

Operational considerations

• Attribute mapping is the most common source of issues — verify what comes across.
• Lifecycle — when a user is disabled in source, are they fully removed from the target? Yes, but verify your settings.
• Conditional Access at the target still applies — synchronised users are subject to the target's CA policies.
• Audit — both tenants log every sync action.

For organisations with multiple legitimate tenants belonging to one entity, cross-tenant synchronization is the foundation of operating them as one organisation.

Scope: how to decide who syncs

The single biggest predictor of a clean cross-tenant sync deployment is a narrow, well-defined scope. Options, roughly in order of maintenance cost:

• A dedicated Entra group per target tenant (XTS-To-Tenant-B). Everyone in the group is in scope; adding a person to the group provisions them into Tenant B. This is the pattern that scales — group membership is the audit trail.
• A dynamic group by department, cost centre, or an on-prem AD attribute synced via Entra Connect. Good when the source-of-truth already knows who should collaborate.
• All users in the source tenant. Only appropriate for tight mergers where every employee genuinely needs presence in every tenant. Even then, prefer an explicit exclusion group for service accounts and non-human identities.

Cross-tenant sync should never be scoped by "all users, filter later" — the filters live on the target side and are easy to forget when someone provisions a new team.

Attribute mapping: what to change from the defaults

The default mapping is safe but generic. Two changes are almost always worth making:

• companyName — force it to the source tenant's name (Contoso NA, Contoso EU) rather than passing through. In a multi-tenant org this is what lets the target's Teams people picker and Exchange GAL show where a person is from.
• department and jobTitle — pass through. These are what target-tenant CA policies and app groups will filter on, and they are the attributes people actually search on.

Do not sync mail, mailNickname, proxyAddresses, or userPrincipalName without deliberate thought. The target tenant creates a guest UPN of the form alice_contoso.com#EXT#@target.onmicrosoft.com; leaking source addresses into other attributes causes surprise routing decisions in Exchange and Teams.

Trust settings that matter in practice

Beyond the sync job itself, the target tenant's Cross-Tenant Access Settings (CTAS) inbound policy for the source tenant should:

• Trust MFA claims from the source. Without this, synced guests get an MFA prompt on the target on top of the one they already did — the single most-reported user complaint.
• Trust compliant-device and Hybrid-Entra-joined claims if the target's CA policies require compliant devices. Otherwise every synced guest fails compliance even though their device is managed by the source.
• Enable automatic redemption on both sides. This is what suppresses the consent screen and makes sync feel automatic.
• Allow user objects in the sync object types. Groups are supported but require the target to accept Group as an inbound object type.

MSP context

For MSPs the same feature applies inside a client's tenant estate — for example when a customer has separated production and dev-test tenants and wants dev-test users to appear in production for pilot work. It is not, however, a substitute for GDAP for delegated admin: cross-tenant sync gives users presence in the target tenant, GDAP gives the MSP staff role-based administrative access. Both are needed for a full multi-tenant operating model.

Third-party MSP tooling (CIPP, Nerdio, Rewst) can automate CTAS and sync configuration across the fleet, which matters when the number of tenant pairs is more than a handful.

Common wrong turns

• Configuring the outbound side only. The target tenant must also opt in via inbound CTAS and accept the sync object types — a common cause of "the job runs but no users appear".
• Assuming sync deletes users on the target. It removes them when they leave scope on the source (disabled, deleted, or dropped from the scope group). It does not delete objects the target created directly.
• Ignoring the ~40 minute cadence. Provisioning is not real-time. Do not build joiner-mover-leaver flows that assume a change in Tenant A is visible in Tenant B within a minute.
• Forgetting Conditional Access at the target. Synced guests obey the target's CA. A "require compliant device" policy without the corresponding trust setting locks every synced user out.