What Is ZTNA? Zero Trust Access That Replaces the VPN

What is ZTNA? Zero Trust Network Access is a remote-access model that connects a user only to the specific application they are authorized to use, and re-verifies identity, device security posture and context on every session. It replaces the classic VPN approach of "authenticate once, then admit to the whole network".

What Is ZTNA and What Does Zero Trust Mean?

ZTNA applies the principle "no user, device or network location is implicitly trusted" to remote access. The user first proves identity, the device passes a security posture check, and only then is a connection opened to the one application the policy allows, for that session only. The rest of the network stays invisible to the user.

Zero trust is an architectural approach, not a product. The reference definition comes from the U.S. National Institute of Standards and Technology in NIST SP 800-207 Zero Trust Architecture. Its core tenets, simplified:

• All data sources and computing services are treated as resources; everything from a printer to the ERP server must be protected.
• All communication is secured regardless of network location; a request from inside the LAN is as suspect as one from the internet.
• Access is granted per session and follows least privilege.
• Access decisions rest on dynamic policy that weighs identity, application, device state and behavioural signals together.
• The enterprise monitors the integrity and security posture of every asset it owns or uses.
• Authentication and authorization are strictly enforced before access and re-evaluated as needed.
• Collected network, asset and traffic data is used to keep improving the security posture.

The same document describes a logical architecture of three components: the Policy Engine, which makes the access decision; the Policy Administrator, which turns that decision into a connection instruction; and the Policy Enforcement Point, which opens and closes the path between user and resource. ZTNA is this architecture applied to remote and hybrid workers. It solves the same problem a VPN tries to solve, connecting someone outside the office to an internal application safely, but with a different trust model.

Why Is the Classic VPN No Longer Enough?

A classic remote-access VPN authenticates the user once and then makes them a member of the internal network; access is granted to a network segment, not to an application. That implicit trust turns a single compromised account into a launch point for lateral movement, and it keeps an internet-facing VPN portal permanently exposed to attackers.

VPN carries the assumptions of the era it was designed for: applications live in the data centre, the user is on a corporate device, and the inside of the network is safe. None of the three holds in today's hybrid workplace. The four weaknesses we see most often in field projects are:

• Broad access: A user who only needs the accounting application can, in most deployments, also see the entire server VLAN once the tunnel is up.
• One-time verification: After login the tunnel stays open even if the device gets infected or the user moves to another network.
• Device blindness: A classic VPN does not know whether the connecting device runs antivirus, has current patches or an encrypted disk.
• Exposed surface: A VPN portal is by definition reachable by everyone; a vulnerability in it puts the whole organization at risk until a patch ships.

This picture has also changed Fortinet's product direction. According to Fortinet release notes, as of FortiOS 7.6.3 SSL VPN tunnel mode has been removed and replaced by IPsec VPN, which can also run over TCP port 443; existing configurations are not carried over on upgrade. On some entry-level models the removal started in earlier releases, so verify the release notes for your own model. We have collected the migration steps in our article on the SSL VPN removal in FortiOS 7.6 and the migration plan, and our FortiGate VPN configuration guide remains a valid starting point for understanding your current setup.

How Does ZTNA Work?

In ZTNA the access decision depends on three inputs rather than network location: the verified user identity, the endpoint's current security posture and the requested application. A decision point produces the policy; an enforcement point opens the connection only to the target application, only for that session, and closes it when conditions change.

The step-by-step flow is similar across vendors:

1. Request: The user opens an internal application. The ZTNA agent on the device, or a reverse proxy in browser-based access, intercepts the request.
2. Authentication: The user is verified against the corporate directory (Active Directory, Entra ID, a SAML provider); multi-factor authentication is a standard part of this step.
3. Device posture: The agent reports operating-system version, antivirus status, disk encryption, domain membership and similar attributes; these become tags.
4. Policy decision: If "user in the Finance group + up-to-date, company-managed device + ERP application" matches a rule, access is approved; otherwise it is denied.
5. Connection: Traffic is carried through the application gateway to the target application only. The application is never exposed directly to the internet, and the user cannot route to the rest of the network.
6. Continuous evaluation: If the posture degrades, for example antivirus is switched off, the tag is withdrawn and the session is terminated by policy.

