Why do VPN-bound access models create so much friction in modern workplaces?

Why VPN-Centric Access Feels Heavy in Cloud-First Workplaces

VPN-bound access creates friction because it treats remote access like a network problem first and an application access problem second. That model adds an extra hop, pushes more traffic through a central chokepoint, and makes users wait for full tunnel establishment before they can reach the services they actually need. It also tends to blur policy, device trust, and session context into one broad access path.

In a workplace where people move between office, home, contractor networks, and managed SaaS, the result is often a mismatch between how work happens and how access is delivered. Users experience that mismatch as latency, repeated prompts, brittle connectivity, and inconsistent reachability across applications.

Where the Friction Comes From Operationally

VPNs were designed to extend a trusted network boundary, so they often move traffic through a perimeter-era control plane that was never meant to handle every cloud session individually. When the control path assumes a stable network tunnel, it becomes harder to grant just enough access for a specific app, device state, or user session without overextending the connection.

That design also creates practical friction for IT and security teams. Access decisions become coarse, troubleshooting spans network and identity teams at once, and exceptions accumulate as the organisation tries to keep legacy VPN access working alongside SaaS, IaaS, and third-party services.

A cleaner mental model is zero trust and session-scoped access, where connectivity is not the same thing as authority. NIST SP 800-207 Zero Trust Architecture captures that shift well: verify each request, minimise standing trust, and avoid making a network tunnel carry more trust than the business need requires. For a broader remote-access perspective, Remote Access Identity Guide connects VPN friction to MFA, device posture, and replacing dormant VPN accounts with more selective access paths.

Why Users, Devices, and Applications Each Feel the Pain Differently

For users, the friction shows up as repeated authentication, slower logins, and access that feels all-or-nothing. For devices, a VPN can collapse too many trust decisions into a single network connection, which makes posture-based gating and split access harder to express cleanly. For applications, especially SaaS and cloud services, a tunnel often adds an unnecessary dependency because the service already expects direct, policy-driven access rather than inherited network reach.

The more distributed the environment, the more those drawbacks multiply. Teams working across jurisdictions, contractors, and multiple device types need access paths that can vary by application, sensitivity, and session risk. A single VPN pattern tends to flatten those differences, which is why it often feels both restrictive and oddly permissive at the same time.

That is also why authorisation design matters more than many teams expect. Authorisation Models Guide is useful here because VPN-bound access usually forces organisations to lean on broad network membership instead of finer-grained decisions about who can do what, from where, and under which conditions. When that gap matters, Just-in-Time Access and Zero Standing Privilege Guide shows the more selective pattern: grant access only when needed, for the minimum duration, and only to the target resource that actually requires it.

Risk and Threat Considerations

VPN friction is not just a usability issue. When remote access depends on long-lived network trust, organisations can end up with broader access than the task really needs, weaker visibility into individual sessions, and more incentive to create exceptions that bypass the intended control path. That widens the blast radius if credentials are stolen or a remote access gateway is abused.

Failure mechanism: A broad tunnel can turn one compromised login, one stale account, or one weakly governed remote access path into access across far more internal resources than a session-specific model would allow.

Impact: Attackers gain easier lateral movement, defenders lose precision in access governance, and the business inherits higher operational risk from outages, misrouting, and overexposed legacy connectivity.

Remote access is also a common abuse target because it concentrates trust in a small number of gateways and credentials. If those entry points are overused, under-monitored, or left dormant, they become attractive paths for initial access and persistence. SonicWall SSL VPN account compromises 2025 illustrates how valid credentials can be used at scale against VPN accounts, while MITRE ATT&CK Enterprise Matrix helps map the follow-on behaviours that often matter after that first foothold, including credential access and lateral movement.

Practitioner Guidance

What to prioritise: Treat “remote access” as an application access design problem, not a tunnel-availability problem. If a user only needs one SaaS app or one internal tool, do not force full-network reach just to satisfy the request.

What to verify: Check whether the VPN is still carrying access to applications that could be governed more cleanly through per-app policy, device posture, and short-lived sessions. If the answer is yes, the friction is likely structural, not a tuning issue.

Decision rule: If the access path cannot express least privilege without granting broad network membership, it is time to redesign the control path rather than keep optimising the tunnel.

Practitioner takeaway: The fastest remote access model is not the one with the fewest controls, it is the one that applies the right control at the right layer, so users get direct access while security keeps authority narrow and observable.

Related resources from NHI Mgmt Group

• What breaks when access controls create too much friction?
• Why do shared workstations create so much access friction in healthcare?
• Why do university access programs create so much identity friction?
• Why do SaaS environments create so much access review friction?