Why “trust but verify” was always the wrong model for network access — and what actually replacing it requires from your network and identity stack.

netdaemons.com · Network Engineering Deep Dives · Article #19 · 14 August 2026

A flat VPN concentrator with a single group policy applied to every remote user is still the default remote-access design at a large share of the mid-market enterprises we review. It works — until one contractor’s laptop gets phished and the attacker inherits the same Layer 3 reachability as the network admin who authenticated five minutes earlier from the next desk. That is the failure mode zero trust network access (ZTNA) exists to close: not “hackers get in” — they eventually do, regardless of architecture — but “once they’re in, how far can they move before anyone notices.” Get the architecture wrong and you have usually just renamed your VPN; the perimeter did not move, it got new marketing language.

Get it right and the payoff is not only security — it is an access model that scales cleanly across acquisitions, contractors, BYOD, and multi-cloud without a network team provisioning a new subnet and firewall rule for every new SaaS app or partner integration. That is the part CIOs actually budget for. This article covers the mechanics: what ZTNA changes at the session level, where deployments break, and what a working design looks like for a mid-size enterprise running a mix of on-prem data centre, cloud workloads, and a distributed workforce across India, Southeast Asia, or the Middle East.

Disclaimer: General: This article reflects the NetDaemons team’s research and understanding of zero trust network access architecture at time of writing (August 2026). Zero trust and SASE terminology and vendor positioning continue to evolve — verify current definitions and platform capabilities directly with NIST (nist.gov) and the relevant vendors before making architecture or purchasing decisions. Vendor and platform references: Vendor and platform names mentioned (Zscaler, Palo Alto, Cloudflare, Cisco, Fortinet, Netskope, and others) are illustrative of how the architecture is implemented in practice and do not constitute an endorsement, ranking, or comparison. Capabilities and packaging change frequently — verify directly with each vendor. Certification content: Certification blueprint descriptions (CCIE Security, JNCIE-Security, CISSP) reflect the authors’ understanding at time of writing. Exam blueprints, objectives, and exam codes change without notice — verify current details directly with Cisco, Juniper/HPE, and (ISC)² before planning study time. Verdicts: All recommendations and design positions reflect the independent technical assessment of the NetDaemons team. This article does not currently contain affiliate links.

The Concept Explained

Zero trust is a security model, not a product category, and NIST Special Publication 800-207 (published August 2020) is still the reference architecture worth anchoring to — most vendor material on “Zero Trust 2.0” or “true ZTNA” is repackaging its three logical components under different names. Those components:

• Policy Engine (PE) — evaluates the access request and outputs a trust decision. NIST frames this as a trust algorithm consuming multiple signals: subject identity, device posture, threat intelligence, resource sensitivity, and behavioural context — not a single static yes/no rule.
• Policy Administrator (PA) — takes the PE’s decision and instructs the enforcement layer: issue a session token, update a gateway permission, tear down a session.
• Policy Enforcement Point (PEP) — sits in the data path and actually allows or blocks the session based on what the PA tells it.

NIST groups the PE and PA into a single logical Policy Decision Point (PDP). Every ZTNA product on the market — Zscaler Private Access, Palo Alto Prisma Access, Cloudflare Access, Netskope Private Access, Cisco Secure Access, Fortinet’s ZTNA — maps onto this same PE/PA/PEP structure, even when the vendor’s own architecture diagram uses different labels. Recognise the shape and you can evaluate any vendor’s design on its merits instead of on the diagram.

The property that actually distinguishes ZTNA from a VPN is not encryption — IPsec and TLS VPNs are already encrypted. It is default-deny plus per-session, per-application authorisation, instead of network-level reachability. A VPN puts a user on the network; ZTNA puts a user in front of one specific application, and only after the PE has evaluated that specific request. There is normally no routable path from the client to anything else on that segment — the endpoint typically never receives a real IP address on the destination subnet. That last point is where most confusion starts: with most ZTNA architectures, the endpoint never resolves a genuine internal DNS name or gets a genuine internal route. Traffic is proxied or brokered through the vendor’s edge, not routed end to end the way VPN traffic is.

How It Actually Works

Take the Device Agent / Gateway deployment model — the one most enterprise ZTNA products use for laptops and servers. NIST 800-207 documents this alongside Enclave Gateway, Resource Portal, and Application Sandboxing variations, but Device Agent/Gateway is what covers the majority of a typical enterprise user population. Walk through a request end to end:

