Security Visualized
Library

Identity and access

ZTNA compared with remote-access VPN

A remote-access VPN authenticates once and then grants network reachability, so everything routable from the tunnel is reachable; ZTNA evaluates each request and connects the user to one named application, so the network is never exposed.

What is being compared

The two subjects

Both are one scene apart, not two architectures apart — which is why the diagram below is a single scene with each subject's claim on it marked, rather than two pictures to hold in your head at once.

  • Remote-access VPN

    Marked "only in Remote-access VPN" in the delta below.

    A tunnel to a published concentrator. Once it is up, the client holds an address on a network segment and can reach whatever routing allows.

    No entry of its own yet

  • Zero trust network access (ZTNA)

    Marked "only in Zero trust network access (ZTNA)" in the delta below.

    A broker that evaluates each request and stitches a session to one named application, reached through a connector that only ever dials outward.

    Zero trust network access (ZTNA)

Architecture diagram

Two paths to one application, and where each attack ends

The same contractor and the same private applications, reached two ways. One path terminates a tunnel at a published concentrator and puts the client on a routed segment. The other presents each request to a policy engine and brokers a session to one application through a connector that only dials outward. The overlay shows lateral movement succeeding on the first path and stopping on the second.

Step 1 / 5One person, one application, two designs

Architectural planes

Annotations

The same architecture, read top to bottom

  1. Remote and unmanaged networks

    UNTRUSTEDNot controlled and not trusted; anyone may be present on it

    Contractor · Contractor laptop · Adversary

    • PersonContractorNeeds the finance application only
    • DeviceContractor laptopUnmanaged, posture unknown to the estate
    • AdversaryAdversaryHolds a phished credential

    Reaches this boundary

    • BlockedAdversary stopped at ZTNA brokerRefused: unknown device, no posture signal
    • BlockedAdversary stopped at Application connectorNothing listening, so nothing answers
    • BlockedAdversary stopped at ZTNA brokerRefused: this session authorises one app

    Within this boundary

    • RequestContractor to Contractor laptopOpens the finance application
    • AttackAdversary to Contractor laptopCredential phished from the contractor

  2. Published internet edge

    MANAGEDOperated or administered on the enterprise's behalf

    VPN concentrator

    • API or gatewayVPN concentratorListening on the internet, terminates tunnels

    Reaches this boundary

    • ContextIdentity provider to VPN concentratorIdentity asserted once, at tunnel setup
    • RequestContractor laptop to VPN concentratorTunnel to the published listener
    • AttackAdversary to VPN concentratorListener found by internet-wide scanning

  3. Brokered access service

    MANAGEDOperated or administered on the enterprise's behalf

    ZTNA broker

    • Security controlZTNA broker
      • One decision per request
      • Session scoped to one application
      • No route to the private network
      • Refusals recorded with the reason
    • Policy decision
      MANAGEDOperated or administered on the enterprise's behalf

      Policy engine

      • Policy decisionPolicy engineAllow this app, step up, or refuse

    Reaches this boundary

    • ContextIdentity provider to Policy engineIdentity and risk claims, per request
    • RequestContractor laptop to ZTNA brokerClient reaches the broker, not the network
    • ContextContractor laptop to Policy engineDevice posture presented with the request
    • RequestApplication connector to ZTNA brokerOutbound-initiated, from inside the network
    • AttackAdversary to ZTNA brokerStolen credential replayed at the broker
    • AttackAdversary to ZTNA brokerSecond application requested on one session

    Within this boundary

    • RequestZTNA broker to Policy engineEach request presented for a decision
    • RequestPolicy engine to ZTNA brokerVerdict naming a single application

  4. Private network

    INTERNALOperated by the enterprise itself

    Application connector

    • API or gatewayApplication connectorDials outward; publishes no inbound port
    • Finance segment
      INTERNALOperated by the enterprise itself

      Finance application · Payroll database

      • ApplicationFinance applicationThe one thing the contractor needs
      • Data storePayroll database
    • Shared services segment
      INTERNALOperated by the enterprise itself

      Shared file server

      • ApplicationShared file serverUnrelated to the engagement

    Reaches this boundary

    • RequestVPN concentrator to Finance applicationReachable once the tunnel is up
    • RequestVPN concentrator to Shared file serverAlso reachable, and never asked for
    • AttackAdversary to Shared file serverLateral movement across the routed segment
    • AttackAdversary to Application connectorScan for an inbound port to reach

    Within this boundary

    • RequestApplication connector to Finance applicationSession delivered to one application
    • RequestFinance application to Payroll databaseApplication reads its own records

  5. Enterprise control plane

    INTERNALOperated by the enterprise itself

    Identity provider · Security operations

    • Identity providerIdentity providerSign-on, second factor and risk claims
    • Security controlSecurity operationsDetection, investigation and access review

    Reaches this boundary

    • ContextContractor to Identity providerSign-on and a second factor
    • TelemetryVPN concentrator to Security operationsTunnel up, tunnel down, bytes moved
    • TelemetryZTNA broker to Security operationsWhich user reached which application

