How should organisations decide between VPNs and application-level access controls?

Organisations should prefer application-level access controls when the goal is to limit who can reach specific resources without exposing the whole network. VPNs can still have a role for legacy systems or secure transport, but they should not be the only control. The best design is usually narrow access, strong identity checks, and minimal network exposure.

Why This Matters for Security Teams

The VPN versus application-level question is really a question about blast radius. A VPN expands network reach and often assumes trust once a tunnel is established, while application-level controls can restrict access to a specific service, action, or dataset. That difference matters because modern attacks rarely stay at the edge. When secrets are exposed or identities are over-permissioned, broad network access turns one compromise into many.

For non-human identities, the risk is even sharper. NHIs are frequently overprivileged and poorly rotated, and NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in its Ultimate Guide to NHIs. In practice, a VPN can mask weak internal segmentation rather than solve it. Security teams should think in terms of explicit authorization, not just private transport. The OWASP Non-Human Identity Top 10 reinforces that identity and secret sprawl are core exposure points, not side issues.

In practice, many security teams encounter lateral movement and service abuse only after a credential has already been used successfully inside the network, rather than through intentional access design.

How It Works in Practice

The most effective pattern is to use the network for transport and the application for authorization. VPNs can still help when a system is legacy, an admin path must be isolated, or transport encryption is needed across untrusted links. But the application should decide what the identity can do once it arrives. That means checking user or workload identity, group membership, device posture, request context, and the specific resource being requested.

For NHIs, this usually means replacing standing network reach with workload-specific access. In the NHI lifecycle, credentials should be short-lived, scoped to one service or task, and revoked automatically when the task ends. That reduces the value of stolen secrets and makes access reviews more meaningful. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it ties overexposure and poor rotation to real compromise paths.

• Use a VPN only for transport or legacy containment, not as the main authorization layer.
• Enforce least privilege at the application, API gateway, or service mesh.
• Issue short-lived secrets or tokens tied to a workload or session.
• Log every request with identity, resource, and decision context.
• Review access at the application boundary, not just at the network perimeter.

This aligns with the direction in PCI DSS v4.0, which emphasizes reducing unnecessary access paths and tightening authentication around sensitive systems. These controls tend to break down when the application cannot make fine-grained decisions, such as with monolithic legacy services that only understand network source IPs.

Common Variations and Edge Cases

Tighter application-level control often increases implementation overhead, requiring organisations to balance security gains against engineering and integration cost. That tradeoff is real, especially when identity-aware proxies, API gateways, or policy engines must be inserted into older environments.

There is no universal standard for every environment yet. Some teams still need VPNs for remote administration, vendor support, or systems that cannot natively enforce modern authorization. In those cases, best practice is evolving toward layered control: VPN for reachability, then strong authentication, MFA where applicable, and app-level authorization for every sensitive action. For service-to-service traffic, use workload identity and short-lived credentials instead of relying on an internal tunnel as proof of trust.

One practical test is simple: if a breach of the VPN account would expose far more resources than the person or workload legitimately needs, the design is too broad. The safer model is narrow network exposure plus explicit access to the exact resource. NHI Mgmt Group’s Ultimate Guide to NHIs — Standards is a useful reference for mapping that approach to governance expectations.

In environments with flat internal networks, unmanaged service accounts, or shared admin tunnels, even a well-configured VPN can become a convenience layer for attackers rather than a meaningful security boundary.

Related resources from NHI Mgmt Group

• How do organisations decide between DNSSEC and failover controls?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• How should organisations prioritise GRC controls when starting application access governance?