• The endpoint agent (Zscaler Client Connector, GlobalProtect, Cloudflare WARP, or equivalent) establishes an outbound-only mutual TLS (mTLS) tunnel to the nearest cloud broker. Outbound-only matters — there is no inbound listener for this service on the corporate firewall, which accounts for most of ZTNA’s attack-surface reduction on its own.
• The user requests an internal application by name — an internal Jira instance, for example. The agent intercepts this at the DNS or application layer rather than letting it resolve to a real internal IP address.
• The broker (PDP) evaluates the request: is the identity authenticated, usually via SAML or OpenID Connect (OIDC) against the corporate identity provider (IdP); does the device posture check pass (patch level, disk encryption, EDR agent present and healthy); does this identity’s role entitle it to this specific application; does context — time, geolocation, network reputation — look normal.
• If the PE approves, the PA instructs a connector — a lightweight software component installed near the application, inside the data centre or VPC, also with no inbound firewall rule required — to establish the far side of the tunnel.
• The two tunnel segments are stitched together at the broker. Traffic now flows client → broker → connector → application. The client has no routable path to the connector’s local subnet.
• This is not a one-time check. Session context is re-evaluated continuously or at short intervals — if EDR flags the device mid-session, or the user’s risk score changes, the PA can terminate the session immediately, without waiting for a VPN client to disconnect and a firewall admin to pull a static access rule.

The mechanics that matter most to network engineers specifically: mTLS (both sides present certificates, per RFC 8446 for TLS 1.3) authenticates the tunnel endpoints to each other independent of the user’s login; SAML or OIDC authenticates the user to the identity provider; and SCIM (System for Cross-domain Identity Management, RFC 7643 and RFC 7644) is what most enterprise ZTNA deployments use to sync entitlements from the IdP or HR system, so that a user removed from Okta or Microsoft Entra ID loses ZTNA access within the provisioning sync interval — not at the next manual VPN group-policy audit.

Where Engineers Get This Wrong

Treating ZTNA as a VPN replacement project instead of an identity and entitlement project. The most common failure pattern: the network team leads the rollout, migrates the existing VPN’s flat “all corporate users, all internal subnets” group policy directly into ZTNA application groups, and ships. The tunnel technology changed; the blast radius did not. ZTNA’s value depends entirely on entitlements being scoped per application, ideally per role — which means identity owners and application owners need to be in the room from week one, not brought in to review a network diagram afterward.

Confusing an SD-WAN platform with a bundled security stack for ZTNA itself. Several SASE (Secure Access Service Edge — the term Gartner introduced in 2019 for converged SD-WAN plus cloud-delivered security) platforms bundle SD-WAN, a secure web gateway, a CASB, and ZTNA under one console. That is a legitimate architecture, but “we bought SASE” is not the same claim as “we deployed ZTNA correctly.” It is entirely possible to run SD-WAN branch connectivity with full network-level access at the branch, and a ZTNA overlay only for remote users, that never touches how branch-to-branch or branch-to-datacentre traffic is authorised. Ask specifically what enforces per-application authorisation on branch-originated traffic, not only remote-worker traffic.

Treating device posture as a checkbox rather than a real evaluation. A common first-pass deployment authenticates the user and stops there. If the posture check is “agent installed: yes/no” rather than a genuine evaluation of patch level, disk encryption state, and EDR health, strong user authentication has been built in front of a network that still trusts whatever device shows up. Unmanaged BYOD and contractor devices are exactly the population this gap gets exploited through — and exactly the population ZTNA was supposed to make safer to onboard.

No plan for legacy and non-web protocols. ZTNA platforms proxy HTTP/HTTPS applications cleanly through browser-based or agent-based access. Legacy protocols — RDP, SSH, SMB file shares, and older client-server or database protocols that assume a persistent, low-latency Layer 3 path — need explicit connector support, and not every ZTNA platform handles all of them equally well. Rollouts commonly stall for months when a pilot covers SaaS and web apps cleanly and then hits one legacy ERP client that needs a real routed path, with no fallback beyond leaving the VPN running for that single application indefinitely.

Assuming ZTNA removes the need for internal segmentation. ZTNA governs how users reach applications. It does nothing, by itself, about how a compromised server talks to another server, or how a compromised device on the LAN talks to the rest of the flat network it sits on. East-west segmentation — VLANs, microsegmentation, internal firewalling — remains a separate, necessary control, and conflating the two leaves the internal network exactly as flat as before the ZTNA rollout.

Design Considerations for Production Networks

