A remote access VPN builds an encrypted tunnel between one user's device and a gateway on your network. Traffic inside the tunnel is protected from the untrusted network in between. Traffic after the gateway is not protected by the VPN, and a logged-in device gets broad reach unless you limit it.
What is the architecture?
NIST's guide to IPsec VPNs (SP 800-77 Revision 1) calls this model "host-to-gateway." A laptop on hotel Wi-Fi runs a VPN client, authenticates, and sends everything through the tunnel to a gateway at headquarters. The gateway decrypts the traffic and forwards it to internal hosts.
NIST points out the consequence: the remote access VPN does not protect data for the whole path. The link between the gateway and the destination server is outside the tunnel. If that internal segment is flat and unmonitored, the VPN has moved your trust boundary without shrinking it.
Why is it hard to run?
NIST describes the model as somewhat complex to implement and maintain, because the gateway must manage the credentials of every remote device and user, and those change often. Users must authenticate before they can use it, and each device needs a configured client.
The UK NCSC adds an operational warning in its VPN guidance: VPNs are complex to set up and need maintenance, and a failure can cause organization-wide outages. Plan for gateway capacity and for a second gateway before you plan for features.
Which choices matter most?
The NCSC guidance is specific, and most of it holds up for any remote access design.
Protocol. TLS and IPsec are the most widely used. NCSC recommends IPsec, an open standard with clients built into many operating systems. It says that, other things equal, there is very little difference in risk between IPsec and TLS VPNs. TLS-based products can traverse NAT and firewalls more reliably but usually need a vendor's own client.
Authentication. NCSC recommends client certificates for machine authentication, because one certificate can be revoked without touching the rest, and private keys can live in a TPM or similar hardware.
Client. Native operating system clients are free, update automatically and work reliably, but have limited routing options. Third-party clients add software to patch and raise the risk that some traffic leaks outside the tunnel.
Forced or optional. If the VPN is optional, users can switch it off and avoid monitoring. NCSC generally recommends forcing traffic through it, with a note that captive portals on public Wi-Fi can complicate this.
Split tunnelling. It sends some traffic through the VPN and the rest directly. It reduces load on the gateway and increases the amount of traffic you cannot see.
A constructed example
A 40-person engineering firm gives every laptop a VPN client with a shared pre-shared key and full network access. A contractor's laptop is stolen. Revoking access means changing the key on 40 devices. With per-device certificates, the team revokes one certificate and nothing else changes. With network-level access limits, the thief would also have reached one file share rather than the whole office network.
How to check or apply this
- List what users actually reach through the VPN. If the answer is "everything," write the short list of services they need and restrict the rest.
- Use per-device certificates, not a shared pre-shared key, and store keys in hardware where the platform allows.
- Prefer the native client unless you need a feature it cannot provide.
- Decide on forced versus optional tunnels, and write down why.
- Patch the gateway on a fixed schedule, and check new advisories against CISA's Known Exploited Vulnerabilities catalog, since the gateway is exposed to the internet by design.
- Log connections and review them, so a stolen credential shows up as an odd login rather than a surprise.
- Test failure: take the gateway down in a drill and see who can still work.
If the application stack behind the gateway is the weak part, scanning your own dependencies for known vulnerabilities and reachability is a separate piece of work that Safeguard supports. It does not replace gateway patching.
Quick check
Does a remote access VPN protect traffic all the way to the server?
No. According to NIST, it protects the segment between the device and the gateway. The segment between the gateway and the destination host is not covered by the tunnel.
Is IPsec or TLS safer for a remote access VPN?
The NCSC says there is very little difference in risk between them, all other things equal. It recommends IPsec mainly because it is an open standard with built-in client support.
Sources
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- NCSC, Virtual Private Networks (VPNs) device security guidance
- CISA, Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
