What is a remote access VPN and what should you check first?

A remote access VPN gives an individual user or device an encrypted tunnel into a private network from outside it. It protects traffic on the way in, but it does not make the user trustworthy. Before relying on one, check how users authenticate, how the gateway is patched, and how much network the tunnel opens.

How is it different from a site-to-site VPN?

A site-to-site VPN joins two networks, usually between gateways that stay up all day. A remote access VPN connects one laptop or phone to a gateway on demand. The tunnel protocol can be the same, and NIST SP 800-77 Rev. 1 describes IPsec for different circumstances, but the risk is different. Users roam across hotel and home networks, their devices vary, and their credentials are phishable.

What does the tunnel protect, and what does it not?

It protects confidentiality and integrity of traffic between the device and the gateway. It does not check whether the device is clean, and it does not decide what the user may reach. Once inside, a user with a full tunnel often sees the entire internal network. A compromised laptop then becomes a compromised network.

NIST SP 800-207 describes zero trust as a shift from static, network-based perimeters toward users, assets and resources, and notes that no implicit trust should come from network location alone. A VPN that grants broad network access on login is the older perimeter model in a new coat.

What are the usual failure points?

The gateway itself is the biggest one. It faces the internet and holds the keys to the internal network, so an unpatched flaw in it is an entry point. Treat gateway firmware like a public web server: track vendor advisories, patch fast and limit the management interface to a trusted network.

Weak authentication is the next. A password alone is not enough. CISA's guidance for small organizations says to require multi-factor authentication whenever possible, and to start with privileged, administrative and remote access users. VPN users are on that list by name.

Then scope. A full tunnel with flat access is convenient and wide. Split access by group, so finance staff do not reach build servers.

Finally, logging. If nobody can say who connected, from where and to what, you cannot investigate.

Should you keep a VPN at all?

Often yes, for legacy applications that cannot sit behind modern access brokers. Many organizations keep a VPN for those and move web applications behind identity-aware access. The question is not VPN or no VPN. It is how much of the internal network a single login should open.

A constructed example

A 120-person company runs a VPN gateway for remote staff. During a review, the IT lead finds three things: the gateway firmware is two releases behind, every employee has the same access once connected, and logins need only a password. She schedules the update in the next window, creates four access groups with different subnets, and turns on MFA with an authenticator app, moving privileged users to a hardware key first. She also sets an alert for logins from countries where the company has no staff. None of the changes touched the tunnel protocol.

How to check or apply this

1. Inventory gateways and their software versions. Subscribe to the vendor's security advisories.
2. Require MFA for every user. Prefer phishing-resistant methods for administrators.
3. Split access by group and by application. Remove the default of full network access.
4. Check device health where you can, such as disk encryption and current patches, before granting access.
5. Log connections centrally with user, time, source and destination, and review anomalies.
6. Restrict the gateway's management interface to a trusted network.
7. Review every few months who still needs access, and remove dormant accounts.

Quick check

Sources

• NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
• NIST SP 800-207, Zero Trust Architecture
• CISA Cyber Essentials

Last reviewed: 18 October 2026.