# CBI and SIPA — when Isolate is not the same as Anchor Source: https://ai.techclick.in/blog_zscaler_b11_12_cbi_sipa Markdown: https://ai.techclick.in/blog_zscaler_b11_12_cbi_sipa.md Publisher: Techclick Infosec Pvt Ltd Choose Isolate (CBI / Zero Trust Browser) vs Source IP Anchoring vs inspect-in-PSE. Draw the traffic path, apply exemptions, and prove Isolate plus anchored egress in logs. Quick answer (say this out loud) Inspect-in-PSE is the default: ZIA inspects at a Public Service Edge and the destination sees a Zscaler egress IP. Isolate (Zero Trust Browser / CBI) is a URL Filtering or Cloud App Control action — the request is redirected to an Isolation Profile URL, a remote browser fetches the page, and the user gets a rendered stream. Active content stays off the endpoint. SIPA does not skip ZIA. After inspection, Forwarding Control with Forwarding Method = ZPA sends the already-inspected session through a ZPA App Connector whose Source IP Anchor flag is on, so the destination sees your connector IP. CBI is a content / endpoint problem. SIPA is a source-IP problem. They compose; they do not replace each other. Hero · two last hops Notice: one cloud, two exits. Isolate keeps active web off the laptop. Anchor changes the IP the SaaS sees. ## 1. Why two last hops exist ZIA + ZPA already inspect, authenticate, and broker private apps. Production still hits two walls that “Allow at the Public Service Edge” cannot answer. Wall 1 — the endpoint is untrusted. A contractor on a personal Mac must read Newly Registered Domains or Miscellaneous & Unknown. You do not own the laptop. Block kills the work. Allow puts active HTML and JavaScript on a device with no EDR. Isolate is the third verdict: yes, but rendered in a disposable remote browser. Wall 2 — the destination trusts source IPs. Workday, a bank API, or Microsoft 365 Conditional Access will only accept logins from a short corporate allow-list. Default ZIA egress is a large, shared Public Service Edge pool. No SaaS admin will whitelist that. SIPA changes the last hop so the destination sees the App Connector IP you control. #### CBI / Zero Trust Browser Product name in current Help is Zero Trust Browser (formerly Isolation / Cloud Browser Isolation). Interviews still say CBI. The policy action is Isolate . #### SIPA Source IP Anchoring is a ZIA + ZPA feature. Help also files it under Customer-Managed Dedicated IP. The on-switch is the Source IP Anchor checkbox on an Application Segment. Feel · three answers Path A Isolate, Path B SIPA, Path C inspect-in-PSE. The table later names when each wins. ## 2. Mental model — three paths, two problems Pre-train these words before you open Admin. - Inspect-in-PSE — user → Public Service Edge → destination. SSL Inspection, URL Filtering, DLP, Sandbox all run. Destination sees a Zscaler IP from the cloud’s published ranges. - Isolate — URL Filtering (or Cloud App Control) matches, action is Isolate , an Isolation Profile is attached. Help: the HTTP/HTTPS request is redirected to the isolation profile URL. The remote browser fetches the origin. The user’s tab is a viewport. - SIPA — same ZIA inspection first. Then Forwarding Control Forwarding Method = ZPA sends the session to a ZPA Gateway and a Source-IP-Anchored Application Segment. The App Connector egresses. Destination sees that connector’s IP. Say this out loud Isolate answers “can active content touch this laptop?” SIPA answers “which source IP does the destination see?” Inspect-in-PSE is the default when both answers are already acceptable. Flow · three last hops Inspect at PSE, Isolate in a remote browser, or SIPA through an App Connector - User / ZCC Browser or tunnel Same first hop Public Service Edge Inspect + policy Then pick last hop Inspect-in-PSE Zscaler egress IP Isolate Isolation Profile URL SIPA App Connector IP SaaS / web sees different source IP and/or pixels Read left → right. Inspection is not optional on SIPA. Isolate changes what the laptop receives. SIPA changes what the destination records as source. ## 3. Decision flow — ask two questions The flowchart is the lesson. Prose only names the diamonds. Decision · Isolate, SIPA, or inspect Decision tree for Isolate versus SIPA versus inspect-in-PSE What is the ticket actually asking? Must active content stay off this endpoint? Yes Isolate + Isolation Profile No Destination needs your source IP? Yes SIPA Source IP Anchor No Inspect-in-PSE Default ZIA egress BYOD + SaaS IP list? contractor → Workday Isolate + SIPA compose, do not merge Hard constraints from Help (do not invent around them) Isolate is a URL Filtering / Cloud App Control action. SIPA is Forwarding Method = ZPA after inspection. SIPA ≠ Dedicated IP (ENATDEDIP) ≠ Surrogate IP. Source IP Anchor cannot share Browser Access or Double Encryption. Diamond = decision. If both diamonds are yes, stack Isolate and SIPA. Do not turn Isolate into a fake IP allow-list. ## 4. How to choose — Isolate vs SIPA vs inspect-in-PSE Help names three different objects. Interviews fail when someone calls Dedicated Proxy “SIPA” or calls Isolate “a proxy.” Situation Prefer Last hop the destination / laptop sees Do not use when Risky or unknown web on a managed or unmanaged device; you need a third verdict between Allow and Block Isolate (Zero Trust Browser / CBI). URL Filtering or Cloud App Control action Isolate + Isolation Profile. Laptop sees a rendered isolation session. Origin HTML/JS stays in the remote browser. Destination still sees the isolation farm / Zscaler fetch, not “pixels as source IP.” The app is sanctioned SaaS-of-record, banking OTP, Jira/Confluence multi-tab, Zoom/Teams/WebRTC, or an IdP login you have not exempted. Isolate is also a paid add-on — do not Isolate Social Media for the whole company. Destination has a short IP allow-list, Conditional Access named locations, or a compliance rule that egress must be a customer-owned IP SIPA . Application Segment with Source IP Anchor + ZIA Forwarding Control Forwarding Method = ZPA . Destination sees the App Connector’s public IP (your NAT / EIP). ZIA still inspected the session. You try to SIPA “all internet.” You define the segment as a raw IP when Help wants FQDN for that app type. You also enable Browser Access or Double Encryption on the same segment. Normal internet. Destination accepts Zscaler IPs. Content is not so risky that you need a remote browser Inspect-in-PSE . Default Allow / Caution / Block at the Public Service Edge. SSL Inspection + URL / Cloud App / DLP / Sandbox as usual. Destination sees a Zscaler Public Service Edge IP from the published cloud ranges. The SaaS admin already sent “give me your four corporate IPs,” or the device cannot be trusted with native active content. Contractor on BYOD must use your Workday, and Workday only allows corporate IPs Isolate + SIPA stacked. Isolate the user experience; SIPA the fetch toward Workday. Laptop gets pixels. Workday sees the App Connector IP. You pick only one tool and hope. Isolate does not create a stable corporate IP. SIPA does not air-gap the laptop. You need a Zscaler-owned reserved egress IP, not a connector in your VPC Dedicated IP (Forwarding Method that Help / Terraform call dedicated-IP / ENATDEDIP ). Separate SKU. Destination sees a Zscaler-provisioned dedicated IP, not your App Connector. You call this SIPA in an interview. SIPA’s last hop is the customer App Connector. Microsoft 365 Conditional Access — scope SIPA to login Help’s M365 SIPA article: you typically only need to anchor the initial login hosts — login.microsoftonline.com , login.windows.net , login.microsoft.com . After the token is issued, bulk M365 traffic does not need the corporate IP. Keep the Application Segment that narrow or you pay latency on every SharePoint download. ## 5. Mini runbook — Side A destination, Side B product, Side C exemptions Goal: one Isolation Profile + one Isolate rule for risky web, and one SIPA chain for a named SaaS. Source for Isolate: Help What Is Zero Trust Browser? , Creating Isolation Profiles for Internet & SaaS , Configuring Internet & SaaS for Zero Trust Browser , Configuring the URL Filtering Policy . Source for SIPA: Help Understanding Source IP Anchoring , Configuring Source IP Anchoring , Configuring Forwarding Policies for Source IP Anchoring using ZPA . ### Side A — destination and connector first #### Confirm the ticket is a source-IP problem Ask the SaaS admin for the exact allow-list UI (Workday IP restriction, Microsoft Entra named location, bank API ACL). If they do not have one, you do not need SIPA. - #### Place App Connectors that already egress from the IPs you will publish SIPA’s destination-visible IP is the App Connector’s egress (your NAT Gateway / EIP). Collect every connector in the group — primary and failover. The SaaS allow-list must include all of them. - #### Do not confuse three similarly named features SIPA = Source IP Anchor + Forwarding Method ZPA. Dedicated IP = Zscaler-provisioned dedicated egress. Surrogate IP = map a private client IP to an authenticated user for policy. Only the first one answers “Workday must see 203.0.113.10.” ### Side B — product: Isolate, then SIPA admin.zscaler.net · Isolation Profiles Training mock · not live Policies → Common Configuration → Resources → Browser Isolation Threat → Isolation Profiles → Add Isolation Profile ### Add Isolation Profile Profile name ISO-Risky-Web-Research Region selection All Isolation experience Native Browser Experience Isolation banner Default Allow copy & paste from Configured (restrict copy out) Allow file transfers from Restricted Read-only mode Off — enable only for view-only research Persist browser isolation URL bar Disabled Cancel Save and activate Help field names: Allow Copy & Paste From, Allow File Transfers From, Isolation Banner, Isolation Experience, Read-Only Mode, Persist Browser Isolation URL bar. Older tenants: Administration → Secure Browsing → Browser Isolation. Next: attach this profile on a URL Filtering rule whose action is Isolate. Source: Creating Isolation Profiles for Internet & SaaS. - #### Create the Isolation Profile Current Help path: Policies → Common Configuration → Resources → Browser Isolation Threat → Isolation Profiles → Add Isolation Profile . Set Allow Copy & Paste From and Allow File Transfers From to the tightest setting the use case still allows. Turn Read-Only Mode on when the user should only view. Isolation Banner tells the user they are isolated — use it when silent Isolate would confuse them. - #### Create the Isolate URL Filtering rule above conflicting Allow/Block Path: Policy → URL & Cloud App Control → Add URL Filtering Rule . Action Isolate . Isolation Profile = the one you just saved. Typical categories: Newly Registered Domains, Miscellaneous & Unknown, suspected phishing. Help auto-creates a Miscellaneous & Unknown isolate rule and leaves it disabled — do not assume it is live. First-match wins: an Allow or Block above this rule means Insights will never show Isolate. admin.zscaler.net · Add URL Filtering Rule Training mock · not live Policy → URL & Cloud App Control → Add URL Filtering Rule ### Add URL Filtering Rule Rule name ISO-Misc-Unknown-Research Rule order 12 — above the generic Allow News rule URL categories Miscellaneous or Unknown · Newly Registered Domains Users / groups grp-ma-research@example.com Action Isolate Isolation profile ISO-Risky-Web-Research Client Connector groups (when licensed) Cloud Browser Isolation group appears only if Zero Trust Browser is enabled for the org Cancel Save and activate Isolate appears only if Cloud Browser Isolation / Zero Trust Browser is entitled. Isolation Profile is required once Isolate is selected. Cloud App Control can Isolate the same way. Next: activate, then browse a Misc & Unknown URL as the pilot user and confirm Web Insights Action = Isolate. Source: Configuring the URL Filtering Policy · Configuring Internet & SaaS for Zero Trust Browser. - #### SIPA Application Segment — Source IP Anchor on, Bypass = Use Client Forwarding Policy In the ZPA Admin Portal create the Application Segment for the SaaS FQDNs. Enable Source IP Anchor . Set Bypass to Use Client Forwarding Policy . Do not also enable Browser Access, Double Encryption, or Multimatch Inclusive — Help treats those as mutually exclusive with SIPA. - #### Client Forwarding Policy + Access Policy (domain-based pattern) Domain-based Help pattern: one Client Forwarding rule Bypass ZPA for the SIPA segment groups, client types except ZIA Service Edge . Second rule Forward to ZPA for client type ZIA Service Edge only. Access Policy: Allow Access for ZIA Service Edge to that segment. Do not add user / group / SAML / SCIM criteria on the ZPA Access Policy — ZPA sees the ZIA Service Edge as the client, not priya@example.com. Scope users on the ZIA Forwarding Control rule instead. - #### ZIA ZPA Gateway + Forwarding Control Method = ZPA Create the named ZPA Gateway (Administration → ZPA Gateway). Then Policy → Forwarding Control → Add Rule : Forwarding Method = ZPA , Application Segment = the SIPA segment, Forward to ZPA Gateway = the gateway you just created. Match users/locations here. - #### DNS Control — ZPA Resolver order Enable the preconfigured ZPA Resolver for Road Warrior and ZPA Resolver for Locations . Road Warrior must sit above Locations. If DNS for the SIPA FQDN leaves Zscaler (for example 8.8.8.8), the client never gets the ZPA synthetic IP and SIPA fails silently. Z-Tunnel 1.0 / PAC road warriors also need Administration → Advanced Settings → Enable Firewall for Z-Tunnel 1.0 and PAC Road Warriors . admin.private.zscaler.com · Application Segment · Source IP Anchor Training mock · not live Application Segments → Add Application Segment · then ZIA Policy → Forwarding Control ### Application Segment · SIPA Name SIPA-workday-login Applications (FQDN) wd5.myworkday.com Source IP Anchor Enabled Bypass Use Client Forwarding Policy Browser Access Off — mutually exclusive Double Encryption Off — mutually exclusive ZIA forwarding control (after this segment exists) Forwarding Method = ZPA · Application Segment = SIPA-workday-login · ZPA Gateway = zpa-gw-prod Cancel Save Placeholder FQDN only. Help: enable Source IP Anchor and Use Client Forwarding Policy. Access Policy allows ZIA Service Edge — not a copy of your ZIA user list. Next: enable both ZPA Resolver DNS rules, allow-list every App Connector egress IP on Workday, then prove the destination-seen IP. Source: Configuring Source IP Anchoring. ### Side C — exemptions and file access - #### Do not Isolate the IdP, the SaaS of record, or real-time media Leave Microsoft / Okta login hosts, Workday/Jira/ServiceNow of record, and Zoom/Teams/WebRTC on inspect-in-PSE (or SIPA if the destination requires it). Isolating an IdP can hairpin SAML the same way an un-exempted PAC does. - #### File access from an isolated page needs a URL Filtering exception Help Transferring and Viewing Files in Isolation : to open files from an Internet & SaaS isolation profile you must configure a URL Filtering exception. Without it, users report “download does nothing.” - #### SIPA allow-list every connector IP, then stop Publish primary and failover App Connector egress IPs to the SaaS admin. Do not SIPA the rest of the internet. Keep DNS for those FQDNs on Zscaler. Do not treat ip.zscaler.com as SIPA proof ip.zscaler.com shows a Public Service Edge IP for ordinary ZIA traffic. A SIPA’d destination is the only place that will record the App Connector IP. If you did not put that “what is my IP” host in the SIPA segment, the page will still show a Zscaler IP — and you will file a false incident. ## 6. Runtime path after go-live Once both policies are active, a single user request takes one of these three wires. Isolation can sit in front of a SIPA fetch: the remote browser is the client that ZIA then forwards through the App Connector. Runtime · inspect, Isolate, SIPA Three runtime paths from user through ZIA to destination - Same user · three possible last hops A · Inspect-in-PSE (default) User Public Service Edge Destination ← Zscaler IP Logs: Action Allow / Block B · Isolate (Zero Trust Browser / CBI) User tab PSE Isolate Isolation Profile URL remote browser fetches Origin Logs: Action Isolate C · SIPA (inspect, then App Connector) User PSE inspect Fwd Method ZPA ZPA Gateway App Connector SaaS ← your IP Path C never skips the Public Service Edge. If Isolate and SIPA are stacked, row B’s remote browser is the client that then walks row C toward the SaaS. ## 7. Traps + proof in logs Proof · close the ticket with a named field Notice: proof is a named field on a timestamp, not a screenshot of a spinning tab. Symptom Likely cause First check Web Insights shows zero Isolate hits; users still get native pages A higher URL Filtering or Cloud App rule already Allow / Block / Caution. Or the auto Misc & Unknown isolate rule is still disabled. Analytics → Web Insights → Logs. Filter the URL. Read Policy / Action on the first match. Move Isolate above the conflicting rule. User can see the isolated page but cannot download or preview a file No URL Filtering exception for file access from isolation. Help: Transferring and Viewing Files in Isolation. Add the exception, then retest with the same Isolation Profile. OTP paste into an isolated bank login fails; user says “the bank is broken” You Isolated a category that should have stayed inspect-in-PSE. Copy/paste is governed by Allow Copy & Paste From on the profile. Remove banking / IdP from Isolate. Do not “fix” it by opening copy-out on a risky-web profile. Workday / M365 CA blocks every user after a connector failover SaaS allow-list has only the primary App Connector IP. Compare the destination’s last-login IP to the full connector group. Add failover NAT/EIPs. This is not a ZIA URL issue. ZIA Forwarding Control matches, ZPA still denies SIPA Access Policy requires SAML user/group, or it does not allow client type ZIA Service Edge . Or Source IP Anchor is off. ZPA Diagnostics + Access Policy. Strip user criteria. Allow ZIA Service Edge only. Road warriors egress from the wrong IP; office users look fine ZPA Resolver for Road Warrior disabled or sitting below Locations. Or client DNS bypasses Zscaler. DNS Control rule order. Confirm the SIPA FQDN resolves through ZIA, not 8.8.8.8. Pilot checklist — green means you can close the ticket Isolate: Analytics → Insights → Web Insights Logs. Transaction for the pilot URL shows Action = Isolate , the URL Filtering rule name, the Isolation Profile, and the username. The user’s View Source is the isolation viewport, not the origin HTML. - Inspect-in-PSE: same log view, Action is Allow / Block / Caution (not Isolate). Client IP / server-side source is a Zscaler Public Service Edge address. - SIPA: ZIA log shows the Forwarding Control rule and Forwarding Method ZPA. ZPA Diagnostics shows the App Connector healthy. The SaaS admin’s last-login / named-location IP equals the connector NAT (example 203.0.113.10), not a Zscaler CENR address. A non-SIPA control user to the same app still shows a Zscaler IP. - Stacked: Isolate log for the contractor tab and Workday last-login = connector IP on the same test. #### Weak interview answer “CBI is a proxy and SIPA is four dedicated Zscaler IPs.” That mixes Isolate with inspect, and SIPA with Dedicated IP. #### Strong interview answer “Isolate redirects to an Isolation Profile so active content never reaches the endpoint. SIPA inspects at the PSE then egresses from a Source-IP-Anchored App Connector. I prove Isolate with Action Isolate, and SIPA with the destination-seen IP.” ## Knowledge check Six judgment items. Pick one option each, then Check answers. Reasons point back to the section to re-read. Q1 A contractor on a personal laptop must read Newly Registered Domains for an investigation. Security will not Allow native browse. What is the right ZIA action? Allow the category and rely on SSL Inspection Isolate and attach an Isolation Profile (Zero Trust Browser / CBI) Enable Source IP Anchor on an Application Segment for the whole internet Turn on Surrogate IP at the location Correct: b . Isolate is the third verdict between Allow and Block. SIPA and Surrogate IP do not keep active content off the laptop. Re-read §4 Choose-when and §2 Mental model. Q2 Workday will accept logins only from your corporate IPs. Users already go through ZIA. What actually changes the last hop the SaaS records? An Isolation Profile with Read-Only Mode Surrogate IP so ZIA can name the user Source IP Anchor on the Application Segment plus Forwarding Method = ZPA Block Workday in URL Filtering so users go direct Correct: c . SIPA inspects at the Public Service Edge, then the App Connector egresses with your IP. Isolation and Surrogate IP do not publish a customer source IP. Re-read §4 and Side B steps 3–5. Q3 You built ISO-Misc-Unknown-Research last week. Analysts browse Miscellaneous or Unknown all day. Web Insights shows zero Isolate actions. What do you check first? Whether SIPA consumed the session before URL Filtering A higher URL Filtering or Cloud App rule that already Allow / Block / Caution the same category Whether Kerberos is enabled on Default Settings Whether Dedicated IP is licensed Correct: b . URL Filtering is first-match. Help also ships a disabled Miscellaneous & Unknown isolate rule — if yours sits below an Allow, Insights will never show Isolate. Re-read Side B step 2 and the traps table. Q4 ZIA Forwarding Control matches the SIPA user. ZPA Diagnostics shows the connector green. The user still cannot reach Workday. You scoped the ZIA rule to one SCIM group. What is the classic Access Policy mistake? You forgot to enable Isolation Banner You copied the SCIM group onto the ZPA Access Policy — ZPA sees client type ZIA Service Edge, not the user You used FQDNs instead of raw IPs on the Application Segment You left Browser Access enabled, which Help requires for SIPA Correct: b . Help warns: do not add user/SAML/SCIM criteria on the SIPA Access Policy. Allow ZIA Service Edge only. Browser Access is mutually exclusive with Source IP Anchor. Re-read Side B steps 3–4 and traps. Q5 Microsoft 365 Conditional Access needs a trusted corporate IP at login. What is the Help-aligned SIPA scope? Source-IP-Anchor every Microsoft 365 FQDN including SharePoint and Teams media Isolate login.microsoftonline.com so pixels hit Entra Application Segment only for login.microsoftonline.com, login.windows.net, and login.microsoft.com Enable Double Encryption on the SIPA segment for the token Correct: c . Help’s M365 SIPA article scopes the initial login hosts; post-auth traffic uses the token. Isolate does not satisfy named locations. Double Encryption is mutually exclusive with SIPA. Re-read the M365 callout in §4. Q6 How do you prove Isolate fired and SIPA changed egress — on the same contractor → Workday test? Web Insights Action = Isolate for the tab, and Workday’s last-login IP equals the App Connector NAT — not ip.zscaler.com ip.zscaler.com on the contractor laptop shows a Zscaler IP, so SIPA is working ZCC tray shows a CBI badge and a SIPA badge Firewall Insights Action = Block and Surrogate IP is populated Correct: a . Isolate proof is Web Insights Action Isolate. SIPA proof is the destination-seen connector IP. ip.zscaler.com is inspect-in-PSE evidence, not SIPA. Re-read §7 proof checklist. Check answers Reset ## Sources - What Is Zero Trust Browser? — Isolate redirect to the Isolation Profile URL. - Creating Isolation Profiles for Internet & SaaS — Allow Copy & Paste From, Allow File Transfers From, banner / experience. - Configuring Internet & SaaS for Zero Trust Browser — URL Filtering rule that forwards to isolation. - Configuring the URL Filtering Policy — Action Isolate, Isolation Profile, Cloud Browser Isolation group. - Understanding Isolation of Miscellaneous & Unknown Category in ZIA — auto-created, disabled-by-default isolate rule. - Transferring and Viewing Files in Isolation — URL Filtering exception for files. - Read-Only Mode in Isolation . - Configuring Smart Browser Isolation Policy — separate AI/ML isolate policy. - Understanding Source IP Anchoring . - Configuring Source IP Anchoring — Source IP Anchor + Use Client Forwarding Policy. - Configuring Forwarding Policies for Source IP Anchoring using ZPA — Forwarding Method = ZPA. - Configuring Source IP Anchoring for Microsoft 365 Conditional Access — login-host scope. - Understanding Source IP Anchoring Direct — DR variant; revert manually. - Customer-Managed Dedicated IP (Source IP Anchoring) — Help category that houses SIPA. - Web Insights Logs: Columns — Action and policy fields for proof. Related: URL Filtering & Cloud App Control · SSL Inspection · ZPA App Connectors · ZPA policies & app segments · Logs & ZDX · Authentication — identity before policy --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt