Why do VPNs make third-party access harder to govern?

Why VPN-Based Third-Party Access Becomes Hard to Govern

VPNs are built to extend network reach, but third-party access is a governance problem, not just a connectivity problem. Once a vendor lands on the internal network, security teams often lose the clean separation needed to prove who accessed what, for how long, and under which business approval. That creates weak audit trails, broader blast radius, and inconsistent offboarding. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes this a recurring supply chain issue rather than an edge case.

The core issue is that VPNs often inherit employee-style trust assumptions for external users who should have narrower, task-bound access. That clashes with least privilege, Zero Trust, and the need for fast revocation when a contract ends or a support window closes. The NIST Cybersecurity Framework 2.0 pushes organisations toward tighter identity governance and access accountability, but a flat VPN model makes that difficult to implement cleanly. In practice, many security teams discover third-party overreach only after access has already been used for something broader than the original ticket.

How VPNs Undermine Least Privilege and Revocation

VPN access tends to start at the wrong layer: network membership instead of task-specific entitlement. A vendor who authenticates into the tunnel may gain visibility into multiple systems, then rely on secondary controls to stay constrained. That works only if every internal application, subnet, and admin path is already segmented and logged with precision, which is rarely true in legacy environments.

Governance gets harder because the VPN session is usually longer-lived than the business task. Credentials, device posture, and session state may remain valid even when the work is complete. That is where NHI lifecycle controls matter. The Lifecycle Processes for Managing NHIs guidance is useful here because it frames access as something to issue, monitor, rotate, and revoke, not simply permit.

• Use task-bound access windows instead of standing network access.
• Restrict vendors to specific apps, hosts, or jump services rather than full subnet reach.
• Log the business justification, approver, and expiration time for each access grant.
• Revoke connectivity automatically when the change ticket, incident, or maintenance window closes.

For network access to be governable, organisations also need policy enforcement at the point of request. The OWASP Non-Human Identity Top 10 highlights the risk of over-privileged, poorly rotated identities, and VPNs often make those failures harder to detect because the access path looks “normal” at the network layer. These controls tend to break down when vendors use shared credentials, unmanaged devices, or broad subnet access because attribution and revocation become ambiguous.

Common Exceptions, Tradeoffs, and Better Patterns

Tighter third-party access often increases operational overhead, requiring organisations to balance faster vendor support against stronger control and auditability. That tradeoff is real, especially when suppliers need urgent access during incidents or when legacy applications cannot support modern application-level authorization.

There is no universal standard for this yet, but current guidance suggests replacing broad VPN reach with narrower patterns: per-application access, privileged access workflows, brokered jump hosts, and short-lived credentials. NHI Mgmt Group’s 52 NHI Breaches Analysis and the Key Challenges and Risks section both underscore that visibility and rotation gaps are what turn convenient access into lasting exposure.

Exceptions do exist. A tightly segmented VPN may still be acceptable for a small number of highly controlled administrative workflows, but only if it is paired with strong MFA, device checks, session recording, and rapid deprovisioning. For most third-party use cases, however, the governance model is clearer when access is tied to the resource and the task rather than to the network. That is the difference between proving a vendor was allowed to do one thing and merely proving they were on the tunnel.

Related resources from NHI Mgmt Group

• How should organisations govern third-party access in continuous monitoring programmes?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern third-party AI agents that use OAuth access?