TL;DR: VPNs were designed for a network-centric world, but modern remote work now depends on cloud apps, SaaS, and hosted systems, so broad tunnel access can expose far more than users need, according to CyberFOX. SASE shifts access to preapproved applications and services, narrowing blast radius and aligning remote access with least privilege.
At a glance
What this is: This is an analysis of why VPN-centric remote access creates excess exposure and why SASE changes the access model by limiting users to approved applications and services.
Why it matters: IAM and security teams should treat remote access as an entitlement problem, because broad tunnels can turn one compromised credential into network-wide reach across cloud, SaaS, and hosted systems.
Context
VPNs were built for a network-centric era, when remote users needed access to an internal environment that contained most applications and files. That model breaks down in cloud-first environments where access should be scoped to specific services, data sets, and third-party connections rather than the whole network.
The identity angle is straightforward: a remote access control is only as safe as the privileges it grants after authentication. When broad tunnels remain in place, least privilege becomes harder to enforce, and one compromised account can move from an access problem into a lateral movement problem.
For MSPs and IT teams, the issue is not remote access itself but the mismatch between legacy tunnel design and modern application placement. The article reflects a common and still typical pattern in many organisations that have not fully re-architected remote access for cloud and SaaS use.
Key questions
Q: How should security teams reduce risk when remote users still need broad application access?
A: Scope access to the specific applications and services a role needs, then enforce that policy at session creation rather than at network entry. That keeps a compromised credential from becoming a general-purpose foothold and makes remote access easier to review, revoke, and separate by user type.
Q: Why do vpn tunnels create lateral movement risk in cloud-first environments?
A: Because a tunnel often places the user inside a broader trusted network than the task requires. If the credential is stolen, the attacker inherits reach beyond a single application and can pivot toward other internal systems unless segmentation and application-level policy are already in place.
Q: What are the signs that remote access controls are too broad for sensitive internal systems?
A: Remote access is too broad when users can reach more systems, files, or functions than their job requires, especially if clipboard, file transfer, or unrestricted shell access is left open by default. Another warning sign is access that stays active after role changes. If sessions are not restricted, recorded, or tied to specific targets, the control boundary is already too loose.
Q: What should organisations do when contractors need temporary access to internal systems?
A: Treat contractor access as a separately governed entitlement with narrower scope, explicit expiry, and destination-level logging. External users usually need task-specific reach, not general network presence, so their access should be easier to isolate and remove than employee access.
Technical breakdown
Why vpn tunnels create excess access in cloud-first environments
A VPN extends a user session into a broader network segment, then relies on downstream segmentation to stop unnecessary reach. In practice, that means the access decision happens too early and too broadly, before the system knows which application, service, or data set the user actually needs. In cloud and SaaS-heavy environments, that design conflicts with modern identity-centric control, because authentication should lead to narrowly scoped authorisation rather than network-wide visibility. The result is not just convenience risk. It is a trust boundary problem.
Practical implication: move access decisions from network entry to application-level policy enforcement.
How SASE and ztna change the remote access trust model
SASE combines secure access controls with cloud-delivered enforcement, while ZTNA is the access method that restricts a user to approved applications. The key architectural shift is that the user no longer lands inside an implicit trusted network. Instead, each request is evaluated against policy, device context, and user identity before a connection is granted. That reduces the chance that a stolen credential becomes a network foothold. It also makes access review more meaningful, because the entitlement is tied to specific services rather than a general tunnel.
Practical implication: define application-level policies and verify that each remote session maps to a specific approved service.
Why least privilege and auditability matter for remote access governance
Least privilege is not only a principle for admin accounts. In remote access, it is the control that decides whether users can reach only the systems needed for their role or an entire environment they should never see. Better controls also leave an audit trail of who connected to what, which helps teams support compliance and investigation. This matters for third-party access as well, because vendors and contractors often need short, task-specific reach rather than ongoing broad connectivity. The governance task is to make access narrow, reviewable, and revocable.
Practical implication: pair access policy with logs that show which user reached which application, and review contractor access separately.
Threat narrative
Attacker objective: The attacker wants to turn a single compromised remote access credential into broad internal reach, then pivot to sensitive data and critical systems.
- Entry occurs when a user authenticates through a VPN and is placed into a broader network than the task requires.
- Credential abuse then turns one stolen username and password into a foothold that can reach multiple internal services.
- Escalation follows when the attacker moves laterally from that foothold to higher-value applications and sensitive data.
- Impact is the exposure of business-critical systems and information that were never meant to be reachable from that session.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
- Poland ArcGIS password leak 2023: An ArcGIS login emailed in 2020 was published from stolen mail in 2023 and still worked, exposing Polish military and infrastructure maps.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Remote access is becoming an entitlement problem, not a connectivity problem. The article’s core logic is that network tunnels were designed for a world where the network itself was the trust boundary. Cloud applications, SaaS services, and hosted systems invert that model, so the real control question is which applications a user may reach after authentication. For IAM and PAM teams, that means remote access policy must be managed like any other high-risk entitlement.
Least privilege now needs to be enforced at the point of session creation. A user who is broadly placed into the network after login can still overreach even when authentication is strong. The practical failure mode is not weak login alone but excess post-authentication access scope. That makes the access policy layer, not the tunnel technology, the decisive control point.
SASE creates a named governance pattern: application-scoped remote access. That concept matters because it shifts the audit question from 'who got onto the network' to 'who reached which service and why'. In identity programmes, that is a better fit for contractor access, third-party support, and distributed workforces. Practitioners should treat the model as a control architecture, not a product category.
Auditability becomes stronger when remote access is service-specific. Security and compliance teams need logs that show entitlement, destination, and session context, not just a binary connected or disconnected state. This is especially relevant where least privilege expectations are already embedded in regulatory and governance reviews. The programme implication is simple: if the access path cannot be scoped and evidenced, it is too broad.
Remote access sprawl is now part of the identity governance surface. The article points to a broader market shift in which access architecture, identity policy, and third-party governance converge. That means organisations cannot separate network control from identity control anymore. The practical conclusion is to align remote access with the same lifecycle discipline used for privileged access and third-party accounts.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Remote Access Identity Guide
What this signals
Application-scoped remote access is becoming the practical replacement for broad tunnels. The control objective is no longer to get users onto the network, but to prove they can only reach the service required for the task. That shift makes identity policy, device context, and session logging part of the same governance model.
Least privilege for remote work is now an entitlement design problem. If a VPN still exposes unrelated systems after authentication, the organisation is relying on network location to carry a trust decision it should have made at the application layer. That mismatch is where many remote access programmes still leak risk.
43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. The same governance instinct applies here: broad access paths make it harder to contain where sensitive information can travel once a session is established.
For practitioners
- Replace network-wide VPN entitlements with application-scoped access Limit each remote user or contractor to the specific cloud apps, SaaS services, and hosted systems required for the role.
- Map contractor and vendor access separately Create distinct policies for third-party access so external support cannot inherit broader internal reach than employees need.
- Log destination-level access for audit review Record which user reached which application, along with policy context, so reviews can prove least privilege rather than assume it.
- Review credentials that still unlock broad remote access Identify remote access accounts that can still pivot into multiple internal systems and retire them from overly permissive tunnel designs.
- Align remote access with zero trust policy Require identity and device checks before each session reaches a preapproved resource, instead of trusting the network after one login.
Key takeaways
- VPN-based remote access remains too broad for cloud-first work because one authenticated session can still expose systems far beyond the user’s role.
- SASE changes the control point from network entry to approved applications, which reduces blast radius and makes access reviews more meaningful.
- Identity teams should treat remote access as a lifecycle governance issue, with separate policies for employees, contractors, and vendors.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article is fundamentally about limiting session scope to the minimum required access. |
| Recommendation — Enforce least privilege so remote users only reach the applications their role requires. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | SASE is presented as a zero trust-aligned alternative to implicit VPN trust. |
| Recommendation — Apply zero trust principles to verify each remote request before granting access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on overbroad entitlements after authentication. |
| Recommendation — Restrict remote entitlements to approved applications and services. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article highlights how a compromised credential can become a lateral movement path. |
| Recommendation — Map VPN credential abuse paths to TA0006 and TA0008 during threat hunting. | ||
Key terms
- Virtual Private Network: A virtual private network creates an encrypted tunnel between a device and a network, or between two networks, over an untrusted transport. It protects data in transit, but it does not by itself provide the full policy, routing, or segmentation controls that larger access programmes often need.
- Secure Access Service Edge: SASE is a converged architecture that combines network connectivity with security controls such as zero trust access, secure web gateway, and firewall services. It is useful for consistent enforcement across distributed environments, but it does not replace identity governance or entitlement ownership.
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management with practical guidance for modern access control. It helps identity and security practitioners connect remote access decisions to broader identity governance.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org