PRODUCT INTELLIGENCE SSE / ZTNA

Zscaler
Combined public and private application access

Zscaler Internet & SaaS and Private Access

Internet policy and private application access require two carefully designed control paths

Zscaler separates Internet & SaaS traffic protection, commonly known as ZIA, from Private Access, or ZPA. Client Connector can steer both while private applications are reached through configured App Connectors and access policy.

01 / EDITORIAL JUDGMENT

The Atlas take.

Zscaler is a serious evaluation candidate for organizations replacing network-centric remote access and central internet inspection. The combined profile should still be understood as ZIA for internet/SaaS traffic and ZPA for private applications, with Client Connector and application-side connectivity designed explicitly. Atlas sees the application boundary as the decisive benefit to test: a user should reach the approved service without gaining unnecessary adjacent reachability. The project succeeds through application inventory, identity and forwarding accuracy. A broad platform purchase cannot compensate for incomplete routing or an overly permissive application definition.

Our interpretation of the cited evidence. Independent hands-on effectiveness remains unassessed.

02 / DEFINE THE BOUNDARY

What you are actually evaluating.

The scored configuration selects ZIA web policy plus ZPA private application access and Client Connector. ZDX, advanced data protection, browser isolation and privileged access add-ons are excluded unless specifically purchased and assessed.

Names you may encounter ZIA · ZPA · Zero Trust Exchange. Historical names do not establish current feature equivalence.

03 / THE CONTROL PATH

Where it sits. How it works.

Atlas architecture interpretation: steer managed-user traffic toward the appropriate ZIA or ZPA service; private access additionally depends on application-side connectors and an explicit user-to-application policy.

Conceptual architecture Atlas interpretation · verify the proposed configuration
  1. 01

    User identity and Client Connector

    Authenticate the user and steer the intended internet or private application traffic.

  2. 02

    ZIA or ZPA policy decision

    Apply the chosen internet inspection or private application access policy.

  3. 03

    Internet destination or App Connector

    Reach a public service or a private application through its approved connector path.

04 / WHAT EARNS ITS PLACE

Strengths, with the evidence attached.

Atlas analysis of documented capabilities; availability and behavior depend on the edition and environment.

01

Distinct control purposes

The documented ZIA and ZPA offerings make internet inspection and private application access separable design and evaluation decisions.

02

Outbound application connectors

ZPA documentation describes connectors initiating outbound connections, supporting application access without opening inbound connector ports.

Inspect the documented capability notes
  • ZPA defines applications, user attributes, identity-provider integration and access policies.
  • App Connectors provide the private application path; log streaming supports external investigation.
  • Documented ZIA/ZPA integration includes explicit requirements for particular inspection and source-IP use cases.

05 / KNOW THE COMPROMISES

The tradeoffs to take seriously.

Architectural implications and procurement questions from Atlas; these are not independently measured product failures.

Application reachability is engineered

Connector placement and access to application dependencies remain deployment responsibilities; a healthy client alone does not prove service access.

Breadth needs an entitlement map

Browser, experience monitoring, advanced data and privileged-access functions need explicit selection instead of inheriting credit from platform branding.

06 / FROM PURCHASE TO PRACTICE

Make it work in your environment.

A proposed implementation sequence. Confirm supported versions, permissions, and rollback with the current documentation.

  1. 01

    Inventory a representative application

    Map DNS, ports, helper services and user groups before migrating a complex business workflow.

  2. 02

    Pilot forwarding and certificates

    Check endpoint traffic paths, trust configuration and exceptions on representative operating systems and networks.

  3. 03

    Rehearse connector failure

    Demonstrate redundancy, useful diagnostics and an owned recovery process without opening broad fallback access.

07 / THE OPERATING COMMITMENT

The bill is only part of the cost.

Commercial shape

Compare a written ZIA, ZPA and Client Connector configuration with any optional services. Include application discovery, connector infrastructure and migration operations in the commercial model.

  • User populations and selected ZIA/ZPA editions
  • Connector infrastructure and regional architecture
  • Application migration, endpoint rollout and diagnostics
AFTER GO-LIVE

What your team owns

Network, endpoint and identity teams share responsibility for forwarding, client updates, application definitions and connector availability. Troubleshooting must distinguish authentication, policy and application reachability. When a new application arrives, its DNS, dependencies and access owner need to enter the same operating process rather than an expanding catch-all exception.

Confirm the full order form: modules, usage meters, support, retention, and exit costs. A public price is not your complete operating estimate.

08 / COMPARE THE JOB

Put these beside it.

Alternatives worth examining for the same problem. Check each offering’s scope before treating it as a substitute.

Open a comparison workspace ↗

09 / MAKE THE DECISION OBSERVABLE

Earn confidence through a real evaluation.

Suggested by Atlas. Agree acceptance criteria, use synthetic fixtures in an authorized environment, and capture both useful work and failed controls.

  1. TEST 01

    Allow one private application and deny an adjacent service

    Acceptance evidence: Keep identity, policy and destination-side evidence.

  2. TEST 02

    Fail a test App Connector

    Acceptance evidence: Record remaining reachability and diagnostic ownership.

  3. TEST 03

    Trace an internet policy decision

    Acceptance evidence: Correlate client route, inspection outcome and the user-visible result.

START WITH ONE EXERCISE

A test contractor may reach one private web application while ordinary browsing uses the web security service.

Evidence to look for: Prove the two traffic paths and show that a neighboring application remains unavailable; then remove the user’s entitlement and measure the effect.

Questions to bring to the vendor
  1. Which ZIA and ZPA subscriptions are actually selected?
  2. Which session controls require client or application changes?
  3. How are connector health, inspection exceptions and exported logs operated?
Take the evaluation brief with you ↓

10 / SHOW THE WORK

Evidence, and what is still unknown.

What this research cannot establish

  • Atlas has not independently measured latency, resilience or prevention efficacy.
  • Some help pages require JavaScript; confirm full release-specific prerequisites in the deployment review.

Dossier research reviewed October 18, 2026. Earlier profile references are retained for traceability; products and commercial terms change.

  1. ZPA configuration workflow ↗Earlier profile reference
  2. Private Access architecture ↗Earlier profile reference
  3. ZIA to ZPA forwarding policy ↗Earlier profile reference
  4. Private Access policy API ↗Earlier profile reference
  5. Zscaler Internet and SaaS Access ↗Product information
  6. Zscaler Private Access ↗Product information
  7. ZPA App Connectors ↗Documentation
  8. ZPA private-access architecture ↗Documentation

KEEP BUILDING YOUR JUDGMENT

Understand the system around the tool.

Read the SSE / ZTNA field guide ↗

Find your next idea.

Tip: press / to open search. Escape closes this window.