Should organisations replace VPNs with an identity-aware proxy for all access?

Why This Matters for Security Teams

An identity-aware proxy can be a strong control for web applications, but it is not a universal replacement for VPNs. The core question is not tunnel versus proxy, but whether the access control reaches the actual resource boundary and can enforce least privilege, session visibility, and revocation. For NHIs, that distinction matters because secrets, service accounts, and automation often outlive the session that created them, which is why the NHI Mgmt Group’s Ultimate Guide to NHIs highlights how widespread exposed credentials and excessive privilege remain across enterprises. OWASP also treats identity and secret handling as a distinct risk area in the OWASP Non-Human Identity Top 10. The practical issue is that many resources are not HTTP apps at all, so a proxy may improve user experience while leaving databases, clusters, and admin channels weakly governed. In practice, many security teams discover the gap only after a proxy rollout has hidden the real privilege model rather than replacing it.

How It Works in Practice

A better pattern is to classify access by resource type, then choose the narrowest control that still reaches the boundary. Identity-aware proxies work well when the target is a browser-based app, an internal SaaS front end, or a service that can authenticate with standard web tokens. They can provide central policy, device checks, and session logging without exposing the app directly to the network. That aligns with current guidance in the OWASP Non-Human Identity Top 10, which emphasizes eliminating broad standing access and reducing secret sprawl. For non-web resources, the design changes:

• Databases usually need native auth, short-lived credentials, and query-level auditing rather than a generic proxy alone.
• Kubernetes often needs workload identity, RBAC, and admission controls, because a proxy does not govern pod-to-pod trust or cluster API actions.
• Servers and bastions need privileged session control, command logging, and just-in-time elevation, not only a login front door.
• Secrets should be hidden from users and workloads wherever possible, with rotation and revocation tied to lifecycle events.

The NHI Mgmt Group’s Top 10 NHI Issues is useful here because it frames the operational failure modes that appear when access is extended faster than governance can keep up. For example, a proxy can front a console, but it cannot by itself fix an over-privileged service account or a long-lived token embedded in automation. These controls tend to break down when legacy protocols, direct TCP access, or multi-hop administrative workflows bypass the proxy and still expose the underlying resource.

Common Variations and Edge Cases

Tighter proxy-based access often increases operational overhead, requiring organisations to balance simpler user access against deeper control coverage. That tradeoff is real: replacing VPNs everywhere can reduce network exposure, but it can also create blind spots if teams assume the proxy is now the security boundary for all systems. Current guidance suggests treating proxy adoption as one layer in a broader ZTNA and NHI strategy, not as a universal substitute for network access. Two edge cases matter most. First, partner and contractor access to a small set of browser apps is a good proxy fit when the business need is narrow and revocation must be immediate. Second, machine-to-machine access is usually not a proxy-first problem at all; it is a workload identity and secret lifecycle problem. The NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows why exposure, rotation gaps, and privilege creep compound over time, especially when access decisions are decoupled from the resource itself. For deeper operational context, the 52 NHI Breaches Analysis is a reminder that identity compromise rarely stops at the first entry point. The practical boundary is simple: if the control cannot authenticate, authorise, and audit the actual resource action, it is not a full replacement for VPN access.

Related resources from NHI Mgmt Group

• What should organisations do when agent access keeps expanding during pilots?
• When should organisations re-evaluate database access controls for AI workloads?
• What do organisations get wrong about crypto agility in identity systems?
• Should organisations replace point DLP tools with an orchestration layer?