VPN Reference and Use Cases

A Virtual Private Network (VPN) is a network security technology that creates an encrypted tunnel between a user's device and a remote server or network, masking traffic content and origin IP address from third parties. This page describes how VPN technology is classified, the mechanisms behind its operation, the professional and organizational contexts in which it is deployed, and the boundaries that determine when a VPN is — and is not — the appropriate technical control. The Digital Security Listings catalog includes practitioner resources across the broader cybersecurity service sector.

Definition and scope

A VPN establishes a secure, encrypted communication channel over a public or untrusted network, allowing the endpoint device to operate as though it were directly connected to a private network. The technology is classified under network security controls and referenced within the NIST Cybersecurity Framework as a component of the "Protect" function, specifically under access control and data security categories.

VPN implementations fall into three primary classification types:

Remote-access VPN — Connects individual users to a central corporate or organizational network. Common in enterprise environments where employees access internal resources from off-site locations.
Site-to-site VPN — Links two or more fixed networks (e.g., branch offices to headquarters) into a unified private network topology without per-user client software.
Consumer/personal VPN — Routes individual internet traffic through a third-party server to obscure origin IP and encrypt transmission over untrusted networks such as public Wi-Fi.

These categories are not interchangeable. A remote-access VPN authenticates individual users and applies organizational access policies; a consumer VPN does not provide access to protected organizational resources and carries no enterprise authentication layer.

Regulatory frameworks reference VPN use in multiple contexts. The NIST SP 800-77 Rev 1, "Guide to IPsec VPNs," provides federal technical guidance on configuration and key management. Under the Federal Information Security Modernization Act (FISMA), federal agencies are required to enforce encrypted remote access, with NIST guidance providing the technical baseline.

How it works

A VPN operates by encapsulating data packets inside an encrypted wrapper before transmission, using one of several established tunneling protocols. The receiving endpoint (VPN server or gateway) decrypts the payload and forwards traffic to its intended destination. The process involves four discrete phases:

Authentication — The client and server verify each other's identity, typically via certificates, pre-shared keys, or multi-factor credentials.
Tunnel establishment — A handshake negotiates encryption algorithms and session keys. Common protocols include IKEv2/IPsec, OpenVPN, WireGuard, and SSL/TLS-based solutions.
Encapsulation — Traffic is wrapped in the chosen protocol's packet structure, hiding the original payload and source metadata from intermediate network nodes.
Transmission and decryption — Packets traverse the public network as ciphertext and are decrypted at the destination endpoint, then forwarded to the target resource.

The dominant protocols carry distinct performance and security profiles. WireGuard uses approximately 4,000 lines of code — significantly fewer than OpenVPN's codebase — which reduces its attack surface and simplifies security auditing, as documented in published protocol analysis (WireGuard technical paper, Jason A. Donenfeld). IPsec operates at the network layer (Layer 3), while SSL/TLS-based VPNs operate at the transport or application layer, making the latter compatible with environments that block non-HTTP protocols.

Split tunneling is a configuration option that routes only designated traffic through the encrypted tunnel while allowing other traffic to use the local internet connection directly. This reduces bandwidth load on organizational gateways but introduces risk if sensitive traffic is misrouted. The NIST SP 800-113, "Guide to SSL VPNs," addresses split tunneling risks within enterprise deployments.

Common scenarios

VPN deployment scenarios are organized by the security objective they serve rather than by industry vertical, though regulatory obligations in specific sectors shape configuration requirements.

Enterprise remote access — Organizations deploy remote-access VPNs to enforce perimeter-equivalent security controls for off-site employees. Under the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 CFR §164.312), covered entities must implement transmission security controls, which VPN encryption satisfies for remotely accessed electronic protected health information (ePHI).

Public network exposure — Devices connecting to uncontrolled Wi-Fi networks (airports, hotels, conference venues) are exposed to passive interception and man-in-the-middle attacks. A VPN on such connections encrypts all traffic before it touches the local network infrastructure.

Cross-border data transmission — Organizations operating across national boundaries use VPNs to maintain data confidentiality in transit. This is relevant to compliance with the European Union's General Data Protection Regulation (GDPR) Article 32, which mandates appropriate technical measures for data security during transfer.

Site-to-site network integration — Enterprises with distributed physical locations use site-to-site VPNs to maintain a unified internal network without leasing dedicated private circuits. This configuration is common in financial services, healthcare systems, and multi-campus government agencies.

Controlled access to geographically restricted resources — Researchers and journalists in jurisdictions with restricted network access use VPNs to reach otherwise blocked resources, a use case documented in press freedom literature from the Committee to Protect Journalists.

The Digital Security Authority's directory purpose and scope page outlines how security technology categories, including network privacy tools, are classified within this reference framework.

Decision boundaries

VPN technology is a network-layer control, not a comprehensive security solution. Its applicability depends on the threat model, regulatory requirement, and architectural context.

VPN is appropriate when:
- The threat is transmission interception on untrusted network infrastructure
- Regulatory frameworks require encrypted remote access (FISMA, HIPAA, PCI DSS Requirement 4)
- An organization needs to extend a private network topology across geographically distributed sites
- User identity and access policy enforcement must accompany remote connectivity

VPN is not a substitute for:
- Endpoint security controls — A VPN does not protect a device compromised before the tunnel is established
- Zero Trust Architecture (ZTA) — NIST SP 800-207 defines Zero Trust as a paradigm that eliminates implicit trust within a network perimeter; VPN alone preserves perimeter assumptions that ZTA is designed to eliminate
- Application-layer security — Encrypted tunnels carry whatever application-layer vulnerabilities exist in transmitted traffic
- Identity and access management (IAM) — VPN authentication is a single gate; it does not replace role-based access control or privileged access management within the destination network

The comparison between traditional VPN and Zero Trust Network Access (ZTNA) is a central architectural decision point as of NIST SP 800-207's publication in 2020. VPN grants access to a network segment; ZTNA grants access to specific applications after continuous identity verification, reducing lateral movement risk if credentials are compromised. Organizations subject to CISA's Zero Trust Maturity Model guidance are advised to assess whether VPN-centric architectures align with their migration roadmap toward ZTA.

For organizations evaluating network security service providers, the how to use this digital security resource page describes how professional categories and service listings are structured within this directory.

References

📜 3 regulatory citations referenced · 🔍 Monitored by ANA Regulatory Watch · View update log