Notifications
Clear all
Topic starter
11/07/2026 8:43 pm
TL;DR: Traditional VPNs give remote users broad network access, expose internet-facing attack surfaces, and struggle with third-party risk, according to Zero Networks and Verizon’s 2025 DBIR, which reports zero-day exploits targeting edge devices and VPNs grew almost eightfold and 56% of organisations saw at least one VPN-related attack last year. The practical shift is from network trust to identity-aware, least-privilege access with continuous verification.
NHIMG editorial — based on content published by Zero Networks: VPN Alternatives: Modernizing Secure Remote Access
By the numbers:
- 91% of security leaders express concerns about VPNs leading to a security breach.
- zero-day exploits targeting edge devices and VPNs grew almost eightfold in the last year, and 56% of organizations experienced at least one VPN-related cyberattack in the last year.
- 30% of breaches included third-party involvement of some sort, up 15% from the previous year.
Questions worth separating out
Q: What breaks when organisations keep using a traditional VPN for remote access?
A: Traditional VPNs break least-privilege governance because a single authenticated session often grants broad network reach.
Q: Why do VPNs make third-party access harder to govern?
A: VPNs tend to collapse external users into the same trust model as employees, even though vendor access should be narrower, shorter-lived, and easier to revoke.
Q: How can security teams measure whether remote access controls are working?
A: Look for evidence that sessions are scoped to applications, not the whole network, and that access decisions are tied to identity, device posture, and context.
Practitioner guidance
- Inventory VPN use by identity type Separate employee, vendor, and privileged operator use cases, then document which internal resources each group truly needs.
- Reduce exposed remote access surface Eliminate unnecessary open ports and internet-facing administration paths on remote access infrastructure.
- Bind access to identity and device context Require remote access decisions to use user identity, device health, and contextual signals rather than tunnel presence alone.
What's in the full article
Zero Networks' full analysis covers the operational detail this post intentionally leaves for the source:
- A side-by-side breakdown of VPN, ZTNA, SASE, and SDP deployment tradeoffs for remote access teams.
- Specific configuration considerations for least-privilege access, MFA integration, and traffic visibility.
- The operational impact of cloud proxy bottlenecks, NAT obfuscation, and user experience degradation in legacy ZTNA.
- How Zero Networks positions just-in-time MFA and microsegmentation in a remote access architecture.
👉 Read Zero Networks' analysis of VPN alternatives and secure remote access →
VPN alternatives and ZTNA: what IAM teams need to evaluate?
Explore further
11/07/2026 9:11 pm
Broad VPN access is an identity governance problem, not just a network design problem. Once a VPN session is treated as a generic trusted channel, the organisation loses the ability to express least privilege at the point where access is actually consumed. That is why the same access path becomes dangerous for employees, vendors, and privileged operators alike. The practitioner conclusion is simple: remote access governance must be defined by identity, device, and resource, not by network membership.
A few things that frame the scale:
- 85% of organizations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A further 47% report only partial visibility into those third-party connections, which leaves governance teams unable to verify the true access footprint in most environments.
A question worth separating out:
Q: Who is accountable when a remote access pathway gives an attacker broad internal reach?
A: Accountability usually sits across IAM, infrastructure, and application owners, but the control failure is often a governance issue rather than a single technical mistake. Teams should be able to show who approved the access model, who owns third-party access, and who is responsible for revocation.
👉 Read our full editorial: VPN replacement strategies for identity-aware remote access
