VPN has served organisations faithfully for decades. It was the right tool for the problem it was designed to solve: giving remote workers a secure tunnel back into the office. The trouble is, the office has changed almost beyond recognition over the last decade, and VPN hasn’t changed with it.
Today, the average organisation runs a mix of on-premises infrastructure, cloud-hosted applications, SaaS platforms, and a workforce that connects from laptops, home broadband connections, and coffee shops. The secure tunnel back to a central firewall, which is the core concept of a VPN, doesn’t make sense when the applications aren’t behind that firewall anymore.
But the more fundamental problem with VPNs isn’t architectural. It’s about trust.
The Trust Problem
VPN operates on a binary model: you’re either in or you’re out. Authenticate successfully and you’re on the network. Once you’re on the network, you can, in most, if not all, organisations, reach most things within that network.
This setup made sense when every user was an employee on a managed device and every application lived in the data centre. It doesn’t make sense when contractors use personal devices, when applications live in Azure or AWS, and when the biggest security threats come not from external attackers forcing their way past the perimeter but from compromised credentials walking straight through it.
IBM’s Cost of a Data Breach Report ranked stolen credentials as the #1 initial attack vector in 2024, responsible for 16% of breaches and averaging USD 4.81M in damage per incident — with credential-based attacks taking a combined 292 days to identify and contain, the longest of any attack vector. In 2025, phishing overtook credentials at the top, fuelled by AI-generated messages that cut drafting time from hours to minutes. VPN doesn’t help with either threat. It makes both worse.
If an attacker obtains a valid username and password, either stolen, through phishing, or credential stuffing, or by purchasing them from a dark web marketplace, a VPN hands them the keys to your network. No questions asked. No device check. No contextual verification. They’re in.
From there, the same flat network that makes life easy for your IT team makes life easy for them too. They can move laterally, escalate privileges, reach sensitive systems, and extract data — often going undetected for weeks or months.
The Perimeter Is Gone
There’s a related problem that has crept up on IT teams gradually: the network perimeter that VPN was designed to protect no longer exists in any meaningful sense.
When your CRM lives in Salesforce, your email and collaboration in Microsoft 365, your development environment in AWS, and your finance system in a SaaS application, there is no inside and outside. There’s just a collection of services that need to be accessible to the right people under the right conditions.
Routing all of that access through a central VPN gateway doesn’t secure it — it creates a bottleneck, degrades performance, and gives users an incentive to find workarounds. IT teams regularly discover that staff are bypassing the VPN to access cloud applications directly because the experience is unusably slow. That’s not a user behaviour problem. That’s a signal that the architecture doesn’t fit the environment.
What the NCSC Is Actually Saying
The National Cyber Security Centre published its Zero Trust Architecture guidance in 2021 and updated it in 2023. The guidance is explicit: organisations should stop relying on implicit trust granted by network location and move toward a model where every access request is evaluated on its own merits — identity, device posture, context, and risk level.
This isn’t a future-looking aspiration. For government organisations, it’s an expectation. Cyber insurers are heading in the same direction: an increasing number of policy questionnaires now ask specifically about ZTNA adoption, endpoint compliance checking, and per-session access controls. VPN alone no longer satisfies those requirements.
What Replaces It
Zero Trust Network Access (ZTNA) is not a single product — it’s a security model. Instead of connecting a user to the network, it connects them to the specific application they need, after verifying who they are, what device they’re on, and whether that device meets your security standards.
The practical effect is significant. An attacker with a compromised credential can’t use it to move across your network, because ZTNA doesn’t grant network access. They’re granted access to specific, authorised applications — and only after clearing a series of checks that a stolen password alone cannot satisfy.
Applications can be hidden from the internet entirely. If an attacker doesn’t know your applications exist at a given address, they can’t attack them directly. The ZTNA application gateway is the only exposure — and it verifies everything before passing traffic through.
The Migration Question
The most common objection to moving away from a VPN is that it’s a major project — a rip-and-replace that requires re-engineering access controls across every application. That’s not accurate.
A well-architected ZTNA implementation is typically deployed alongside VPN initially, with applications migrated progressively. For organisations running FortiGate firewalls — already widely deployed across the public sector — FortiClient ZTNA capabilities are built into FortiOS 7.0 onwards. The infrastructure is likely already in place.
The starting point isn’t a full migration. It’s an honest assessment of where your current access model leaves you exposed and a plan that addresses the highest-risk gaps first.
One data point worth noting: IBM’s 2025 Cost of a Data Breach Report found that organisations using AI and automation extensively in their security operations contained breaches 80 days faster than those that didn’t and saved an average of USD 1.9 million per incident. ZTNA is a foundational component of the architecture that makes that level of visibility and control possible.
Take our free Zero Trust Readiness Assessment, it is a structured, independent review of your current access model mapped to NCSC ZTA guidance. No commitment required.