IDENTITY & ACCESS MANAGEMENT

The VPN Trap: Why Legacy Remote Access Is a Risk Your Board Should Understand

Hairpinning, Split-Tunnelling, Encrypted Blind Spots, Ransomware-as-a-Service, and the Alternatives That Actually Work

CyberCQR Thought Leadership | May 2026 | 26 minutes reading time

The Core Problem

Legacy client Virtual Private Networks (VPNs) were designed for a world that no longer exists. They extend the corporate network to remote devices and grant broad access to whoever authenticates. That trust model was adequate when the office network was the security perimeter and remote workers were an exception. Neither is true today.

Three structural problems make legacy VPN the wrong answer in 2026. First, full-tunnel VPN forces remote traffic back through the enterprise gateway before it can reach cloud services -- a routing inefficiency called hairpinning. Split-tunnelling was introduced to fix that. It does fix the performance problem. It creates a different and more serious security problem by shifting the enforcement boundary from a hardened enterprise firewall to a device sitting in a hotel room. Second, the encrypted tunnel that protects VPN traffic from eavesdropping also prevents your security gateway from inspecting what is inside it. Third, VPN credentials are now the primary commodity traded on criminal marketplaces and the preferred initial access vector for Ransomware-as-a-Service (RaaS) operators.

Better alternatives exist and, for most organisations in the Microsoft ecosystem, some of them are already paid for. The gap is rarely procurement. It is awareness and implementation.

Executive Summary

This article covers six areas:

Why VPN persists despite well-documented risk.
Hairpinning -- the routing inefficiency that full-tunnel VPN creates -- and split-tunnelling, the fix that solves the performance problem while creating a more serious security one.
The traffic inspection problem -- why encrypted VPN tunnels prevent the gateway from seeing what is inside them, and what that means for your security stack.
RaaS and VPN credentials -- how the criminal market for stolen VPN access has changed the threat picture.
The full landscape of alternatives -- from micro-VPN and per-app VPN as halfway measures, through to true ZTNA platforms and specialist privileged access tools.
Board questions and immediate actions.

Why VPN Persists: Familiarity Is Not Fitness for Purpose

Client VPN has been the standard answer to remote access for three decades. IT teams understand it. Vendors support it. The procurement story is familiar. For organisations that built on-premises infrastructure, it made complete sense: VPN extended the corporate network to remote workers, and the network was where the data lived.

Three changes have undermined that logic. Applications and data have moved to Microsoft 365, Azure, and SaaS platforms -- the corporate network is no longer where the work happens. VPN gateways are internet-facing infrastructure, and major appliance vendors have disclosed critical zero-day vulnerabilities exploited in the wild within the past two years. And identity and device health -- not network location -- are now the correct basis for access decisions, as established by NIST SP 800-207 and confirmed by every major cloud provider's security architecture guidance.

Despite all of this, most mid-market organisations still run client VPN as their primary remote access mechanism. The reason is institutional inertia: VPN works, the team knows how to run it, and migration feels disruptive. These are understandable positions. They are not defensible risk management positions.

The Hairpinning Problem and the Split-Tunnelling Fix That Creates a Worse One

Hairpinning: the performance problem

Hairpinning -- also called trombone routing -- describes any situation where network traffic is forced to travel back through a central point before reaching its destination, rather than taking a direct path. The traffic doubles back on itself like a trombone's slide, adding latency and consuming bandwidth unnecessarily.

VPN is one common cause, but not the only one. Poor DNS configuration can produce the same effect without a VPN in sight: if DNS resolves a cloud service hostname to an internal IP address rather than its public endpoint, traffic from a branch office or remote worker travels into the organisation's network, crosses to the cloud service, and returns -- a round trip that adds latency and gateway load for no security benefit. Misconfigured routing tables and hub-and-spoke Wide Area Network (WAN) architectures that route all branch traffic through a head office before it can reach the internet create exactly the same pattern.

In a full-tunnel VPN context, the hairpinning problem is acute. A Microsoft Teams call from a remote worker travels from the laptop into the encrypted tunnel, to the corporate data centre, out to the internet, to Microsoft's infrastructure, and back the same way. When organisations moved to cloud-first working at scale, this routing pattern saturated gateways, degraded call quality, and drove up bandwidth costs. Microsoft documented the problem explicitly and recommended allowing Microsoft 365 traffic to reach the internet directly from the client device rather than through the corporate gateway.

Split-tunnelling: the fix, and the new problem it creates

Split-tunnelling was introduced to solve the hairpinning problem. It routes only traffic destined for defined internal network ranges through the VPN tunnel. Everything else -- cloud services, internet browsing, software updates -- goes directly from the client device to the internet, bypassing the gateway entirely.

