Who is accountable when privileged access spans VPNs, bastions, and identity-based tooling?

Why This Matters for Security Teams

When privileged access spans VPNs, bastions, and identity-based tooling, the real risk is not the path itself but the lack of a single owner for the session lifecycle. Accountability has to follow the policy and the identity controls that define who can do what, when, and under which conditions. NHI Management Group’s Ultimate Guide to NHIs shows how often governance gaps persist when secrets, service accounts, and access paths are managed in fragments rather than as one control plane.

Practitioners should also separate tool administration from access governance. A VPN team can manage tunnels, a bastion team can manage jump hosts, and an IAM team can manage identity assertions, but none of those functions alone owns the end-to-end privilege decision. OWASP’s OWASP Non-Human Identity Top 10 treats poor lifecycle control and over-privilege as core risks, because fragmented custody is where audit trails, approvals, and revocation usually fail.

In practice, many security teams discover that accountability was undefined only after a dormant account, shared credential, or delayed offboarding has already been used to move through multiple access layers.

How It Works in Practice

Accountability should be assigned to the team that owns the access policy, the approval workflow, and the lifecycle enforcement for the privileged session. That usually means one accountable control owner, even if several platforms are involved. The team responsible for identity governance must ensure the request, issuance, step-up verification, logging, and revocation chain are coherent across VPNs, bastions, and identity-based tooling.

In operational terms, that means the answer is not “the bastion admin” or “the VPN operator” by default. The accountable group defines whether access is human, service, or agent-driven, and then maps the control points to those identities. For NHI-heavy environments, the Ultimate Guide to NHIs — Key Challenges and Risks is useful because it frames the common failure modes: excessive privilege, poor rotation, and weak offboarding. NHI Mgmt Group also notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why lifecycle ownership matters as much as technical access enforcement.

Good practice is to make the accountable team answerable for all of the following:

• Policy definition for who can request privileged access and under what conditions
• Workflow ownership for approvals, time limits, and escalation paths
• Identity binding across VPN, bastion, and downstream systems
• Session logging and evidence retention for audit and incident response
• Revocation and offboarding when the task, user, or service changes

Where possible, use a single policy layer to unify decisions across tools instead of treating each hop as an independent exception. That is consistent with zero trust guidance and with NIST’s view that access decisions should be continuously evaluated, not assumed after initial authentication. These controls tend to break down when legacy operations require shared accounts and manual jump-host approvals because no single system can reliably enforce or revoke the full session lifecycle.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance strong accountability against the reality of legacy estates and emergency support needs.

There is no universal standard for every environment, but the accountability model should change based on how privilege is granted. For human admin access, the owner is usually the privileged access policy team working with IAM and infrastructure operations. For machine-to-machine access, the accountable team is often the workload owner, because secrets, tokens, and certificates need lifecycle controls that match the application. For autonomous or agentic systems, current guidance suggests the accountability must include runtime authorisation and short-lived credential issuance, not just static role assignment.

Edge cases arise when VPN, bastion, and identity tooling are split across different departments or vendors. In those environments, governance often fails at the seams, so clear RACI ownership becomes essential. The best control is not necessarily the most centralised one, but the one that can prove who approved access, what identity was used, and when the privilege ended. NHI Mgmt Group’s broader research, including the 52 NHI Breaches Analysis, shows how often gaps in ownership become gaps in detection and recovery.

When incident response, platform engineering, and security operations all believe another team owns revocation, accountability becomes symbolic instead of enforceable.

Related resources from NHI Mgmt Group

• Who is accountable when risky identity access persists across reviews?
• Which frameworks apply to multi-cloud identity governance and privileged access?
• What breaks when privileged access depends on the same identity fabric that has been compromised?
• What is the difference between role-based access and API key governance for NHI security?