Last updated: May 1, 2026
Traditional VPN gave users full network reach; the implicit assumption was that the corporate network is a “trust zone”. That assumption was wrong by 2010 and indefensible by 2020. ZTNA inverts the model: identity-aware proxy in front of every application, explicit authorisation per-request, no broad network access ever granted. This module is the working introduction to ZTNA, comparison with VPN, and the migration path — relevant in 2026 to almost every Indian enterprise rolling out hybrid work.
The two trust models — and why VPN's broke
VPN modelauthenticate once, get network access, applications enforce their own auth. The implicit trust: “if you are on the corporate network, you are an employee with reasonable intentions”. Worked acceptably when “the network” was a single office building with controlled physical access. Broke when remote work, contractors, BYOD, and supply-chain compromise meant any device on the VPN might be a hostile beachhead. Lateral movement became trivial — once on the VPN, you could ping every internal host.
ZTNA modelno network-level access at all; instead, an identity-aware proxy fronts each application; every request is authorised based on user identity + device posture + request context; only authorised connections pass through.
Resulta compromised endpoint sees only the apps that user is allowed to use, and only when the device passes posture checks. Lateral movement is meaningfully harder.
ZTNA architecture — what the moving parts are
Identity Provider (Entra ID, Okta, Google Workspace, JumpCloud) — provides identity, MFA, group membership. ZTNA broker / connector — the cloud-hosted control plane (Cloudflare Access, Zscaler ZPA, Netskope NPA, Twingate gateway). App connector — a small agent in your private network that initiates outbound connections to the broker; no inbound ports needed. Client agent / browser — connects to the broker; for browser-based apps, just a TLS connection through the broker; for non-browser apps (SSH, RDP, databases), a client agent that proxies. Policy engine — evaluates per-request: who, from where, what device posture, what app, what time.
Why this is operationally elegantno inbound ports on your network (the connector dials out), no public-IP origin services, every application gets MFA + posture checks without app-level integration.
Posture and continuous verification — the differentiating capability
Traditional VPN posture checks happen at connection time — does the device have current AV, OS patches, disk encryption. ZTNA does this continuously: posture is re-evaluated for each request (or on schedule). If a device falls out of compliance during a session — disabled disk encryption, stopped AV — the next request is denied.
Posture signalsOS version + patch level, AV/EDR running and current, disk encryption enabled, MDM enrolment, certificate present, geographic location, time of day.
Risk-based accessanomalous behaviour (unusual hour, unusual location, unusual device) elevates the auth challenge — re-MFA, step-up, or block.
India contextcontinuous posture is increasingly expected by RBI / SEBI auditors; documented evidence of “device meets policy at every access” is a stronger control story than “device met policy at VPN login this morning”.
The major products — comparison and Indian availability
Cloudflare Access (Zero Trust)strongest at web apps, free tier for small teams, integrates with WARP client for SSH/RDP/non-HTTP.
Zscaler Private Access (ZPA)enterprise-default in BFSI/large corp; tight policy model, expensive, full-stack ZTNA + secure web gateway.
Netskope Private Accesssimilar to Zscaler, particularly strong at SaaS-context awareness.
Microsoft Entra Private Accessintegrates deeply with Microsoft 365 / Entra ID; logical default for Microsoft-stack shops.
Tailscale / Twingate / NetBirdWireGuard-based, more “modern engineer” feel, strong at developer use cases; smaller enterprise-policy footprint.
Indian PoPsCloudflare, Zscaler, Microsoft all have Indian DC presence — important for latency-sensitive BFSI and DPDP data-residency questions. Migration sizing: 100-500 users per quarter is a realistic pace for a structured rollout.
Migration from VPN — the staged path
Service-to-service ZTNA — beyond user access
ZTNA principles also apply machine-to-machine. Service mesh (Istio, Linkerd, Consul) gives east-west mTLS, identity-based authorisation, and policy enforcement between microservices. SPIFFE / SPIRE standardises service identity.
Cloud-nativeAWS IAM Roles for Service Accounts (IRSA) on EKS, Workload Identity Federation on GCP, Azure Managed Identity — each is a flavour of “service identity without long-lived secrets”.
The unifying principleevery actor (human or machine) has cryptographically verifiable identity, every request is authorised based on that identity plus context, no network-level trust. The same Zero Trust frame applied consistently from CEO laptop to backend microservice is the modern Indian enterprise architecture target.
Operational realities — what nobody mentions in marketing decks
ZTNA for non-web apps — the hard cases
Web apps are easy under ZTNA: terminate at the broker, identity-aware policy, done. Hard cases: Database admin tools (DBeaver, MySQL Workbench, SSMS) — speak their own protocols; need a client agent that tunnels them via the broker. SSH — clientless via browser-based terminals, or native tunnelled by client agent. RDP — typically clientless via HTML5 console (RDPweb-style), or native through agent. SMB / CIFS — usually requires client agent + DNS handling. Java RMI / .NET Remoting — legacy enterprise apps; often need a refactor or a thicker proxy.
The architectural fixmost legacy apps benefit from being put behind a modern web frontend (e.g., bastion-host SSH gateway with web SSO, web-based DB admin like phpMyAdmin or pgAdmin web). The journey from ZTNA-easy to ZTNA-everything is partly a modernisation journey for the app portfolio.
ZTNA + Conditional Access — the Microsoft pattern
For Microsoft-heavy environments, the practical ZTNA stack pairs Entra Conditional Access (identity + posture + risk) with Entra Private Access (the connector to private apps) and Defender for Cloud Apps (SaaS posture). Each access request to any app — internal or SaaS — is evaluated by Conditional Access: user, device, location, risk score, app sensitivity. Rules can require MFA, compliant device, specific country, off-hours block.
What this gives youa single policy plane for both private apps (via Entra Private Access) and SaaS (via Defender for Cloud Apps), driven by the same identity.
What it costsEntra ID P2 + Defender bundle is meaningful per-user spend; this is enterprise-scale tooling.
For Indian BFSI on Microsoft 365 E5Conditional Access is already licensed; the Private Access piece is typically the marginal cost. Most Indian banks running Microsoft are on this trajectory in 2026.
Cost modelling — the realistic ZTNA total-cost-of-ownership
ZTNA pricing models vary; here are realistic numbers for an Indian mid-market enterprise (1,000-3,000 users) in 2026: Cloudflare Zero Trust — ~$3-7 per user per month at this scale; ~₹3,000-7,000 per user per year. Tailscale Business — $6-18 per user/month depending on tier. Zscaler Private Access — $6-15 per user/month bundled with broader Zscaler suite. Microsoft Entra Private Access — bundled with E5 / specific Entra tiers.
VPN replacement savingstypical enterprise VPN concentrator + maintenance + remote-access licensing runs ₹500-1,500 per user per year — partial offset.
Other costsapp modernisation for stubborn legacy apps; user enablement; service-desk capacity to handle migration tickets.
The ROI argumentZTNA reduces incidents (lateral movement contained), reduces audit lift (per-user/per-app logs), and shifts the access model to one regulators want to see. The harder argument: which apps stay on VPN forever, and how to retire them gradually.
Phasing third-party access into ZTNA — the contractor problem
Most enterprises have hundreds of contractors, partners, and vendors with VPN access. Migrating them to ZTNA hits friction: contractors do not have managed devices, partners do not want to install your agent, and vendors want one set of credentials that works for many customers. Three working patterns:
Diagrams
Remote user ──VPN tunnel──▶ VPN concentrator ──▶ corporate LAN
│
├─ DC: file server
├─ DC: DB server
├─ DC: AD controller
└─ DC: every internal IP
Once on the LAN: lateral movement is at LAN distance.
Posture checked once at connection time.
Compromised device = compromised LAN reachability.
Remote user ── client agent / browser ──▶ ZTNA broker (cloud)
│
│ identity check (IdP)
│ posture check (continuous)
│ policy check (per-request)
▼
App connector (in private net)
│
▼
Specific application only
No network access ever granted. Compromised device = limited
to the specific apps the policy authorises, with continuous re-check.
References & deeper reading
- NIST SP 800-207 — Zero Trust Architecture
- Cloudflare Zero Trust
- Zscaler ZPA
- Tailscale documentation
- Microsoft Entra Private Access
- SPIFFE / SPIRE workload identity
- BeyondCorp (Google's ZTNA paper)
FAQ
Is ZTNA a product or an architecture?
An architecture; products implement it. NIST SP 800-207 defines the principles; Cloudflare, Zscaler, etc. are implementations. Avoid vendor lock-in by understanding the principles first; products fit into a coherent design.
Can ZTNA handle SSH and RDP?
Yes — every major ZTNA product offers either browser-based (clientless) SSH/RDP via HTML5 console or native-client tunnelling. Browser-based gives strongest audit (recordable sessions), native-client gives best UX. Choose by use case.
How does ZTNA work for unmanaged contractor devices?
Two patterns:
Is VPN going away entirely?
No. Site-to-site VPN (M6) remains the standard for cloud-to-cloud and branch-to-HQ networking. What is going away is VPN for end-user remote access — that is what ZTNA replaces.
How does ZTNA help with DPDP compliance?
Three ways:
Can I run multiple ZTNA products simultaneously?
Yes — many enterprises run Cloudflare Access for web, Tailscale for engineering remote access, and a mainstream ZTNA for the broad employee user base. Operationally tractable as long as the identity provider is unified. Avoid running multiple ZTNA agents on the same endpoint where avoidable.
What about contractors who use their own laptops?
Three options:
⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.