A virtual private network (VPN) creates an encrypted tunnel between a device or network and a VPN server, so traffic crossing an untrusted network such as the internet or public Wi-Fi cannot be read or altered on the way. It is one of the most widely used security technologies and one of the most misunderstood: a VPN protects data in transit, but it does not stop phishing, malware or an attacker who already controls the device. This guide explains in plain language how tunnelling and encryption work, the difference between remote access and site-to-site VPNs, what split tunnelling means, how corporate and consumer VPNs differ, and where VPNs fall short and zero trust access takes over. It is for practitioners who need a clear model to explain to others, and for executives deciding what a VPN does and does not buy them. Protocol detail is in VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide and hardening in the VPN Security Guide.
Key takeaways
- A VPN is an encrypted tunnel, not a security product for everything. It protects traffic between two endpoints; what happens on the device and at the destination is outside its reach.
- Remote access and site-to-site solve different problems. Remote access connects individual devices to a network; site-to-site connects whole networks to each other, usually router to router.
- A VPN moves trust rather than removing it. The network you are on can no longer see your traffic, but the VPN server and whoever operates it can.
- A corporate VPN is a front door into the network. Stolen VPN credentials without MFA, and unpatched VPN appliances, are among the most common ways attackers get in.
- Zero trust access narrows what a VPN opens up. NIST SP 800-207 describes granting no implicit trust based on network location; ZTNA grants access to named applications instead of whole networks.
What it is
A VPN makes a private network connection over a public one. "Virtual" because no dedicated cable is laid; "private" because encryption and authentication keep the traffic confidential and tamper-evident between the two ends of the tunnel. The NCSC describes VPNs as providing encrypted connections that protect data in transit across untrusted networks, and lists further uses: supporting legacy systems, adding a second layer of defence for internal services, shielding internal servers from unauthenticated attackers, protecting devices from local network attacks and routing traffic through monitoring tools.
There are two broad kinds of VPN, and most confusion comes from mixing them up.
| Corporate VPN | Consumer (commercial) VPN | |
|---|---|---|
| Purpose | Give staff or sites access to the organisation's internal network and services | Hide browsing from the local network and internet provider, or appear to be in another country |
| Who runs the server | The organisation (appliance, cloud gateway or managed service) | A commercial VPN provider |
| Who can see your traffic | The organisation's network and security tools | The VPN provider |
| Authentication | Corporate identity, ideally certificates plus MFA | An account with the provider |
| Main risks | Stolen credentials, unpatched gateways, over-broad network access once connected | Untrustworthy providers, logging and data sale, fake or malicious VPN apps |
For guidance aimed at households and individuals choosing a consumer service, see the Choosing a VPN Safely Guide.
How it works
Tunnelling
Tunnelling means wrapping one network packet inside another. Your device builds its normal packet, addressed to, say, an internal file server. The VPN client encrypts that whole packet and puts it inside a new packet addressed to the VPN server. Anyone on the path sees only traffic between your device and the VPN server. The VPN server unwraps the outer packet, decrypts the inner one and forwards it to the file server as if your device were on the internal network.
IPsec, the protocol suite NIST covers in SP 800-77 Rev. 1, Guide to IPsec VPNs, shows the idea precisely. RFC 4301 defines two modes: transport mode protects mainly the payload between two hosts, while tunnel mode protects an entire IP packet inside a tunnel, with an outer header identifying the IPsec endpoints and an inner header identifying the real source and destination. Tunnel mode is required whenever either end is a security gateway, which is why VPNs use it.
Encryption and integrity
Two things protect the tunnel. Encryption keeps the contents confidential; integrity protection makes any tampering detectable. In IPsec, the Encapsulating Security Payload (ESP) provides both, and RFC 4301 says that using ESP for confidentiality without integrity is not recommended. Modern VPNs use authenticated encryption that does both at once: WireGuard, for example, uses ChaCha20 with Poly1305, while IPsec and TLS-based VPNs commonly use AES in GCM mode.
Key exchange and authentication
Before any data flows, the two ends must prove who they are and agree on fresh encryption keys. IPsec usually does this with the Internet Key Exchange protocol (IKEv2). WireGuard uses a Noise-based handshake with Curve25519 key agreement, and identifies peers by their static public keys. TLS-based VPNs reuse the same handshake that protects websites. Authentication can be a pre-shared key, a certificate, or a user sign-in; the NCSC prefers certificates over pre-shared keys for device authentication, with private keys held in hardware such as a TPM where possible.
Remote access versus site-to-site
| Model | What connects | Typical use | Who authenticates |
|---|---|---|---|
| Remote access (client-to-site) | A user's device to a VPN gateway | Staff working from home or travelling | The device (certificate) and the user (credentials and MFA) |
| Site-to-site (gateway-to-gateway) | One network's gateway to another's | Branch offices to headquarters, data centre to cloud | The two gateways, usually with certificates or pre-shared keys |
| Mesh (peer-to-peer overlay) | Devices directly to each other through a coordinated overlay | Small teams, developer access, distributed servers | Each device by its key, coordinated by a control service |
Mesh VPNs are covered in the Mesh VPN Security Guide.
Full tunnel and split tunnel
A full tunnel sends all of a device's traffic through the VPN. A split tunnel sends only traffic for certain destinations (usually internal networks) through the VPN and lets the rest go straight to the internet. Split tunnelling saves bandwidth and improves performance for cloud services, but traffic outside the tunnel bypasses corporate monitoring and filtering. The NCSC recommends avoiding split tunnelling and generally forcing all traffic through an automatic, always-on VPN. The trade-offs are covered in VPN split tunnelling.
Why it matters
VPNs remain the main remote access technology for many organisations, which makes them both a key control and a key target.
- Protecting data on untrusted networks: hotel, café and home networks can be monitored or tampered with. A VPN protects traffic that is not otherwise encrypted, and legacy protocols that cannot be secured on their own.
- Reaching internal systems: applications that were never designed to face the internet can be reached without publishing them.
- Connecting sites and clouds: site-to-site VPNs link offices, data centres and cloud networks over the internet at lower cost than dedicated circuits.
- A front door for attackers: the VPN gateway is internet-facing, and the NCSC stresses patching it quickly. Stolen VPN passwords are a common ransomware entry point: in the Colonial Pipeline Ransomware Attack 2021, attackers used a legacy VPN account that had never been disabled and had no MFA. Exploited flaws in the gateway itself are the other common route.
Running a corporate VPN well
- Authenticate strongly: device certificates plus user MFA, with phishing-resistant methods for administrators.
- Patch the gateway first: treat vendor security advisories for the VPN appliance as emergency changes.
- Limit what a connection reaches: assign users to groups that can reach only the subnets or applications they need, rather than the whole network.
- Remove dormant accounts: disable VPN access when people leave or stop using it, and review accounts quarterly.
- Log and monitor: send gateway authentication and session logs to the SIEM. See the VPN and Firewall Log Detection Guide.
- Change safely: test configuration changes on a pilot group with a second gateway in place, since the NCSC notes a VPN failure can cause organisation-wide outages.
Useful measures are: percentage of VPN accounts with MFA (target 100), days to patch critical gateway advisories, number of VPN accounts unused for 90 days, and failed authentication rates per account.
Common misconceptions
| Misconception | Reality |
|---|---|
| "A VPN makes me anonymous" | The VPN operator sees your traffic and IP address; websites can still identify you through accounts, cookies and browser fingerprinting |
| "A VPN protects me from phishing" | A phishing page reached through the tunnel is still a phishing page; a VPN does not judge what you visit |
| "A VPN stops malware" | Malware on the device runs regardless, and can use the tunnel to reach internal systems |
| "Once on the VPN, the user is trusted" | A connected device with stolen credentials looks exactly like a legitimate one; network access should still be limited and monitored |
| "Encryption means the data is safe end to end" | Encryption ends at the VPN server; from there to the destination, traffic is protected only if the application uses its own encryption such as HTTPS |
| "Most web browsing is unencrypted without a VPN" | Most websites already use HTTPS, so a VPN mainly hides which sites you visit from the local network, not what you send |
| "All VPN protocols are equally secure" | The NCSC regards PPTP as obsolete; use IPsec (IKEv2), WireGuard or a well-maintained TLS VPN with current cryptographic settings |
Decision guidance: for a small organisation with a few internal systems, a well-configured VPN with MFA, or moving those systems to SaaS, may be all that is needed. For larger organisations with many applications and contractors, a VPN that drops users onto a flat network is a large risk, and application-level access is the better target.
Related concepts
- Zero trust network access (ZTNA): instead of joining the network, users are brokered to individual applications after identity and device checks. NIST SP 800-207 describes moving defences from static, network-based perimeters to users, assets and resources, and granting no implicit trust based on network location. The NCSC notes there is little benefit in a VPN once an organisation has fully adopted zero trust networking. See the Secure Remote Access Beyond VPN Guide.
- TLS and HTTPS: encryption between a browser or application and a server; it protects the content end to end even without a VPN.
- Secure web gateways and SASE: cloud services that combine filtering, ZTNA and network security, often replacing the full-tunnel VPN for internet traffic.
- Machine and service identities: site-to-site tunnels and VPN gateways authenticate with certificates and pre-shared keys that are themselves non-human credentials needing an owner, rotation and secure storage. VPN service accounts used for directory lookups are a frequent target. See the Zero Trust Identity Guide.
- Post-quantum readiness: VPN key exchange is one of the first places quantum-resistant algorithms are being introduced. See the Post-Quantum Readiness for VPNs and IKEv2 Guide.
Where VPNs sit in frameworks
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-17 Remote Access; SC-8 Transmission Confidentiality and Integrity | Authorising and protecting remote connections |
| NIST CSF 2.0 | PR.DS-02 data in transit; PR.IR-01 networks protected from unauthorised access | Outcomes a VPN contributes to |
| MITRE ATT&CK | T1133 External Remote Services; T1078 Valid Accounts | How attackers abuse VPN access |
Practitioner checklist
- Explain to stakeholders what the VPN protects (data in transit) and what it does not (device, phishing, destination).
- Use IPsec IKEv2, WireGuard or a maintained TLS VPN; retire PPTP and other obsolete protocols.
- Authenticate devices with certificates held in hardware where possible, and users with MFA.
- Prefer an automatic, full-tunnel VPN; document and limit any split tunnelling.
- Restrict each user group to the networks or applications it needs once connected.
- Patch VPN gateways as emergency changes and monitor their logs centrally.
- Disable VPN accounts that are unused or belong to leavers, and review quarterly.
- Plan a move to application-level (ZTNA) access for high-risk users and contractors.
Standards and references
- NIST: SP 800-77 Rev. 1, Guide to IPsec VPNs
- IETF: RFC 4301, Security Architecture for the Internet Protocol
- NIST: SP 800-207, Zero Trust Architecture
- NCSC: Virtual private networks
- WireGuard: Protocol and cryptography
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: External Remote Services
Related NHI Mgmt Group resources: VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide · VPN Security Guide · Secure Remote Access Beyond VPN Guide · Choosing a VPN Safely Guide