What breaks when organisations rely on VPNs for modern remote access?

Why This Matters for Security Teams

VPNs were built to extend trusted network access, not to support session-level, application-specific access in a cloud-first environment. That difference matters because modern work often combines personal devices, SaaS applications, contractors, and automated workflows. Once a VPN connection is established, the access boundary is usually much wider than the task requires, which increases lateral movement risk and complicates conditional access decisions.

Security teams also run into identity blind spots. A VPN can verify that a tunnel exists, but it does not prove the device is healthy, the session is low risk, or the action is appropriate for the user’s current context. That is why many organisations pair remote access redesign with control mapping to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement, logging, and least privilege need to be explicit rather than assumed.

In practice, many security teams encounter VPN overreach only after a compromised account or unmanaged device has already been used to move beyond the original remote access use case, rather than through intentional access scoping.

How It Works in Practice

Modern remote access should be designed around the application, the session, and the identity signal, not the whole network. Browser-mediated access is one common pattern because it allows the organisation to expose only the specific application or workflow required, while keeping the broader environment segmented. That reduces the value of a stolen credential and makes policy decisions easier to enforce at the point of use.

In practice, the shift usually involves several control changes:

• Replace network-wide reachability with per-application access decisions.
• Require strong authentication and step-up checks when risk changes.
• Verify device posture before granting access to sensitive resources.
• Log session activity so SOC teams can detect abuse, not just connection events.
• Treat privileged access and automation separately from ordinary user access.

This is also where identity governance becomes more important than perimeter design. A VPN may connect a user, but it does not manage whether the account is appropriate for the resource, whether a privileged session should be time-bound, or whether non-human identities should be allowed to use the same access path. For that reason, many programmes align remote access redesign with identity control reviews and with guidance such as the OWASP Non-Human Identity Top 10 when service accounts, API tokens, or automation are part of the same remote workflow.

Operationally, the goal is to move from “connected equals trusted” to “each request is evaluated on its own merits.” That usually means tighter policy, more telemetry, and clearer ownership across IAM, security operations, and application teams. These controls tend to break down in flat legacy networks where old internal dependencies still assume broad subnet access because the application estate was never segmented for session-based access.

Common Variations and Edge Cases

Tighter remote access controls often increase policy complexity and user friction, requiring organisations to balance security gains against operational speed and legacy compatibility.

There is no universal standard for every environment yet. Some teams can move quickly to browser-based or zero-trust access for SaaS and internal web apps, while others still need VPNs for niche protocols, administrative tools, or systems that cannot be fronted by a modern access gateway. In those cases, the best practice is evolving toward limiting VPN use to the smallest possible set of use cases rather than treating it as the default.

Edge cases also arise where identity is not purely human. Machine-to-machine traffic, CI/CD pipelines, and agentic workflows may still traverse remote access paths during administration or support. That creates an intersection between remote access design and NHI governance, because the same tunnel that works for a person may be unsafe for long-lived secrets or over-permissioned service identities. The question is not only who connected, but what identity type was allowed to use the path and whether that path was appropriate for the risk.

In highly regulated environments, the remote access pattern should be tested against auditability, session logging, and privileged access requirements rather than convenience alone. Browser-based access is often a strong fit for routine work, but exceptions for engineering and operations need explicit approval, narrow scope, and continuous review.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on MFA and VPNs alone for contractor access?
• What breaks when organisations rely on passwords and OTPs for high-risk access?
• What breaks when organisations keep password-based remote access in place?
• What breaks when organisations rely on push notifications for sensitive access?