CASB and SSE platform migration playbook: change platforms without opening egress gaps

Replacing a cloud access security broker (CASB) or security service edge (SSE) platform means changing the path every user and device takes to the internet, SaaS and private applications, and most migrations open gaps because traffic steering, bypass lists and API connectors are moved by configuration export rather than verified by traffic. Organisations change platforms when they consolidate a standalone CASB, web gateway and remote access VPN into one SSE service, when a contract ends, when an acquisition brings a second platform, or when performance or regional coverage no longer fits. This playbook is for network and security engineers, identity teams and programme managers running that switch. It covers what has to move, how to prove policy parity on real traffic, how to migrate user populations in rings, how to handle TLS inspection and bypass lists, and how to retire a platform that holds API access to your SaaS tenants. It is vendor-neutral and names no products. The fundamentals are in the CASB Guide and the SASE and SSE Guide; moving from legacy appliances to a converged service for the first time is covered in SASE Migration.

Key takeaways

• Steering is the first parity test. Before comparing policy verdicts, prove every user, device, office and server segment is actually sending traffic through the new platform, and know exactly what bypasses it.
• Bypass and exception lists are decisions. Domains excluded from inspection or steering were each excluded for a reason; re-approve them with an owner rather than copying the list.
• API mode and inline mode migrate differently. SaaS API connectors can run in parallel with no user impact; inline steering cannot, so it moves in rings with a rollback path.
• Private access is the riskiest consumer. Move remote access to internal applications last, application by application, keeping the old path available for a defined period.
• Retirement is an identity task. OAuth grants, tenant admin consents, connector credentials, client certificates and inspection root certificates from the old platform must be removed everywhere on a fixed date.

What has to move

A CASB or SSE platform combines traffic steering, policy, inspection, SaaS API integrations, private access connectors and logs. Inventory each element yourself before relying on any import tool.

Build a policy requirements register first: for each requirement (block uploads of regulated data to unsanctioned storage, allow the corporate tenant of a collaboration suite but not personal tenants, isolate uncategorised sites, require a compliant device for finance applications) record owner, driver, user population and expected action. That register is portable; a platform's policy objects are not. A requirement written as an outcome can be tested on both platforms.

Proving steering and policy parity

1. Steering parity. For each ring, compare the device inventory, office list and server egress segments with the sessions the new platform actually sees. A device with the client installed but traffic failing open, or an office tunnel that routes only some subnets, is a gap. Record every bypass that remains and why.
2. Policy parity on test cases. Build a test plan from the register: a blocked category, an allowed category, an unsanctioned storage upload with synthetic regulated data, a personal tenant sign-in, a non-compliant device reaching a restricted application. Run each from a test device on the old platform and the new one and record the verdict and the log entry each produced.
3. Policy parity on live traffic. For the pilot ring, compare top blocked categories and applications, DLP hits and warn prompts week on week between the old baseline and the new platform. Explain every material difference as a translation error, a catalogue difference to accept, or an improvement.
4. Identity parity. For a sample of users in each sensitive group, confirm the new platform resolves the same group membership through SCIM and applies the same policy. A missing group mapping silently drops users into the default policy.

NIST SP 800-207 describes zero trust as verifying user and device separately before access to an enterprise resource is granted, regardless of network location; the identity and device posture tests are where a migration either preserves or quietly weakens that model.

Choosing a migration pattern

Small organisations: often one platform serving remote users through a client; a pilot of a few users per department, a two week ring schedule and a short test plan is proportionate. Large organisations: expect hundreds of bypass entries, multiple tunnel locations and regional data residency requirements for logs; treat bypass re-approval, certificate deployment and private access migration as separate workstreams with their own owners.

The phased playbook

1. Phase 0: scope and dates. Confirm capabilities in scope, user populations, regions, log residency needs and the old contract end date. Record a risk acceptance for any capability with reduced coverage during the move.
2. Phase 1: inventory and rationalise. Export policies, bypass lists, category mappings, private applications, connectors and integrations. Flag rules with no hits in twelve months and bypass entries with no owner.
3. Phase 2: secure foundations. Configure admin roles, single sign-on and audit logging on the new platform first, following Securing the CASB and SSE platform itself. Set up SCIM sync and group mappings. Distribute the new inspection certificate to managed device trust stores and to application trust stores that do not use the operating system store.
4. Phase 3: API mode in parallel. Connect SaaS tenants with scoped OAuth grants or service accounts, run data at rest scans and posture checks in report-only mode, and compare with the old platform's findings.
5. Phase 4: inline pilot. Deploy the new client or steering to the pilot ring with the old one uninstalled or disabled for those devices. Start with inspection on a limited set of categories, then widen. Watch for broken applications, certificate pinning failures and performance complaints.
6. Phase 5: rings and sites. Expand ring by ring and move office tunnels site by site. Keep old steering configuration intact so a ring can revert.
7. Phase 6: private access. Migrate internal applications one at a time, lowest risk first, with old access retained for each application until the new path is proven. Remove old connectors from the network only after their applications have moved.
8. Phase 7: freeze, archive and retire. Freeze old policies, export logs needed for investigations and audits, revoke all grants and credentials, remove the old certificate and client, and confirm supplier data deletion.

