Zero trust network access replaces implicit network trust with continuous, per-application verification of identity, device health, and context before granting a connection. Its core benefit is least-privilege access: users reach only the specific applications they are authorised for, never the wider network. Security teams and IT decision-makers managing hybrid workforces, cloud applications, or third-party access should treat ZTNA as the current standard architecture for remote and internal access control alike.
TL;DR:
- ZTNA offers advantages in attack surface reduction by granting access only to specific applications, minimizing lateral movement risks.
- Proper planning requires mapping application dependencies and starting with pilot groups to avoid policy sprawl and access failures.
- Client-based ZTNA provides deeper device posture visibility, while clientless ZTNA suits temporary or unmanaged device scenarios, balancing security and support overhead.
- Integrating ZTNA with existing identity, endpoint, and security tools enhances decision-making, as isolated trust brokers risk weaker security outcomes.
- Most organizations phase out VPNs gradually, using ZTNA for scoped, application-specific access while maintaining VPNs for legacy or operational technology networks.
Table of Contents
- What is zero trust network access?
- How does ZTNA work in practice?
- ZTNA vs VPN: which one actually fits your environment?
- Core components and deployment types
- Why does ZTNA reduce risk more than perimeter security?
- How do you plan a ZTNA rollout without breaking things?
- What are the most common ZTNA use cases?
- What are the limitations of zero trust network access?
- Re-solution’s perspective on delivering ZTNA
- Ready to move from VPN to zero trust?
- Sources
- FAQ
What is zero trust network access?
Zero trust network access operationalises a principle laid out in NIST Special Publication 800-207: trust should never be assumed based on network location. A user on the corporate LAN gets no more automatic credibility than one connecting from a coffee shop. Every request is evaluated on its own merits, using identity, device posture, and behavioural context.
That framing shifts the entire security perimeter from the network edge to the individual application. Instead of granting access to a subnet or VPN tunnel, ZTNA grants access to one resource at a time, brokered by a policy decision point that checks conditions before and during the session.
A few terms recur throughout ZTNA architecture:
- Trust broker — the component that sits between the user and the application, enforcing policy decisions rather than routing raw network traffic.
- Application-level access — connections scoped to a single app or service, not the network segment hosting it.
- Policy engine — the logic that evaluates identity, device, and context signals against defined rules.
- Device posture — a real-time assessment of whether an endpoint meets security requirements (patch level, encryption, endpoint protection status).
CISA’s zero trust guidance frames this as operating on the assumption that a breach has already occurred somewhere in the environment. ZTNA sits within a broader security stack, typically alongside identity providers, endpoint detection tools, and increasingly, secure access service edge (SASE) platforms that deliver these controls from the cloud.
How does ZTNA work in practice?
Every access request follows a similar decision chain, regardless of vendor or deployment model. Understanding this flow matters more than memorising product names, because it explains why ZTNA behaves so differently from a traditional VPN.
- Request initiation — a user or device attempts to reach a specific application, not the network as a whole.
- Identity verification — the request is checked against an identity provider (IdP), usually with multi-factor authentication enforced.
- Device posture check — the connecting endpoint is assessed for patch status, encryption, and security agent health.
- Policy evaluation — the trust broker weighs identity, device posture, location, and behavioural signals against defined access rules.
- Brokered connection — if the request passes, the broker establishes a session scoped to that single application, never the underlying network.
Cisco’s technical explanation of ZTNA versus VPN notes that this evaluation is continuous, not a one-time gate. A session that starts compliant can be revoked mid-connection if device posture changes or behaviour looks anomalous.
Two operational models exist. Client-based ZTNA installs an agent on the endpoint, giving deeper posture visibility and support for legacy protocols. Clientless ZTNA runs through a browser, which suits contractors, BYOD users, or short-term third-party access where installing software isn’t practical.
Pro Tip: Reserve client-based ZTNA for managed corporate devices where you need deep posture telemetry, and use clientless access for anyone outside your device management scope. Mixing the two by default multiplies your support overhead for no security gain.
ZTNA vs VPN: which one actually fits your environment?
A VPN authenticates once and then trusts the device with broad network access. ZTNA authenticates continuously and grants access to one application at a time. That distinction drives every practical difference between the two models.
- Attack surface: VPNs expose an entire network segment to a compromised credential; ZTNA exposes only the specific app requested.
- User experience: ZTNA typically routes traffic more directly to cloud applications rather than backhauling through a central VPN concentrator, which Microsoft’s ZTNA overview cites as a common performance improvement.
- Scalability: VPN concentrators need capacity planning for peak concurrent users; cloud-delivered ZTNA scales with the provider’s infrastructure.
VPNs still earn their place for specific legacy site-to-site tunnels and certain operational technology (OT) networks where per-application brokering isn’t yet supported. Most organisations run both during a phased migration, retiring VPN access application by application rather than in one cutover.
Core components and deployment types
A working ZTNA deployment relies on several components operating together rather than a single box or agent.
- Trust broker/gateway — enforces the connection decision and terminates sessions.
- Policy engine — the rules logic that decides who gets access to what, under which conditions.
- Identity provider (IdP) — the authoritative source of user identity and authentication strength.
- Endpoint posture tooling — agents or integrations that report device health to the policy engine.
- Logging and monitoring — continuous session telemetry for audit and anomaly detection.
Deployment models vary by where the broker sits. Client-based deployments install an agent for deep posture checks. Clientless deployments run through a browser for lightweight or third-party access. Gateway-based models place the broker on-premises for latency-sensitive or regulated environments. Cloud-delivered models, often bundled into a broader SASE or security service edge (SSE) platform, extend ZTNA alongside secure web gateway and CASB functions from the same cloud fabric.
Integration points matter as much as the core components. ZTNA needs to talk to your IAM platform for identity, your CASB for SaaS visibility, your secure web gateway for general internet traffic, and your EDR tools for posture signals. A trust broker operating in isolation from these systems makes weaker decisions than one wired into the full stack.
Why does ZTNA reduce risk more than perimeter security?
The measurable benefit is containment. When access is scoped to individual applications, a compromised credential or infected device can’t move laterally across the network hunting for other targets, because there’s no flat network to move across.
That containment also solves the third-party access problem that plagues most VPN deployments. Contractors and vendors get access to the exact application they need to do their job and nothing else, rather than a shared VPN profile that quietly grants far more reach than intended. NCSC’s guidance on ZTNA frames this scoped access as one of the strongest arguments for UK organisations to adopt the architecture for hybrid and cloud-first estates.
Performance often improves too, since users connect directly to cloud applications instead of routing through a central VPN gateway. Because every session carries continuous policy evaluation rather than a one-off login check, security teams gain far richer visibility into who is accessing what, from which device, and under what conditions. That telemetry feeds directly into incident response and compliance reporting, turning access logs from a forensic afterthought into an ongoing risk indicator.
How do you plan a ZTNA rollout without breaking things?
The single highest-value step, and the one most teams underestimate, is mapping which users and roles actually need to reach which applications before writing a single policy rule. Skip it, and policy sprawl or access failures follow almost immediately once real users start hitting the system.
- Map applications and dependencies — identify every app, who uses it, and what it connects to on the back end.
- Pilot on a contained group — start with contractor access or a handful of non-critical applications, not your entire workforce.
- Validate posture checks under real conditions — test what happens when a legitimate device fails a check, not just when it passes.
- Iterate policy before scaling — expand coverage only after the pilot surfaces gaps in logic or coverage.
- Build operational capacity — telemetry review, policy governance, and incident playbooks need to scale alongside the rollout, not get bolted on afterwards.
The most common mistake at this stage is lifting existing firewall rules and pasting them into the new policy engine unchanged. It feels efficient, but it recreates the same broad, location-based trust that ZTNA exists to remove, and it leaves you managing two overlapping rule sets instead of one coherent one.
Pro Tip: Run your pilot against contractor or third-party access first, not internal staff. Contractors already expect scoped access, so friction from early policy mistakes causes far less disruption than testing on your entire finance team.
What are the most common ZTNA use cases?
ZTNA earns its keep fastest in a handful of recurring scenarios rather than as a blanket network replacement.
- Hybrid and remote worker access to internal applications, replacing broad VPN tunnels with per-app connections.
- Scoped third-party and contractor access, granting exactly the application needed for a defined engagement.
- Protecting legacy applications that can’t be rearchitected, by placing a brokered front door in front of them.
- Securing cloud and SaaS access when paired with a broader SSE or SASE platform for consistent policy across environments.
ZTNA needs careful adaptation for environments with heavy unmanaged device populations, such as certain OT or IoT networks, where posture agents can’t be installed and identity-based controls have limited reach.
What are the limitations of zero trust network access?
ZTNA isn’t a drop-in replacement with no trade-offs, and vendors pitching it as effortless are glossing over real operational cost.
- Policy management overhead grows with application count; each new app needs its own access rules and testing.
- Coverage gaps persist for unmanaged devices and OT/IoT systems that can’t run posture agents.
- Ongoing telemetry and support costs accompany continuous monitoring, which needs staffing and tooling beyond the initial rollout.
Before selecting a partner or platform, put these questions to any vendor: How does the broker integrate with our existing IdP? Is it compatible with our EDR stack? What SLA governs broker availability? What logging and compliance reporting does it produce for audit purposes? Answers that dodge specifics on any of these usually signal gaps that surface later, not earlier.
Re-solution’s perspective on delivering ZTNA
Zero trust looks straightforward on a whiteboard and gets complicated fast in a live estate with legacy applications, contractor access, and departments that have never had their app dependencies properly mapped. As a Cisco partner with over 35 years of infrastructure experience, Re-solution has found that the projects that succeed are the ones that resist the urge to skip straight to policy configuration.
The sequence that works: assess the current access model and identify where implicit trust exists, map application dependencies properly, run a contained pilot, design policy around actual usage rather than assumptions, then move into managed operations with tuning built in from day one. Re-solution delivers this through Cisco Zero Trust security solutions, applying the same phased discipline to a manufacturing floor’s OT access as to a hospitality group’s guest and staff networks. The architecture is standard; the sequencing rarely is.
— Jacob
Ready to move from VPN to zero trust?
Re-solution designs and manages Cisco-based ZTNA deployments for organisations that need scoped, identity-driven access without the guesswork of building policy from scratch. If your team is still relying on flat VPN access across education, manufacturing, logistics, or hospitality environments, that’s precisely the gap this approach closes: per-application access control instead of broad network trust, backed by over 35 years of Cisco infrastructure delivery.
Whether you need a full assessment of your current access model or a managed rollout that handles policy design and ongoing tuning, Re-solution’s managed IT services and Network as a Service options both support phased ZTNA adoption. Start with a conversation about where implicit trust exists in your current network, then get in touch to scope an assessment tailored to your environment.
Sources
- SP 800-207, Zero Trust Architecture | CSRC
- Zero Trust | Cybersecurity and Infrastructure Security Agency CISA
- Introduction to ZTNA – Zero Trust
- ZTNA explained: Secure per-app access vs. VPN How It Works – Cisco
FAQ
What is zero trust network access?
Zero trust network access is a security architecture that grants users access to individual applications only after verifying identity, device health, and context, rather than trusting anyone connected to the network. NIST SP 800-207 formalises this as an approach centred on resources, not network location.
What is zero trust network access vs VPN?
A VPN authenticates once and grants broad access to a network segment, while ZTNA continuously verifies identity and device posture and grants access to one application at a time. This scoping is why Cisco and other vendors position ZTNA as a lower-risk replacement for legacy VPN access.
What are the disadvantages of zero trust network access?
The main drawbacks are policy management overhead as application count grows, coverage gaps for unmanaged or OT devices that can’t run posture agents, and ongoing telemetry and support costs that need dedicated staffing beyond the initial deployment.
Which vendors offer zero trust network access solutions?
The market includes major networking and security vendors alongside managed service providers who deploy and operate these platforms on a client’s behalf. Re-solution delivers Cisco-based ZTNA as a certified Cisco partner, handling assessment, policy design, and managed operations rather than leaving deployment to in-house teams alone.
Do I need to replace my VPN entirely to adopt ZTNA?
No. Most organisations run VPN and ZTNA in parallel during migration, retiring VPN access application by application while retaining VPN for specific legacy tunnels or OT networks that aren’t yet ready for per-app brokering.
Recommended
- Modern network security: A complete guide for IT leaders
- Secure network design: proven examples for robust protection
- Examples of secure access solutions for IT managers
