ZTNA (Zero Trust Network Access)

ZTNA is a security model that gives users access to specific private applications without putting them on the full corporate network.
Example: Company employee want to access Jira only(no other application), then providing access to this application only is ZTNA.
Core idea: “Never trust, always verify.” A user on a home laptop or at an airport gets the same scrutiny as someone in a branch office.

Example

A bank employee working from home needs the internal loan-processing app (hosted in a private datacenter).
Without ZTNA: Employee connects VPN → lands on corporate LAN → can reach many servers if ACLs are loose.
With ZTNA: Employee opens the ZTNA client, signs in with Okta MFA, passes device compliance check → broker opens access only to loan-app.internal.bank → traffic flows through an app connector; no VPN, no broad network access.
Vendor Examples
Zscaler Private Access (ZPA), Netskope Private Access, Cloudflare Access, Microsoft Entra Private Access

How ZTNA works (vs traditional VPN)

Traditional VPN ZTNA
User joins the entire corporate network (Layer 3 tunnel)
Once connected any service
User connects only to a broker (cloud or on-prem)
Broker opens a narrow path to one approved app
flowchart LR
  subgraph user_side [User]
    U[Remote user]
  end
  subgraph cloud [ZTNA broker cloud POP]
    PE[Policy engine]
    AC[App connector]
  end
  IDP[Identity Provider]
  APP[Private app on-prem / VPC]

  U -->|1 SSO / MFA| PE
  PE -->|2 verify| IDP
  PE -->|3 posture check| PE
  U -->|4 request app| PE
  PE --> AC
  AC -->|5 micro-tunnel| APP
  APP --> AC --> PE --> U
        

ZTNA vs SWG (Secure Web Gateway)

SWG ZTNA
Traffic direction Outbound — user going out to the internet and SaaS (Google, Salesforce, malicious sites) Inbound-style access — user reaching private internal apps that are not on the public internet
Primary goal Secure web browsing: block malware, filter URLs, inspect SSL, stop data leaks on cloud apps
See SWG
Replace VPN: grant least-privilege access to specific internal applications only
What user accesses Public internet & sanctioned SaaS Private apps (ERP, internal Git, RDP to a server, datacenter app)
Typical controls URL categories, SSL inspection, antivirus, DLP on uploads, CASB for SaaS App catalog, per-app policy, device compliance, MFA, micro-segmentation
Client path PAC file / forward proxy — all web traffic steered to SWG
Example: HTTP Authentication via forward proxy
ZTNA client agent or browser-based portal; broker mediates to app connector inside the datacenter/VPC

ZTNA vs Zero Trust Forward Proxy (ZTFP)

A Zero Trust Forward Proxy applies zero-trust principles to outbound HTTP/HTTPS traffic — the same path as an SWG or enterprise forward proxy. It authenticates the user, enforces identity-aware policy, may do SSL inspection, DLP, and audit logging before traffic leaves to the internet.

Terms and components included in ZTNA

Term Role in ZTNA
Identity Provider (IdP) Source of truth for users and groups (Okta, Azure AD, Google Workspace). ZTNA trusts IdP assertions for SSO and MFA.
Device posture / trust Checks OS patch level, disk encryption, managed vs BYOD, jailbreak status before allowing app access.
Policy engine Evaluates rules: user + group + device + location + app → allow / deny / step-up MFA.
ZTNA broker / gateway Cloud or on-prem service that terminates user sessions and enforces policy (Netskope, Zscaler Private Access, Cloudflare Access, etc.).
App connector / cloud connector Lightweight agent inside the datacenter or VPC that creates outbound-only tunnels to the broker — private apps stay off the public internet.
Application catalog Admin-defined list of apps (hostname, port, protocol) users may request through ZTNA.
Agent vs agentless Agent: client on laptop/phone (full posture checks).
Agentless: browser portal / reverse proxy — good for contractors or unmanaged devices with tighter limits.
SDP (Software Defined Perimeter) Earlier name for the same idea: hide infrastructure, authenticate before revealing apps. ZTNA is the market term Gartner uses in SSE.
Least-privilege access User gets only the apps needed for their role — not entire VLANs or RDP to every server.
Micro-segmentation Network segmentation at application or workload level instead of coarse firewall zones.
Context-aware access Decisions use IP geolocation, time of day, anomaly score, and threat intel — not just username/password.
Continuous authorization Session can be re-evaluated or revoked if device becomes non-compliant or risk score changes.
MFA / step-up auth Extra verification for sensitive apps (finance ERP, production admin consoles).
Audit & session logging Who accessed which app, when, from which device — for compliance and incident response.
Related SSE pieces Often bundled with SWG, DLP, CASB, and FaaS in one platform — but each solves a distinct problem.