Who is accountable when third-party or service access is still routed through a VPN?

Why This Matters for Security Teams

When third-party or service access still rides through a VPN, accountability often gets blurred between network operations, identity owners, and the business team that approved the relationship. The real issue is not the tunnel itself, but whether someone owns the full lifecycle of that access: approval, scope, monitoring, and revocation. NHI Mgmt Group notes that only 20% of organisations have formal offboarding and API key revocation processes in place, a sign that access often outlives the work it was meant to support, as discussed in the Ultimate Guide to NHIs.

That matters because VPN routing can create a false sense of control. A vendor account inside the network may still have broad reach, long-lived secrets, and no task-bound expiration, which is exactly how service access becomes difficult to trace and even harder to remove. Current guidance from the OWASP Non-Human Identity Top 10 treats this as an identity governance problem, not a network perimeter problem. In practice, many security teams discover the accountability gap only after a vendor engagement ends and access is still active.

How It Works in Practice

Accountability should follow the team that owns the access path lifecycle, which usually means the application owner or service owner, with security and network teams acting as control enablers. The VPN team may operate the tunnel, but it does not own whether a third party should still be connected, what systems they can reach, or whether the credential should still exist. For non-human access, the identity must be governed as a workload or service identity, not as a generic remote user.

In practical terms, this means the accountable owner must be able to answer four questions at any time: who approved the access, what system or secret grants it, when it expires, and how revocation is verified. That aligns with the governance emphasis in the 52 NHI Breaches Analysis, where compromised or excessive access repeatedly appears as a lifecycle failure. The OWASP Non-Human Identity Top 10 is consistent on this point: visibility, rotation, and offboarding are identity controls, not optional hygiene.

• Assign a named business or application owner for each vendor or service path.
• Track VPN access as one component of the access chain, not the control owner.
• Use short-lived credentials or session boundaries where possible, so access can end automatically.
• Log approval, use, and revocation events in the same audit trail.
• Validate that offboarding actually removes the credential, not just the VPN route.

This guidance tends to break down in legacy environments where shared accounts, static VPN profiles, and undocumented integrations make it impossible to tie access to a single accountable owner.

Common Variations and Edge Cases

Tighter control over third-party VPN access often increases operational overhead, so organisations have to balance speed for vendors against traceable ownership and revocation discipline. There is no universal standard for this yet, but current guidance suggests that if a VPN is only the transport layer, then the accountable owner still sits with whoever authorised and can revoke the underlying identity.

Edge cases usually appear when service accounts are reused across multiple teams, when a contractor is onboarded through procurement but technically managed by infrastructure, or when an external support channel uses the same VPN pool as internal admins. In those cases, the right answer is not to debate who owns the network appliance. The right answer is to document who owns the entitlement, who approves exceptions, and who signs off on offboarding. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights that hidden or poorly governed service identities are a recurring source of exposure.

When organisations move toward Zero Trust, this accountability becomes more explicit because access should be continuously evaluated rather than assumed safe once the VPN connects. The important distinction is simple: the network team runs the tunnel, but the service owner remains accountable for whether the access should exist at all.

Related resources from NHI Mgmt Group

• Why do third-party access paths create so much NYDFS compliance risk?
• Who is accountable when an attacker reuses valid access to move through systems?
• How should organisations govern third-party access in regulated environments?
• Who is accountable when healthcare data is exposed through weak access governance?