The performance improvement is real and the guidance to implement it for Microsoft 365 traffic is technically sound. What that guidance does not address is the security architecture that disappears when you follow it.

The control boundary shift

In a full-tunnel environment, all remote traffic passes through the enterprise security stack: next-generation firewall, Intrusion Detection and Prevention Systems (IDPS), Data Loss Prevention (DLP) controls, Secure Web Gateway (SWG), and security monitoring tooling. This infrastructure is maintained by professional security teams, updated to current signatures, and configured to policy.

When split-tunnelling is enabled, all traffic not destined for internal ranges goes directly to the internet from the client device. That traffic bypasses every enterprise security control entirely.

The security boundary for that traffic is now the Windows Firewall on the laptop -- configured to defaults, rarely reviewed, and subject to modification by any software the user installs. You have replaced a hardened enterprise firewall managed by a security team with a client-side control on a device in a coffee shop. These are not equivalent. Treating them as equivalent is a significant risk management error.

The bridging risk: untrusted networks reaching the corporate network

The most serious and least-discussed risk in split-tunnel deployments is network bridging. A split-tunnel client has two active network connections simultaneously: the VPN tunnel to internal corporate systems, and a direct connection to whatever external network the device is on. If the device is on an untrusted network -- hotel WiFi, a compromised home network, a co-working space -- and if the client firewall is misconfigured, an attacker on the external network may be able to reach the corporate network via the device.

This happens in practice through four mechanisms:

IP forwarding enabled inadvertently. Developer tools, virtualisation software, and some VPN clients enable IP forwarding at the operating system level. Combined with split-tunnelling, this creates a routable path from the external interface through the device to the VPN tunnel. The device becomes an unintended router.
Misconfigured host firewall rules. Installed software frequently modifies Windows Firewall rules to allow inbound connections. Rules intended to allow a specific local application function can inadvertently permit traffic from the external interface to forward to the VPN-connected interface. These rules accumulate over the device's lifetime and are rarely audited.
Virtualisation and container networking. Developers running virtual machines with bridged rather than NAT (Network Address Translation) networking create additional virtual interfaces. These can form unintended bridges between the external and VPN-connected network stacks.
Compromised devices acting as deliberate pivots. An attacker who has already compromised the device has access to both interfaces. Split-tunnelling removes the gateway inspection that might detect unusual lateral movement traffic. Exfiltration and reconnaissance can happen entirely outside the tunnel, invisible to enterprise monitoring.

Why the blast radius matters: VPN is typically deployed to grant broad network segment access rather than specific application access. A successful bridging attack therefore does not reach one application -- it reaches whatever the VPN segment can reach. In most deployments that includes file servers, internal applications, and infrastructure with no other internet exposure.

Route table drift: configuration that silently becomes wrong

Split-tunnel route tables define which traffic goes through the tunnel. They are configured at deployment and rarely updated. As organisations add SaaS applications, move workloads to cloud platforms, and change their infrastructure, the route configuration drifts from intended policy.

Traffic that security architects intended to route through enterprise controls ends up going directly to the internet. Traffic intended for cloud services gets unnecessarily routed through the gateway rather than bypassing it. Neither error generates an alert. The configuration drifts silently. Nobody notices because users can still access what they need.

The Traffic Inspection Problem: Encrypted Tunnels and Gateway Blind Spots

VPN security is built on encryption. IPSec (Internet Protocol Security) and SSL/TLS (Secure Sockets Layer/Transport Layer Security) tunnels protect remote access traffic from interception in transit. This is the right property for a secure connection. It creates an unintended consequence: the enterprise gateway cannot inspect what is inside the tunnel.

Why deep packet inspection fails at the VPN gateway

Deep Packet Inspection (DPI) is the technique security appliances use to examine the content of network traffic -- identifying malware, detecting data exfiltration, and enforcing policy. DPI works on traffic that the appliance can read. Encrypted traffic presents as opaque ciphertext. The firewall can see that a packet arrived and where it is going. It cannot read the contents.

For VPN traffic, the gateway terminates the outer tunnel and decrypts the packets -- so inspection is theoretically possible at the VPN concentrator. In practice, most organisations do not deploy full DPI on VPN gateway traffic. The computational cost is significant. The latency impact on an already-stretched gateway is real. And the inspection infrastructure is often separate from the VPN infrastructure, meaning the decrypted traffic would need to be re-routed through an inspection layer before being forwarded internally.

The result is that most VPN deployments have a de facto inspection gap at the gateway. Traffic arrives encrypted, the tunnel is terminated, and the payload is forwarded to the internal network with limited or no content inspection.

What the inspection gap allows through