Legend

Participants

  • PersonSomeone making a request, and the identity they assertCircle with a person mark
  • DeviceAn endpoint the request is made from, with its own postureRounded rectangle with an inset panel
  • ApplicationAn application that serves or holds dataRounded rectangle with a panel stacked behind it
  • Identity providerThe authority that asserts who is askingHexagon marked ID
  • API or gatewayA network endpoint that terminates or forwards connectionsCapsule marked API
  • Data storeWhere data restsCylinder
  • Security controlA protective control, and the control plane's own observationRounded octagon with a check mark
  • AdversaryA hostile party attempting somethingDiamond marked with an exclamation mark
  • Policy decisionWhere policy is evaluated and one verdict is reachedDiamond with a split-path mark on its trailing point

Relationships

  • RequestTraffic asking to reach a destinationSolid line. Filled arrowhead.
  • TelemetryEvents reported onward for observation — observation, not controlDotted line. Small open arrowhead.
  • ContextA signal that informs a decision without carrying the request itselfDash-dot line. Open chevron.
  • AttackAn attempt made by an adversaryShort-dashed heavy line. Barbed open arrowhead.
  • BlockedAn attempt terminated by the control the line starts fromHeavy line that stops short of its target. Perpendicular bar, and deliberately no arrowhead: the attempt did not arrive.

Boundaries

  • Internal boundaryOperated by the enterprise itselfSolid outline. Badge reads INTERNAL.
  • Managed boundaryOperated or administered on the enterprise's behalfDashed outline with a subtle wash. Badge reads MANAGED.
  • Untrusted boundaryNot controlled and not trusted; anyone may be present on itDotted outline with a hatched leading corner. Badge reads UNTRUSTED.

Text alternative

The request, step by step

  1. One person, one application, two designs

    A contractor on unmanaged hardware needs the finance application for the length of an engagement, and signs on with a second factor. Everything after this point differs between the two designs.

    • Request: Contractor to Contractor laptop, “Opens the finance application”
    • Context: Contractor to Identity provider, “Sign-on and a second factor”

    Emphasised at this step: Contractor.

  2. The VPN grants reachability, then trusts the client

    Identity is asserted once as the tunnel is built. The client is then placed on a segment and can reach the finance application, the shared file server and anything else routing permits. Nothing asked what the contractor came for.

    • Context: Identity provider to VPN concentrator, “Identity asserted once, at tunnel setup”
    • Request: Contractor laptop to VPN concentrator, “Tunnel to the published listener”
    • Request: VPN concentrator to Finance application, “Reachable once the tunnel is up”
    • Request: VPN concentrator to Shared file server, “Also reachable, and never asked for”

    Emphasised at this step: VPN concentrator.

  3. The broker asks about every request

    The client connects to a broker rather than a network. Identity claims and device posture reach a policy engine with each request, and the verdict names one application. A posture change is evaluated on the next request, not at the next reconnect.

    • Request: Contractor laptop to ZTNA broker, “Client reaches the broker, not the network”
    • Context: Contractor laptop to Policy engine, “Device posture presented with the request”
    • Context: Identity provider to Policy engine, “Identity and risk claims, per request”
    • Request: ZTNA broker to Policy engine, “Each request presented for a decision”
    • Request: Policy engine to ZTNA broker, “Verdict naming a single application”

    Emphasised at this step: Policy engine.

  4. The application is reached from the inside out

    A connector beside the application holds an outbound connection to the broker, and the two are stitched into one session. No inbound port is published, so the application gains no internet exposure and the contractor gains no address on the private network.

    • Request: Application connector to ZTNA broker, “Outbound-initiated, from inside the network”
    • Request: Application connector to Finance application, “Session delivered to one application”
    • Request: Finance application to Payroll database, “Application reads its own records”

    Emphasised at this step: Application connector.

  5. What each design can later prove

    Concentrator records show who connected and for how long; what happened on the network afterwards must be reconstructed elsewhere. Broker records show which user reached which application from which posture, and which requests were refused.

    • Telemetry: VPN concentrator to Security operations, “Tunnel up, tunnel down, bytes moved”
    • Telemetry: ZTNA broker to Security operations, “Which user reached which application”

    Emphasised at this step: Security operations.

