What Is Zero Trust Network Access (ZTNA)?

Zero trust network access is the product category implementing zero trust principles for remote and internal access. Its defining property is that it grants access to a specific application rather than to a network.

That single difference addresses the structural weakness of VPN: a user authorised for one system can reach only that system, and everything else remains not merely blocked but invisible.

Applications become undiscoverable

In a conventional model, an internal application listens on a network an authorised user can reach, so anyone who gets onto that network can find it and attack it. Under this model the application is not exposed at all — a broker establishes the connection outbound, and unauthorised users cannot see that the service exists.

Removing discoverability eliminates an entire class of attack against internal applications that were never designed to face hostile traffic.

Continuous evaluation, not a one-time gate

Access decisions incorporate identity, device posture, location and behaviour, and are re-evaluated during the session rather than only at connection. A device that falls out of compliance, an account that is disabled, or a risk signal that rises can end access mid-session.

That is a meaningful improvement over a tunnel that remains valid for hours regardless of what changes.

What it does not solve

Applications requiring network-level protocols that cannot be published individually. Thick clients with unusual connectivity requirements. And anything on an operational network where introducing a broker is not acceptable.

It also depends entirely on identity being sound. Deployed over a weak identity foundation it relocates the problem rather than solving it — an attacker with valid credentials and a compliant device is authorised by design.

The broker is a dependency worth understanding

Access now depends on a service that brokers every connection. That service becomes critical infrastructure: its outage is a total loss of access to the applications behind it, and its compromise is a path to all of them.

The questions worth asking a provider are the ones that apply to any critical dependency. What is the availability record and the architecture behind it? What happens during a regional outage? Can sessions survive a broker restart? Where is the traffic processed, which matters for both latency and data residency?

Self-hosted connectors reduce some of this exposure and add operational burden. Either way the dependency is real and belongs in continuity planning rather than being discovered during an outage.

Application discovery is the unglamorous prerequisite. Publishing applications individually requires knowing which exist, who uses them and what they depend on — and in most estates that inventory does not exist, because network-level access made it unnecessary. Expect that discovery to be a meaningful share of the project rather than a preliminary.

A common mistake worth avoiding

Where to start

Identify the two or three internal applications most used by remote staff and publish those first. It delivers visible benefit, builds the operational pattern, and reduces what the VPN needs to reach.

See zero trust architecture. GuardsArm delivers zero trust security.