Malware payloads delivered over encrypted sessions. An attacker who has positioned malware on a device can use the VPN tunnel itself as a delivery channel for additional payloads, lateral movement tools, and command instructions. The encrypted tunnel protects this traffic just as effectively as it protects legitimate user data.
Encrypted command-and-control (C2) traffic. Modern malware communicates with its operators over HTTPS (Hypertext Transfer Protocol Secure) channels that are indistinguishable from normal web traffic at the network level. If this traffic flows inside the VPN tunnel, it is doubly protected: encrypted by the malware's own TLS session and wrapped in the VPN tunnel encryption.
Data exfiltration over authorised channels. An insider or compromised account can exfiltrate sensitive data by uploading it to a cloud service over an encrypted connection inside the VPN tunnel. Without content inspection at the gateway, DLP tools cannot detect what is leaving. The transaction looks identical to any other authorised upload.
SSL inspection as a partial remedy with its own problems. Some organisations deploy SSL inspection (also called TLS inspection or man-in-the-middle decryption) at the gateway to decrypt, inspect, and re-encrypt traffic. This restores inspection capability but introduces latency, creates certificate trust issues with some applications, and generates privacy concerns where personal traffic traverses the inspection infrastructure. It is operationally complex and frequently incomplete in practice.

The architectural contradiction: VPN's core security property -- encryption -- directly undermines the gateway's ability to perform security inspection. The stronger the encryption, the blinder the gateway. This is not a configuration problem. It is an inherent property of the architecture. ZTNA platforms address it differently: access policy is enforced at the identity and application layer, not by inspecting encrypted payloads at a network gateway.

Ransomware-as-a-Service and the VPN Credential Economy

The threat landscape has professionalised. Ransomware-as-a-Service (RaaS) is a business model in which criminal groups develop and maintain ransomware infrastructure and then licence it to affiliate operators who carry out the actual attacks. The affiliate receives a share of the ransom proceeds. The developer takes a platform fee. Both profit without needing the full capability set to execute an attack end-to-end.

This model depends on reliable initial access. RaaS operators -- and the Initial Access Brokers (IABs) who supply them -- have identified VPN credentials as the most cost-effective and reliable entry point into mid-market and enterprise organisations.

How the VPN credential economy works

The process is more structured than most boards realise:

Credential harvesting at scale. Phishing campaigns, credential-stuffing attacks using previously breached username and password combinations, and infostealers harvested via malware all generate large volumes of potential VPN credentials. Many are tested automatically against known VPN gateway URLs using tooling sold on criminal marketplaces.
Initial Access Brokers list verified access. A working VPN credential -- confirmed to authenticate against a specific organisation's gateway -- is packaged and listed for sale on criminal forums. Listings specify the organisation, sector, employee count, and estimated revenue. Prices range from hundreds to tens of thousands of pounds depending on perceived value.
RaaS affiliates purchase and deploy. The affiliate buys verified access, connects via VPN, and begins lateral movement to identify domain controllers, backup infrastructure, and valuable data. This phase may take weeks. The endpoint is ransomware deployment or data exfiltration for double extortion.
The VPN gateway has no visibility into steps two and three. The credential was valid. The authentication succeeded. From the gateway's perspective, this was a legitimate user connection.

Impossible travel: an anomaly VPN cannot detect itself

Impossible travel is a detection concept: if a user's account authenticates from London at 09:00 and then from Singapore at 09:45, the second authentication is physically impossible without teleportation. One of the two sessions is fraudulent. Detecting impossible travel is a standard capability in modern identity platforms.

Legacy VPN has a specific and serious limitation here. VPN gateways authenticate credentials. They do not natively correlate authentication events against the user's prior location, session history, or behaviour patterns. A credential sold to a buyer in Eastern Europe who connects to a UK organisation's VPN gateway may look entirely normal to the gateway: valid username, valid password, valid Multi-Factor Authentication (MFA) token if MFA is enforced.

ZTNA platforms integrated with modern identity providers such as Microsoft Entra ID apply Conditional Access policies that evaluate location, session risk, device compliance, and authentication behaviour continuously -- not just at connection time. An authentication from an unexpected geography triggers a risk signal. A login at an unusual time combined with access to sensitive resources triggers a further signal. The session can be challenged or terminated automatically without administrator intervention.

The MFA caveat: MFA significantly reduces the risk of credential compromise being used successfully. It is not a complete defence against RaaS access broker techniques. Session hijacking attacks, adversary-in-the-middle (AiTM) phishing platforms that capture MFA tokens in real time, and social engineering of MFA approvals (MFA fatigue attacks) all represent credible techniques for defeating MFA on VPN gateways. Modern Conditional Access with phishing-resistant MFA -- FIDO2 (Fast IDentity Online 2) hardware keys or Windows Hello for Business -- provides substantially stronger protection than SMS or push-notification MFA against these techniques.