Attempts shown, and where each one stops

  • Adversary attempts:

    • Attack: Adversary to Contractor laptop, “Credential phished from the contractor”
    • Attack: Adversary to VPN concentrator, “Listener found by internet-wide scanning”
    • Attack: Adversary to Shared file server, “Lateral movement across the routed segment”
    • Attack: Adversary to ZTNA broker, “Stolen credential replayed at the broker”
    • Attack: Adversary to Application connector, “Scan for an inbound port to reach”
    • Attack: Adversary to ZTNA broker, “Second application requested on one session”
    • Terminated here by ZTNA broker — “Refused: unknown device, no posture signal”. The line stops short and takes a bar, not an arrowhead.
    • Terminated here by Application connector — “Nothing listening, so nothing answers”. The line stops short and takes a bar, not an arrowhead.
    • Terminated here by ZTNA broker — “Refused: this session authorises one app”. The line stops short and takes a bar, not an arrowhead.

Annotations

  1. The line nobody asked for

    Relationship — Request: VPN concentrator to Shared file server, “Also reachable, and never asked for”

    This path exists because the grant is reachability, not authorisation. The contractor never requested the file server and has no reason to open it, yet it answers. Narrowing this depends on segment design and firewall rules staying correct for as long as the tunnel exists.

  2. Why the arrow points outward

    Relationship — Request: Application connector to ZTNA broker, “Outbound-initiated, from inside the network”

    The connector initiates the connection from inside the private network and holds it open. Because nothing is listening on the internet side, there is no service for an adversary to enumerate, and no edge appliance whose next advisory becomes an emergency.

  3. Where lateral movement runs out of road

    Relationship — Blocked: Adversary stopped at ZTNA broker, “Refused: this session authorises one app”

    A held session is authorisation for one application, so asking for a second is a new decision made from scratch. The adversary is not blocked by a network control noticing unusual traffic; there is simply no path that was ever granted.

  4. An over-broad application definition is a VPN

    Boundary “Finance segment” (internal)

    If the application is defined as an address range or a whole subnet, the broker grants reachability to all of it and the delta on this page disappears. The precision of the definition is the control, and it decays when nobody reviews it.

  5. Posture is a per-request signal, not a gate

    Component “Policy engine”

    Evaluating device state at every request is what makes access from unmanaged hardware defensible: a laptop that fails a check gets a narrower answer rather than none, and a laptop that fails one later loses access without waiting for a reconnect.

  6. A published listener is an asset and a liability

    Component “VPN concentrator”

    It is the reason the design works without agents on every private application, and the reason it is scanned continuously. Its patch cycle becomes an availability decision, because taking it down removes remote access for everyone at once.

  7. Neither design segments the network for you

    Boundary “Private network” (internal)

    Brokering puts a boundary in front of applications, which helps, but the segment behind the connector stays as flat as it was. Anything already running inside the network, including the application itself if it is compromised, still moves freely.

The delta

What each one adds, and what they share

Computed from the claims each subject makes on the one scene above, not drawn separately. Every box and every path in that diagram is claimed by all of these designs or by exactly one of them, and the bands below are that partition.

37 elements in the scene · 11 shared · 9 in VPN · 17 in ZTNA

Shared by both designs

7 boxes · 4 paths

Claimed by Remote-access VPN and Zero trust network access (ZTNA) alike. This is the larger part of the scene, and saying so is part of the answer: two things worth comparing usually agree about most of the architecture, and a comparison that hides the agreement makes the difference look bigger than it is.

  • Contractor Person — Needs the finance application only Shared by both designs.
  • Contractor laptop Device — Unmanaged, posture unknown to the estate Shared by both designs.
  • Adversary Adversary — Holds a phished credential Shared by both designs.
  • Identity provider Identity provider — Sign-on, second factor and risk claims Shared by both designs.
  • Finance application Application — The one thing the contractor needs Shared by both designs.
  • Payroll database Data store Shared by both designs.
  • Security operations Security control — Detection, investigation and access review Shared by both designs.
  • Contractor to Contractor laptop Request — Opens the finance application Shared by both designs.
  • Contractor to Identity provider Context — Sign-on and a second factor Shared by both designs.
  • Finance application to Payroll database Request — Application reads its own records Shared by both designs.
  • Adversary to Contractor laptop Attack — Credential phished from the contractor Shared by both designs.

