Replacing VPN with ZTNA inside a SASE platform

A VPN usually puts a remote user on the network, from where many systems are reachable. ZTNA grants access to one application at a time, after checking the user and device. For security teams that means a smaller blast radius; for network teams it means fewer concentrators to run. Inside a SASE platform, ZTNA shares the same policy and logs as web and SaaS controls.

Cato states its ZTNA is offered through a "ZTNA Client, Enterprise Browser, Browser Extension, and Clientless Portal", which "can coexist with current access solutions".

Source: Cato Networks homepage

Cisco describes ZTNA "client or clientless" and VPN as a Service for applications that ZTNA does not cover, with "any port or protocol" support.

Source: Cisco Secure Access

Zscaler lists Secure Private Access (ZPA) for private apps "without a VPN" and a Zero Trust Browser.

Source: Zscaler SASE

Fortinet describes agent-based and agentless options and a secure browser.

Source: Fortinet FortiSASE

Netskope lists Private Access and Remote Browser Isolation in its navigation.

Source: Netskope One

Palo Alto Networks lists ZTNA in Prisma Access and Prisma Browser.

Source: Palo Alto Networks Prisma Access

Different users need different methods. Employees on managed laptops can run an agent. Contractors and partners often cannot install software, so a clientless portal or browser-based access fits better. Legacy applications that use unusual protocols may still need a VPN-style tunnel for a while. A platform that offers several methods under one policy lets you move each group without a separate product for the exceptions.

Start with an inventory of the applications users reach over VPN today, and group them by protocol and sensitivity. Move web applications first, since browser-based access is simplest. Move thick-client applications next, with an agent. Leave the hardest cases, such as applications that need inbound connections or broad port ranges, until last, and decide whether a VPN-as-a-service bridge is acceptable for them.

Test a contractor on an unmanaged device reaching one web application through a clientless method. Test an employee moving from the office to home without dropping a session. Test an application that uses a non-web protocol. Check that every access decision appears in the same log as web and SaaS events, and that device posture checks behave as you expect.

Few organizations switch off VPN in one weekend. Ask each vendor how its ZTNA runs alongside the existing VPN during the migration, whether users need two clients, and how you route traffic for applications that have moved and those that have not. Cato states its access methods can coexist with current access solutions; ask the other vendors for the same detail in writing.

Source: Cato Networks homepage

Access methods count under deployment options, which carries 10% of the total. ZTNA itself is one of the eight components in the SASE ring, and every vendor in our set lists it.

ZTNA decisions usually depend on the device as well as the user. Ask which posture checks each access method supports: an agent can read disk encryption and patch level, while a clientless portal sees far less. Decide which applications need a managed device and which can be reached from any browser, and write that into policy before the first group moves. Ask how posture is rechecked during a long session, not only at sign-in.

Also decide what happens when a check fails. Some teams block the session outright; others step the user down to browser-only access with uploads and downloads disabled. The second keeps people working while the device is fixed, and most platforms that offer several access methods can express it as one rule.

ZTNA is on every list, so compare access methods instead. Map them to your user groups, plan the order of moves, and test the awkward cases first.