Halfway Measures: Micro-VPN and Per-Application VPN

Between legacy full-network VPN and true ZTNA sits a category of approaches that address some problems while retaining others. Understanding where these sit is important for evaluating what vendors propose and what technology teams may already be deploying.

Per-application VPN

Per-application VPN -- sometimes called app-based VPN or per-app tunnel -- routes VPN traffic on a per-application basis rather than per-device. Instead of all traffic from the device going through the tunnel, only traffic from specific designated applications is tunnelled. This is the split-tunnelling concept applied at the application layer rather than the network layer.

Per-app VPN is common in mobile device management (MDM) and Unified Endpoint Management (UEM) platforms -- Microsoft Intune, Jamf, and VMware Workspace ONE all support it. It is particularly used for corporate applications on employee-owned or shared devices, where routing all device traffic through the corporate tunnel would be inappropriate.

What per-app VPN improves

Reduces the volume of traffic hairpinned through the enterprise gateway.
Prevents personal device activity from traversing corporate infrastructure.
Narrows the scope of the VPN tunnel, reducing -- though not eliminating -- lateral movement risk.
Easier to deploy on mobile and bring-your-own-device (BYOD) fleets than full-device VPN.

What per-app VPN does not solve

The designated applications still create a network-level tunnel to the corporate infrastructure. A compromised application can still be used to probe internal systems reachable via that tunnel.
The VPN gateway is still internet-facing infrastructure. The appliance vulnerability risk remains.
Access is still network-level for the tunnelled applications -- the user reaches the network segment, not a specific application endpoint with granular policy.
Device health validation depends on the MDM platform, not the access architecture itself.

Assessment: Per-app VPN is a meaningful improvement over full-device VPN, particularly for mobile and BYOD scenarios. It is an intermediate position on the journey toward ZTNA. For organisations already using Intune, deploying per-app VPN is a practical near-term step. It should not be the destination.

Micro-VPN (micro-segmented tunnel)

Micro-VPN takes the per-app VPN concept further. Rather than one tunnel per application group, micro-VPN establishes a separate, short-lived tunnel for each individual connection or session. The tunnel exists only for the duration of the session and is scoped to a specific target. Some ZTNA platforms use this pattern internally to broker connections between the user and the application -- the tunnel is created on demand, inspected at both ends, and torn down when the session ends.

When implemented properly as part of a ZTNA architecture, this is the right approach. The distinction matters: micro-VPN as a standalone technology -- without application-layer policy enforcement, continuous device health checks, and identity-based access control -- retains many of the problems of traditional VPN at smaller scope. It is the ZTNA wrapper that makes micro-tunnels safe, not the tunnel technology itself.

The CASB-plus-VPN hybrid: A Cloud Access Security Broker (CASB) is sometimes added to an existing VPN deployment to inspect cloud application traffic -- detecting shadow IT, enforcing DLP on uploads to cloud storage, and providing visibility into SaaS usage. This is a useful improvement. It does not address the bridging risk, the inspection gap inside the VPN tunnel, or the internet-facing appliance attack surface. CASB improves a VPN deployment. It does not replace one.

True Alternatives: A Full Landscape

The alternatives to legacy VPN share a common architectural principle: the user never receives network access. They receive access to a specific application or resource, brokered through a cloud intermediary, with identity and device health verified at the point of access and continuously thereafter. There is no tunnel to bridge, no gateway to exploit, and no route table to drift.

OPTION 1 -- MICROSOFT -- INCLUDED IN ENTRA ID P1 (E3/E5)

Microsoft Entra application proxy

Best for: Publishing internal web applications and Remote Desktop Protocol (RDP) to specific servers. No inbound firewall ports required. Included in Microsoft Entra ID P1 (Microsoft 365 E3 and above).

A lightweight connector installed on an internal server makes an outbound-only connection to Microsoft's cloud. Users authenticate via Entra ID with MFA enforced. They reach the specific published application. They receive no network access at all -- there is no tunnel to bridge, no route table, and no VPN gateway on the internet. The traffic inspection problem also disappears: the access is brokered at the application layer, and the content of the session is visible to Microsoft Defender for Cloud Apps if deployed.

Application Proxy covers HTTP/S applications and RDP. It does not cover arbitrary TCP/UDP traffic, Server Message Block (SMB) file shares, or legacy non-web protocols. Those require Entra Private Access.

Quick win: Migrating the five most-used internal web applications to Application Proxy is typically a two-week project. Users report a better experience -- no VPN client to connect before working. The security gain is immediate.