Testing and rollback

Write the rollback condition before each ring or site moves: for example a business-critical application unreachable for longer than an agreed time with no workaround, or help desk tickets above an agreed rate. Rollback means restoring the old client, proxy configuration or tunnel for that ring, which works only if the old platform's policies are frozen and its licences still cover the ring. Test the rollback once on the pilot ring before wider rollout. As an NHI Mgmt Group recommendation, keep each ring able to revert for at least 30 days after it moves, and never let the old and new clients run active on the same device.

Where identity fits: grants, connectors and certificates

A CASB or SSE platform depends on non-human identities with unusually broad reach: OAuth applications with tenant-wide read access to mail, files and chat; SaaS admin consents; private access connector credentials inside your network; SCIM tokens that can read the directory; device certificates or tokens that authenticate the client; and an inspection certificate trusted by every managed device.

• Record each grant and credential as an NHI with owner, scope and removal date; the Cloud Workload Identity Guide covers token-based alternatives to static secrets.
• Scope API grants to what the policy needs: read rather than read and write where remediation is not used.
• Treat the inspection certificate as a crown jewel: know where its private key lives and who can export it, and remove the old certificate from trust stores at retirement.
• Watch both platforms' grants during overlap for use from unexpected locations (ATT&CK T1550.001 Application Access Token, T1078.004 Cloud Accounts).

Archiving logs and retiring the old platform

• Agree with security operations, legal and audit which web, SaaS activity and DLP logs must be retained, export them to a controlled store with the regional residency they require, and record the retention period (NIST SP 800-53 AU-11).
• Revoke OAuth grants and admin consents in every SaaS tenant, delete SCIM tokens, and remove the old platform's enterprise application from the identity provider.
• Uninstall old clients and remove proxy auto-configuration files, explicit proxy settings and tunnels; confirm no device or site still resolves or reaches the old service.
• Remove old private access connectors and their credentials from the network, and the old inspection certificate from every trust store.
• Obtain written confirmation of customer data deletion from the supplier. CSF 2.0 GV.SC-10 covers activities at the end of a supplier relationship; NIST SP 800-88 Rev. 2 covers sanitisation of any on-premises appliances.

Detection and measurement

• Egress that bypasses both platforms: firewall and DNS logs showing direct internet traffic from managed devices and servers (CSF DE.CM-01).
• Exfiltration techniques the policies target: ATT&CK T1567.002 Exfiltration to Cloud Storage and T1530 Data from Cloud Storage; confirm the test cases fire on the new platform.
• Admin activity on both consoles: policy, bypass and certificate changes, forwarded to the SIEM.

Common failure patterns

• Copying the bypass list. Hundreds of exclusions move across unexamined, including whole cloud storage domains added years ago to fix one application.
• Deploying the certificate late. Inspection starts before all trust stores hold the new certificate, applications break, and the team responds by widening inspection bypass.
• Two clients on one device. Old and new clients both try to steer traffic, causing failures that are fixed by disabling one without tracking which.
• Losing group mappings. A SCIM attribute maps differently and privileged or restricted users fall into the default policy.
• Cutting private access in one step. Internal applications become unreachable for remote staff, and an emergency rollback restores broad network access.
• Leaving tenant grants behind. The old platform's OAuth application keeps tenant-wide read access to mail and files long after the contract ends.

Framework mapping

Practitioner checklist

• Policy requirements register built with owner, driver, population and expected action.
• Every bypass and inspection exclusion re-approved with an owner and reason.
• New inspection certificate deployed to all operating system and application trust stores before inspection starts.
• SCIM group and attribute mappings tested for every sensitive group.
• API connectors running in parallel with scoped grants and findings compared.
• Test plan run on both platforms with verdicts and log entries recorded.
• Rings moved one at a time with a tested rollback and no device running both clients.
• Private applications migrated individually with old access retained until proven.
• Logs archived with required residency and retention for open investigations and audits.
• Old grants, consents, SCIM tokens, connectors, clients and certificates removed; supplier deletion confirmation filed.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CISA: Trusted Internet Connections (TIC) 3.0
• CISA: Secure Cloud Business Applications (SCuBA)
• NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
• MITRE ATT&CK: Exfiltration to Cloud Storage

Related NHI Mgmt Group resources: CASB and SSE platform health check, If your CASB and SSE platform is compromised, SASE and SSE Buyer's Guide, ZTNA Guide, Secure Web Gateway and Web Filtering Guide.