A VPN answers one question: is this user allowed onto the network? Once the answer is yes, the user can usually reach far more than the job requires. So can anyone who steals that user's credentials.
That design made sense when a handful of staff connected from home a few times a month. It breaks down when half the workforce is remote on any given day and most applications live in the cloud.
Two Ways to Start a Monday
Under a legacy VPN. A sales manager opens her laptop at home and launches the VPN client. Her traffic, including Microsoft 365, Salesforce, and personal browsing, travels to the head office concentrator, through the data center firewall, and back out to the internet. The concentrator struggles under the morning load. Pages load slowly. A video call stutters. She disconnects the VPN to get work done, and her laptop is now on the open internet with no inspection at all.
Meanwhile, the VPN gives her a network-level connection to the corporate LAN. The file server, the ERP, and dozens of systems she never uses all sit within reach. If her credentials leak, an attacker inherits the same reach.
Under ZTNA and SASE. The same laptop connects to the nearest cloud security point of presence. Internet and SaaS traffic get inspected there, close to the user, with no trip through head office. When she opens the ERP, the ZTNA broker checks who she is, whether her device is patched and running endpoint protection, and whether policy allows this user on this device to reach this application. If all three checks pass, she gets a connection to that application only. Nothing else on the network is visible to her.
Same user. Same apps. Very different exposure.
Where Legacy VPNs Fail
The problems stack up in three places.
Performance. Backhauling all remote traffic through a central concentrator creates a bottleneck at exactly the point where every remote user converges. Scaling it means buying bigger appliances for peak demand that sits idle most of the day.
Access scope. Traditional VPN access is network access. Segmenting it properly takes complex, fragile rule sets that few organizations maintain well, so most remote users end up with far broader reach than they need.
Attack surface. VPN gateways face the internet by design, and attackers target them relentlessly. Internet-facing VPN appliances from many vendors have featured in serious exploitation campaigns in recent years. Every exposed gateway is a door that has to stay patched on the attacker's timeline, not the IT team's.
At IT Builders, our engineers often find remote access built exactly this way: a VPN sized for a smaller remote workforce, granting broad network access, with users quietly disconnecting whenever it slows them down.
Planning Your Move Away From Legacy VPN?
The right SASE and ZTNA design depends on where your users work, where your applications live, and which systems must stay on-premises.
What ZTNA Changes
ZTNA replaces network access with application access. It verifies three things on every connection request: the user's identity, the device's security posture, and the policy for that specific application. Then it brokers a connection to that application and nothing else.
Two consequences follow. Users can no longer browse the network, so a stolen credential stops at one application instead of opening the whole LAN. And the applications themselves stop listening on the internet, because users reach them through the broker rather than through an exposed gateway.
Where SASE Fits
ZTNA covers private applications. Hybrid workers also need protection for everything else they touch: the web, SaaS platforms, and cloud storage. SASE combines ZTNA with cloud-delivered secure web gateway, firewall, CASB, and DLP services, and applies them from points of presence close to the user.
FortiSASE delivers these services from the cloud while sharing FortiOS, the same operating system that runs on FortiGate. That matters more than it sounds. The organization writes one security policy and applies it to users in the office behind a FortiGate, users at home through FortiSASE, and branch sites on Secure SD-WAN. A single agent, FortiClient, handles ZTNA, SASE connectivity, and endpoint posture checks, so users don't juggle separate clients for separate services.
Multi-vendor SASE stacks can work, but they force teams to translate policy between different engines and troubleshoot across different consoles. Single-vendor SASE removes that translation layer.
What to Check Before You Choose
A few questions separate a workable SASE design from a disappointing one:
- Point-of-presence location. Where will your users' traffic be inspected, and how far is that from your offices? Latency to the nearest PoP shapes the user experience.
- Data residency. For organizations subject to Saudi regulations such as the PDPL and NCA controls, confirm where traffic, logs, and user data are processed and stored.
- Private application coverage. List every internal application remote users need, including legacy systems, and confirm how each will be published through ZTNA.
- Migration path. Plan to run VPN and ZTNA side by side, moving user groups and applications in stages rather than switching everyone over in one cutover.
The Bottom Line
VPNs give remote users too much access and too little performance. ZTNA narrows access to the applications each user actually needs, and SASE extends consistent inspection to every user wherever they connect. When the office firewall, the cloud service, and the endpoint agent share one operating system and one policy, hybrid work stops being a security exception.
IT Builders is an authorized Fortinet Engage Partner holding the SASE specialization. Our engineers map remote access requirements application by application, design ZTNA policies around real roles, and move user groups off legacy VPN in stages that keep people working.
Ready to retire the VPN concentrator?
