The VPN is doing a job it was never designed for
The corporate VPN was built for a world that no longer exists: a fixed office, a trusted internal LAN, and a handful of remote workers dialling into it after hours. That model assumed everything inside the tunnel was safe and everything outside was suspect. In our engagements across banking, telecom, and critical infrastructure, we keep meeting the same failure mode. An attacker phishes one set of credentials, connects over the VPN, and lands on a flat internal network where they can reach far more than the one application the user actually needed.
The market has already moved. IDC's 2024 research on Zero Trust Network Access put China's ZTNA solution market at roughly RMB 2.64 billion, growing about 13.5% year on year, with the software-defined perimeter segment growing closer to 16%. Those are regional figures, but the direction is the same everywhere we work in the UAE and wider GCC: double-digit growth in access controls that verify every request instead of trusting a network location. Cyber Magazine framed the reason well in its coverage of zero trust adoption, noting that in some modern workspaces non-human identities, the service accounts and AI agents acting with real privilege, now outnumber human users by as much as 100 to 1. A perimeter you can VPN into was never going to police that.
This is not a call to rip out your VPN next week. It is a practitioner's account of what Zero Trust Network Access and SASE actually replace, where teams get the migration wrong, and how we sequence the work so production keeps running while the old tunnel is retired.
What "zero trust network access" actually replaces
Strip away the marketing and ZTNA is a simple idea. Instead of granting a device a route onto the network and then hoping segmentation contains it, you put a broker in front of every application. A user or workload requesting access is authenticated, the device it is coming from is inspected, and a policy decision is made per application, per session. If any signal fails, the connection is never established. The application stays dark to everything that has not passed the check, which is why the approach is often built on a software-defined perimeter.
The contrast with a VPN is stark. A VPN authenticates once, at the edge, and then hands the client an IP address on the inside. From that point the network trusts the packets. ZTNA never grants that implicit trust. The broker mediates each connection and re-evaluates it continuously, so a compromised laptop does not become a compromised network.
The three planes you are really buying
When we scope a ZTNA project, we tell clients they are buying three capabilities that have to work together, not a single box.
The first is identity. This is the foundation, and it has to be solid before anything else matters. That means a single authoritative identity provider, federation through SAML or OIDC, provisioning and de-provisioning through SCIM, phishing-resistant multi-factor authentication, and conditional access policies that key off risk. If your identity layer is weak, ZTNA simply moves the weakness closer to your applications.
The second is device posture. The broker should refuse a session from an endpoint that is not managed, not encrypted, missing its endpoint detection and response agent, or running an out-of-date OS. This is where a lot of the real security value lives, and it is the part teams most often defer.
The third is per-application policy. Access is scoped to the specific application and the specific action, tied to the user's role and the sensitivity of the data. A contractor reaching one internal web app should never gain a path to the finance file server as a side effect of connecting.
SASE: where ZTNA, SWG, CASB and FWaaS converge
ZTNA solves inbound access to private applications. It does not, on its own, secure the traffic your users send out to the internet and to SaaS. That is why the two trends are converging. Secure Access Service Edge, or SASE, is the delivery model that folds several controls into one cloud-delivered layer that sits between users and everything they reach.
In practice a SASE stack combines ZTNA for private applications, a secure web gateway for outbound web filtering and inspection, a cloud access security broker for governing SaaS usage and data movement, and firewall-as-a-service for network-layer policy. IDC's analysts described this convergence plainly: to cover hybrid work, cloud-native environments, and data protection at the same time, access solutions are evolving into integrated platforms that consolidate network, identity, endpoint, and data controls under one policy engine and one place to run security operations.
The practical payoff is that a user in Dubai, a branch in Abu Dhabi, and a developer working from home all get the same policy applied at the nearest edge, without hair-pinning their traffic back through a data-centre firewall over a VPN. The operational payoff is that your team stops stitching together five consoles that each hold a fragment of the truth.
How VPN and ZTNA/SASE compare
DimensionLegacy VPNZTNA / SASE
Trust model
Trust the network after one login
Verify identity, device and context every session
Blast radius
Lateral movement across a flat internal network
Access scoped to a single application
Visibility of assets
Applications reachable once connected
Applications dark until policy passes
Device checks
Usually none beyond the client software
Posture required: managed, encrypted, EDR present
User experience
Tunnel up or down, often slow and back-hauled
Direct-to-app at the nearest edge
Non-human identities
Poorly handled; shared service accounts
Brokered and scoped like any other principal
SaaS and web traffic
Out of scope
Covered by SWG and CASB in a SASE stack
Where teams get this wrong
Most ZTNA projects that stall do so for reasons that have nothing to do with the technology. Here are the patterns we see most often.
The first is treating ZTNA as a VPN with a nicer login. Teams deploy the broker, then point it at the same flat network segment the VPN used to drop people onto. Now every application is still reachable once you are past the front door. The point of the exercise was to scope access per application, and that only works if you actually publish applications individually and write policy for each.
The second is building on a shaky identity foundation. If accounts are still provisioned by hand, multi-factor authentication is optional, and there is no single source of truth for who works where, ZTNA will inherit all of it. We have walked into environments where the same person existed as three separate accounts across systems. No access broker can make good decisions on top of that.
The third is skipping device posture to hit a go-live date. Posture is the control that stops a genuine credential on a compromised or unmanaged machine, and it is exactly what a VPN never gave you. Deferring it "until phase two" quietly removes most of the security upside on day one.
The fourth is forgetting the human layer. One of the most damaging incidents we were called into started not with a network exploit but with a business email compromise, an attacker impersonating a trusted contact over a collaboration platform to move a conversation, and then money. Access controls matter, but so does hardening the identity and collaboration surfaces that social engineering targets: external access rules on Teams and email, conditional access on the tenant, and tight control of guest accounts. Zero trust is a program that spans identity, endpoints, network and people, not a single appliance.
A phased migration that does not break production
Zero trust cannot be switched on in a weekend, and IDC's own guidance is that it has to be built in stages, with planning, capability and ongoing operations treated as one continuous effort rather than a one-off install. That matches how we run these projects. The sequence below is the one we use to retire a VPN without an outage.
Assess and inventory. List every application people reach over the VPN, who uses each one, and what data it holds. Include the machine identities, the service accounts and automation that also ride the tunnel. You cannot scope access to applications you have not enumerated.- Build the identity foundation. Consolidate onto one identity provider, turn on SCIM provisioning and de-provisioning, enforce phishing-resistant MFA, and define conditional access by risk. This phase delivers value on its own, independent of ZTNA.
- Pilot in parallel. Stand up the ZTNA broker for a small, well-defined set of applications and a friendly user group, running alongside the VPN. Prove the policy model, the posture checks and the user experience before you touch the wider estate.
- Roll out and enforce posture. Publish applications one at a time, moving user groups over as each is proven. Turn on device posture as a hard requirement rather than a warning. Watch your logs, not just your tickets.
- Decommission and operate. Once traffic has drained from the VPN, retire it and close the inbound firewall rules it needed. Then treat zero trust as an operational discipline: review policies, tune posture, and fold the access logs into your SOC or SIEM.
Do not forget OT and the machine identities
Two areas deserve special attention for the sectors we serve in the region. The first is operational technology. In utilities, energy and other critical national infrastructure, the zero trust conversation is still early, and the naive approach of dropping an IT access broker in front of a control network does more harm than good. Segmenting IT from OT, brokering the few legitimate cross-boundary flows, and doing it without disturbing safety and availability is careful work. It is worth doing precisely because a flat VPN into that environment is the nightmare scenario.
The second is the non-human identity problem Cyber Magazine highlighted. Service accounts, API clients and, increasingly, AI agents now act inside your systems with standing privilege. IDC expects generative AI to work both sides of this: helping security teams by analysing behaviour and adjusting policy dynamically, while also raising the stakes if those same agent identities are left unmanaged. If your access model only understands human users logging in each morning, it is blind to most of what actually touches your data. Bring machine identities under the same brokered, scoped, continuously-verified model as everyone else.
A short readiness checklist
- Do you have a single authoritative identity provider, with SCIM provisioning and phishing-resistant MFA enforced?
- Can you produce a current inventory of the applications, users and service accounts that use your VPN today?
- Do your endpoints report posture (managed, encrypted, EDR present, patched) that a policy engine can read?
- Are your internal applications individually addressable, or is everything behind one flat network segment?
- Have you mapped how zero trust aligns to the framework you report against, whether NIST CSF, ISO 27001, or CIS Controls?
- Do you have a plan for IT/OT segmentation and for governing machine and AI-agent identities?
If you answered no to two or more of these, start with the identity and inventory work. That is where the real project lives, and it pays off whether or not you ever buy a ZTNA product.
How Aydahwa Enterprise can help
We plan and deliver zero trust and SASE programs for organisations across the UAE and GCC, from mid-market firms retiring an ageing VPN to banks and critical-infrastructure operators with strict availability and compliance constraints. Our work is grounded in real infrastructure engineering: identity provider consolidation and conditional access, device posture and endpoint hardening, IT/OT segmentation, and mapping the whole effort to the standards you are audited against, including ISO 27001, PCI-DSS, NIST CSF and CIS Benchmarks.
A good place to begin is understanding where you stand today. Our free cybersecurity self-assessment and readiness checklist give you a fast, honest baseline. From there, our cybersecurity services cover the identity, posture and policy foundations a ZTNA rollout depends on, our cloud security and migration practice handles the SASE and cloud-native side, and our managed IT and support team keeps it running once the VPN is gone. If you are weighing a migration and want a straight answer on sequencing and effort, talk to us.
