Intracompany Federation with Domain Sharing for Microsoft Teams and Cisco Webex

The architectural problem nobody warned you about

A single legal entity. One email domain. Multiple Microsoft 365 tenants — typically 2 to 7 — each acquired through an M&A event, each with its own Conditional Access policies, its own Purview retention rules, its own Teams external-access posture. Layered on top, one or two Cisco Webex organizations, each with its own Common Identity (CI) configuration. And a CEO who wants every employee to be able to message every other employee as if it were one company.

This is intracompany federation with domain sharing, and by 2026 it describes roughly 39% of Fortune 500 organizations at any given moment, according to the 2026 IDC Workplace Identity Survey. The percentage spikes after every major M&A wave and never quite drops back down because divestitures create the same problem in reverse.

The architecture is genuinely hard. It sits at the intersection of identity (Azure AD cross-tenant access, Webex CI, the shared email domain), real-time collaboration (Teams federation, Webex spaces), data governance (Purview, Webex compliance, eDiscovery on both sides), and the operational reality that the M&A integration team that started the project is usually disbanded before it finishes.

This guide is the deep architecture. We will cover the technical scenario, the cross-tenant access policy model, the domain-claim mechanics, Webex Common Identity, the SyncRivo implementation pattern, the M&A and corporate-restructure use cases, and the identity and DLP considerations that decide whether the project ships or stalls.

The technical scenario in detail

A representative scenario, which we will refer to throughout:

• AcmeCo is a single legal entity operating under the email domain acme.com.
• AcmeCo runs four Microsoft 365 tenants: acme-corp.onmicrosoft.com (corporate HQ, 6,000 users), acme-northeast.onmicrosoft.com (acquired regional business unit, 2,200 users), acme-eu.onmicrosoft.com (EU subsidiary under GDPR data-residency mandate, 1,400 users), and acme-labs.onmicrosoft.com (a research subsidiary with FedRAMP-aligned controls, 800 users).
• AcmeCo runs two Cisco Webex organizations: a primary org tied to corporate HQ (5,800 users on Webex Calling and Webex Meetings), and a smaller org for the EU subsidiary (1,200 users).
• All users have email addresses under acme.com. The mail flow is brokered through a single Exchange Online tenant routing to and from each Microsoft 365 tenant.

The CEO wants Sarah in acme-corp to message Pavel in acme-eu and Yuki in acme-labs as if they were all in one Teams environment. The CISO wants every conversation to attribute to the right tenant for audit, retention, and DLP. The Webex users want the same — Webex spaces that span the two Webex orgs, with chat-and-call interop into the four Teams tenants.

This is the problem. The four Teams tenants do not federate to each other natively in any meaningful way until you configure cross-tenant access policies. The two Webex orgs do not share spaces natively. The Teams tenants do not federate to the Webex orgs without an intermediate bridge. And every step has to attribute correctly to the right tenant for compliance.

The federation architecture: three layers

A working intracompany federation in this scenario decomposes into three layers.

Layer 1: Identity. Who is who across the tenants? The shared email domain is necessary but not sufficient — it gives users a memorable identifier but it does not solve cross-tenant authentication, B2B object lifecycle, or cross-Webex-org identity.

Layer 2: Access policy. Which tenant trusts which other tenant for which actions? Cross-tenant access policies in Azure AD, federation settings in Webex CI, and external-access settings in Teams.

Layer 3: Federation control plane. Where does the cross-platform routing happen? For Teams ↔ Teams across tenants, native cross-tenant access is the answer. For Teams ↔ Webex and Webex ↔ Webex across orgs, a federation broker (SyncRivo, NextPlane OpenHub, or a custom build) is the answer.

The next four sections walk through each layer's mechanics in protocol detail.

Layer 1a: Domain claim across multiple Microsoft 365 tenants

Microsoft 365's domain ownership model assumes one verified domain per primary tenant. In a multi-tenant scenario sharing one email domain, the architectural answer is to claim the domain in only one tenant (typically the corporate HQ tenant) and route mail through that tenant's Exchange Online to the others using internal relay domains or internal mail flow connectors.

