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. |