Why do VPNs create more risk in cloud-heavy environments?

Because VPNs assume that connectivity from inside the tunnel implies trust. In cloud-heavy environments, applications are distributed and identities are fragmented, so a stolen credential can open access well beyond the original remote session. That makes flat network trust a poor fit for modern identity governance.

Why VPNs Increase Risk in Cloud-Heavy Environments

VPNs were built to extend a trusted network boundary, but cloud-heavy environments are defined by distributed applications, ephemeral workloads, and identities that do not map cleanly to a subnet. Once a user or service lands inside the tunnel, the network layer often says little about what that identity should actually be allowed to do. That is why stolen credentials and overbroad access become so dangerous in practice. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that access decisions must be tied to risk and identity, not just location.

In NHI-focused incidents, the same pattern repeats: one valid credential opens the door to far more than the original session intended. NHIMG research on the Snowflake breach and the SonicWall VPN Mass Breach via Stolen Credentials shows how identity misuse, not network entry alone, becomes the real failure mode. In practice, many security teams encounter lateral movement and cloud privilege abuse only after a VPN credential has already been used to traverse services that were never meant to share trust.

What Actually Breaks After the Tunnel Opens

A VPN creates an implicit trust zone, but cloud workloads depend on multiple identity systems, service-to-service permissions, and temporary tokens. That mismatch is the core problem. A user may authenticate once, then reach management planes, SaaS consoles, internal APIs, and cloud control services that each require different assurance levels. The tunnel does not enforce those distinctions.

Current best practice is to treat VPN connectivity as transport, not authorization. Security teams increasingly pair VPNs with conditional access, strong device posture checks, and workload-specific controls such as short-lived credentials and real-time policy evaluation. In cloud-heavy environments, the identity primitive should be the workload or session itself, not the network location. That is why frameworks like Top 10 NHI Issues and broader NHI guidance emphasize secret hygiene, credential scope, and rotation over perimeter assumptions.

• Use the VPN only to establish reachability, then require separate authentication and authorization for cloud resources.
• Replace long-lived shared secrets with short-lived tokens where possible.
• Apply least privilege at the application, API, and cloud control-plane layers.
• Monitor for impossible travel, unusual privilege escalation, and new tool access after VPN login.

For cloud operations, the most resilient pattern is to bind access to device state, user identity, and workload context at request time, consistent with NIST CSF 2.0 and the identity-centric lessons in the Ultimate Guide to NHIs — Key Challenges and Risks. These controls tend to break down when a single VPN account can reach multiple cloud tenants because identity boundaries are too coarse to stop lateral movement.

Where VPN Design and Cloud Reality Clash

Tighter network controls often increase operational overhead, requiring organisations to balance simplicity against segmentation, access review, and user friction. That tradeoff becomes sharper in hybrid and multi-cloud estates, where legacy applications still depend on VPN connectivity while modern services expect token-based, context-aware access.

There is no universal standard for when a VPN must be removed entirely, but current guidance suggests narrowing its role as cloud adoption grows. The practical shift is toward zero trust patterns, where every request is evaluated against identity, device health, and policy rather than implied by the tunnel. NHIMG’s reporting on the 230M AWS environment compromise and the Codefinger AWS S3 ransomware attack illustrates how cloud exposure often follows broad permissions and weak identity controls more than it follows network ingress alone.

Operationally, teams should reserve VPNs for constrained admin paths, then layer PAM, JIT access, and strong audit logging around cloud consoles and sensitive APIs. That reduces the blast radius of a stolen credential and makes anomalous use visible sooner. Where VPNs remain, they should be treated as one signal among many, not a trust accelerator.

Related resources from NHI Mgmt Group

• Why do non-human identities create audit risk in modern environments?
• Why do passwords and OTPs still create risk in regulated environments?
• How should security teams prioritise NHI remediation in cloud environments?
• Why do non-human identities create more audit risk than human accounts?