Support
      Back to home
      1. SecureDynamics Knowledge Base
      2. Support

      🧩 How to Merge ZIA and ZPA Tenants in Zscaler + What to Expect for End Users

      If your organization first deployed Zscaler Private Access (ZPA) and is now adding Zscaler Internet Access (ZIA), you’ll need to merge the tenants to enable unified management. This guide explains the merge process, user experience

       

      ✅ SecureDynamics provides white glove support through this process.

      🧭 Overview: Why Merge ZIA and ZPA Tenants?

      ZPA and ZIA are provisioned as separate tenants by default. Merging them:

      • Enables centralized policy and user management

      • Provides unified logging and diagnostics

      • Streamlines Client Connector behavior

      • Prevents duplicated user management and policy drift

      🔄 Step-by-Step: How to Merge ZIA and ZPA Tenants

      1. Prepare Your Environment

      Before initiating a merge, sync all ZPA users into ZIA to avoid post-merge auth errors.

      Example: SCIM with Azure AD

      1. In the ZIA Admin Portal:

        • Go to Administration > Authentication > SCIM Configuration

        • Enable SCIM provisioning

      2. In Azure AD:

        • Go to Enterprise Applications > Zscaler Internet Access

        • Set Provisioning to Automatic

        • Assign users/groups already configured for ZPA

      3. Test sync and confirm users appear under ZIA > Administration > Users

      For Okta or Ping: Follow Zscaler’s SCIM provisioning guide.

      2. Submit a Merge Request

      • Open a Support Case with Zscaler

      • Include:

        • ZIA and ZPA tenant IDs

        • Company name and contact info

      3. Zscaler Performs the Merge

      Zscaler’s Provisioning Team will:

      • Validate tenant ownership

      • Merge backend systems

      • Sync users, roles, SSO, and profiles

      4. Validate Access & Forwarding Profiles

      Once notified:

      • Log into Mobile Admin Portal

      • Ensure both ZIA + ZPA are active

      • Go to Administration > Forwarding Profile

      • Set ZIA Forwarding Action to “None” for:

        • Trusted Network

        • VPN Trusted Network

        • Off Trusted Network

      This prevents ZIA policies from immediately impacting ZPA users post-merge.

      Screenshot

      5. Final Testing

      • Validate ZIA functionality

      • Confirm user sync

      • Notify Zscaler Support of any issues

      6. Begin ZIA Rollout

      • Create a new Forwarding Profile for ZIA access

      • Assign select groups for phased rollout

      • Update your main profile once ready for full production use

      👥 What Users Will Experience

      🔐 Authentication Prompt After Merge

      When ZIA is introduced via ZCC after ZPA, users will typically be prompted to sign in again.

      Why?

      • Separate SAML authentication flow

      • ZIA performs new device fingerprint validation

      • Different SSO configurations

      Common Scenarios:

      • Reauthentication required in ZCC

      • 42000 error for mismatched usernames

      • Device fingerprint rejection (triggering BRK_MT_AUTH_SAML_FINGER_PRINT_FAIL)

      🔁 Ask users to log out and back into ZCC after merge to avoid auth loops

      ⚠️ Important Notes

      Consideration Details
      Merge Timeline Usually takes 2–5 business days
      Policy Gaps Review policies manually post-merge
      End-User Impact Minimal if ZIA Forwarding Action is set to “None” initially
      Trusted Network Settings Must be validated for ZIA profiles

      📘 Additional Resources

      💬 Need Help?

      📨 Submit a Ticket to SecureDynamics Support