# ZPA Browser Access: a visitor pass, not a building key Source: https://ai.techclick.in/blog_zscaler_zpa_browser_access Markdown: https://ai.techclick.in/blog_zscaler_zpa_browser_access.md Publisher: Techclick Infosec Pvt Ltd ZPA Browser Access is a visitor pass, not a building key. Publish one internal web app to an unmanaged browser — no agent, no inbound port — then work every production scenario and the six-hop fault map. Ticket that starts this lesson “Audit vendor starts Monday. Their laptop is theirs. They need the ticketing portal only. Do not give them VPN. Do not install our agent. And no, we are not opening 443 inbound.” Quick answer Browser Access publishes one internal HTTP/HTTPS application as a public hostname served by the ZPA Service Edge. The user authenticates at your IdP. Policy is checked per request. The App Connector still dials outbound only. The app server is never on the internet. What you lose is device posture — there is no Client Connector to report it. ## The user who cannot install your agent Hero · visitor pass Notice: they get a pass to one room. They do not get a key to the building. That is the whole Browser Access bargain. ZPA’s normal model is clean: Zscaler Client Connector on the device, a broker in the cloud, an App Connector next to the app, and a one-to-one tunnel stitched between them. The user never touches the network. The app is never published to the internet. Then reality shows up. A three-month audit vendor. A partner helpdesk. An employee on a personal iPad. A newly acquired company whose devices you do not manage yet. None of them will install your agent, and honestly none of them should. The old answer was a DMZ reverse proxy or a VPN account with a network route — both mean an inbound listener and a routable path into your estate. Browser Access is the ZPA answer: the Service Edge itself becomes the reverse proxy for one published web application. The browser is the client. Brokering, SAML, policy, and the outbound-only connector tunnel stay the same as agent-based ZPA. Who talks to whom Browser → ZPA Service Edge → App Connector → one app. Public DNS lands on Zscaler, not on your perimeter. The one-line definition Browser Access publishes a single internal HTTP/HTTPS application as a public hostname served by the ZPA Service Edge, authenticated by your IdP and policy-checked per request, without exposing the app server or opening an inbound port. Official start: About Browser Access . ## Mental model — visitor pass Learn three objects before you click anything. If you skip this, every later menu looks like another VPN wizard. #### 1. Published hostname The name the user types. Public DNS CNAME s it to a Zscaler-supplied target so the browser lands on a ZPA Service Edge. #### 2. Browser Access certificate The certificate the Service Edge presents during TLS. You upload one, or you let Zscaler generate and renew a managed certificate. #### 3. Internal application The FQDN the App Connector resolves inside your estate. It must be HTTP/HTTPS and the server must support TLS 1.2 . Two things you do not get on this path: a network route, and a device posture signal. Policy can see the user, SAML attributes, and SCIM groups. It cannot see disk encryption or EDR, because nothing on the laptop is reporting. Say this out loud The Service Edge is the reverse proxy. The connector still dials out. Identity is the whole control plane. Posture is gone by design. Session feel · four beats Click URL → IdP login → policy allow → one app. If any beat is wrong, stop there. Do not rebuild the whole segment. ### Words you will see in the portal Term Meaning in this lesson Application segment The object that names the app, port, and Browser Access checkbox. For Browser Access you may enter FQDNs only — no IP ranges. SNI The hostname the browser puts in TLS. The Service Edge uses it to pick the published application. User Portal Optional landing page. After IdP login the user sees only the apps their policy entitles. Privileged Remote Access (PRA) Different product path: RDP, SSH, VNC in an HTML5 console — not a web app. Clientless Access diagnostics The log view for Browser Access transactions. Start here when one user fails. ## Nine hops from click to app A Browser Access failure is always a failure at one identifiable hop. Learn the order once; every ticket gets shorter. Flow 1 · request path Nine-step Browser Access request from unmanaged browser to internal app - UNMANAGED DEVICE ZSCALER CLOUD YOUR ESTATE — NO INBOUND PORT Any browser no ZCC · TLS 1.2+ Public DNS CNAME → Service Edge ZPA Service Edge — reverse proxy Terminates TLS with the Browser Access cert Matches SNI · rewrites host · holds connector mTLS Your IdP SAML + MFA SCIM groups Access policy user / SAML / group default = deny App Connector outbound 443 mTLS only resolves the internal FQDN Internal web app HTTP/HTTPS · TLS 1.2 required never internet-facing 1 2 3 4 5 6 7 8 — response returns the same brokered path. The app never sees the internet. 9 — session is re-evaluated against policy. No ZCC means no device signal at any step. Read left → right, then follow the dashed return. The only client change versus agent ZPA is the browser; the connector story is unchanged. Browser asks public DNS for the published hostname. - CNAME sends TLS to a ZPA Service Edge. Certificate must match that name. - Unauthenticated request is redirected to your IdP (SAML). - IdP returns assertion. ZPA evaluates access policy — user, SAML attribute, SCIM group. Default deny. - On allow, the Service Edge uses the connector tunnel that is already up. - App Connector resolves the internal FQDN and picks a server in the server group. - Connector opens HTTP/HTTPS to the app. Server must speak TLS 1.2. - Response returns the same path. No inbound port on your firewall changed. - Later requests are re-checked. There is still no posture object to evaluate. Two properties that fall out of the picture The app is still not on the internet — the public name resolves to Zscaler. And the broker still brokers. What you lost is not control. It is device signal. ## BA vs ZCC vs PRA — choose before you click Decision feel Path A is a managed endpoint with Client Connector. Path B is clientless. Do not start in the Admin Portal until this diamond is answered. Flow 2 · which access method Decision tree: Client Connector, PRA, or Browser Access Can you install an agent? managed endpoint you own - yes Client Connector any protocol · full posture no RDP, SSH or VNC? privileged console yes Privileged Remote Access HTML5 · approval · recording no HTTP/HTTPS by FQDN? web app the connector can name yes Browser Access clientless · identity policy only no Rethink the ask Sensitive data on an unmanaged device? Layer isolation or DLP — the browser is not a data boundary. Protocol first, device second, data last. Most bad designs start at the bottom of this tree. Client Connector Browser Access Privileged Remote Access Client needed Agent installed Any TLS 1.2 browser Any browser Protocols TCP and UDP, any app HTTP / HTTPS only RDP, SSH, VNC Device posture Yes No No Segment definition FQDN, wildcard, IP, ranges FQDN only Defined per privileged app Certificate needed No public app cert Yes — published host or wildcard Yes — portal certificate Typical user Employee Contractor, partner, BYOD Admin, third-party DBA Session recording No No Yes Source: About Browser Access , Configuring Defined Application Segments (FQDN-only + TLS 1.2), Understanding Privileged Remote Access . ## Same domain or split domain This single decision causes more Browser Access rework than everything else combined. The external hostname the user types does not have to equal the internal hostname the connector dials — Zscaler documents that split explicitly — but making them differ has consequences inside the application . Infographic · two domain models Same-domain versus split-domain Browser Access publishing A · Same FQDN in and out user types app.corp.example connector dials app.corp.example Links, cookies and redirects keep working. One bookmark works for agent and browser users. You must own the public zone for that name. Internal clients must not resolve the public CNAME. Use split DNS: public → ZPA, internal → real server. B · Different external / internal user types hr.access.example connector dials hrportal.intranet.local Publish .local names safely. Hide internal naming. One wildcard zone for every published app. Absolute internal URLs break the page. Login and logout redirects hide this first. Service Edge rewrites the Host header. Same-domain is invisible to the application. Split-domain is invisible to the attacker. Choose based on how well-behaved the app’s URLs are. Official: different external vs internal domains . Practical test before you commit to model B: browse the app internally, open developer tools, and look at what it emits. If every asset and form action is a relative path, split-domain will be clean. If login bounces through an absolute https://hrportal.intranet.local/… URL, the user’s browser will chase a name it cannot resolve. ## Runbook — Side A identity, Side B ZPA, Side C proof Work a first contractor app in this order. Do not start with the certificate if the IdP group does not exist yet — you will publish an empty door. ### Side A — IdP and entitlement #### Create a time-bound group Guest user or dedicated partner realm. Put them in one group such as ext-audit-ticketing . Set an expiry in the identity system, not a calendar reminder. Source: your IdP lifecycle process + ZPA access policy uses SAML/SCIM groups. - #### Enforce MFA and a short session With no device posture, identity is the entire control plane. Conditional access at the IdP is the compensating control Browser Access cannot provide. - #### Confirm SCIM (or SAML attributes) actually arrive in ZPA A missing group looks identical to an explicit deny. Check the user object in ZPA before you blame the segment. ### Side B — ZPA objects Primary source for this block: Configuring Defined Application Segments and the June 2025 managed-certificate notes. admin.private.zscaler.com · Application Segments · Add Training mock · not live Resource Management → Application Management → Application Segments → Add ### Add Application Segment Name ext-ticketing-ba Domain / FQDN ticket.access.example TCP port 443 IP addresses / ranges Unavailable — Browser Access accepts FQDNs only Browser Access Certificate type Managed Internal domain (if different) jira.intranet.example Cancel Save Click next: attach the server group whose connectors can resolve jira.intranet.example . Field names follow Zscaler Help — Adding Application Segment / Browser Access / Managed certificate type. Example values only. - #### Application segment + Browser Access FQDN, port, Browser Access enabled. Enabling Browser Access still keeps Client Connector access on that segment — employees with ZCC can keep using the same app. You cannot paste an IP range here. - #### Certificate + public DNS Managed: ZPA generates, signs, and renews the cert and can publish the CNAME for you. Customer-managed: upload cert + private key + full chain, then publish the CNAME yourself. Prefer managed for anything contractor-facing — expired certs are the classic self-inflicted outage. You can also hide the application name behind a hash so partners never see your authentication domain. Source: Zscaler managed certificates and unified portal . - #### Server group + connector group Connectors must resolve the internal FQDN and have a route to it. Production habit: at least two connectors per group, close to the app. Green on the connector means it reached Zscaler, not the app. - #### Access policy — identity only One rule, one app, one contractor group. Do not share the employee posture rule. If the portal will not save a device-posture criterion, that is expected — there is no agent to report it. admin.private.zscaler.com · Access Policy · Add Rule Training mock · not live Policy → Access Policy → Add Rule ### Allow · ext-audit-ticketing Applications ext-ticketing-ba SAML / SCIM groups ext-audit-ticketing Client type Web Browser Device posture Not available on clientless / Web Browser sessions Action Allow Cancel Save Click next: place this rule above any broader deny. Then prove it from an off-network browser. Default policy is deny — a missing group looks like a block. ### Side C — prove it before you mail the URL - #### Resolve from off-network From a phone hotspot, confirm the published name is a CNAME to the Zscaler target — not to your own edge. Do not test this only from the corporate LAN (split-DNS will lie to you). - #### Certificate matches the published host Browser padlock, no name mismatch, full chain. If you used managed certificates, renewal is Zscaler’s problem. - #### SAML + allow in diagnostics Log in as the contractor. Open Clientless Access diagnostics, filter to that user, and read the request detail before you change configuration. Source: Browser Access / Clientless Access Diagnostics . - #### Page completeness If CSS, images, or the login redirect 404, you have a split-domain / absolute-URL problem — not a ZPA “down” problem. Confirm in developer tools first. Off-network checks (example names only) dig +short ticket.access.example CNAME curl -sI https://ticket.access.example | head # Expect: CNAME to the Zscaler-supplied target, then HTTP 302 toward your IdP. # Do not copy a CNAME target from a blog — take it from your tenant. ## Twelve production tickets These are the situations that actually arrive. The build is the easy half. The gotcha is why the ticket comes back. BA-01 Third-party contractor on an unmanaged laptop Situation Vendor needs ticketing for three months. You have no legal basis to install an agent. Build Browser Access + guest identities in one SCIM group + one allow rule for that segment. Gotcha Entitlement outlives the engagement. Expire the group in the IdP. BA-02 Employee on a personal phone or tablet Situation Leave portal and payslips from personal devices. MDM on personal phones is a fight. Build Browser Access for those two low-sensitivity apps only, MFA at the IdP. Everything else stays agent-only. Gotcha Data leaves the app onto an unmanaged device the moment it renders. Pair with isolation or DLP, or do not publish that app clientlessly. BA-03 Straight-through publish — same FQDN Situation Internal web app already answers on a name you own publicly. Build One segment, Browser Access, cert matching that name, public CNAME to ZPA, internal DNS still to the real server. Gotcha If an internal client resolves the public CNAME, traffic hairpins out to Zscaler and someone calls it a latency problem. BA-04 Publishing a .local or non-routable name Situation App answers on appsrv01.intranet.local . Build Split-domain: external app.access.example , internal the .local name. Connector resolves internally. Gotcha Test login and logout redirects specifically. That is where absolute internal URLs hide. BA-05 Twenty apps, one certificate Situation A pattern for publishing internal tools to partners. Build Reserve *.access.example , one wildcard Browser Access cert, one segment per app, one rule per app. Gotcha A wildcard cert is a shared blast radius. Keep it off anything you would not want reachable if that key were mishandled. BA-06 Same app for agent users and browser users Situation Employees run Client Connector; contractors do not; both need the finance dashboard. Build Enable Browser Access on the existing segment. Write two access rules — the employee rule can carry posture, the contractor rule cannot. Gotcha One rule for both audiences means the weakest audience sets the security level. BA-07 A partner front door instead of a list of URLs Situation Forty people, four apps. Emailing four links is not onboarding. Build User Portal with its own (preferably managed) certificate. After IdP login, each user sees only entitled apps. You can merge Browser Access and PRA into one portal. Gotcha The portal is also a disclosure surface. Keep names boring, or use the name-hashing option. BA-08 Day one of an acquisition Situation Acquired staff need three of your apps on Monday. Their endpoints and network are not yours. Build Federate their IdP, publish three Browser Access apps, entitle by their group. No site-to-site project. Gotcha This is a bridge. Put an end date on it the day you build it. BA-09 Shared kiosks and shop-floor terminals Situation Frontline staff share machines; installing an agent per profile is impractical. Build Browser Access with short authentication timeouts and MFA. Gotcha Cached credentials and a walk-away are the threat. Timeout is the control that matters. BA-10 Admin asks for RDP or SSH in the browser Situation Third-party DBA needs a jump host without a VPN. Build Not Browser Access. That is Privileged Remote Access — HTML5 RDP/SSH/VNC with approvals and session recording. Gotcha Both are “clientless in a browser.” Different licences, different portals, different policy model. BA-11 A thick client, file share, or database tool Situation Someone asks whether SAP GUI, SMB, or a SQL client can go through Browser Access. Build No. Browser Access carries HTTP and HTTPS. Anything else needs Client Connector, or PRA if the protocol is RDP/SSH/VNC. Gotcha A web front end for a thick-client app is still a web app and is fine. The test is the protocol on the wire. BA-12 “Add a posture check to the contractor rule” Situation Audit wants disk encryption and EDR before the contractor reaches the app. Build You cannot on Browser Access. Compensate at identity and data: MFA, time-bound entitlement, short timeouts, isolation or DLP. Gotcha The most common design mistake: “harden” a clientless rule with a device condition and lock every legitimate user out — or assume the platform is broken when it will not save. ## Fault map, traps, and proof Ops · prove it Pull the clientless transaction before you rebuild the segment. Browser Access issues are almost never where the user says they are. Browser Access fails quietly. You rarely get a useful error — you get a spinner, a certificate warning, or a redirect loop. Work the chain in order: DNS, certificate, identity, policy, connector, app. Flow 3 · six-hop fault map Six hops where Browser Access breaks 1 · DNS name missing or points at you check the CNAME from off-net 2 · Cert warning, SAN, missing chain SAN = published host, full chain 3 · Identity redirect loop or re-prompt IdP domain vs app segment 4 · Policy auth then deny some users only SCIM group and rule order 5 · Connector green, still unreachable resolve, port, NTP, outbound 6 · The app half page, broken assets absolute URLs or no TLS 1.2 Work left to right. The first broken hop is the answer. Filter Clientless Access diagnostics to that user before you change a single object. Symptom Likely cause Fix Certificate warning on first visit SAN does not match the published host, or intermediate chain missing Reissue with the exact name and upload the full chain — or move to a managed certificate Public hostname does not resolve CNAME never published, or published in the wrong zone Verify from an off-network device, not from the corporate LAN Endless login loop IdP domain overlaps an application segment or discovery Bypass the IdP domain in ZPA; confirm SAML ACS is not hairpinned Some users in, some out, same URL Group not synced, or rule ordered below a broader deny Check SCIM and rule order. Default deny looks like a block. Connector connected, app unreachable Green means the connector reached Zscaler From the connector: resolve the internal FQDN, test the port, confirm NTP TLS handshake fails to the backend Application server does not support TLS 1.2 Upgrade the app TLS stack or front it with something that does Page loads, assets and redirects 404 App emits absolute internal URLs under a different external name Same-domain model, or fix the app’s base URL Cannot save a posture condition Clientless sessions have no device signal Not a bug. Keep the ZPA rule identity-based; use IdP conditional access Cannot add an IP or range Browser Access segments accept FQDNs only Give the app a name the connector can resolve ### Hardening before you call it done - MFA at the IdP, always. Unmanaged device + single-factor is a published web app with extra steps. - Time-bound entitlement in the identity system. - One app per rule for third parties. Resist the wildcard segment. - Short authentication timeouts on shared or personal devices. - Hide internal naming with split-domain or the application-name hash. - Managed certificates wherever your CA policy allows. - Layer data controls (isolation / DLP) or simply do not publish regulated apps clientlessly. - Review clientless logs monthly. The mistake to remember Browser Access trades device trust for reach. That trade is fine — if you rebuild the lost assurance at identity and data, instead of assuming ZPA still has your back at the endpoint. Pilot checklist — green means ship the URL - Off-network CNAME to the Zscaler-supplied target (value taken from your tenant). - Browser trusts the certificate; SAN equals the published host. - Contractor user authenticates at the IdP with MFA. - Clientless Access diagnostics show the matching allow rule — not default deny. - A second user in a different group is denied. - Page assets and login/logout redirects complete (no internal FQDN in the browser bar after login). - Connector group has two healthy members; internal FQDN resolves on the connector. - Group expiry exists in the IdP. Review date is on the calendar. ### Interview lines you should be able to say Why no posture on a Browser Access rule? Posture is reported by Client Connector. Browser Access is clientless, so the criterion is unavailable by design. Why no IP range on the segment? The Service Edge selects the published application by hostname during TLS. FQDN only. Does this expose the app to the internet? No. The public name resolves to Zscaler. The connector still dials outbound only. No inbound port opens on your perimeter. ## Knowledge check Six judgment questions. Pick one answer each, then Check. Reasons point you back to the section to re-read. Q1 Audit wants disk encryption on the contractor Browser Access rule. What do you do first? Add a posture profile to the same access rule Keep the ZPA rule identity-based and move device assurance to IdP conditional access (plus short timeout / isolation) Install Client Connector silently on the vendor laptop Open an inbound 443 VIP so you can inspect the device at the edge Correct: b . Posture is reported by Client Connector. Browser Access has no agent, so the criterion is unavailable by design. Re-read Mental model and BA-12. Q2 A Browser Access application segment will not accept an IP range. Why? The Service Edge selects the published application by hostname during TLS, so the object is FQDN-only ZPA never supports IP addresses on any segment You must enter the connector’s public IP instead IP ranges are only allowed after you enable posture Correct: a . Official help: when defining applications for Browser Access you can only configure FQDNs. Agent-based segments can still use IPs. Re-read Words you will see and Side B. Q3 A contractor needs RDP to a jump host with no VPN. Is that Browser Access? Yes — enable Browser Access on the jump-host segment Yes, if you publish the RDP port as HTTPS No — that is Privileged Remote Access (HTML5 RDP/SSH/VNC with approvals and recording) No — only Client Connector can ever do remote desktop Correct: c . Browser Access is HTTP/HTTPS web apps. PRA is the privileged-console path. Re-read BA vs ZCC vs PRA and BA-10. Q4 Users authenticate successfully but the page returns broken CSS and the login redirect hangs. First suspicion? The App Connector is down — rebuild the provisioning key External and internal FQDNs differ and the application emits absolute internal URLs SCIM has not synced — wait 24 hours You forgot to open inbound 443 on the datacenter firewall Correct: b . Auth succeeded, so DNS, cert, IdP, and policy already worked. Broken assets after a split-domain publish is hop 6 — the app. Confirm in developer tools. Re-read Domain models and the fault map. Q5 Which requirement does the application server itself have to meet for Browser Access? It must have a public VIP It must be in a DMZ with an inbound NAT It must support UDP 500/4500 It must support TLS 1.2 Correct: d . Zscaler Help: Browser Access requires the application server to support TLS 1.2. The browser also needs TLS 1.2 (cipher suite ECDHE-RSA-AES128-GCM-SHA256). Re-read the flow and Side B. Q6 One contractor reports failure. Everyone else works. Where do you look first? Clientless Access diagnostics — filter to that user and read the request detail before changing config Rebuild every Browser Access certificate in the tenant Disable default deny globally so you can test Ask them to install Client Connector, then troubleshoot as a ZCC case Correct: a . A single-user fail is usually group membership, rule order, or their IdP session — all visible in the clientless transaction. Re-read Side C and the fault map. Check answers Reset ## Sources - Zscaler Help — About Browser Access (clientless browser, TLS 1.2, ZCC still applied on the same segment). - Zscaler Help — Configuring Defined Application Segments (FQDN-only for Browser Access; app server TLS 1.2; Managed certificate type in Add Application Segment). - Zscaler Help — Different external vs internal domains . - Zscaler Help — Browser Access Deployment and Operations Guide . - Zscaler Help — Understanding Privileged Remote Access and About User Portals . - Zscaler product blog (13 Jun 2025) — Managed certificates, automatic CNAME, name hashing, unified portal . - Local evidence PDFs: Zscaler-ZPA-App-Connector-Deployment-and-On-Premises-Configuration.pdf ; zscaler-zia-zpa-architecture-and-troubleshooting-student-guide.pdf (connector outbound mTLS, two-per-group, APP_NOT_REACHABLE). Related: Browser Access setup (certs & CNAME) · Browser Access vs PRA · ZPA architecture · ZPA access policy · Application segments · ZTNA clientless vs agent Product behaviour follows Zscaler documentation current at the time of writing. Verify field names in your tenant before you implement — portal labels move. Do not copy CNAME targets from this page; take them from your Admin Portal. --- 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