We have a small number of employees who work from home at least four days a week, and we currently use Azure VPN for remote access. I'm evaluating whether to move to a ZTNA platform such as Twingate, ZeroTier, Fortinet ZTNA, or possibly an Entra-based option. We already have FortiGate devices on-premises and in the cloud, and we use BunkerWeb as a WAF.
I understand the general Zero Trust benefits, such as identity-based access and limiting users to specific applications instead of giving them broad network access. However, I need to explain the practical benefits to management, especially how access should work when a user is physically in the office. Should the same ZTNA policies apply both on and off the corporate network, or should office users bypass ZTNA?
Our current Azure VPN also has reliability problems. When users lock their laptops or remain idle, the connection may drop. Internal DNS can then stop working correctly, applications return 403 errors, and users may lose unsaved work. Would ZTNA help with this kind of experience, or would it simply introduce another layer of complexity? If you had this environment and only a few remote users, would you replace Azure VPN, keep it, or use ZTNA selectively?
5 Answers
Since you already operate FortiGate devices in both environments, I would first evaluate Fortinet’s ZTNA capabilities before adding Twingate, ZeroTier, or another separate platform. A third remote-access product can create more agents, policies, support cases, and licensing to manage.
A sensible migration would be to keep Azure VPN temporarily, select a few applications, and pilot Fortinet ZTNA with the remote users. Measure connection stability, application compatibility, policy granularity, user experience, and audit reporting. Move more workloads only if the pilot demonstrates a real improvement.
The strongest security argument for ZTNA is application-level access rather than network-level access. For example, a Finance employee could be allowed to reach a file share over SMB without automatically getting the ability to RDP to the file server or scan other internal systems.
A well-designed ZTNA service also avoids exposing inbound services to the internet. The connector inside your environment establishes an outbound connection to the provider, and the user is authenticated to the service edge. That can reduce the attack surface compared with publishing or broadly routing into the network through a VPN.
ZTNA is not automatically better in every environment. Its main advantages are least-privilege application access, identity- and device-aware policies, reduced network exposure, and often simpler access for users who only need a few services. It does not automatically fix application errors, dropped sessions, or unsaved work.
For management, frame the decision around specific outcomes instead of the product label: what resources users can reach, how compromised devices are contained, whether inbound exposure is reduced, how reliably sessions survive sleep and network changes, and what the ongoing cost and support burden will be. A hybrid approach is perfectly reasonable.
With only a few users, I would avoid replacing a working VPN purely because ZTNA is the newer term. First compare the actual goals: reliable connectivity, MFA, device compliance, least-privilege access, logging, and administrative overhead.
If users need broad network access, keeping Azure VPN may be simpler. If they only need a handful of internal web applications, file services, or specific remote tools, ZTNA can be introduced selectively without exposing an entire subnet. Test the VPN disconnect and DNS behavior first, because a client configuration, idle timeout, DNS design, or device sleep policy may be the real problem.
Users do not necessarily need a different security model just because they are in the office. You can enforce the same identity, device, and application policies on and off the corporate network. Depending on the product, office traffic might use a local connector or private access path, while remote users go through the cloud service.
That said, simply allowing anything on the office LAN and applying Zero Trust only at home defeats much of the model. Network location can be one signal, but it should not be the only thing that determines access.
The main reason I started looking is that the Azure VPN client frequently disconnects when a laptop is locked or idle. Internal DNS then fails and applications return 403 errors, which is especially frustrating when users lose unsaved work. I’m trying to determine whether ZTNA would solve that reliability problem rather than just provide a different security model.