You’ve merged the AD forests. You have one identity store. The Entra ID (Azure AD) tenant situation is where the next crisis hides.
Most post-merger Entra ID environments are a mess of competing policies, orphaned application registrations, and conditional access rules that were written for one company’s risk tolerance being applied to another company’s entire user base.
Here are the six that cause the most damage.
Landmine 1: Named Locations Based on the Wrong Company’s IP Ranges
Conditional Access policies in Entra ID use Named Locations to define trusted networks. “Allow access without MFA when users are on corporate network” is a common policy.
After a merger, the acquiring company’s Named Locations still contain only acquiring-company IP ranges. Every acquired company user is treated as an untrusted network user — and either blocked or forced through MFA for every application.
The problem: this isn’t just annoying. It breaks application integrations that don’t handle step-up authentication gracefully. Service principals running under acquired-company identities can’t authenticate from the acquired company’s office IPs because those IPs aren’t in the named location.
Fix: Re-run ACQI’s Entra ID discovery in both tenants. Map both companies’ egress IP ranges, VPN ranges, and any known corporate network CIDRs. Update Named Locations in the consolidated tenant before Day 1.
Landmine 2: Cross-Tenant Identity Synchronization Not Disabled After Initial Migration
Many teams use Azure AD Connect’s optional feature to synchronize the source anchor (ImmutableID) from the source forest to the target tenant. This is correct during a migration — it allows mailboxes and Teams to be remapped.
But after the migration completes, this synchronization creates a permanent cross-tenant link that can cause unexpected behavior: users from the acquired domain can still appear in the target tenant’s directory. Application assignments made to the acquired company’s security groups still resolve. License assignments may conflict.
Fix: After migration completion, decommission the source Azure AD Connect server. Run Set-MDirSyncProvisioning -Enabled $false on the target tenant. Verify with Get-MsolDirSyncConfiguration that delta synchronization is disabled.
Landmine 3: Legacy Authentication Policies Not Unified
Conditional Access has a setting for “Legacy Authentication” — blocking POP3, IMAP, Basic Auth across Exchange Online.
Post-merger, if the acquired company had this disabled (because their legacy apps needed it) and the acquiring company had it enabled (corporate policy), you now have an inconsistent posture in a merged tenant. Since Entra ID tenant-level settings apply to all users equally once the directories are consolidated, someone has to make a decision: block legacy auth (break acquired company apps) or allow it (lower security for everyone).
Fix: ACQI’s application discovery module identifies all OAuth-enabled applications and flags which ones use legacy auth protocols. Run this before merging — gives the team 4-6 weeks to remediate or formally accept the risk before Day 1.
Landmine 4: Application Registrations from Both Tenants Still Active
Both the acquiring and acquired companies have application registrations in their respective Entra ID tenants. When you consolidate to a single tenant (ideally the acquiring company’s), all those app registrations need to either migrate or be retired.
The problem: many apps are registered with implicit OAuth grants, app role assignments, and certificate credentials tied to the source tenant’s application ID. When you move to the target tenant, those application IDs change. If the app is a Line-of-Business app that references its own Application ID in config files (common for internal apps), it breaks immediately and silently.
Fix: Document every app registration in both tenants before migration. Assign each one to one of four buckets: (a) migrate to consolidated tenant, (b) retire and replace, (c) run in coexistence, (d) convert to external/shared app model. ACQI’s SaaS discovery module surfaces all registered apps across both tenants.
Landmine 5: Conditional Access Policies That Conflict
Post-merger, you have two sets of Conditional Access policies with potentially contradictory signals. Acquiring company policy says “block access from non-managed devices.” Acquired company policy says “allow access from any device for these 3 user groups.”
These aren’t always obvious conflicts — they may only surface for specific edge cases. User A in the acquired company’s finance team gets blocked from the M&A deal room app because the acquiring company’s device management policy applies but the acquired company’s exception doesn’t translate correctly into the merged environment.
Fix: Export all Conditional Access policies from both tenants as JSON before migration. Map each policy to its applicable user groups and applications. Look for: (a) conflicting access grants for the same app, (b) contradictions in session policies, (c) device compliance requirements that differ between companies. Build the consolidated policy set before Day 1.
Landmine 6: Tenant-Specific B2B Settings
Entra ID B2B (external guest access) settings are tenant-specific: who can invite guests, what domains are allowed or blocked, what guest user types are permitted, and what the default collaboration restrictions are.
When you consolidate to a single tenant, the B2B settings from one company suddenly apply to all users. If the acquiring company had a permissive B2B policy (any external domain allowed) and the acquired company was in a restricted industry (only pre-approved domains), the merger creates a compliance issue.
Fix: Check the Entra ID cross-tenant access settings for both organizations. The AllowInternalOrganization and AllowExternalOrganizations settings in B2B directly affect which partners and vendors can access your tenant post-merger.
The Pattern
All six landmines share a common root cause: Entra ID configuration was treated as a Day 1 operational problem rather than a pre-close discovery problem.
Every one of these is cheaper to find in due diligence than to debug post-close during an integration when 2,000 users are depending on the systems to work.