OPTION 2 -- MICROSOFT -- ENTRA SUITE OR SEPARATE LICENCE

Microsoft Entra Private Access

Best for: Complete VPN replacement for organisations in the Microsoft estate. Covers all TCP and UDP protocols including SMB file shares. Integrates natively with Defender for Endpoint for device health signals and Entra ID for continuous Conditional Access.

Entra Private Access is Microsoft's purpose-built Zero Trust Network Access (ZTNA) product. Access policy is defined per application or resource in Entra, not in a route table on the client device. The route table drift problem disappears because there are no client-side routes. The bridging risk disappears because there is no network extension to the client. The impossible travel and anomalous access detection is native: Defender for Endpoint feeds device risk signals into Conditional Access, and a compromised or non-compliant device loses access automatically.

For E5 organisations: Entra Private Access is not part of Microsoft 365 E5. It is licensed on its own or through Microsoft Entra Suite, and licensing changes often, so check your current agreement before assuming it is paid for.

OPTION 3 -- THIRD PARTY -- ENTERPRISE SASE

Zscaler Private Access (ZPA)

Best for: Large or multi-cloud organisations requiring enterprise-grade ZTNA with deep policy controls, non-Microsoft identity providers, and a unified Secure Access Service Edge (SASE) platform covering both private access (ZPA) and internet security (Zscaler Internet Access, ZIA).

Zscaler has been in production at large-scale enterprises for longer than most competitors. ZPA operates as a cloud broker: a connector on internal infrastructure makes an outbound-only connection to Zscaler's cloud. Users connect to Zscaler, which brokers access to the internal resource. Neither the user's device nor the internal server has a direct network connection to the other.

A key differentiator is Zscaler's inline inspection capability. Because traffic passes through the Zscaler cloud, ZPA can apply content inspection, DLP, and threat detection to the brokered session. This directly addresses the traffic inspection problem inherent in VPN: rather than encrypting traffic past a blind gateway, traffic flows through an inspection layer that has full visibility. ZPA combined with ZIA also provides internet security for split-tunnel traffic -- the direct internet path goes through Zscaler rather than bypassing security controls.

Significant additional licence cost for organisations already on Microsoft 365 E5.
Right choice for organisations wanting a single vendor for private access and internet security gateway.
Integration with Entra ID for identity and Defender for Endpoint for device compliance is well established.

OPTION 4 -- THIRD PARTY -- MID-MARKET AND CONTRACTORS

Cloudflare Access (Cloudflare Zero Trust)

Best for: Mid-market organisations, those with significant contractor or third-party access requirements, and organisations wanting competitive pricing with low deployment overhead. Agentless browser-based access for external users is a specific strength.

Cloudflare Access uses Cloudflare Tunnel to connect internal resources to Cloudflare's edge network via an outbound-only connector. Users authenticate through the Cloudflare proxy, which evaluates identity, device posture, and policy before proxying the session to the internal resource.

Cloudflare's global network of points of presence typically delivers lower latency than competing cloud-brokered solutions for distributed workforces. Third-party and contractor access is particularly clean: external users can access specific resources without installing a client or joining the corporate identity provider. Cloudflare Gateway provides internet security (SWG, DNS filtering, DLP) to complement Access, offering a complete SASE-aligned capability at a more accessible price point than Zscaler.

Device posture checking is maturing and is less deeply integrated with Defender for Endpoint than Microsoft-native options.
WARP client required for non-HTTP protocol coverage beyond browser-based applications.
Strong free tier and competitive pricing make it accessible for evaluation and for smaller deployments.

OPTION 5 -- SPECIALIST -- PRIVILEGED INFRASTRUCTURE ACCESS

HashiCorp Boundary

Best for: IT administrator and developer access to servers, databases, and Kubernetes clusters. Not a general user VPN replacement. The right answer for the specific problem of privileged infrastructure access -- typically the use case organisations find hardest to migrate away from legacy VPN.

Boundary provides just-in-time (JIT) access to infrastructure targets. An administrator does not receive network access to an infrastructure segment. They receive a time-limited, session-recorded connection to a specific target, with credentials injected automatically via HashiCorp Vault and the session logged for compliance and forensic purposes. The session terminates when the work is done. There is no standing access to pivot from.

Boundary combined with Entra Private Access or Cloudflare Access for general user access covers the full remote access picture without a VPN appliance anywhere in the architecture.

HashiCorp Vault required for full credential brokering. HCP Boundary (managed cloud) reduces infrastructure overhead.
Session recording and advanced policy features require Boundary Enterprise.
Not appropriate for end-user application access -- attempting to use it as a general VPN replacement creates poor experience and high support overhead.

Side-by-Side Comparison

