In short
Zero trust network access works by sending every access request to a policy engine, which checks signals about the user, their device and their behaviour before brokering a connection to one specific application. The application sits behind an outbound-only connector, so it is not exposed to the internet, and access is re-evaluated while the session runs.
Get a quote for a ZTNA roll-out
Tell us roughly how many users or sites you have and we will reply by email with options and a quote.
The short version
A VPN answers one question at the start: "is this user allowed on the network?" Once the answer is yes, the user's device can usually reach far more than the user needs. Zero trust network access asks a narrower question, and asks it repeatedly: "should this user, on this device, in this context, reach this application right now?"
To answer it, a ZTNA architecture separates three jobs that a VPN concentrator does all at once:
- Deciding: a policy engine weighs signals about the user and device against your rules
- Enforcing: an enforcement point, such as a cloud gateway, proxy or connector, only forwards traffic that the policy engine has approved
- Hiding: applications are reachable only through that enforcement point, so they have no public address for an attacker to probe
The NCSC describes ZTNA as an architectural approach for controlling how users and devices access applications, in which network connectivity alone does not grant access to a service. The rest of this page shows how products implement that. For a shorter definition of the term, see ZTNA on our Cloud Security site.
The components of a ZTNA architecture
Vendors use different names, but the same building blocks appear in almost every zero trust network access architecture:
| Component | What it does | Where it lives | Other names you will see |
|---|---|---|---|
| Client or agent | Signs the user in, reports device posture and builds per-app tunnels to the broker | On the user's laptop or phone | ZTNA client, endpoint agent, secure client |
| Broker or cloud point of presence (PoP) | Receives the user's connection and stitches it to the right connector once policy allows | In the provider's cloud, near the user | ZTNA gateway, service edge, access proxy |
| Policy engine | Evaluates identity, device and behaviour signals against your rules and returns allow, deny or step-up | Usually in the provider's cloud console; sometimes in the identity provider | Policy decision point, access policy |
| Connector | Makes outbound-only connections from your network to the broker so apps need no inbound ports | A small VM or container beside the applications | Resource connector, app connector, ZTNA connector, sentry |
| Identity provider (IdP) | Authenticates the user, applies MFA and supplies group membership | Usually a cloud service such as Microsoft Entra ID | SSO, directory |
| Device management and endpoint security | Confirms the device is enrolled and compliant, and supplies a health or risk score | MDM such as Microsoft Intune, plus EDR | Posture source, compliance |
| Logging and monitoring | Records every allow and deny with the reason, for investigation and tuning | SIEM or the provider's log store | Audit, observability |
Some platforms also enforce on-site. Cisco's universal ZTNA, for example, applies the same per-application policy to users in the office by enforcing it on the firewall rather than in the cloud; see Cisco universal ZTNA.
Not sure which option fits? Ask us
Tell us what you need and we will recommend the right option for your organisation, with a quote.
What happens when a user opens an internal app
Take a member of staff working from home who opens the finance system, a web application hosted in your data centre or private cloud. With client-based ZTNA, the sequence typically looks like this:
- Sign-in: the ZTNA client signs the user in through your identity provider, which applies MFA and returns who they are and which groups they belong to.
- Posture check: the client reports device signals, such as whether the device is managed, encrypted, patched and free of active EDR alerts.
- Request: the user browses to the finance app. The client intercepts the request for that application's name and sends it to the provider's nearest point of presence rather than to the internet.
- Policy decision: the policy engine compares the user, device and context with your rules. Finance group, managed device, phishing-resistant MFA and normal sign-in location: allow. Anything missing: deny, or ask for step-up authentication.
- Brokering: if allowed, the broker joins the user's connection to the tunnel already held open by the connector beside the finance app. The connector made that tunnel outbound, so no inbound firewall rule exists.
- Per-app session: the user reaches the finance app and only the finance app. Other servers on the same subnet are not reachable through this session.
- Re-evaluation: while the session runs, the platform keeps checking. If EDR raises an alert on the laptop or the user's risk score rises, access can be restricted or ended.
- Logging: the decision, the signals used and the policy that matched are logged, so you can explain later why access was granted or refused.
The user sees none of this; the app simply opens or a message explains why it did not. Compare that with the VPN model on ZTNA vs VPN.
Signals: what the policy engine looks at
The NCSC recommends a baseline set of signals for access decisions and says to prioritise four types:
| Signal type | Examples | Typical source |
|---|---|---|
| User identity | Group membership, authentication strength (password, one-time code, phishing-resistant passkey or security key) | Identity provider |
| Device identity | Device is organisation-owned and enrolled; hardware-backed device certificate | MDM, certificate authority, TPM |
| Device health | Compliance with configuration baseline; EDR risk score | MDM and EDR |
| User behaviour | Risk scores from unusual sign-in times or impossible travel; sign-in location | Identity provider or SASE platform |
The guidance stresses combining signals from multiple, independent sources: no single signal is perfect, and combining them makes bypass more difficult. It also notes that location on its own is a weak signal: helpful alongside the others, not a substitute for them. Strong identity is the foundation, which is why we cover ZTNA vs IAM separately.
Is a ZTNA roll-out the right fit for you?
We will check it against your systems and requirements and recommend the right option.
Network-level and application-level policy engines
The NCSC distinguishes two kinds of policy engine, and most real deployments use both:
- Network-level: decides which network destinations a client can reach and tells an enforcement point (a proxy or connector) to forward the traffic. VPN as a service, SSE and SASE platforms work at this level, which limits exposure before the user touches the application.
- Application-level: authorises access to one application, usually through the identity provider or SSO. The user is redirected to the engine and receives a short-lived token if allowed.
Layered together, the network-level engine controls which segment is reachable and the application-level engine decides whether this user may use this app. For SaaS, where you do not control the network, the application-level engine does most of the work, backed by strong authentication and short-lived tokens. Detail on both is in our summary of the NCSC ZTNA guidance.
Client-based vs clientless access
ZTNA comes in two delivery models, and many platforms offer both:
| Client-based ZTNA | Clientless (browser-based) ZTNA | |
|---|---|---|
| How the user connects | An agent on the device builds per-app tunnels | The user signs in through a web portal or enterprise browser |
| Applications covered | Web and non-web: file shares, RDP, SSH, thick clients | Mainly web apps; some vendors add browser-based RDP and SSH |
| Device posture | Rich: the agent reports device health | Limited: little or no visibility of an unmanaged device |
| Best fit | Managed staff laptops and phones | Contractors, partners, BYOD and short-term access |
| Examples we supply | Cisco Secure Access, Check Point SASE, NordLayer, Todyl SASE, Zero Networks Connect | Check Point SASE Agentless ZTNA, Cisco Secure Access clientless ZTNA, Exium SASE Pro, Island Private Access |
The trade-offs of the browser route are covered on agentless ZTNA. Transports differ too: some clients use WireGuard-based tunnels, while Cisco's client-based ZTNA uses QUIC and MASQUE. The protocol detail is on ZTNA vs IPsec and SSL VPN.
Continuous re-evaluation and logging
A ZTNA decision is not a one-off gate. The NCSC's design requirements ask for access to be re-evaluated as context changes, and for the architecture to be observable. In practice:
- Short-lived tokens and sessions force regular re-checks rather than a sign-in that lasts all week
- Event-driven revocation lets a signal such as an EDR detection end a session in near real time, where the platform supports it
- Logs of allowed and denied requests, with the user, device, application, time and matching policy, should flow to a central SIEM and be reviewed
- Resilience matters: a misconfigured policy can lock out everyone, so changes should be phased, and a tightly controlled break-glass route should exist and be tested
How well each platform does this varies, and it is one of the things worth testing in a trial.
How we help
We can review an existing ZTNA or VPN design against the components and signals above, or design one from scratch: which applications go behind which connectors, which signals each policy should use and how logging reaches your SIEM. Because we supply several platforms, we can show how each would implement the same design. When you are ready to plan the rollout, our guide on how to implement zero trust network access sets out the phases. Scope is confirmed at quote. Contact us to talk it through.
How Forever Systems helps with ZTNA and SASE
We are an independent IT and cyber security provider. We supply and support several zero trust access and SASE platforms, so we can recommend what fits how your people work rather than one vendor's answer to everything.
- Assess first: we look at your current VPN, firewall, identity set-up and the applications people need to reach before suggesting anything new
- Vendor-aware advice across ZTNA, SSE and SASE options, including Cisco Secure Access and Check Point Harmony SASE
- Pilots and phased roll-out: we can help you start with one group of users or one application, then extend access policy by policy
- VPN replacement: planning the move away from remote access VPNs, including identity provider integration and device posture checks
- Ongoing support: policy changes, licence reviews and renewals, with the details confirmed at quote
We work with businesses, schools, charities and public sector organisations. Pricing depends on users, features and term, so ask us for a quote.
Frequently asked questions
How does ZTNA work without a VPN?
Instead of joining the device to the network, the ZTNA client sends each application request to a cloud broker. A policy engine checks identity, device and context, then the broker joins the session to an outbound connector beside that one application. The user reaches the app, not the network.
What is a ZTNA connector?
A connector is a small piece of software, usually a virtual machine or container, installed near your private applications. It makes outbound connections to the provider's cloud, so the applications need no inbound firewall ports or public addresses. Vendors call it a resource connector, app connector or sentry.
What is a ZTNA gateway?
A ZTNA gateway is the enforcement point that users connect to: usually a cloud point of presence run by the provider, sometimes a gateway on your own firewall. It forwards traffic only when the policy engine has approved the request.
Does ZTNA need an agent?
Not necessarily. Client-based ZTNA uses an agent and covers non-web protocols with full device posture. Clientless ZTNA works through a browser for web apps, and with some vendors browser-based RDP and SSH, but sees much less about the device.
Is ZTNA continuous?
It should be. The NCSC asks for access to be re-evaluated as context changes, using short-lived tokens and event-driven revocation where possible. Products differ in how quickly they act on a change in device health or user risk, so test it during a trial.
Still have a question about a ZTNA roll-out?
Ask us and a member of our team will reply by email.