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.
Why VPN Tunnels Increase Lateral Movement Exposure
A VPN tunnel is not just a path to one app, it often extends a device into a trusted network segment. That means the security decision is about reach, not connectivity. In cloud-first environments, that expanded reach can be more dangerous than in a traditional office network because cloud apps, admin planes, and internal services are already split across many trust boundaries.
The risk grows when the tunnel is treated as a blanket trust grant instead of a constrained access method. If a stolen credential or session token is reused, the attacker may inherit the same internal visibility as the legitimate user, then probe adjacent systems, shared services, and management interfaces that were never needed for the original task.
Cloud-first architecture makes this worse when identity is the real control point but network access is still broad. A tunnel can bypass the intended application-level policy model by delivering network-level presence before finer-grained authorization is checked. If segmentation is weak, the tunnel becomes a pivot point rather than a simple remote access channel.
Where the Pivot Happens in Practice
The pivot usually starts with the first valid login, not with an exploit. Once inside the tunnel, an attacker can enumerate reachable hosts, discover internal DNS names, test service ports, or target management consoles that were assumed to be hidden behind the perimeter. If the environment mixes employee access, third-party access, and administrative paths, one compromised tunnel can expose multiple trust zones at once.
This is why remote access designs need to be evaluated by blast radius. A tunnel that is acceptable for a tightly scoped support workflow may be unsafe for a cloud operations team if it also reaches identity providers, build systems, secret stores, or management APIs. Remote Access Identity Guide is useful here because it frames VPN use alongside MFA, ZTNA, device posture, and dormant account retirement.
Real breaches show the pattern clearly. Stolen credentials have been used to turn VPN access into broader internal reach, and once attackers get that foothold they tend to move toward higher-value systems, credentials, and control planes. SonicWall SSL VPN account compromises 2025 illustrates how valid logins can become a starting point for mass access abuse, while CitrixBleed 2 2025 shows how session theft can bypass MFA and let an attacker ride the existing trust path.
What Changes the Answer in Cloud-First Networks
Cloud-first environments reduce the value of “inside the network” as a security boundary. Access decisions are increasingly supposed to happen at the application, workload, and identity layers, so a VPN that grants broad network reach is often misaligned with the actual security model. That mismatch is the core reason lateral movement risk rises.
The strongest control shift is to limit what the tunnel can reach and what each user can do after connection. Micro-segmentation, per-application policy, device posture checks, and step-up authentication reduce the chance that a stolen credential becomes a general-purpose internal foothold. If those controls are absent, the tunnel behaves like a privileged shortcut. NIST SP 800-207 Zero Trust Architecture is relevant because it argues for least privilege and continuous verification, which directly limits lateral movement potential.
Cloud identity compromise also turns tunnels into a bridge between environments. Once an attacker can reach internal tooling, they may use the same access to seek tokens, keys, or sync accounts that connect on-prem, cloud, and SaaS systems. Storm-0501 hybrid cloud attacks 2024 is a good example of how one identity path can become a cross-environment pivot.
Risk and Threat Considerations
The main risk is not the tunnel itself, it is the amount of trust the tunnel inherits. If a remote credential is stolen, the attacker may gain network adjacency that was never necessary for the job, and adjacency is what makes lateral movement practical in cloud-connected estates.
Failure mechanism: Broad tunnel access, weak segmentation, or over-trusted internal routing lets an attacker enumerate and reach systems beyond the intended application boundary, then pivot to admin tools, data stores, or identity-linked services.
Impact: A single compromised VPN session can become a multi-system intrusion, increasing the chance of credential theft, privilege escalation, service disruption, and cloud control-plane abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege | VPN risk here is broad internal reach, so least privilege directly limits pivot opportunities. |
| PR.AA-01 — Identity and Credential Management | The question hinges on stolen credentials turning remote access into lateral movement. | |
| Recommendation — Restrict tunnel access to the minimum set of applications and paths each user actually needs. Bind remote access to strong identity checks and short-lived credentials. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Segmentation and flow control are the main barriers to post-compromise pivoting through a VPN. |
| AC-6 — Least Privilege | Over-broad tunnel access creates unnecessary lateral movement paths. | |
| IA-2 — Identification and Authentication (Organizational Users) | Stolen user credentials are the usual entry point for VPN abuse and subsequent pivoting. | |
| Recommendation — Enforce information-flow restrictions between remote users and internal systems. Limit connected users to only the systems and functions required for the task. Require strong authentication for remote users before granting any tunnel access. | ||
Practitioner Guidance
What to prioritise: Treat the VPN as a temporary transport mechanism, not as a trust boundary. The first question is whether the connected user needs network reach at all, or whether application-level access is sufficient. If the answer is “only one app,” the tunnel should not expose the rest of the environment.
What to verify: Confirm that segmentation blocks access to management planes, secret stores, identity infrastructure, and east-west paths that are unrelated to the user’s task. Also verify that a stolen session cannot be reused to reach more than one trust zone.
What good looks like: A compromised remote session should have a narrow blast radius, with access tied to workload, device state, and application policy rather than to broad internal network presence.
Practitioner takeaway: If a VPN gives a user “inside” status, assume the attacker will use that status to hunt for the next reachable system, and design the tunnel so that reach is already minimal before the credential is ever stolen.
Related resources from NHI Mgmt Group
- Why do service accounts and workloads still create lateral movement risk in cloud environments?
- Why do API secrets create lateral movement risk in cloud and application environments?
- Why do sandboxed NHIs still create lateral movement risk in cloud environments?
- Why do compromised Git admins create such a high-risk path for lateral movement across development and cloud environments?