Virtual Private Network

Expanded Definition

A virtual private network, or VPN, creates an encrypted path over an untrusted transport so traffic can move between a user device and a private network, or between two networks, with reduced exposure to interception. In NHI security, that transport layer matters, but it is only one part of the control stack. A VPN does not automatically define which application, workload, or service account should be trusted, nor does it enforce the segmentation, continuous verification, or device posture checks associated with modern access models. That distinction is important because identity-led controls increasingly sit beside the tunnel rather than inside it, especially in NIST SP 800-207 Zero Trust Architecture programs where trust is evaluated per request. Definitions vary across vendors when VPNs are folded into broader secure access offerings, so the term should be read narrowly unless the architecture explicitly adds policy enforcement and identity context. NHI Management Group treats VPN as a transport control, not an identity control. The most common misapplication is treating VPN connectivity as proof of authorization, which occurs when organisations assume network entry alone validates the caller, the workload, or the secret being used.

Examples and Use Cases

Implementing a VPN rigorously often introduces operational friction, requiring organisations to weigh simpler remote connectivity against stricter identity and routing controls.

• Remote administrators connect to an internal management plane through a VPN, but still require privileged access management and separate authorization before touching production systems.
• Two data centres establish a site-to-site VPN for encrypted transport, while application-layer segmentation handles which services may exchange traffic.
• A vendor reaches an internal support portal over VPN, yet the organisation still limits access by device posture, role, and time window because network presence alone is not sufficient.
• Service-to-service traffic in a migration phase uses VPN tunnels as a temporary bridge, while the long-term target is workload identity and direct trust assertions.
• For broader NHI governance context, the Ultimate Guide to NHIs shows why transport controls must be paired with credential lifecycle management and visibility into service accounts.
• Standards guidance for zero trust can be paired with tunnel usage by following NIST SP 800-207 Zero Trust Architecture so the VPN becomes one component of a larger policy system rather than the policy itself.

Why It Matters in NHI Security

VPNs often appear in NHI incidents as a compensating control that was assumed to be enough. That assumption fails when secrets are reused, service accounts are over-privileged, or an attacker obtains valid credentials and simply rides an encrypted tunnel into a trusted segment. NHI Management Group research shows that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which means transport security alone does not meaningfully reduce the blast radius of identity abuse. The same theme appears in the Ultimate Guide to NHIs, where weak visibility and poor offboarding repeatedly show up as root causes rather than network exposure by itself. For governance teams, the practical issue is that a VPN can hide bad identity hygiene behind a successful connection. Organisations typically encounter this consequence only after a privileged session is abused or a service credential is replayed, at which point VPN access becomes operationally unavoidable to review and contain.

Related resources from NHI Mgmt Group

• Why do virtual private clouds matter for NHI governance?
• Virtual Private Cloud
• Why has identity replaced the network perimeter as the primary security boundary?
• Why are identity-based attacks growing faster than traditional network attacks?