Two consequences follow. First, applications go "dark": an external scan shows neither an open port nor a login page. Second, security controls attach to the connection rather than to the person; the same user reaches the ERP from a corporate laptop but sees only the webmail interface from a personal tablet. In a classic VPN that distinction can be built only with complex rule sets, and usually incompletely.

VPN vs ZTNA Comparison

The fundamental difference between VPN and ZTNA is the trust model: VPN grants access to the network and verifies once; ZTNA grants access to the application and verifies continuously. The table below sets the ten criteria decision makers ask about most side by side; each row summarizes the typical behaviour we observe in projects.

The table shows that ZTNA is a different trust model, not a "better VPN". VPN is not dead, though: IPsec tunnels between branches, some legacy UDP-based applications and VoIP scenarios are still best served by IPsec VPN. In a sound design the two coexist for a while: ZTNA carries user access, IPsec carries site-to-site and exception traffic.

Fortinet ZTNA Architecture: FortiClient, EMS and the FortiGate Application Gateway

The Fortinet ZTNA architecture consists of three components: the FortiClient ZTNA agent on the endpoint, FortiClient EMS, which converts identity and device posture into tags, and the FortiGate ZTNA application gateway, which enforces the access decision. The design was introduced with FortiOS 7.0; the FortiGate's existing IPS, antivirus and web-filtering profiles also apply to ZTNA traffic.

The division of roles is as follows:

Fortinet documentation describes the flow like this: the FortiGate connects to EMS through a Security Fabric connector and synchronizes ZTNA tags automatically; EMS pushes tag changes instantly over a persistent connection. Security posture tags are based on checks such as whether antivirus is installed, the operating-system version, whether the device is logged on to the domain, whether a given process is running, a registry value, the device's vulnerability level and the presence of a known CVE. The FortiGate can use those tags in ZTNA rules, firewall policies and NAC policies. The basic setup is documented in the Fortinet FortiOS administration guide.

Access comes in two forms. The HTTPS access proxy publishes web applications and sessions wrapped in HTTPS such as RDP, SSH and VNC, from a browser or through the agent. TCP forwarding serves non-web client-server applications: FortiClient intercepts requests to defined destination addresses and ports and forwards them to the application gateway, so an ERP client or a database administration tool works without a network tunnel. If branch traffic and internet egress control should move to the same model, our article on SASE and the FortiSASE approach is the natural continuation of this one.

How Do You Plan a VPN-to-ZTNA Migration?

A VPN-to-ZTNA migration is not an overnight cut-over; it is a phased programme of inventory, identity, endpoint and pilot-application steps, with the VPN running in parallel for a while. In our projects the most time-consuming task is not the technology but establishing which user genuinely needs which application.

1. Application and user inventory: List every application reached over the VPN, its protocol (HTTPS, RDP, SSH, database, file sharing) and its user groups. Your VPN logs are the most honest source for this inventory.
2. Identity infrastructure: Directory hygiene, group structure and multi-factor authentication are prerequisites for ZTNA. Orphaned accounts and groups everyone belongs to make policy meaningless.
3. Endpoint preparation: Install FortiClient EMS, deploy the agent to existing devices first and collect posture tags in "monitor" mode. Device posture relies on a trustworthy endpoint protection layer; we explain which layer you need in our article on the differences between EDR, XDR and MDR.
4. Pilot: Start with one or two web applications and a volunteer user group. This phase tests policy logic and user experience at low risk.
5. Expansion: Add RDP, SSH and client-server applications with TCP forwarding rules; answer "who, with which device posture" separately for each application. The principles of FortiGate policy management apply here too, to keep the rule set lean.
6. Managing exceptions: Keep IPsec VPN with a narrow scope for UDP-based or legacy applications that ZTNA cannot cover.
7. Decommissioning the VPN portal: Once user and application coverage is complete, disable the old portal and feed access logs into central log management.