The mechanics:

acme.com (verified in acme-corp.onmicrosoft.com only)
        │
        ▼
Exchange Online (acme-corp tenant)
        │
        ├── connector to acme-northeast.onmicrosoft.com
        ├── connector to acme-eu.onmicrosoft.com
        └── connector to acme-labs.onmicrosoft.com

For Teams chat federation across these tenants, the user identity in each tenant typically uses an alternate UPN suffix that matches the email — so Sarah's Teams UPN is sarah@acme.com even though her tenant is acme-corp.onmicrosoft.com. This requires explicit UPN suffix configuration in each tenant's Azure AD.

The risk: if two tenants both claim a UPN of sarah@acme.com (typically because the M&A integration didn't reconcile cleanly), authentication breaks. Best practice is to maintain a master identity registry that asserts canonical tenant ownership for every acme.com UPN, and to enforce uniqueness during user onboarding to any tenant.

Layer 1b: Webex Common Identity across two Webex organizations

Cisco Webex's Common Identity (CI) is the directory layer underneath Webex Messaging, Calling, and Meetings. In a multi-Webex-org scenario, CI is per-org by default. There are three architectural choices:

Choice A: Consolidate to a single Webex org. The cleanest answer when feasible. Cisco's Webex Org Migration tooling can move users between orgs, with caveats around licensing, calling configuration, and historical message retention.

Choice B: Run two CIs and federate. Both orgs continue to exist, with directory sync into each from the same upstream identity provider (typically Azure AD or Okta). Cross-org messaging requires a federation broker because Webex spaces are CI-scoped.

Choice C: One CI, multiple Webex orgs. A less common but supported model where a single CI feeds two Webex org configurations — typically used when one org has Webex Calling enabled and the other does not. Cross-org spaces are still constrained.

Most AcmeCo-shaped deployments end up at Choice B because Choice A is operationally heavier than the M&A team has appetite for, and Choice C does not solve the cross-org space problem.

Layer 2a: Microsoft 365 cross-tenant access policies

Cross-tenant access policies (XTAP) in Azure AD govern which Teams tenants can federate with which others, and what features are enabled across the federation. The relevant Microsoft Graph resources:

GET  /policies/crossTenantAccessPolicy/default
GET  /policies/crossTenantAccessPolicy/partners
POST /policies/crossTenantAccessPolicy/partners
PATCH /policies/crossTenantAccessPolicy/partners/{tenantId}

A working intracompany configuration enables, for each pair of internal tenants:

• B2B collaboration with a tenant-restriction policy that scopes cross-tenant access to a specific group (typically all licensed users in the partner tenant).
• B2B direct connect for Teams shared channels (if you intend to use shared channels for cross-tenant collaboration; otherwise this can be off).
• Teams federation with inbound and outbound chat enabled; voice/video escalation enabled.
• Identity protection with MFA trust if the partner tenant's MFA enforcement matches your home tenant's policy.

A real partner-policy payload (abbreviated):

{
  "tenantId": "11111111-2222-3333-4444-555555555555",
  "b2bCollaborationInbound": {
    "usersAndGroups": { "accessType": "allowed" },
    "applications":   { "accessType": "allowed" }
  },
  "b2bCollaborationOutbound": { /* mirror */ },
  "b2bDirectConnectInbound": {
    "usersAndGroups": { "accessType": "allowed" },
    "applications":   { "accessType": "allowed" }
  },
  "automaticUserConsentSettings": {
    "inboundAllowed":  true,
    "outboundAllowed": true
  },
  "inboundTrust": {
    "isMfaAccepted":                          true,
    "isCompliantDeviceAccepted":              true,
    "isHybridAzureADJoinedDeviceAccepted":    true
  }
}

This must be set for every pair of internal tenants. For four tenants, that is six pairs, twelve policy objects (inbound and outbound), kept in sync. A drift in one pair's MFA trust setting can break authentication for cross-tenant Teams meetings overnight. Most mature deployments use a Terraform or PowerShell-based source-of-truth for these policies.

Layer 2b: Webex external communication settings

Webex Control Hub exposes per-org "External Communications" policy that governs which other Webex orgs can message into spaces in this org, which can be invited as guests, and which video/audio conferencing platforms (Microsoft Teams, Zoom, Google Meet) can interop.

The relevant settings:

• External Communications. "Allow people from any organization" / "Allow people from these specific organizations" — pin this to your other intracompany Webex org.
• Block external file sharing — typically off for intracompany; on for third-party.
• Microsoft Teams / Cisco Webex federation — the bidirectional federation channel that Cisco and Microsoft jointly support since 2023. This is what lets a Teams user in any of the four AcmeCo Teams tenants federate-message a Webex user in either of the two AcmeCo Webex orgs.

The Microsoft–Cisco federation is functional but feature-limited. It supports 1:1 chat and presence; group chat and threading are not supported as of 2026. For full-fidelity intracompany messaging across Teams and Webex, a federation broker (SyncRivo, NextPlane OpenHub) is required.

Layer 3: The federation control plane

For the AcmeCo scenario, the control plane has to handle:

• Teams ↔ Teams across the four tenants — natively via XTAP, no broker needed for chat and voice.
• Webex ↔ Webex across the two orgs — natively via Webex external communications for 1:1 chat; broker for shared spaces.
• Teams ↔ Webex — natively via the Microsoft–Cisco federation for 1:1 chat; broker for group chat, threading, and full feature fidelity.
• Cross-platform group spaces — broker required.

The SyncRivo implementation pattern for AcmeCo:

                    ┌──────────────────────────────────────┐
                    │  SyncRivo Federation Control Plane   │
                    │  (signed identity registry,          │
                    │   thread translation, DLP mirror,    │
                    │   audit reconciliation)              │
                    └──────────────────────────────────────┘
                           │           │           │
       ┌───────────────────┘           │           └────────────────────┐
       │                               │                                │
   Teams (4 tenants                Webex (2 orgs                  Other platforms
   via XTAP and Graph)             via CI federation              if applicable
                                   and Messaging API)             (Slack, Workspace)

Inside the control plane, AcmeCo's identity registry maps every acme.com UPN to (a) its canonical Microsoft 365 tenant, (b) its Webex CI org, and (c) any cross-platform identifier (Slack workspace ID, Workspace primary email) if other platforms are in scope. The registry is signed; mappings are immutable once attested by the source-of-truth identity provider.

Real Microsoft Graph application permissions used by the federation control plane include ChannelMessage.Send.Group, ChannelMessage.ReadWrite.All, Group.ReadWrite.All, User.Read.All, Directory.Read.All, and CrossTenantInformation.ReadBasic.All (the last for surfacing partner-tenant information during identity reconciliation).

Real Webex API scopes include spark:all, spark-admin:people_read, spark-admin:organizations_read, spark:rooms_write, spark:messages_write, and spark:messages_read.

The M&A use case in detail

The most common entry point for an intracompany federation project is an M&A event. The pattern:

Day 1 of the deal close. The acquired company has its own Microsoft 365 tenant, possibly a Webex org, and an email domain that may or may not align with the parent company's domain.

Days 2–14. The integration team reconciles email — typically by adding the acquired domain as an alternate domain in the parent's Exchange Online and routing acquired-company mail through the parent. The acquired Microsoft 365 tenant usually stays separate; consolidation is a 12-month-plus project.

Days 15–60. The integration team enables cross-tenant access policies between the parent and acquired tenants. Teams chat across the tenants becomes possible. Voice and video escalation between the tenants typically lights up in the same window.

Days 61–120. The integration team confronts the multi-platform reality: the acquired company has Webex, the parent has Teams, neither side wants to migrate. A federation broker is procured. Group spaces, threaded conversations, and DLP across the boundary go live.

Months 5–12. The "consolidation" project is started, paused, deferred, and ultimately re-scoped as "rationalization" rather than "consolidation." The federation becomes permanent.

The architectural cost of NOT planning for this from day 1 is that every M&A event re-runs the same project, with each iteration accumulating cruft in the cross-tenant access policies. Mature parent companies maintain a federation playbook that the M&A integration team can apply within 30 days of any deal close, with templated XTAP configurations, a templated Webex external-communications policy, and a templated SyncRivo or equivalent federation onboarding.

The corporate-restructure use case

A less-discussed but equally common use case is corporate restructure — a divestiture, a spin-off, or a reorganization that creates new tenant boundaries inside what used to be one tenant.

The architectural challenge is the inverse of M&A: you start with a single tenant and have to split it into two without dropping ongoing conversations or losing audit trail.

The pattern:

1. Stand up the new tenant. Configure XTAP between the old and new tenants on day 1.
2. Identify the in-flight conversations that span the boundary. Typically these are channels with members from both sides of the new boundary.
3. Use the federation broker to maintain those conversations as cross-tenant channels during the transition window (typically 90–180 days).
4. Move user accounts on a wave plan. As each user moves to the new tenant, the federation broker rewrites their identity attribution forward — old messages remain attributed to the old tenant for audit, new messages attribute to the new tenant.
5. After the transition window, decommission cross-tenant channels that are no longer needed; convert remaining cross-tenant channels to permanent intracompany federation.

The DLP consideration during a divestiture is sharper than during an M&A, because data crossing the boundary may be subject to information-barrier requirements driven by the divestiture agreement. A federation broker that surfaces classification mismatches to an admin queue is materially safer than one that silently mirrors classifications.

Identity considerations: the deep details

Several identity gotchas every multi-tenant federation project hits:

Guest user proliferation. Naive cross-tenant Teams meeting attendance creates B2B guest accounts in every partner tenant. A mature deployment uses XTAP's "trust MFA from the home tenant" setting and B2B direct connect to avoid creating guest objects for ad-hoc meetings. Without this, the guest object count grows unboundedly and creates an off-boarding hazard when employees leave.

UPN suffix collisions. Two tenants both configured to use acme.com as a UPN suffix can collide on the same UPN (sarah@acme.com). Authentication breaks for one or both. The federation broker should treat the canonical-tenant assertion in the identity registry as the source of truth and refuse to onboard a colliding UPN.

Source-of-truth identity provider. AcmeCo-shaped deployments typically run an external IdP (Okta, Ping, OneLogin) above the multiple Azure ADs and the Webex CIs to provide a single SSO surface and a single user lifecycle. The federation broker should consume the IdP's user lifecycle events to keep its identity registry current.

Webex CI scoped uniqueness. A user existing in two Webex CIs simultaneously is supported but creates duplicate-identity confusion in cross-org spaces. Best practice is to enforce that any acme.com user has exactly one CI home, even when they need to participate in spaces in the other org.

DLP and compliance considerations

The DLP architecture in a multi-tenant intracompany federation has to enforce policy from each user's home tenant on every cross-tenant message they send.

Microsoft Purview DLP evaluates against the home tenant's policies; cross-tenant Teams chat is in scope as of 2026 with the appropriate Purview SKUs. The federation broker must mirror classifications to the receiving side without downgrading.

Webex DLP in Cisco's Cloud Collaboration security model evaluates per-org; the federation broker should propagate classifications across orgs.

eDiscovery and audit reconciliation. A cross-tenant conversation produces audit events in the home tenant of every participant. eDiscovery searches scoped to a single tenant will miss the other side. Mature deployments either run cross-tenant eDiscovery searches as a standard playbook, or rely on the federation broker's reconciled audit feed as a single source of truth.

Information barriers. If an information-barrier policy applies (typical in financial services with research/banking separation), the federation broker must enforce the barrier on cross-tenant routing, not just within each tenant.

SyncRivo's compliance posture for this scenario

For intracompany federation specifically:

• SOC 2 Type II. Audit covers January 1 – December 31, 2025, with controls explicitly scoped to multi-tenant federation, identity registry integrity, and audit reconciliation. Report available under NDA.
• HIPAA BAA. Enterprise tier; covers cross-tenant chat federation and signaling. Median execution 11 days.
• FedRAMP boundary alignment. The acme-labs FedRAMP-aligned tenant scenario is supported via a regional control-plane deployment that does not commingle with the commercial control plane.
• EU data residency. The acme-eu GDPR scenario is supported via the EU (Frankfurt) regional tenancy. Control-plane data does not leave the EU.
• Zero-retention default. Message bodies pass through the federation control plane without persistent storage; only signed identity attributions and audit-required metadata are retained.

This level of specificity is what an enterprise's privacy officer will ask for in writing during procurement. The vendors that cannot answer in writing tend to fail the procurement review.

For the broader business case for federation as the architectural pattern, see Unified Communications: 12 Benefits of a Multi-Platform Enterprise Strategy.

Frequently asked questions

What is intracompany federation with domain sharing? A federation pattern in which a single legal entity operates multiple Microsoft 365 tenants and Cisco Webex organizations that all share a single email domain. Users across these tenants need to message, call, and collaborate as if they were in one company while compliance and audit attribution remain per-tenant.

Can multiple Microsoft 365 tenants share one verified email domain? Yes, but the domain is verified in only one tenant — typically the corporate HQ tenant — and mail flow to the other tenants is brokered through Exchange Online connectors. Each tenant uses an alternate UPN suffix matching the shared domain so user identities present consistently across the federation.

How do cross-tenant access policies work? Microsoft Graph's crossTenantAccessPolicy resource defines, for each pair of partner tenants, what B2B collaboration, B2B direct connect, Teams federation, and identity-trust settings apply. The policies must be configured pairwise for every internal tenant pair; a 4-tenant intracompany scenario requires 6 pairs of bidirectional policies kept in sync.

Is Microsoft–Cisco Webex federation enough for intracompany Teams ↔ Webex messaging? For 1:1 chat and presence, yes. For group chat, threading, attachments, and full feature fidelity, no — a federation broker is required. The Microsoft–Cisco federation is feature-limited as of 2026 and is best treated as a fallback rather than a primary control plane.

What happens during an M&A event? The acquired company's Microsoft 365 tenant is typically retained as a separate tenant during a 12+ month integration window. Cross-tenant access policies are configured between the parent and acquired tenants within the first 60 days. If either side runs Webex, a federation broker is procured to bridge the multi-platform reality. Most "consolidation" projects ultimately become permanent federation projects.

How do we prevent UPN collisions across tenants sharing one domain? Maintain a single source of truth for canonical tenant ownership of every UPN under the shared domain. Enforce uniqueness during onboarding to any tenant. A federation broker should treat the canonical-tenant assertion as the authority and refuse to onboard colliding UPNs.

How does eDiscovery work across multiple tenants? eDiscovery searches scoped to a single tenant will miss conversation participants in other tenants. The two viable patterns are (a) running cross-tenant eDiscovery searches as a standard playbook, or (b) using the federation broker's reconciled audit feed as a single source of truth. Mature deployments do both.

Does this work in a FedRAMP environment? Yes, with regional control-plane deployment that does not commingle with commercial workloads. The SyncRivo regional control plane for FedRAMP-aligned tenants is operated separately from the commercial control plane, with the appropriate boundary controls.

Take the next step

For organizations architecting intracompany federation:

• The SyncRivo Multi-Tenant Federation Architecture Reference covers the same diagram set we ship to enterprise security reviews for M&A and corporate-restructure use cases.
• The Cross-Platform Compliance Checklist is the privacy-officer question list, with the SyncRivo answers pre-filled for the multi-tenant scenario.
• A 60-minute architecture review with the SyncRivo solutions team will sequence your federation playbook for the next M&A event.

Intracompany federation with domain sharing is one of the harder architectural patterns in enterprise collaboration — and one of the most common. The teams that approach it with a templated playbook ship in weeks. The teams that approach it ad-hoc spend quarters.