Vendor-neutral guide · 10 min read

Remote access architectures compared: VPN, zero trust, hosted desktops and hybrids

In short

There is no single correct remote access architecture, only architectures whose assumptions you can or cannot satisfy. Traditional VPN access extends the network and relies on internal controls. Zero-trust access authorises each request against a specific resource. Hosted desktops keep data and processing centrally so endpoints hold less. Brokered remote control connects an operator to a specific device for a specific session. Most real estates run more than one, and the failures usually come from the joins rather than the components.

Key takeaways

  • Choose by assumption, not by fashion: each model depends on something you must actually be able to do.
  • VPNs assume the internal network is a meaningful trust boundary.
  • Zero trust assumes reliable identity and device-state evaluation at every request.
  • Hosted desktops reduce data on endpoints but concentrate cost, capacity and latency centrally.
  • Brokered remote control is scoped to a device and a session, which makes it easier to audit but is not a general network access method.

Traditional VPN access

A VPN establishes an encrypted tunnel that places the remote device logically on the corporate network. It is well understood, widely supported and simple to explain, which is a genuine advantage.

Its weakness is granularity. Once connected, the device typically has broad network reachability, and the controls limiting what it can touch live elsewhere. That makes lateral movement after a compromise easier than most organisations assume, and it makes third-party access difficult to scope tightly.

  • Strengths: mature, familiar, protocol-agnostic, works for legacy applications
  • Weaknesses: coarse authorisation, lateral movement risk, concentrated gateway dependency
  • Best suited to: internal staff on managed devices needing broad access to legacy systems

Zero-trust network access

Zero-trust approaches drop the assumption that being on the network confers trust. Each access request is authenticated and authorised against the specific resource requested, ideally with device health taken into account, and the user never gains general network reachability.

The trade-off is prerequisite complexity. You need dependable identity, meaningful device-state signals and an application inventory. Where those exist, the security improvement is substantial. Where they do not, a partial implementation can produce the operational cost without the benefit.

  • Strengths: per-resource authorisation, no implicit lateral reach, works well for third parties
  • Weaknesses: depends on identity and device posture maturity; legacy applications can be awkward
  • Best suited to: mixed workforces, contractor access, and estates with modern identity in place

VDI and published desktops

Virtual desktop infrastructure and published applications keep the operating environment and data centrally, delivering only the display to the endpoint. National guidance highlights the security value of this: corporate information stays centrally held, less is cached on personal devices, and the consequence of losing a device is reduced.

The costs are equally clear. Central capacity has to be sized and paid for, latency shapes the user experience, and misconfiguration — especially of authentication and of what can be copied in and out — undoes much of the benefit.

  • Strengths: data stays central, endpoint loss is less consequential, standardised environment
  • Weaknesses: capacity cost, latency sensitivity, configuration and authentication complexity
  • Best suited to: high-sensitivity data, contractor and BYOD scenarios, tightly standardised roles

Brokered remote control

Remote control tools connect an operator to a specific device for a specific session, typically through a cloud broker so that neither end needs an inbound firewall opening. Access is scoped to a machine rather than to a network, and can be consent-based where a user is present.

This is the right model for support and maintenance work, and a poor one for general employee access to corporate systems. Its audit story is strong — sessions are discrete, attributable events — but it is a complement to a network access strategy, not a replacement for one.

  • Strengths: device-scoped, session-discrete, easy to audit, no inbound firewall exposure
  • Weaknesses: not a general network access method; governance depends on the platform's identity and logging
  • Best suited to: helpdesk support, server maintenance, unattended estate management

Hybrids and the joins between them

Almost every real organisation runs a hybrid: a VPN for legacy systems, zero-trust access for modern applications, hosted desktops for sensitive roles, and remote control tooling for IT. That is a reasonable outcome, not a failure of planning.

The risk lives at the joins. Each model has its own identity source, its own logging and its own offboarding process, and it is entirely common for someone to be removed from three of them and remain active in the fourth. Consolidating identity and consolidating logs are the two moves that make a hybrid estate governable.

Best-practice checklist

  1. 1. Write down each model's assumption

    For every access path in use, state what it assumes about identity, device health, network trust and application inventory. Then check whether you can actually satisfy it.

  2. 2. Consolidate identity first

    One identity source across access paths is the prerequisite for coherent authorisation, review and offboarding.

  3. 3. Consolidate logging second

    Session and access records from every path should land in one place, or nobody can answer 'how did they get in?'.

  4. 4. Scope third parties to the narrowest model that works

    Per-resource or per-device access for suppliers; broad network access only where nothing else is viable, and then time-bounded.

  5. 5. Test offboarding across every path

    Remove one test account and verify it is gone from all of them. This is where hybrid estates fail.

  6. 6. Review the estate annually

    Access paths accumulate. Decommissioning an unused one is a security improvement with no user impact.

Common pitfalls

  • Adopting zero trust as a label while keeping flat network access underneath
  • Running four access paths with four identity sources and four offboarding processes
  • Sizing hosted desktop capacity for the average rather than the Monday morning peak
  • Using remote control tooling as a substitute for a network access strategy
  • Keeping a legacy VPN alive for one application nobody has reviewed in years

What to measure

Metrics for Remote access architectures
MetricHow to read it
Access paths in useCount, with an owner for each
Identity consolidation% of paths using the primary identity source
Log centralisation% of paths shipping to the central store
Offboarding completenessVerified by test, not assumed
Third-party scope% of supplier access that is per-resource or per-device

Frequently asked questions

Is zero trust a replacement for a VPN?
For many use cases it can be, but not universally — legacy applications and protocols often still require network-level reachability. National guidance treats them as architectural options with different assumptions rather than a straight upgrade path.
Does VDI make endpoints secure?
It reduces what an endpoint holds, which limits the consequence of loss or theft. It does not secure the endpoint itself, and NCSC guidance is explicit that authentication and configuration decisions determine how much benefit you actually get.
Where does remote support tooling fit?
As a device-scoped, session-based complement to whichever network access model you run. It is well suited to support and maintenance, and poorly suited to general user access.
How many access paths is too many?
The number matters less than whether each one has a named owner, a shared identity source, centralised logs and a tested offboarding process. Any path missing those is one too many.

Sources

Independent, standards-body and peer-reviewed material. None of these sources is affiliated with 247connect.

Putting it into practice

This guide is deliberately product-neutral. If you want to see how one implementation handles these requirements — attended and unattended access, named operator accounts, AES-256 encryption, audit logs and fixed pricing — the reference pages on this hub document 247connect in detail, and the product itself lives at 247connect.cloud.

What is 247connect?See a worked example

More best-practice guides