Factor	Legacy VPN	Per-App VPN	App Proxy	Entra Private Access	Zscaler ZPA	Cloudflare Access	Boundary
Access scope	Full network	App tunnel (network)	Per app (HTTP/RDP)	Per app/resource	Per app/resource	Per app/resource	Per session (JIT)
Bridging risk	High	Reduced	None	None	None	None	None
Traffic inspection	Blind (encrypted tunnel)	Partial	Via Defender for Cloud Apps	Via Defender for Cloud Apps	Inline (Zscaler cloud)	Via Gateway	Session recorded
Impossible travel / anomaly detection	Not native	Not native	Entra ID Conditional Access	Native (Entra + Defender)	Yes	Yes	Yes
Internet-facing attack surface	VPN appliance exposed	VPN appliance exposed	No exposed ports	No exposed ports	No exposed ports	No exposed ports	No exposed ports
RaaS credential risk	High -- primary target	High	Low (no VPN gateway)	Low (Conditional Access)	Low	Low	Low (JIT, no standing access)
Device health check	Rarely	Via MDM	Conditional Access	Conditional Access + Defender	Yes	Yes (maturing)	Yes
Cost vs M365 E5	Appliance + licences	Via MDM licence	Included E3/E5	Included E5	Additional licence	Additional (competitive)	Additional licence

How to Choose

What Microsoft 365 licence tier do you hold? E3 and E5 include Microsoft Entra ID P1, which covers application proxy. Entra Private Access is licensed separately or through Microsoft Entra Suite. Knowing exactly what you hold tells you how much of the replacement is already paid for.
Is your primary access need web applications, or do you also need file share and legacy TCP access? Application Proxy covers the former. Entra Private Access, ZPA, or Cloudflare with WARP cover the latter.
Do you have significant contractor or third-party access requirements? Cloudflare Access handles external users without requiring client installation -- a meaningful practical advantage.
Do administrators and developers use VPN to SSH into servers and databases? HashiCorp Boundary is the right solution for that specific problem, regardless of which platform handles general user access.
Are you moving toward a unified SASE architecture? Zscaler (ZPA plus ZIA) or Cloudflare (Access plus Gateway) provide a coherent platform covering private access and internet security together.

For most mid-market organisations in UK regulated industries, already on Microsoft 365 E3 or E5, the answer is: deploy Application Proxy for web applications now, migrate to Entra Private Access for full coverage, and deploy Boundary if privileged infrastructure access is a distinct requirement. Application proxy is usually within current licensing; Entra Private Access usually needs an additional licence. The larger investment is implementation and change management.

Board-Level Questions

Do we use split-tunnelling? If so, has anyone assessed the bridging risk -- could a client device act as a path from an untrusted external network into our corporate network?
What security inspection applies to traffic inside our VPN tunnels? Or does the encryption prevent gateway inspection?
Are our VPN credentials available for purchase on criminal marketplaces? When did we last check, and what is the monitoring process?
Does our VPN gateway detect impossible travel -- authentication from geographically implausible locations -- or does it simply authenticate valid credentials regardless of origin?
What Microsoft 365 licence tier do we hold, and are Entra Private Access or Application Proxy deployed? If not, why not?
What does an attacker have access to in the 15 minutes after successfully authenticating to our VPN with a purchased credential?
How is privileged infrastructure access -- administrator SSH and database connections -- controlled and audited? Is VPN the mechanism, and is there a more appropriate alternative in scope?

Three Actions This Week

1. Commission a split-tunnel and inspection review

Ask for a written assessment of your split-tunnel configuration, what traffic bypasses the enterprise security stack, how route tables are maintained, and whether IP forwarding is enabled on VPN clients. Also ask specifically what security inspection applies to traffic inside the VPN tunnel and what the answer is when the gateway cannot decrypt it. If no assessment exists, that is itself a board-level finding.

2. Check your Microsoft licence and deployed capabilities

If your organisation holds Microsoft 365 E3 or E5, Application Proxy and Conditional Access are available now. Entra Private Access needs Microsoft Entra Suite or a separate licence. Ask whether these are deployed. You may already be paying for part of what replaces VPN. Understanding the licensing position is one conversation with your IT team.

3. Set a VPN retirement target in the risk register

Add VPN architecture to your cyber risk register with a target migration date. A realistic timeline for a 500-1,500 user Microsoft 365 E5 organisation is six to twelve months. Without a target date and assigned ownership, this is a documented risk with no remediation commitment. That is not a defensible board position.

Glossary

AiTM (Adversary-in-the-Middle): A phishing technique that interposes a proxy between the user and a legitimate login page. The proxy captures the session token after authentication completes -- including after MFA -- and replays it to gain access to the account. Defeats push-notification and SMS-based MFA. Phishing-resistant MFA methods such as FIDO2 hardware keys are resistant to AiTM attacks.

