Entra cross-tenant access settings — the M&A playbook for AU mid-market (2026)

An Australian acquisition closed; the legal entities are now one company; the staff are on two different Microsoft Entra tenants. The board wants people collaborating in Teams and SharePoint on day one. Full tenant-to-tenant migration is six to nine months away. The control plane that bridges that gap is Entra cross-tenant access settings — and it's the most misunderstood Entra feature in 2026.

B2B Collaboration versus B2B Direct Connect

Entra ships two cross-tenant access models. B2B Collaboration is the older one — an external user is invited, a guest object is created in your tenant, they sign in with their home credentials and exist as a guest. B2B Direct Connect is the newer one — there is no guest object; the external user accesses resources using their home tenant's identity, with the resource tenant's trust policies governing access. Direct Connect powers Teams Shared Channels — staff from both tenants in the same channel, no guest accounts, no licence implications.

Cross-tenant access settings — what you actually configure

Cross-tenant access settings live in Microsoft Entra → External Identities → Cross-tenant access settings. There are two settings to think about. Inbound: which other tenants can their users access your resources from, what user/group restrictions apply, what trust signals (MFA from their tenant, device compliance from their tenant) your tenant will accept. Outbound: which other tenants your users can access resources in, with the same restriction model.

Default settings are 'allow everyone except specific blocks'. For an AU mid-market organisation that just acquired another, this is too open. The right pattern is to explicitly configure the acquired tenant with tailored settings and leave the default as it was.

Day-one configuration for an AU acquisition

1. 1Identify both tenant IDs — the GUIDs from each Entra admin centre. Document them in your runbook.
2. 2Add the acquired tenant to your Cross-tenant access settings with explicit configuration (do not use defaults). For most acquisitions you want to allow inbound B2B Collaboration and B2B Direct Connect, restrict to specific groups (typically the leadership team and integration team initially), and accept the acquired tenant's MFA claim (so your users don't double-MFA when reaching into resources in the other tenant).
3. 3Accept their MFA and device compliance claims under Trust settings — this prevents the most common day-one friction (MFA prompts everywhere).
4. 4Mirror the configuration in their tenant. This requires either coordinated change windows with their admin team, or by-agreement Entra access for your team to administer their tenant during the transition.
5. 5Create Teams Shared Channels in priority workspaces (executive team, integration management office, IT) using B2B Direct Connect — no guest invitations, no licence cost.
6. 6Use B2B Collaboration with managed guest objects for the broader collaboration scope (cross-tenant SharePoint sites, cross-tenant access to a CRM hosted in one tenant).

Trust signals — the under-used control

The trust-signals capability is the single most under-utilised Entra control in AU M&A scenarios. Without it, your Conditional Access policies that require MFA, device compliance and Hybrid Azure AD Join apply only to identities homed in your tenant — a guest from the acquired company hits your resources with no claims to evaluate. With trust signals on, your CA policies can read 'MFA was satisfied in their tenant' and accept it. The result: no double-MFA for legitimate users, no MFA gap for risky ones.

Common AU pitfalls

• Leaving the default 'allow all inbound' state in place — over-permissive, easy to forget, audit risk.
• Configuring B2B Collaboration but not B2B Direct Connect — locks Teams Shared Channels out of the integration playbook.
• Treating the acquired tenant as 'just another federation' — it's not federation; it's tenant-trust. Don't conflate.
• Forgetting to set Trust signals — produces a flood of MFA prompts and false-positive Conditional Access blocks.
• Not coordinating timezones for change windows — both admin teams need to be active when settings are flipped.

When to stop using cross-tenant access and migrate

Cross-tenant access settings are not a permanent answer — they're a bridge. The right exit signals: the integration ROI requires unified licensing/cost, compliance review wants a single tenant of record, executive search for content across both tenants is failing more often than working, or the integration timeline reaches 18 months without merge. At that point a proper tenant-to-tenant migration project is justified, typically 4–9 months end-to-end depending on scope.