Post-Merger SASE Consolidation With Overlapping Addresses
Two regional insurers are merging. Company A has 3,000 users, 25 sites, FortiSASE with Azure AD authentication, and a regional EU data-residency requirement. Company B has 2,000 users, 15 sites, a legacy on-premises proxy, VPN concentrators, and on-premises Active Directory. Both use 10.0.0.0/8 internally, with several overlapping 10.10.x.x and 10.20.x.x subnets. Company A’s FortiSASE tenant is in the EU; Company B’s users are mostly in the EU but some contractors are in Asia. The merger team wants one SASE platform within 12 months, no disruption to policy renewal, and a single identity view. Company B’s security team insists its on-premises proxy has custom URL categories that must be preserved. Company A’s CISO is concerned that overlapping IP addresses will cause routing loops and policy ambiguity during migration.
1. How would you unify identity and policy across Azure AD and on-premises Active Directory without forcing a risky re-IP project first?
Read the worked answer
Use Azure AD as the target identity plane and federate or synchronize Company B’s on-premises AD into it, preserving group structure where it maps to policy. Establish a single UPN namespace and resolve duplicate or conflicting accounts before migration. Map Company B’s proxy groups and custom URL categories to FortiSASE policy objects, and re-create only the categories that have a business owner; do not carry forward unowned rules. For contractors in Asia, use separate groups and conditional access, with EU data-residency rules applied to EU users and a documented exception process for cross-region access. The judgement is to avoid a parallel identity forever: dual identity creates policy drift. A re-IP project is not required for identity unification, but overlapping addresses still need an access strategy, so separate the identity workstream from the network workstream and sequence identity first because it unlocks policy migration.
2. What is your approach to the overlapping 10.x address space during the SASE migration?
Read the worked answer
Do not merge the two private networks into one flat routed domain. Use ZTNA application publishing or per-application connectors so users reach named applications by identity and DNS name rather than by destination IP. Where IP-based access is unavoidable, use NAT at the connector or a dedicated migration enclave, and document the translation. Keep Company A and Company B sites in separate SD-WAN domains or VRFs until the address plan is cleaned up. For FortiSASE private access, publish only the specific applications and subnets required, not the entire 10.0.0.0/8. Test with overlapping test subnets to confirm that policy and routing select the correct tenant. The judgement is that overlapping IP is a routing and policy problem, not a reason to delay identity migration; application-based access reduces the blast radius and lets the merger proceed in phases.
3. Propose a 12-month migration sequence that preserves EU data residency and retires the legacy proxy without a policy renewal gap.
Read the worked answer
Phase 1, months 0–3: inventory Company B proxy rules and URL categories, map owners, and stand up Azure AD synchronization and group mapping. Phase 2, months 3–6: onboard a pilot group from Company B to FortiSASE in the EU tenant, using ZTNA for overlapping applications and mirrored custom categories. Keep the legacy proxy as fallback. Phase 3, months 6–9: migrate by site and business unit, with EU users kept on EU PoPs and logging retained in the EU; route Asian contractors through the approved region with a documented data-residency exception. Phase 4, months 9–12: retire proxy and VPN concentrators after two clean audit cycles, remove fallback rules, and validate one identity view. The judgement is to migrate policy ownership before traffic, and traffic before decommissioning. A “big bang” cutover would create a renewal gap and make overlapping-address incidents hard to isolate.