BYOD (Bring Your Own Device): A policy permitting employees to use personal devices to access corporate systems. Per-app VPN is particularly relevant to BYOD fleets where routing all device traffic through the corporate tunnel would be operationally inappropriate.

CASB (Cloud Access Security Broker): A security service providing visibility and control over cloud application usage. Inspects SaaS traffic, enforces DLP policy, and detects shadow IT. Useful as a complement to any remote access architecture. Does not replace VPN -- adds inspection capability to traffic that bypasses VPN, but leaves VPN's structural risks intact.

C2 (Command and Control): The infrastructure used by attackers to communicate with and control malware deployed on compromised devices. Modern C2 traffic typically uses HTTPS to blend with normal web traffic and evade gateway inspection. C2 traffic inside a VPN tunnel is invisible to gateway inspection.

Conditional Access: A Microsoft Entra ID policy framework evaluating identity, device compliance, location, session risk, and other signals before granting or denying access. Supports impossible travel detection and continuous access evaluation. The primary enforcement mechanism in Entra Private Access and Application Proxy deployments.

DLP (Data Loss Prevention): Security controls monitoring and restricting the transfer of sensitive data. Gateway-based DLP can only inspect traffic that passes through the enterprise gateway -- blind to split-tunnel bypass traffic and to traffic inside an encrypted VPN tunnel that is not decrypted for inspection.

DPI (Deep Packet Inspection): A technique for examining the content of network packets, not just their headers. Used for malware detection, DLP, and policy enforcement. Requires unencrypted traffic. Encrypted VPN tunnels must be decrypted before DPI can be applied, which most gateway deployments do not do in practice.

FIDO2 (Fast IDentity Online 2): A modern authentication standard enabling phishing-resistant MFA using hardware security keys or platform authenticators (Windows Hello, Touch ID). Not susceptible to AiTM token capture because the cryptographic response is bound to the specific website origin. Recommended for high-value accounts and privileged access scenarios.

Hairpinning: A routing problem in which network traffic is forced to travel back through a central point before reaching its destination, rather than taking a direct path. In full-tunnel VPN deployments, all remote traffic passes through the enterprise gateway even when the destination is a cloud service the device could reach directly -- adding latency, consuming gateway bandwidth, and degrading performance at scale. The same problem occurs outside VPN: poor DNS configuration resolving a cloud hostname to an internal address, or hub-and-spoke WAN architectures routing branch traffic through head office, produce identical effects. Split-tunnelling was introduced specifically to solve the hairpinning problem in VPN contexts. See also: Trombone routing.

Trombone routing: An alternative name for hairpinning. The trombone analogy describes traffic that doubles back on itself like the slide of a brass instrument rather than travelling directly to its destination. The two terms are interchangeable; hairpinning is more common in general networking contexts, trombone routing in WAN and SD-WAN architecture discussions. See: Hairpinning.

IAB (Initial Access Broker): A criminal specialisation in obtaining verified access to target organisations and selling that access to other threat actors, including RaaS operators. VPN credentials are the most commonly traded commodity in IAB marketplaces. Access listings typically include organisation name, sector, employee count, and estimated revenue to help buyers assess the value of the target.

IDPS (Intrusion Detection and Prevention Systems): Security appliances monitoring network traffic for known attack patterns, malicious activity, and policy violations. Effective only on traffic they can inspect -- blind to encrypted traffic unless TLS inspection is deployed.

Impossible travel: A security detection signal triggered when a user account authenticates from two geographically separated locations within a timeframe that makes physical travel between them impossible. Indicates credential compromise or unauthorised access. Native in Microsoft Entra ID Identity Protection. Not a native capability of legacy VPN gateways.

IP forwarding: An operating system feature that routes network packets between interfaces rather than consuming them locally. When enabled on a device with both a VPN tunnel and an external network connection, creates conditions for the device to act as an unintended router between the external network and the corporate network.

IPSec (Internet Protocol Security): A suite of protocols for encrypting and authenticating IP communications. Used in many enterprise VPN implementations for tunnel security. The encryption that protects the tunnel from eavesdropping also prevents the gateway from inspecting the content of the packets inside it.

JIT (Just-in-Time) access: A privileged access model granting time-limited access rights for a specific session, automatically revoked when the session ends. Eliminates standing privileged access and reduces the window of exposure from a compromised account. HashiCorp Boundary implements JIT access for infrastructure targets.

MDM (Mobile Device Management) / UEM (Unified Endpoint Management): Platforms managing device configuration, policy enforcement, and application deployment across a device fleet. Microsoft Intune, Jamf, and VMware Workspace ONE all support per-app VPN as part of their management capability.

