The VPN was built for a network that has quietly disappeared
A VPN concentrator sitting in a data centre, backhauling every remote user's traffic to head office before sending it back out to the internet, made sense when the applications lived in that same building. Most of them don't anymore. The email is in Microsoft 365, the CRM is SaaS, the workloads are split across Azure and AWS, and half the people connecting are contractors or third-party integrators who never had a desk in your office to begin with. The tunnel still terminates where it always did, but almost nothing it protects is on the other side of it.
IDC's Future Enterprise Connectivity predictions put a number on how far the industry has moved: its 2024 global SD-WAN survey found that roughly 75% of organisations had already deployed or planned to deploy Secure Access Service Edge (SASE) architecture, and IDC expects that by 2026 around 60% of enterprises will be delivering networking and security capabilities in an as-a-service model rather than as boxes in a rack. Cyber Magazine framed the same shift more plainly in its network security coverage: work is no longer contained by office walls, data now lives everywhere, and attackers have simply followed it to the expanded attack surface.
We've spent enough time inside enterprise networks across the GCC to know that the interesting question is not whether SASE is coming. It is how you get there from a working VPN estate without a painful cutover, a blown compliance obligation, or a week of tickets from users who can suddenly no longer reach the one application they actually need. This is a walk through that migration from the practitioner's chair.
What is SASE, and why is it replacing the VPN?
SASE is less a product than a way of packaging several things you already run. It combines wide-area networking (SD-WAN) with a set of cloud-delivered security functions that the industry groups under Security Service Edge, or SSE. Strip away the marketing and SSE is four familiar controls delivered from a provider's points of presence rather than from your data centre: a secure web gateway (SWG) for outbound traffic, a cloud access security broker (CASB) for SaaS, zero trust network access (ZTNA) for private applications, and firewall-as-a-service (FWaaS) for the rest. Data loss prevention usually rides along inside those components.
The part that directly displaces the VPN is ZTNA. A traditional VPN authenticates a user once, then drops them onto the network. From that point the tunnel behaves like an ethernet cable stretched from the user's laptop into your LAN, and the user can reach anything the routing and firewall rules allow, whether they need it or not. ZTNA inverts that model. It authenticates the user and the device, checks posture, and then brokers a connection to one named application, without ever placing the user on the network. The user never gets an IP address on your internal subnet, so there is nothing to scan, pivot from, or move laterally across. That single change is why the model matters, and it is the reason IDC and others keep coupling the phrases "SASE" and "zero trust" in the same breath.
Where the legacy VPN actually hurts
Before recommending any replacement, it is worth being honest about the specific ways the old model fails, because those failure points are what your migration has to fix. In engagements we see the same handful repeatedly.
The first is flat access. Once a user or a compromised laptop is on the VPN, network-level reachability is far broader than anyone intended. Segmentation on the internal side is usually coarse, so a phished contractor account becomes a foothold with a view of file shares, management interfaces, and sometimes the backup network. Ransomware crews rely on exactly this: get one tunnel, then move sideways.
The second is the concentrator as a bottleneck and a single point of failure. Backhauling cloud-bound traffic through a central appliance adds latency for users who are nowhere near it, and every capacity upgrade means sizing hardware for peak concurrency you hope never arrives. Anyone who scaled VPN capacity overnight in early 2020 remembers what that felt like.
The third is authentication bolted on after the fact. Many VPNs still treat multi-factor authentication as an add-on rather than a gate, device posture is rarely checked at all, and access does not re-evaluate mid-session. A stolen certificate or a reused password is often enough. The fourth, and the one that causes the most quiet risk, is third-party access. Vendors and integrators frequently get the same broad VPN profile as staff because building a tighter one was too much effort, which means your attack surface now includes the security hygiene of companies you don't control.
ZTNA versus VPN, side by side
The two models are easy to conflate because both give a remote user access to internal resources. What differs is everything about how that access is granted, scoped, and observed.
DimensionLegacy VPNZTNA / SASE
Trust model
Authenticate once, then trusted on the network
Per-request verification of user, device, and context
Access scope
Network segment or full LAN
A single named application, nothing else
Lateral movement
Possible once connected
No network placement, so no lateral path
Device posture
Rarely checked
Checked before and during the session
Traffic path
Backhauled through a central concentrator
Brokered at a nearby cloud POP, direct to app
Third-party access
Usually the same broad profile as staff
Scoped per application, time-boxed if needed
Visibility
Connection logs, little application context
Per-user, per-application access records
The comparison is not an argument that VPNs were badly built. They did their job for a perimeter that existed. The point is that the assumptions underneath them, a trusted inside and a hostile outside, stopped holding once the inside moved to the cloud.
A migration path that does not require a big-bang cutover
The mistake we see most often is treating the move as a network project when it is really an identity project wearing a network costume. Get the sequence right and you can run VPN and ZTNA in parallel for months, moving application groups across at a pace your operations team can absorb. A workable order looks like this.
- Fix the identity foundation first. ZTNA is only as strong as the identity provider behind it. Consolidate onto a single IdP such as Microsoft Entra ID or Okta, enforce phishing-resistant MFA (FIDO2 where you can), and clean up the joiner-mover-leaver process. If dormant accounts and shared logins still exist, solve that before anything else, because zero trust with weak identity is theatre.
- Inventory the applications, not the subnets. List what people actually reach over the VPN and who reaches it. Most organisations discover a long tail of internal apps nobody documented, plus a few that will need special handling: thick clients, server-initiated connections, and anything with hardcoded IPs.
- Start with the highest-risk, lowest-complexity group. Third-party and contractor access is usually both. Move those users to ZTNA first, scoped to the one or two applications they need. You reduce real risk immediately and prove the model on a population that will not generate a flood of internal escalations.
- Layer in SSE for outbound and SaaS. Once private-app access is brokered, bring web traffic and SaaS under SWG and CASB, and fold DLP policy into both. This is where you regain the visibility the split-tunnel VPN quietly gave up.
- Decommission the concentrator deliberately. Only when an application group is fully served by ZTNA do you remove its VPN route. Keep a documented break-glass path for emergencies, and do not delete the old firewall rules until you have watched the logs go quiet.
- Make posture and access continuous. Feed access logs into your SIEM, review entitlements on a schedule, and treat device posture as an input that can revoke a session, not a one-time check at login.
The pitfalls worth naming
A few traps have cost teams real time and money, and none of them show up in a vendor demo.
Treating SASE as a single-vendor purchase is the first. The single-vendor pitch is attractive for operational simplicity, and for many mid-market organisations it is the right call, but it can leave gaps where one vendor's CASB or DLP is weaker than the rest of the stack. Decide consciously which components you are willing to accept as "good enough" and which you would rather source separately.
Forgetting east-west and operational technology is the second. ZTNA solves user-to-application access. It does not, by itself, address server-to-server traffic inside the data centre or the OT and ICS networks that many of our clients in utilities and critical infrastructure run. Those need their own segmentation strategy, and assuming SASE covers them is how gaps get left open.
Underestimating the POP and latency question is the third. The performance benefit of a cloud broker depends on a point of presence being genuinely close to your users. For teams concentrated in the UAE and the wider GCC, confirm where a provider's regional POPs actually sit before you sign, rather than trusting a global coverage map. DNS behaviour and certificate handling also need testing early, because they are the two things that break silently.
The last is skipping the compliance mapping. If you cannot show an auditor how the new model satisfies your access-control obligations, you have traded one problem for another.
How this maps to the frameworks you already report against
A VPN-to-SASE move is not a detour from compliance work; done properly it strengthens your posture against the standards most GCC enterprises are already measured on. Under ISO/IEC 27001, the access-control objectives in Annex A map cleanly onto least-privilege, per-application access and stronger authentication. The NIST Cybersecurity Framework's Protect function, and its identity management and access control category in particular, is close to a description of what ZTNA does. For anyone handling cardholder data, PCI DSS has been pushing toward tighter network segmentation for years, and brokered per-application access is a defensible way to shrink the scope that has to be assessed. The CIS Critical Security Controls covering account and access management give you a practical checklist to hold the implementation against. The migration is a good moment to align these on purpose, rather than reverse-engineering the evidence at audit time.
The market is moving the same way, globally
This is not a regional experiment. The IDC data that opened this article showed the China SASE market growing 37.8% year on year to roughly 1.14 billion yuan in 2024, with established names like Sangfor, Huawei, and China Telecom competing hard for share. That is one market, but the direction it points is the same one IDC's global figures describe and the same one we see in procurement conversations here: networking and security are converging into a service, buyers want fewer appliances and more measurable control, and the vendors are consolidating features to match. The specifics of who leads will keep shifting. The architectural shift underneath, from a trusted perimeter to identity-brokered access, is settled.
For an organisation running a healthy VPN today, none of this is a reason to panic or to rip anything out this quarter. It is a reason to make sure the next refresh cycle moves you toward the model the rest of the industry is standardising on, rather than buying another three years of the old one.
How Aydahwa Enterprise can help
Aydahwa Enterprise plans and delivers this kind of transition for organisations across the UAE and the wider GCC, drawing on real infrastructure and security engagements in banking, telecom, and critical national infrastructure. Our team holds credentials that matter for this work, including the Microsoft Cybersecurity Architect Expert certification, and we build to the standards our clients report against: ISO/IEC 27001, PCI DSS, the NIST Cybersecurity Framework, and the CIS Controls.
A typical starting point is an honest assessment of where your current remote-access and network estate leaves you exposed, followed by a phased plan you can actually staff. If you want to gauge your own position first, our free cyber security self-assessment and cybersecurity readiness checklist are a sensible first hour. From there, our cybersecurity and cloud services teams can design and run the migration, and our managed IT support keeps it healthy afterward. When you are ready to talk specifics, get in touch and we will start with your applications and your users, not a vendor's slide deck.
