The VPN was designed to solve a clear problem: create an encrypted connection from an untrusted network into the enterprise environment. For years, that model worked because applications, employees, and data mostly lived inside a recognizable corporate boundary.
Hybrid work changed the geometry. Users now connect from corporate offices, homes, hotels, partner locations, and mobile networks. Applications sit across SaaS, public cloud, private cloud, and data centers. Devices may be corporate-managed, personally owned, shared, or operated by third parties. A secure tunnel still protects traffic in transit, but it does not answer the more important questions: which application should this person reach, from this device, under these conditions, right now?
That is the practical difference in the VPN vs. ZTNA discussion. VPN extends network connectivity. Zero Trust Network Access makes access a resource-level decision based on identity and context. The transition is not simply a product replacement. It changes how applications are published, how policies are written, what endpoint information is required, and how access is monitored.
A VPN authenticates a user or device, establishes an encrypted tunnel, and places that connection within an allowed network context. It remains useful for administrators who need broad protocol access, legacy applications that cannot sit behind an application proxy, site-to-site connectivity, and specific recovery scenarios.
The risk appears when authentication is treated as the end of the trust decision. Once connected, a user may be able to see or reach more of the network than the task requires. Segmentation and firewall policy can narrow that reach, but many environments accumulated VPN groups, routes, and exceptions over years. The effective permission is often broader than the identity team's role description suggests.
A compromised credential or unhealthy endpoint can therefore create a larger path for discovery and lateral movement. CISA has specifically urged organizations to evaluate modern approaches such as zero trust, SSE, and SASE while addressing the vulnerabilities and business risks associated with traditional remote-access and VPN misconfiguration.
NIST describes zero trust as a model in which no implicit trust is granted because of network location or asset ownership. Authentication and authorization of both the subject and the device occur before a session to an enterprise resource is established. The focus moves from protecting a network segment to protecting the resource itself.
Instead of connecting a user to a network and then controlling what happens inside it, ZTNA grants access to a named application or resource. The user receives the access needed for the task without inheriting general network visibility. This reduces the value of a stolen credential because the permitted path is narrower.
A username and password do not describe whether the connecting device is managed, patched, encrypted, running required protection, or displaying risk signals. ZTNA policy can combine user identity, device identity, posture, role, application sensitivity, and other context before allowing the session.
The decision is not assumed to remain valid indefinitely. NIST's implementation guidance describes real-time, continuous, policy-driven risk assessment to establish and maintain access. If device posture changes or the session no longer meets policy, access can be reduced or removed rather than waiting for the next login.
A user sitting inside an office is not automatically trusted, and a remote user is not automatically treated as exceptional. The same application access policy can follow the user and device across locations. This creates a more consistent model for hybrid work and reduces the policy split between on-network and off-network access.
ZTNA can narrow access, but it requires more accurate inputs. An organization needs a reliable identity source, consistent role definitions, endpoint visibility, application ownership, certificate and agent strategy, and a policy model that teams can support. Weak identity hygiene does not become strong simply because the access gateway uses zero-trust terminology.
Application inventory is often the hardest part. Teams know the major SaaS platforms but may miss internal web tools, thick-client dependencies, shared services, administrative interfaces, hard-coded network paths, and third-party support workflows. Publishing an application through ZTNA without mapping those dependencies can create failures that appear random to users.
User experience also requires design. The ideal state is low-friction access that applies policy in the background. Poorly coordinated identity prompts, certificate problems, posture checks, or overlapping agents can make the new model feel more intrusive than the VPN it replaces. Security and experience must be tested together.
For many user-to-application scenarios, ZTNA can replace broad remote network access with more granular control. That does not mean every VPN should disappear immediately. Some protocols, administrative tasks, machine-to-machine connections, unmanaged devices, and legacy applications may still require a tunnel or a different access pattern.
The better objective is not 'eliminate VPN' as a slogan. It is 'remove unnecessary network-level access.' Organizations can reserve VPN for the smaller set of use cases that genuinely require it while moving suitable applications to ZTNA. This coexistence model reduces risk without forcing an all-or-nothing migration.
Map who connects, from which devices, to which applications, using which protocols, and for what business purpose. Include employees, contractors, partners, administrators, service desks, and vendors. Review actual logs because group names rarely tell the full story.
Start with applications that have clear ownership, stable identity integration, compatible protocols, and a defined user population. Separate straightforward web applications from legacy or privileged workloads that need deeper testing.
Decide what constitutes a trusted device for each application class. Requirements may include corporate enrollment, supported operating system, encryption, active endpoint protection, patch level, certificate presence, or a clean risk state. Avoid one universal posture rule when application sensitivity differs.
Measure successful connection rate, authentication time, support tickets, policy denials, application performance, and the reduction in network-level exposure. A pilot should prove both security and usability before the next application group moves.
Document which VPN paths remain, how conflicting policies are avoided, what happens during an identity or endpoint-management outage, and how users recover from failed posture checks. Migration is safer when the exception path is deliberate instead of improvised.
Fortinet Universal ZTNA uses FortiClient to provide user, device, and posture information; FortiClient EMS to manage endpoint policy and tags; and FortiGate as an application access enforcement point. Fortinet states that policy can apply on-network and off-network, allowing applications to move from VPN to ZTNA over time.
That common platform can simplify transition where FortiGate already protects data-center, branch, or cloud environments. Implementation still depends on application mapping, identity integration, endpoint readiness, policy design, testing, and user support.
Learn More about Condado’s Fortinet practice →
Measure the VPN vs. ZTNA transition by how many users retain network-level access, how many applications use per-session policy, how often posture remediates an unhealthy device, and how quickly access can be revoked. Confirm that application discovery and lateral reach have narrowed.
Balance those measures with connection success, sign-in time, repeated prompts, help-desk volume, false positives, and application latency. A VPN vs. ZTNA migration succeeds when access becomes narrower and more adaptive without making legitimate work harder.
The VPN remains a useful technology, but its broadest implementations reflect a world in which the network boundary carried more meaning than it does now. ZTNA shifts control toward the application, the user, the device, and the current session.
The most effective transition is selective and evidence-led. Map access, strengthen identity and endpoint signals, move suitable applications first, and retain network-level connectivity only where the requirement is real.
Work with Condado to identify where Fortinet Universal ZTNA can reduce network-level exposure and build a phased migration plan.
Get in touch →
The following primary sources informed the definitions, security model, migration guidance, and Fortinet architecture described in this article.
Renewing your CMS may seem easier than switching, but hidden costs and publishing bottlenecks can make staying expensive. Use these six questions to decide whether to renew, optimize or migrate.
Condado has become part of One Primero — a consolidated operating brand bringing Condado's contact center expertise and Tricension's technology delivery capability together under one name. Same team, same relationships. New name.