MFA (Multi-Factor Authentication): An authentication mechanism requiring two or more independent verification factors. Significantly reduces credential compromise risk but does not prevent all attacks -- AiTM phishing, MFA fatigue, and session hijacking are techniques for defeating push-notification and SMS-based MFA.

Micro-VPN: A remote access pattern establishing short-lived, narrowly scoped tunnels per connection or session rather than a persistent full-device or full-application tunnel. When implemented as part of a ZTNA architecture with proper identity and device policy, provides strong security. As a standalone technology without those controls, retains many VPN risks at smaller scope.

NAT (Network Address Translation): A technique allowing multiple devices to share a single external IP address. Virtualisation software using NAT rather than bridged networking isolates virtual machine traffic from the host's physical interfaces, reducing the risk of unintended network bridging.

NIST SP 800-207: The US National Institute of Standards and Technology publication defining Zero Trust Architecture. Establishes that identity and device health -- not network location -- are the correct basis for access decisions.

Per-app VPN: A VPN configuration routing tunnel traffic on a per-application basis rather than for the entire device. Common in MDM deployments for mobile and BYOD scenarios. Reduces hairpinning and narrows the access scope compared to full-device VPN. Does not eliminate bridging risk or the internet-facing VPN appliance.

RaaS (Ransomware-as-a-Service): A criminal business model in which ransomware infrastructure and tooling is developed by one group and licenced to affiliate operators who conduct attacks in exchange for a share of ransom proceeds. RaaS operators and their Initial Access Broker suppliers treat VPN credentials as primary acquisition targets. The professionalisation of RaaS has dramatically increased the volume and sophistication of VPN-based initial access attempts.

SASE (Secure Access Service Edge): A security architecture converging network access and security services into a single cloud-delivered platform. Zscaler and Cloudflare both offer SASE-aligned products combining private access and internet security.

SMB (Server Message Block): The Windows protocol for shared file server access. Requires TCP/UDP protocol support. Covered by Entra Private Access, Zscaler ZPA, and Cloudflare with WARP. Not covered by Application Proxy.

Split-tunnelling: A VPN configuration routing only traffic destined for defined internal network ranges through the VPN tunnel. All other traffic goes directly to the internet from the client device, bypassing enterprise security controls. Shifts the effective security boundary from the enterprise gateway to the client device's local firewall.

SSH (Secure Shell): A cryptographic protocol for secure remote command-line access to servers. Primary use case for HashiCorp Boundary in privileged infrastructure access scenarios.

SSL/TLS (Secure Sockets Layer / Transport Layer Security): Cryptographic protocols providing encrypted communications over a network. TLS is the current standard; SSL is the predecessor but the terms are often used interchangeably in the context of SSL VPN. The same encryption that secures VPN connections also prevents gateway inspection of the tunnel contents.

SWG (Secure Web Gateway): A security service inspecting web and internet traffic for threats and policy violations. Effective only on traffic that passes through it. Split-tunnel bypass traffic and traffic inside encrypted VPN tunnels are both invisible to SWG without explicit decryption.

TLS inspection (SSL inspection): A gateway technique that decrypts, inspects, and re-encrypts TLS traffic to restore DPI and DLP visibility. Computationally expensive, introduces latency, creates certificate trust issues with some applications, and raises privacy considerations where personal traffic traverses the inspection path. Frequently incomplete in practice.

VPN (Virtual Private Network): A technology creating an encrypted tunnel between a remote device and a corporate network gateway, giving the device network-level access. Designed for an era when the corporate network was the security perimeter. The encryption securing the tunnel also prevents gateway inspection of its contents.

Zero Trust / ZTNA (Zero Trust Network Access): A security model and associated technology category based on never trust, always verify. Access decisions are based on verified identity, device health, and context -- not network location. ZTNA grants access to specific applications or resources only, without extending network access to the client device. Eliminates the bridging risk, traffic inspection gap, and over-privileged access that characterise legacy VPN.

ZPA (Zscaler Private Access): Zscaler's enterprise ZTNA product. Uses cloud-hosted app connectors to broker access between users and internal resources via Zscaler's cloud, providing inline traffic inspection capability. Typically deployed alongside Zscaler Internet Access (ZIA) for a complete SASE architecture.

Is Your Remote Access Architecture Fit for Purpose?

CyberCQR provides independent remote access architecture reviews and Zero Trust transition roadmaps for boards and technology leadership in UK regulated industries. We assess your current split-tunnel configuration, identify bridging, inspection, and RaaS exposure, and build a practical migration plan using the tools your organisation already holds.

Schedule a Consultation