Synchronize only necessary users and attributes across Entra tenants

Bottom line: Microsoft Entra cross-tenant synchronization automates creation, update, and deletion of B2B collaboration identities between tenants. It is a source-driven push process with scope and attribute mappings configured in the source tenant. That convenience creates a continuing data-sharing and access-lifecycle relationship that needs explicit ownership on both sides.

Source fact: what Microsoft documents

Microsoft’s cross-tenant synchronization overview says the feature uses the Entra provisioning engine to push internal source-tenant members into a target tenant as B2B collaboration identities. The source tenant defines who is in scope, which attributes are mapped, and any transformations. A target administrator enables inbound synchronization and can stop it.

Microsoft documents that the feature is intended to automate user lifecycle and remove B2B accounts when people leave. It does not synchronize external users from the source tenant. Automatic invitation redemption requires settings in both source and target for the documented experience. Microsoft also warns that cross-organization use can add privacy, security, and regulatory responsibilities and says customers must assess consent, data minimization, and other safeguards. Licensing and cloud-pair support vary by scenario.

What the source does not establish

Synchronization does not decide which tenant should be authoritative, which attributes are necessary, or whether the target’s access assignments are appropriate. Deleting or disabling a source user does not by itself prove every target resource, session, group, application-native role, or retained record is removed. The feature does not collect user consent on the organization’s behalf or make a cross-organization design legally appropriate.

Applicability questions

• Are the tenants part of one organization, and is each tenant’s purpose documented?
• Which users and groups require access, and can narrower B2B invitation or entitlement processes meet the need?
• Which attributes are necessary in the target, and which contain confidential or regulated information?
• How are existing target B2B objects matched, and could an internal target account conflict?
• What must happen to target access, sessions, data ownership, and records when a source identity leaves scope?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Document source and target ownership, collaboration purpose, privacy basis, supported cloud pair, licensing, and the process for either tenant to suspend synchronization.
2. Scope a pilot to named users. Map only attributes required for the defined collaboration and review transformations for unintended disclosure.
3. Test new creation, update, manager or department changes, removal from scope, source disablement, deletion, rehire, and preexisting B2B matching.
4. Assign target resource access through owned groups or access packages rather than treating synchronized presence as authorization.
5. Reconcile the source population, target objects, provisioning errors, and target access regularly.

Verification and evidence

• Preserve both tenants’ cross-tenant access settings, automatic-redemption settings, sync scope, mappings, and approvals.
• Capture provisioning logs for creation, update, skip, failure, and deletion tests.
• Compare source identifiers to target B2B objects and document duplicate or unmatched identities.
• Demonstrate that a departure removes or transfers target access and ownership according to policy.

Official references

• What is cross-tenant synchronization? — Microsoft