Only in Remote-access VPN

2 boxes · 7 paths

2 boxes belong to Remote-access VPN alone, and 7 paths do. Most of this difference is therefore in the connections rather than in the parts, which is what it looks like when an advantage is behavioural: there is little to add to the scene, and a great deal to change about how it moves.

  • VPN concentrator API or gateway — Listening on the internet, terminates tunnels Only in Remote-access VPN.
  • Shared file server Application — Unrelated to the engagement Only in Remote-access VPN.
  • Identity provider to VPN concentrator Context — Identity asserted once, at tunnel setup Only in Remote-access VPN.
  • Contractor laptop to VPN concentrator Request — Tunnel to the published listener Only in Remote-access VPN.
  • VPN concentrator to Finance application Request — Reachable once the tunnel is up Only in Remote-access VPN.
  • VPN concentrator to Shared file server Request — Also reachable, and never asked for Only in Remote-access VPN.
  • VPN concentrator to Security operations Telemetry — Tunnel up, tunnel down, bytes moved Only in Remote-access VPN.
  • Adversary to VPN concentrator Attack — Listener found by internet-wide scanning Only in Remote-access VPN.
  • Adversary to Shared file server Attack — Lateral movement across the routed segment Only in Remote-access VPN.

Only in Zero trust network access (ZTNA)

3 boxes · 14 paths

3 boxes belong to Zero trust network access (ZTNA) alone, and 14 paths do. Most of this difference is therefore in the connections rather than in the parts, which is what it looks like when an advantage is behavioural: there is little to add to the scene, and a great deal to change about how it moves.

  • ZTNA broker Security control Only in Zero trust network access (ZTNA).
  • Policy engine Policy decision — Allow this app, step up, or refuse Only in Zero trust network access (ZTNA).
  • Application connector API or gateway — Dials outward; publishes no inbound port Only in Zero trust network access (ZTNA).
  • Identity provider to Policy engine Context — Identity and risk claims, per request Only in Zero trust network access (ZTNA).
  • Contractor laptop to ZTNA broker Request — Client reaches the broker, not the network Only in Zero trust network access (ZTNA).
  • Contractor laptop to Policy engine Context — Device posture presented with the request Only in Zero trust network access (ZTNA).
  • ZTNA broker to Policy engine Request — Each request presented for a decision Only in Zero trust network access (ZTNA).
  • Policy engine to ZTNA broker Request — Verdict naming a single application Only in Zero trust network access (ZTNA).
  • Application connector to ZTNA broker Request — Outbound-initiated, from inside the network Only in Zero trust network access (ZTNA).
  • Application connector to Finance application Request — Session delivered to one application Only in Zero trust network access (ZTNA).
  • ZTNA broker to Security operations Telemetry — Which user reached which application Only in Zero trust network access (ZTNA).
  • Adversary to ZTNA broker Attack — Stolen credential replayed at the broker Only in Zero trust network access (ZTNA).
  • ZTNA broker to Adversary Blocked — Refused: unknown device, no posture signal Only in Zero trust network access (ZTNA).
  • Adversary to Application connector Attack — Scan for an inbound port to reach Only in Zero trust network access (ZTNA).
  • Application connector to Adversary Blocked — Nothing listening, so nothing answers Only in Zero trust network access (ZTNA).
  • Adversary to ZTNA broker Attack — Second application requested on one session Only in Zero trust network access (ZTNA).
  • ZTNA broker to Adversary Blocked — Refused: this session authorises one app Only in Zero trust network access (ZTNA).

Dimension by dimension

How each behaves, on each axis that matters

