What breaks when organisations keep treating VPN access as a trusted internal path?

The main failure is that a VPN turns successful authentication into broad network reach, which creates a large blast radius if credentials are stolen or bypassed. Once connected, attackers can often discover, pivot, and persist more easily than they could through a narrowly scoped application access model.

Why This Matters for Security Teams

VPNs were designed to create encrypted connectivity, not to prove that every destination behind the tunnel should be trusted. Once a user or service authenticates successfully, the network path often becomes far broader than the original access need. That breaks the modern assumption that identity, device state, and request context should all be evaluated before access is granted. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

The practical issue is not the tunnel itself, but the trust it creates after login. A stolen VPN credential can become a network foothold, and a compromised endpoint can expose internal services that were never meant to be reachable from a broad internal segment. That is why the shift toward Zero Trust, least privilege, and application-scoped access matters more than perimeter tunnelling. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 Security and Privacy Controls consistently points toward narrower, request-based authorization rather than implicit network trust. In practice, many security teams encounter lateral movement only after the VPN account has already been used to reach systems that should never have been broadly visible.

How It Works in Practice

Keeping VPN access as a trusted internal path usually means the organisation is treating network location as a proxy for authorization. That model is fragile because the tunnel does not distinguish between a low-risk request and a high-risk one. If an attacker steals credentials, they can often enumerate internal services, probe adjacent subnets, and move laterally with far less friction than through an application gateway or brokered access layer. This is especially dangerous for NHIs, where service accounts, scripts, and automation often inherit network reach without a human sitting in the loop.

A more resilient model is to move from broad network access to explicit application access. That typically includes:

• Per-app or per-service access instead of full network reach.
• Strong device and identity checks at session start, then re-evaluation at request time.
• Short-lived credentials and just-in-time elevation rather than persistent VPN trust.
• Segmentation that limits east-west movement even after authentication succeeds.
• Policy enforcement tied to context, not just to the presence of a tunnel.

This is where NHI governance becomes operational. The attack patterns described in 52 NHI Breaches Analysis and the SonicWall VPN Mass Breach via Stolen Credentials show how credential theft becomes much more damaging when the first successful login opens a wide internal path. For implementation, security teams should align access controls with the request, not the tunnel, and use the VPN only as a transport mechanism, not a trust decision. These controls tend to break down in flat networks with legacy internal apps that cannot enforce application-layer authorization.

Common Variations and Edge Cases

Tighter network access often increases user friction and infrastructure complexity, requiring organisations to balance usability against blast-radius reduction. There is no universal standard for this yet, so the right answer depends on whether the VPN is supporting employees, third parties, contractors, or NHIs. Third-party access is often the most exposed case because external users may have legitimate need for a narrow workflow but receive broad internal connectivity instead. NHI Mgmt Group’s research notes that 92% of organisations expose NHIs to third parties, which makes this a common path to overreach.

Some environments still keep VPNs for administrative continuity, remote support, or legacy systems that cannot be fronted by modern access brokers. In those cases, best practice is evolving toward compensating controls: strict subnet segmentation, explicit allowlists, short session lifetimes, and continuous monitoring for unusual internal discovery behaviour. The VPN should not be the last gate before sensitive assets. If the business must retain it, the safer posture is to treat it as one layer in a broader ZTNA or application-scoped design, not as proof that the user or workload belongs inside.

Where VPNs are used for automation or NHI-driven workflows, the risk is even higher because non-human identities do not behave like humans and often chain actions faster than analysts can detect. That is why guidance from Ultimate Guide to NHIs — Key Challenges and Risks and Microsoft SAS Key Breach is most relevant when access is both persistent and broad. When the organisation cannot bind access to context, the tunnel becomes an implicit trust boundary that attackers routinely exploit.

Related resources from NHI Mgmt Group

• What do teams get wrong when they keep VPN-style access for regulated systems?
• What breaks when broad VPN access is used for CMMC readiness?
• What breaks when utilities rely on VPN access for OT operations?
• Should organisations prioritise external exposure or internal credential governance first?