Start with entitlement design, not tunnel design. Before evaluating a single ZTNA vendor, get application owners and identity/IAM to produce an actual application-to-role mapping, even a rough first pass. This is consistently the slow part of a deployment, and it is the part that determines whether ZTNA delivers a real blast-radius reduction or simply relocates the VPN.

Plan for redundancy at the connector layer, not only the broker. The cloud broker side is the vendor’s responsibility and is usually well-engineered with global points of presence. The connector installed inside a data centre or VPC is the customer’s responsibility — deploy at least two per site behind a load-balanced outbound configuration, because a single connector is a single point of failure for every application behind it, and unlike a traditional VPN concentrator, this is a component teams often forget to build redundancy for precisely because it “just phones home.”

Account for latency architecture across India, Southeast Asia, and Middle East geography specifically. If a vendor’s nearest point of presence is in Singapore or Mumbai and branch users sit in Tier 2/3 Indian cities or across the GCC, every session — not only the initial authentication — is proxied through that point of presence. This is a materially different latency profile from a direct MPLS or SD-WAN path to a data centre, and it matters for anything latency-sensitive: VoIP, RDP, some ERP transaction screens. Check a vendor’s actual point-of-presence map for the specific user geography before committing, not their global point-of-presence count.

Plan the identity-outage runbook. If the IdP (Okta, Entra ID, Ping) has an outage, ZTNA access typically fails closed by design — correct behaviour, but it means an IdP outage becomes a full remote-access outage. Decide in advance whether a break-glass path — a small, tightly audited emergency access group with a separate authentication path — is needed for exactly this scenario, and test it before it is needed.

Budget for device-posture-agent conflicts with existing endpoint tooling. EDR agents, existing VPN clients, and ZTNA agents from different vendors can compete for the same network interception hooks on Windows endpoints, producing intermittent connectivity failures that present as a network problem and are actually two security agents contending for the same driver layer. Pilot on a representative device image — including whatever EDR and DLP agents are already mandated — before a wide rollout.

Decide migration sequencing deliberately. Migrating by application (all relevant users move to ZTNA for Application A, then Application B) is operationally cleaner to troubleshoot than migrating by user group (an entire department moves to ZTNA for everything at once). Application-by-application migration for the first two to three months of a rollout isolates whether a problem is the application, the connector, or the entitlement mapping, before an entire department is running on the new access path with no comparison baseline.

From the field — A pattern worth flagging across ZTNA rollouts generally: the deployments that stay on schedule are the ones where identity and network teams jointly own the entitlement mapping from day one, and the ones that slip by months are almost always the ones where network engineering tries to carry that mapping alone, using the existing VPN group policy as a starting template. The tunnel swap is the easy part; deciding who should actually reach what is the part that takes real cross-team time, and it is consistently underestimated in project timelines that treat this as primarily a network migration.

A Real-World Scenario

Consider a 15-branch retail and distribution enterprise headquartered in Bangalore, with branches across South India and a distribution partner office in Dubai, currently running a single VPN concentrator at headquarters for roughly 200 remote and branch-adjacent users, alongside site-to-site IPsec tunnels from each branch into the same headquarters firewall.

The trigger for the project is a familiar one: a phishing incident on a finance contractor’s laptop gives the attacker VPN-level access to the same flat internal network as the ERP database server, even though the contractor’s actual job needs access to exactly one web application. Nothing is exfiltrated, but the incident review makes the blast radius impossible to ignore.

The design that follows: application owners and IT jointly build an entitlement map covering the ERP web front end, an internal Jira/Confluence instance, a legacy Windows RDP jump box used by three administrators, and a handful of SaaS applications already outside the network entirely. Headquarters deploys two ZTNA connectors behind the internal load balancer, in the same data-centre segment as the applications, with outbound-only connectivity to the broker. Branch sites keep their existing SD-WAN/IPsec connectivity for site-to-site and point-of-sale traffic — a genuinely different traffic pattern with different latency and reliability requirements, where forcing it through a cloud-brokered ZTNA path would be the wrong tool for the job — while remote and branch-adjacent user access to specific applications migrates to ZTNA, application by application, over roughly ten weeks: SaaS and the browser-based ERP front end first, since they are lowest risk and easiest to validate; the Jira/Confluence instance second; and the legacy RDP jump box last, since it needs explicit non-web connector support and its own small pilot group before wider rollout.

