Who should own the decision to move from VPN-based access to identity-based access?

IAM, security architecture, and compliance teams should own it together because the decision affects authorization design, logging quality, and access review evidence. The trigger is usually not a single feature gap but the point where auditability and least privilege no longer hold under the current VPN model.

Why This Matters for Security Teams

Moving from VPN-based access to identity-based access is not just a network change. It shifts the control plane from “where the traffic came from” to “who or what is requesting access, under what context, and for how long.” That affects access reviews, audit evidence, incident response, and the division of responsibility between IAM, security architecture, and compliance. NHI Management Group notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation in the Ultimate Guide to NHIs.

Teams often get stuck because VPN controls feel familiar and “good enough” until auditors ask for least-privilege proof or a compromised endpoint turns the network boundary into a weak proxy for trust. Identity-based access changes the evidence model: logs must show authenticated identity, granted scope, policy decision, and session duration, not just source IP. That is why ownership cannot sit with a single team. It requires IAM to define identity and authorization mechanics, security architecture to set the target pattern, and compliance to validate that the new model improves control effectiveness over the old one. The underlying risk is reinforced in the Top 10 NHI Issues and in OWASP’s OWASP Non-Human Identity Top 10.

In practice, many security teams encounter the ownership debate only after audit exceptions, sprawl, or a VPN exception has already become the default access path.

How It Works in Practice

The decision should be owned as a shared governance change, but with clear roles. IAM usually leads the identity model, security architecture defines the target trust pattern, and compliance validates that the controls produce defensible evidence. The practical shift is from coarse network admission to identity-centric authorization supported by policy, logging, and lifecycle management. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps access control, audit logging, and system monitoring requirements that must still hold when VPN is removed from the trust path.

For non-human identities, the move is even more explicit: access should be tied to workload identity, short-lived credentials, and policy evaluated at request time. Current guidance suggests this should include:

• Identity proof at request time, not just network location
• Least-privilege entitlements with explicit scope and expiry
• Centralized logging that captures who approved access, what was granted, and for how long
• Lifecycle controls for issuance, rotation, revocation, and offboarding
• Policy-as-code so access decisions can be reviewed and tested

That operational pattern aligns with NHI governance research in the Ultimate Guide to NHIs, especially where excessive privilege and weak visibility undermine legacy access models. It also aligns with the direction set by the OWASP Non-Human Identity Top 10, which treats secret hygiene, privilege scope, and lifecycle enforcement as primary control points.

These controls tend to break down when legacy applications still depend on IP allowlists or when service accounts are reused across multiple environments, because identity-based policy becomes too coarse to separate trust domains cleanly.

Common Variations and Edge Cases

Tighter identity-based control often increases operational overhead, requiring organisations to balance stronger auditability against migration complexity and application compatibility. That tradeoff is especially visible in hybrid environments, where some workloads can move to identity-based access quickly while others remain tied to VPN tunnels, private networks, or vendor constraints.

There is no universal standard for this yet, but current guidance suggests treating the decision as a phased architecture program rather than a single switch. For high-risk admin access, identity-based access usually delivers the fastest security gain. For brittle legacy systems, a temporary VPN exception may remain necessary while logging, segmentation, and authentication are modernized. The key is to avoid letting “temporary” become a permanent control.

For non-human identities, another edge case is machine-to-machine access across automation pipelines. A VPN can hide the true requester and make access reviews meaningless, while identity-based access can expose the actual workload, but only if the organisation issues short-lived credentials and maintains per-workload attribution. The 52 NHI Breaches Analysis shows why that visibility matters when secrets or service accounts are abused in ways traditional perimeter tools miss.

In short, the ownership decision should stay with IAM, security architecture, and compliance together, because the real question is whether the target access model can produce provable least privilege without losing operational control.

Related resources from NHI Mgmt Group

• Who should own the move from legacy PAM to identity-driven access?
• How should security teams replace VPN access with identity-based controls?
• Who is accountable when identity-based attacks move through trusted access paths?
• How should security teams decide whether JIT access is safe for non-human identities?