ZTNA compared with remote-access VPN: how each subject behaves on each dimension of the comparison.
Dimension Remote-access VPN Zero trust network access (ZTNA)
What a successful login grants An address on a network segment. Authorisation is whatever the routing table and the firewall rules on that segment happen to permit. A session to one application named in the verdict. No address on the private network is issued, so there is nothing else to reach.
When the decision is made At tunnel setup. The tunnel then persists for hours, and a device that becomes compromised mid-session is not re-evaluated. Per request, against identity, device posture, the application and current risk, so a posture change can end access without a reconnect.
Direction of the connection to the application The concentrator listens on the internet, so it is discoverable by scanning and must be patched under pressure. A connector beside the application dials out to the broker. Nothing inbound is published, so there is no listener to find.
What lateral movement can reach Anything routable from the assigned segment. A stolen credential becomes network presence, and network presence enables discovery. Only the application already authorised. A request for a second application is a fresh decision, and it fails on its own merits.
Device posture Often a one-off check at connect time, and frequently absent entirely for contractors on their own hardware. A signal in every decision, which is what lets an unmanaged device get browser-based access to one application and nothing more.
What the logs can tell an investigator Who connected, from where and for how long. What they then did on the network has to be reconstructed from other sources. Which user reached which application, when, from what device posture, and which requests were refused and why.
Protocol and workload coverage Carries whatever IP traffic the segment permits, which is why it still survives for engineering tools and awkward legacy protocols. Strongest for defined application access. Broad protocol support and server-initiated flows vary considerably between implementations.
The failure mode that recreates the other Split-tunnel and segment design can narrow the grant, but the grant is still reachability, so narrowing depends on firewall rules staying right. An application defined as a wide address range or a whole subnet is a VPN with a broker in front of it. The definition is the control.
Availability dependency The concentrator and the identity provider. Capacity is sized locally, and an outage is visible and understood. The broker service, its connectors and the identity provider, most of which are operated by a third party on their maintenance schedule.

In full

The argument, at length

A remote-access VPN answers one question: can this person get onto the network. Once the answer is yes, a tunnel carries an address on a segment, and authorisation becomes whatever the routing table and the firewall rules allow. That model was built when the things worth reaching were inside one building and the people reaching them were employees on company hardware.

ZTNA answers a different question, and answers it repeatedly: should this request, from this identity on this device, reach this specific application, now. A broker sits between the two and stitches a session for the one application the verdict named. No address on the private network is issued, so there is nothing adjacent to discover. The application is reached through a connector that dials outward from inside the network and holds the connection open, which means nothing inbound is published to be scanned, and no internet-facing appliance sits in the path with a patch cycle that competes with availability.

The consequence shows up in what a stolen credential is worth. On the routed path, a credential becomes network presence, and network presence is the precondition for reconnaissance and lateral movement: a file server nobody asked for answers, because reachability was the grant. On the brokered path, the same credential meets a device-posture requirement it cannot satisfy, and a request for a second application is a new decision that fails on its own terms rather than a boundary that has to detect something.

None of this makes brokering universally correct. An application defined as an address range or an entire subnet gives the broker nothing narrow to grant, and the design becomes a VPN with an extra hop and a better log. Traffic that is not an application session — device management, server-initiated callbacks, engineering protocols, plant equipment that cannot host a connector — often still needs routed reachability, and pretending otherwise produces either a broken workflow or a scope so wide it defeats the point. The honest position is that most human access to defined applications belongs on the brokered path, that a narrower set of flows will keep needing tunnels, and that both leave the network behind the applications exactly as flat as it already was.

Choosing

When each one is the right answer

Grouped by subject rather than interleaved, and every subject has cases of its own — required by the content model, because a comparison in which one side never wins is an argument dressed as a comparison.

Choose Remote-access VPN when

  • Traffic that is not an application session

    Engineering tooling, device management protocols, server-initiated callbacks and awkward legacy stacks often need routed reachability, and forcing them through an application broker either fails or leaks scope.

  • A site-to-site or appliance-constrained requirement

    Connecting networks rather than people, or reaching equipment that cannot run an agent and cannot sit behind a connector, remains a tunnelling problem rather than a brokering one.

Choose Zero trust network access (ZTNA) when

  • A contractor needs one application for one engagement

    Access can be scoped to that application on an unmanaged device, with posture in every decision and a per-request log, and it ends when the engagement ends without touching network configuration.

  • The private estate is flat and cannot be segmented soon

    Brokering per application puts a boundary in front of applications that the network itself does not provide, which is usually faster than a segmentation programme and reduces what a stolen credential reaches.

Sources