Device posture is configured to require disk encryption and an active EDR agent before granting access to the ERP application specifically, with a lighter posture check for lower-sensitivity SaaS access — not every application needs the same bar, and one uniform posture requirement either overprotects low-risk applications or underprotects the ERP system. The Dubai partner office, which needs access to exactly the ERP front end and nothing else, is provisioned as a small, explicit entitlement group from day one rather than folded into the general remote-user policy — a deliberate illustration of ZTNA’s advantage over VPN-based partner access, where a partner connection has historically meant either a dedicated site-to-site tunnel with its own firewall rule set, or, worse, shared credentials on the general VPN group.

The contractor-access gap that triggered the project closes structurally: contractor accounts are provisioned with time-bound entitlements scoped to the single application their engagement covers, synced via SCIM from the HR or contractor-management system, so access expires automatically when the engagement ends instead of depending on someone remembering to revoke a VPN group membership.

From the field — A pattern that comes up repeatedly in scenarios like this one: teams underestimate how much of the timeline gets consumed by the legacy RDP or SSH jump-box application, not the SaaS or web applications. Web-based applications proxy cleanly through almost any ZTNA platform from day one. The one legacy admin jump box is reliably the item that needs its own connector testing, its own posture-policy discussion, and its own small pilot group — plan the project timeline around that reality rather than assuming every application migrates at the same pace.

Certification Angle

Zero trust and ZTNA architecture appear across advanced security certifications, but the exam framing and the production framing diverge in a specific way worth knowing before studying. CCIE Security’s written and lab blueprints test zero trust concepts primarily through Cisco’s own implementation stack — Duo for identity and device posture, ISE for policy enforcement and network access control, and increasingly Secure Access for the ZTNA/SASE piece — so expect configuration-level depth on those specific platforms rather than a vendor-neutral zero trust theory exam. JNCIE-Security leans more heavily on the SRX platform’s security policy and identity-aware firewalling capabilities in a zero-trust-adjacent context (application-layer policy, user-ID mapping) than on ZTNA broker architecture specifically — Juniper’s own ZTNA/SASE portfolio sits somewhat separately from the JNCIE-Security track’s core SRX focus. For a genuinely vendor-neutral, architecture-level understanding of zero trust rather than one vendor’s implementation, NIST SP 800-207 itself, alongside (ISC)² CISSP’s coverage of access control and security architecture domains, gets closer than either CCIE Security or JNCIE-Security alone — both of those exams assume the architecture is already understood and test fluency in one vendor’s tooling for implementing it.

What production deployments actually require, and these exams under-test: the cross-functional entitlement mapping work described above, and the judgment calls around legacy protocol support and migration sequencing. No lab exam can test “get the application owners in the room in week one” — but that is consistently the difference between a ZTNA rollout that finishes on schedule and one that does not.

Recommended Study and Lab Resources

INE’s security track (CCIE Security and broader identity/zero-trust content) is worth it specifically for candidates who want configuration-level depth on Cisco ISE and Duo alongside the architecture theory — lab environment access is the part free resources cannot replicate. (Resource link pending — INE affiliate programme not yet approved.)

CBT Nuggets’ zero trust and SASE-adjacent courses are a reasonable lower-friction starting point for understanding the conceptual architecture before committing to a specific vendor’s lab environment — well suited to IT managers and technical directors who need to evaluate vendor proposals rather than configure the platform themselves. (Resource link pending — CBT Nuggets affiliate programme not yet approved.)

NIST SP 800-207 itself, freely available at nvlpubs.nist.gov, remains the single best use of two hours for anyone who wants the vendor-neutral architecture cold before evaluating any product. It is short, it is precise, and every vendor’s marketing diagram is a rebranding of the same three components — read it once and vendor ZTNA marketing stops being confusing.

The Bottom Line

ZTNA is an identity and entitlement architecture that happens to use the network as its enforcement layer — not a VPN replacement product that can be dropped in without application owners and IAM at the table. This week: pull the current VPN group policy and count how many internal subnets the average user policy actually grants reachability to. If that number is larger than the handful of applications that role genuinely requires, that gap is the business case — and it is exactly the gap ZTNA is built to close.

Related Articles

Article	Why it is relevant	Status
SD-WAN vs MPLS for Indian Enterprises	Companion architecture discussion — how ZTNA and SD-WAN/SASE fit together	LIVE
Best Enterprise Switches in India 2026 — Deployment-Tested	Underlying enterprise network context	LIVE
SASE Architecture Explained	Direct companion piece — the broader convergence ZTNA sits inside	COMING Sep 2026

netdaemons.com · Network Engineering Deep Dives · August 2026 · See full disclaimer above. Zero trust and SASE terminology evolve — verify current vendor and certification details before making decisions.