Remote Access Models for Business

The four common models

Client VPN: still the workhorse

The user runs a VPN client (WireGuard, OpenVPN, IPsec, vendor-specific) that establishes a tunnel from their device to a VPN concentrator in the office or cloud. Once connected, the user's traffic for internal destinations routes over the tunnel as if they were on the office network.

Strengths: simple mental model, works for any TCP/UDP service, broad compatibility. Weaknesses: once connected, the user has network-level access to potentially much more than they need — a compromised laptop on the VPN is a compromised laptop inside.

Split tunnel vs full tunnel

• Full tunnel: all traffic from the device goes through the VPN, including general internet browsing. Easier to control; impacts user latency for non-corp destinations.
• Split tunnel: only traffic destined for internal networks goes through the VPN; internet traffic uses the local connection directly. Better user experience; less visibility into user activity.

See split tunnel VPN explained for the deeper coverage.

Site-to-site VPN

Two firewalls (or routers, or cloud gateways) establish a persistent tunnel between them. All traffic between the two networks transits the tunnel. Used for office-to-office connections, office-to-cloud (e.g., to a VPC), and connections to partner networks. The user doesn't run any client software — the tunnel is transparent to endpoints.

For more, see site-to-site VPN explained.

ZTNA: zero trust network access

ZTNA replaces the perimeter model. Instead of "if you're on the network, you're trusted," ZTNA evaluates every access request:

1. Who is the user? (Verified via SSO/MFA.)
2. What device are they on? (Health check: managed, patched, encrypted, etc.)
3. What application are they trying to reach?
4. Does policy allow this user-device-application combination at this time and from this location?

If yes, a tunnel is brokered to the specific application — not the whole network. If no, the request is blocked.

Operationally this means a contractor can be given access to one tool without being given access to the corporate network. A compromised endpoint has access only to whatever applications its credentials authorize, not the broader internal network.

Identity-aware proxy

A specific ZTNA pattern for web applications. The internal web app sits behind a reverse proxy that:

1. Intercepts every request.
2. Validates the user's SSO session (redirects to login if not authenticated).
3. Forwards authorized requests to the upstream app.
4. Logs the access.

No client software, no VPN. The user goes to intranet.example.com, logs in via SSO, gets the app. Modern enterprise patterns lean heavily on this for internal web apps; the SaaS-grade UX matches users' expectations.

Comparing the models

Choosing for a small business

• Up to ~10 users, simple needs: WireGuard or OpenVPN to the office firewall. Cheap, simple, well-understood.
• Mostly web apps: identity-aware proxy in front of each. SSO-driven access; no VPN required.
• Mix of users, contractors, devices: managed ZTNA service. Pay per user; gain per-app policy without running infrastructure.
• Multi-site: site-to-site VPN between offices, plus one of the above for individual users.

MFA, device posture, and conditional access

Whatever model you pick, modern remote access includes:

• MFA on initial connection. Push, OTP, or hardware key.
• Device posture checks: OS version, encryption, EDR running.
• Conditional access by time, location, network, or risk score.
• Session timeouts so persistent compromise is bounded.

These are independent of the underlying model — VPN, ZTNA, or IAP can each enforce them with appropriate integrations.

Logging and audit

Every model needs an audit trail. VPN logs are at the network level (user X connected at time Y, sent N bytes). ZTNA and IAP logs are at the application level (user X accessed application Y at time Z). For incident response and compliance, application-level logs are far more useful.

Frequently Asked Questions

What is the difference between client VPN and site-to-site VPN?

Client VPN connects individual users from their laptop or phone to the corporate network — one tunnel per user. Site-to-site VPN connects two networks (typically office to office, or office to cloud) over a single persistent tunnel that all traffic between the sites uses. They solve different problems and often coexist.

What is ZTNA?

Zero Trust Network Access — a model where users authenticate and are authorized per application rather than getting blanket network access. Instead of joining the corporate network and reaching whatever they have IP-level access to, the user proves identity and device posture, then accesses only the specific applications policy permits. The mental model is "identity is the perimeter," not "the firewall is the perimeter."

Is VPN obsolete because of ZTNA?

No. VPNs still work and are simpler to deploy for many use cases — site-to-site links, lab access, broad network access for trusted users. ZTNA is better for granular per-application policy, especially when devices and users are scattered across many networks. Many organizations run both: VPN for some teams and use cases, ZTNA for others.

What is an identity-aware proxy?

A reverse proxy that authenticates users (typically via SSO with SAML or OIDC) and forwards authorized requests to internal applications. The user reaches a public hostname; the proxy validates identity and forwards to the internal service. No client software needed — the browser is enough. It is a specific implementation pattern within ZTNA.

Which remote access model should a small business use?

For under ~20 users with simple needs: a client VPN like WireGuard or OpenVPN to the office firewall. For organizations that want per-application policy without managing infrastructure: a managed ZTNA service. For cloud-native organizations: identity-aware proxies for web apps, with WireGuard for the few cases that need raw network access. The right answer scales with team size and security maturity.