The same order applies to organizations forced away from SSL VPN after FortiOS 7.6; the only difference is that step one usually arrives together with a firmware upgrade schedule.

Is ZTNA Realistic for SMBs?

ZTNA is not reserved for large enterprises. An SMB that already runs a FortiGate can add FortiClient and EMS and enable the ZTNA application gateway on the same device. The cost drivers are the number of endpoints, whether EMS runs in the cloud or on premises, and whether branch traffic calls for FortiSASE; the figure is only settled in a quote after discovery.

In our field experience three situations make ZTNA worthwhile at small and mid-size scale. First, external contractors and outside advisers such as accountants or legal counsel: giving them a VPN means opening the whole network, whereas ZTNA exposes only the relevant application. Second, access control for personal data: least privilege and detailed access logging align with the access authorization matrix and log-keeping measures described in the Personal Data Security Guide of the Turkish Personal Data Protection Authority (KVKK); provided you verify current legislation and the official guide, ZTNA supplies the technical counterpart of those measures. Third, ransomware risk: an attacker entering the network with a VPN account and reaching the backup server is prevented by design in ZTNA.

As Sora Yazılım our approach comes from the role of an independent solution partner: in a discovery meeting we map your existing FortiGate, user profile and application inventory, draw the boundary between ZTNA and IPsec together with you, carry out the deployment and, if you wish, maintain the policies as a managed service.

Frequently Asked Questions

Does ZTNA replace VPN completely?

For users' remote access to applications, yes; ZTNA offers narrower privileges and better visibility in that scenario. For site-to-site links between branches, legacy UDP-based applications and some VoIP cases IPsec VPN remains valid. In most organizations the two run side by side for a period.

Does ZTNA always require agent software?

No. Agentless, browser-based access is possible for web applications; device posture checks and non-web applications, however, need an agent. In the Fortinet architecture that agent is FortiClient, and posture information is turned into tags by FortiClient EMS.

Is an additional license needed for ZTNA on the FortiGate?

The ZTNA application gateway on the FortiGate is a built-in FortiOS feature. FortiClient on the endpoint and a FortiClient EMS license in the centre are required. Because license scope varies by version and bundle, verify it against current Fortinet documentation and settle the full scope at the quotation stage.

What is the difference between ZTNA and SASE?

ZTNA is a single function that governs secure user access to internal applications. SASE is a broader framework that combines ZTNA with a secure web gateway, CASB, firewall as a service and SD-WAN, delivered from the cloud. FortiSASE offers ZTNA as part of that whole.

How does ZTNA contribute to KVKK compliance?

ZTNA restricts access to applications holding personal data by identity, device and application, and records every access. This aligns with the access authorization matrix and log-keeping measures in the KVKK Personal Data Security Guide; compliance is a whole, however, so verify current legislation and the official guide.

Will users experience downtime during migration?

Not when planned properly. During the pilot the VPN stays on, users move to ZTNA application by application, and if a problem appears they can return to the VPN the same day. Downtime risk is highest in projects that mass-deploy the agent before the identity infrastructure is ready.

Conclusion

ZTNA changes the trust model of remote access: application instead of network, continuous evaluation instead of one-time verification, resources invisible from outside instead of an exposed portal. The framework drawn by NIST SP 800-207 takes concrete form on the Fortinet side as the trio of FortiClient, EMS and the FortiGate application gateway; the removal of SSL VPN tunnel mode in FortiOS 7.6.3 has put this transition on the calendar for many organizations. The right order is inventory, identity, endpoint, pilot and phased expansion.

To assess together how to move your current VPN setup to ZTNA, you can request a free discovery meeting; we will prepare a quote for the FortiClient, EMS and FortiSASE scope that fits your needs.