Cross-tenant synchronisation provisions and updates selected users from one Microsoft Entra tenant into another so they can be represented and governed across tenant boundaries. Administrators control which accounts and attributes flow, then monitor for over-permissioned access, stale objects and unexpected changes in replicated identity data. It is used to support collaboration, not to replace tenant-specific access controls.
How cross-tenant synchronisation fits into Microsoft Entra administration
Cross-tenant synchronisation is a controlled identity replication path between Microsoft Entra tenants. The practical question is not whether accounts move, but which identities, attributes, and governance decisions are allowed to cross the boundary. That makes the feature useful for collaboration and multi-tenant administration, while still leaving each tenant responsible for its own access rules and local enforcement.
The model is intentionally selective. Administrators define the source tenant, the target tenant, and the scope of objects to synchronise, then decide which attributes are authoritative for the destination. That design helps organisations avoid creating a full duplicate directory, while still making selected users visible enough to collaborate, assign access, and apply tenant-specific policy.
Because the synchronised object is a governed copy rather than a free-floating shared account, changes can have downstream effects if scoping is too broad or attribute mapping is too permissive. The operational challenge is to preserve interoperability without making the target tenant accept more authority than intended.
What crosses the boundary, and what should stay local
In practice, cross-tenant synchronisation should be treated as a representation layer, not as a replacement for the destination tenant’s own identity controls. A user may be provisioned into another tenant for collaboration, but that does not mean the target tenant should inherit the source tenant’s full privilege model, conditional access decisions, or administrative trust.
That distinction matters because not every identity attribute should be synchronised. Display names, job role information, and collaboration-relevant fields are often useful, but sensitive or operationally volatile attributes can create confusion if copied without a clear business need. The cleaner the attribute contract, the easier it is to reason about ownership, change control, and review.
It also helps to think in terms of blast radius. The more objects and attributes you synchronise, the more a mistake in the source directory can propagate to the target tenant. The safest deployments keep the synchronisation scope narrow, document ownership of each attribute, and review whether the destination tenant truly needs the data it receives.
Why identity governance still matters after synchronisation is enabled
Once synchronisation is active, the target tenant needs the same discipline you would apply to any other governed identity population. The main operational risks are over-permissioned accounts, stale objects that remain after a user no longer needs access, and unexpected attribute changes that alter how the user is treated in downstream systems.
That is why synchronised identities should be reviewed like any other privileged or externally sourced population. A target tenant should be able to answer who owns the object, when it was last updated, what access it has, and how quickly it will be removed or disabled when it is no longer needed.
The best control point is usually the boundary between provisioning and authorisation. Synchronisation can create the identity record, but local access control should still decide what the user can actually do in the destination tenant. That separation reduces the chance that a cross-tenant collaboration mechanism becomes an unintended privilege bridge.
When the design becomes risky
Cross-tenant synchronisation sits inside a broader trust relationship, so the main failure mode is not just bad provisioning, but trust sprawl. If administrators treat the synchronisation path like a harmless convenience layer, they can miss how easily a mis-scoped account, a bad attribute mapping, or an overbroad trust setting can widen exposure across tenants.
A second risk is credential or token abuse paired with cross-tenant reach. If an attacker can control the source identity or influence what gets synchronised, the target tenant may receive a representation that looks legitimate enough to be trusted by users, workflows, or downstream applications. That is why cross-tenant settings should be reviewed alongside tenant trust configuration, not in isolation.
Entra tenant abuse scenarios also show why cross-tenant identity paths deserve careful monitoring: when trust boundaries are weak, identity replication can become part of a broader compromise path rather than a simple collaboration feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Cross-tenant synchronisation governs non-human and federated identity trust paths. |
| AC-6 — Least Privilege | The answer centers on limiting what synchronized identities can do in the target tenant. | |
| IA-5 — Authenticator Management | Synchronised identities can expose credential and token lifecycle issues if trust is too broad. | |
| Recommendation — Use IA-9 to authenticate synchronized service and tenant trust relationships before granting access. Apply AC-6 to keep synchronized users on the minimum access needed in the destination tenant. Apply IA-5 to govern any credentials or tokens tied to cross-tenant identity flows. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-tenant synchronization directly affects how access is granted across organizational boundaries. |
| A.8.2 — Privileged access rights | The topic requires controlling over-permissioned synchronized accounts and their elevated rights. | |
| Recommendation — Define and enforce access rules for synchronized identities across tenants. Review and restrict privileged rights assigned to synchronized accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | The feature depends on controlled identity lifecycle and trust at the access boundary. |
| Recommendation — Manage synchronized identity authenticators and trust paths under documented access policy. | ||
Practitioner Guidance
What to verify: Confirm which tenant owns the source object, which attributes are synchronised, and which tenant enforces the final access decision. If the target tenant cannot explain those three points clearly, the deployment is too loose to trust.
Common mistake: Treating synchronisation as if it were a shared account model. The safer pattern is to provision only what is needed for collaboration, then keep authorisation, conditional access, and privileged actions local to the destination tenant.
What practitioners underestimate: Stale synchronised objects are a governance problem, not just a cleanup task. If deprovisioning is slow or review cycles are weak, cross-tenant objects can outlive the business relationship that justified them.
Practitioner takeaway: Cross-tenant synchronisation works best when it is narrowly scoped, explicitly owned, and continuously reviewed, because the real control question is not whether identities can cross tenants, but how much authority crosses with them.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org