No fluff. Just the config that works. This one is the concept and the plumbing. The configuration walkthrough is the next post.

Executive Summary

Fortinet ZTNA (Zero Trust Network Access) replaces the old “connect to the network, then you are trusted” model with a per-application, per-session decision: who is the device, who is the user, is the device healthy right now, and is this exact app allowed. This post breaks down how Fortinet ZTNA works conceptually and technically, which components do what, and what actually happens on the wire when a user opens an app.

Objective: Understand the Fortinet ZTNA architecture end to end (components, trust model, request flow, access methods, deployment models, and what changed in FortiOS 8.0) before touching a single line of config.

Target audience: FortiGate administrators, network and security engineers planning a move off SSL VPN, and architects who need to explain ZTNA to the rest of the room.

Versions referenced: FortiOS 7.0 (where ZTNA landed in FortiOS), 7.4 and 7.6 (where most production deployments live today), and 8.0 (the current train). FortiClient and FortiClient EMS 7.4.x and later.

Prerequisites and Architecture

Assumed knowledge

• FortiGate firewall policies, VIPs, and security profiles
• TLS basics: certificate authorities, CSRs, server certificates, and mutual TLS (client certificates)
• An identity source: Active Directory or LDAP, RADIUS, or a SAML identity provider

Lab addressing used in this post

The components

Why ZTNA Exists: The Problem With “Connect, Then Trust”

A traditional remote access VPN does one big check at the door and then hands the user a routed path into the network. After that:

• Access is network-scoped, not app-scoped. Policies usually allow whole subnets because writing per-app rules for every VPN group is painful.
• Trust is evaluated once. Posture, if it is checked at all, is checked at connect time. A laptop that drops its EDR agent an hour later still has a tunnel.
• Lateral movement is easy. A compromised endpoint with a VPN IP can scan and reach anything the policy allows, which is usually a lot.
• The gateway is a big internet-facing target. SSL VPN portals have been one of the most attacked surfaces on the internet for years, across every vendor.

Zero trust flips the defaults: no implicit trust based on network location, verify every session, grant the least privilege needed for one application, and keep re-evaluating the device as its state changes.

The Four Questions Behind Every Fortinet ZTNA Decision

Every ZTNA session through a FortiGate has to answer four questions. Fail any one of them and the request is denied.

1. Who is the device?

Device identity comes from a client certificate. When FortiClient registers to FortiClient EMS, it submits a certificate signing request and EMS, acting as the ZTNA certificate authority, signs a certificate that carries the FortiClient UID. EMS tracks the certificate serial number and its own EMS serial number alongside it. The FortiGate receives the EMS CA certificate and the endpoint records over the EMS fabric connector, so when a client presents its certificate, the FortiGate can verify the signature and map the certificate back to a specific, managed endpoint.

This is the part a stolen password cannot fake. Valid credentials on an unmanaged laptop do not produce an EMS-signed certificate.

2. Who is the user?

User identity is handled by FortiGate authentication rules and schemes, the same building blocks used by explicit proxy. Options include basic or form-based authentication against LDAP or RADIUS, SAML against an external IdP, and Kerberos-based transparent methods. FortiOS 7.6.3 added an entra-sso authentication method so a domain-joined Windows user can be authenticated against their existing Microsoft Entra ID session without a second prompt.

3. Is the device healthy right now?

Posture is expressed as ZTNA tags (called security posture tags in newer EMS releases). EMS tagging rules evaluate what FortiClient reports: OS and patch level, antivirus and EDR state, domain membership, presence of certificates, files or registry keys, vulnerability counts, the logged-in user’s AD group, on-net or off-net status, and more. The result is a set of named tags per endpoint, such as Corp-Compliant or Critical-Vulns-Present.

Tags are synced from EMS to the FortiGate, where they become objects you reference in policy. They work both ways: require a good tag to allow, or match a bad tag (for example, a malicious file detection) to block. When an endpoint’s state changes, EMS updates its tag membership and pushes the change to the FortiGate, so the next access decision is made on the current state, not on what was true at login.

4. Is this user, on this device, allowed to this app?

Finally, the FortiGate matches the request against ZTNA policy: source user or group, required and forbidden tags, the ZTNA destination or server, and the action. Accepted traffic then runs through whatever security profiles you attach.

How Fortinet ZTNA Works: The Lifecycle of a Session

It helps to split the flow into two phases. Phase 1 happens long before a user clicks anything. Phase 2 is the actual access request.

Phase 1: Enrollment and trust establishment

1. FortiGate joins EMS. The FortiGate connects to EMS through the FortiClient EMS fabric connector. The FortiGate must trust the EMS server certificate, and an EMS admin must authorize the FortiGate as a fabric device. Until both happen, no tags or certificates flow.
2. FortiClient registers to EMS. The endpoint sends telemetry: device details, the logged-in user, and its posture data.
3. EMS issues the device certificate. FortiClient generates a CSR. EMS signs a client certificate containing the FortiClient UID and records the certificate serial number.
4. EMS evaluates tagging rules. The endpoint lands in zero or more tags.
5. EMS syncs to the FortiGate. The EMS CA certificate, endpoint records (UID, certificate serial, user, IP and MAC), and tag membership are shared with every authorized FortiGate. Which tag types get shared is controlled per fabric device in EMS.
6. EMS pushes ZTNA destinations to FortiClient. These tell the agent which hostnames or IP and port combinations are protected, and which proxy gateway (198.18.10.10:443 in our lab) to send them through.

Phase 2: The access request

Scenario A: an internal web app through the HTTPS access proxy

1. The user browses to https://wiki.lab.example. DNS resolves the name to the ZTNA access proxy, 198.18.10.10, not to the real server.
2. The TLS handshake terminates on the FortiGate. The FortiGate presents its own server certificate for the app name and requests a client certificate. The endpoint presents the EMS-signed certificate. This is mutual TLS.
3. The FortiGate validates the certificate against the synced EMS CA, extracts the UID, and looks up that endpoint’s record and current tags.
4. If the policy requires user authentication, the FortiGate runs the matching authentication rule, for example a SAML redirect to the IdP.
5. The FortiGate matches ZTNA policy: user or group, required and blocked tags, destination.
6. Because the FortiGate is the TLS terminator, the traffic is already decrypted, so antivirus, IPS, web filter, application control, and DLP can inspect it without a separate SSL inspection step.
7. The FortiGate opens its own connection to the real server at 10.0.20.10, optionally re-encrypted, with load balancing and health checks across multiple real servers if configured.
8. The session is logged as ZTNA traffic with the user, device UID, matched tags, and policy.

Scenario B: RDP through the TCP forwarding access proxy

1. The user opens an RDP client to 10.0.20.20 (or its hostname).
2. FortiClient sees that the destination matches a ZTNA destination pushed from EMS. It intercepts the connection locally, acting as a local proxy, and opens an HTTPS session with its device certificate to 198.18.10.10.
3. The RDP stream is carried inside that HTTPS session. FortiClient can be set to skip its own extra encryption layer for protocols that are already encrypted, trading a bit of defense in depth for less overhead.
4. The FortiGate runs the same device, user, posture, and policy checks, then forwards the TCP stream to 10.0.20.20:3389.

The user never gets an IP address on the internal network and never gets a route to 10.0.20.0/24. FortiClient only forwards the specific destinations EMS told it about.

Scenario C: UDP applications over QUIC

ZTNA was TCP-only for its first few releases. With FortiClient and EMS 7.4.1 or later, UDP can be enabled per ZTNA application: FortiClient detects UDP traffic to a protected destination and carries it over a QUIC connection to the access proxy, which needs HTTP/3 and QUIC support enabled. After the same authentication, posture, and authorization checks, the proxy forwards the UDP flow to the destination.

Fortinet ZTNA Access Methods

Full ZTNA versus IP/MAC-based access control

Fortinet documents two modes. Full ZTNA is the proxy model described above: an SSL-encrypted access proxy, a device certificate, user authentication, posture, and per-app policy. IP/MAC-based access control reuses the same tags inside normal firewall policies. EMS knows each endpoint’s IP and MAC, so a tag like Corp-Compliant effectively becomes a dynamic address group the firewall can enforce on-net, for example to keep non-compliant laptops off a server VLAN. It is useful for internal segmentation, but it is not proxy-based ZTNA: there is no device certificate check and no per-session application gateway.

In the FortiOS 7.2 and 7.4 GUI you will also see this split described as simple ZTNA policies (regular firewall policies with ZTNA tags) versus full ZTNA policies (proxy policies). Same idea, different labels.

Where agentless fits

The ZTNA agentless web portal (FortiOS 7.6.1 and later) gives browser-only users a bookmark portal after they authenticate, much like the old SSL VPN web mode. It is a good answer for contractors and unmanaged devices, but be clear about what it is not: there is no FortiClient, no EMS certificate, and no posture tags. You get user identity and per-app proxying, not device trust.

Universal ZTNA: Same Policy On-Net and Off-Net

A common misconception is that ZTNA is only for remote users. In the Fortinet model, the same proxy and the same policy can serve a user at home and a user at their desk. EMS on-fabric detection rules tell FortiClient whether it is on the corporate network, and that state can itself be a tag. As long as DNS for the protected app resolves to the access proxy in both places, office users get the same device, user, and posture checks as remote users. There is no “trusted LAN” shortcut.

What Fortinet ZTNA Gives You

• Per-application, least-privilege access. Users reach specific apps, never routed subnets.
• Less lateral movement. A compromised laptop sees a handful of proxied applications, not the network behind them.
• Hidden applications. Only the access proxy port is exposed. The real servers are not reachable from the client side at all.
• Posture-aware decisions that track the device. Tag changes in EMS reach the FortiGate and affect the next decision.
• Full inspection without extra SSL inspection setup. The proxy terminates TLS, so the same NGFW security profiles apply.
• Uses the FortiGates you already own. The access proxy is part of FortiOS (since 7.0). The endpoint side is licensed through FortiClient EMS.
• Consistent policy everywhere. One policy for on-net and off-net users, and the same model extends to FortiSASE.
• Better logs. Every ZTNA log line carries user, device UID, and tag context, which is far more useful in an investigation than a VPN pool IP.
• A clear exit from SSL VPN. Starting in FortiOS 7.6.3, IPsec replaced SSL VPN tunnel mode as the default remote access method, and agentless (web mode) VPN was dropped on several desktop models. Fortinet positions ZTNA, including the agentless web portal, as the forward path.

Fortinet ZTNA vs SSL VPN vs IPsec Remote Access

ZTNA does not have to replace every tunnel on day one. Many shops keep an IPsec profile for IT staff who genuinely need network-level access and move everyone else to ZTNA.

Deployment Models

• FortiGate as the access proxy. The most common model: an existing perimeter or data center FortiGate (hardware, VM, or cloud) becomes the ZTNA gateway. FortiOS 7.2.5 added an ESXi OVF template that bootstraps a FortiGate-VM as a dedicated zero trust application gateway.
• FortiSASE. Enforcement moves to Fortinet cloud PoPs, with the same FortiClient and EMS model, plus agentless ZTNA for browser-only users.
• FortiProxy. A dedicated proxy platform supporting the same HTTPS, TCP, and UDP access proxy types.
• ZTNA service connector (FortiOS 8.0). New in 8.0, a FortiGate can act as a service connector that builds outbound connections to an upstream ZTNA edge, such as FortiPAM or FortiProxy. The edge does the ZTNA checks and enforces policy, and the FortiGate reverse-proxies the session to the local app. The site hosting the app needs no inbound exposure at all.

What Changed in FortiOS 8.0

If your ZTNA screenshots are from 7.2 or 7.4, the 8.0 GUI and CLI will look different. Fortinet modularized the configuration so objects can be mixed and matched:

• New dedicated objects: config ztna web-proxy, config ztna traffic-forward-proxy, and config ztna web-portal, plus config ztna destination for TCP forwarding targets. This work started in 7.6 and is completed in 8.0.
• The ZTNA VIP is now a ZTNA Port object, configured on its own Ports page. Previously a ZTNA VIP was bound to one ZTNA server definition and its real servers.
• firewall proxy-policy references a new ztna-proxy type that points at those objects, and ZTNA policies reference the ZTNA destination directly for TCP forwarding.
• The agentless web portal is supported in the new model.
• The ZTNA service connector (described above) arrives.

The concepts in this post are unchanged across versions. Only the object model and menu locations moved. The configuration post covers both 7.6 and 8.0 syntax.

Verification and Validation: Peeking Under the Hood

No configuration here, but these read-only commands show the moving parts described above on a FortiGate that already has ZTNA running. Replace the placeholders with your values.

Check that the FortiGate can reach EMS and trusts it:

diagnose endpoint fctems test-connectivity <ems-connector-name>

List the endpoint records the FortiGate learned from EMS (UID, user, IP, MAC, and status):

diagnose endpoint record list

Look up a single endpoint by FortiClient UID and see its certificate serial and current tags:

diagnose endpoint lls-comm send ztna find-uid <FortiClient-UID>

What success looks like (illustrative, values are placeholders):

UID: 3C1F0A9E7B2D4E61A8F05C77D2B9E410
 -uid 3C1F0A9E7B2D4E61A8F05C77D2B9E410: {
    "user_name": "jdoe",
    "client_cert_sn": "5E0A...91C4",
    "ems_sn": "FCTEMS0000000001",
    "tags": [ "all_registered_clients", "Corp-Compliant" ] }

If the tag you expect is missing here, the FortiGate will not match the policy, no matter how the policy is written.

See how tags have been resolved into dynamic addresses (useful for IP/MAC-based access control):

diagnose firewall dynamic list

Pull ZTNA traffic logs from the CLI:

execute log filter reset
execute log filter category 0
execute log filter field subtype ztna
execute log display

Watch the proxy daemon (WAD) make its decision in real time, then turn it off:

diagnose wad debug enable category all
diagnose wad debug enable level verbose
diagnose debug enable
# reproduce the access attempt, then:
diagnose debug disable
diagnose debug reset

Troubleshooting and Gotchas

1. DNS is the steering wheel

ZTNA only works if the client sends traffic to the access proxy. For the HTTPS access proxy, the app FQDN must resolve to the ZTNA port (198.18.10.10 in the lab), both off-net and on-net if you want universal ZTNA. If internal DNS still points wiki.lab.example at 10.0.20.10, on-net users bypass ZTNA entirely and you will see nothing in the ZTNA logs.

Diagnose: nslookup <app-fqdn> on the client from each location, then check whether any ZTNA traffic log exists for that user. Fix: make the protected name resolve to the proxy in every view of your DNS, and remove direct paths in firewall policy.

2. Certificate trust has three links, and any one can break

The FortiGate must trust the EMS server certificate (connector), the FortiGate must hold the EMS CA (to validate device certificates), and the client must trust the certificate on the ZTNA port (for the app name). Symptoms range from a disconnected EMS connector to repeated client certificate prompts or ERR_SSL_PROTOCOL_ERROR in the browser.

Diagnose: diagnose endpoint fctems test-connectivity <ems-connector-name> and diagnose endpoint record list to confirm the endpoint and certificate serial are known. Fix: import the CA that signed the EMS server certificate if it is private, re-authorize the FortiGate in EMS, and use a ZTNA port certificate (often a wildcard) that clients already trust.

3. Tags are data, not decisions

A policy that requires a tag can only match endpoints that EMS has put in that tag and shared with this FortiGate. Unregistered FortiClients have no tags. Tag types (for example, classification tags) must be explicitly shared to the fabric device in EMS. Tag names on the FortiGate are prefixed by the EMS connector, so Corp-Compliant in EMS shows up with a prefix in FortiOS.

Diagnose: diagnose endpoint lls-comm send ztna find-uid <FortiClient-UID> and compare its tags to the policy. Fix: correct the tagging rule or the sharing settings in EMS, not the firewall policy.

4. Agentless is not ZTNA with posture

The agentless web portal is valuable, but there is no device certificate and no posture. Treat it as identity-based app proxying for unmanaged devices and scope it to low-risk apps. Keep sensitive apps behind full ZTNA so a managed, compliant device is mandatory.

What’s Next

The follow-up post is the hands-on build: connecting the FortiGate to EMS, writing tagging rules, building a ZTNA server or ZTNA Port, HTTPS and TCP forwarding rules, SAML authentication, and the ZTNA policy itself, with both FortiOS 7.6 and 8.0 syntax.

References

• Fortinet Docs: Zero Trust Network Access introduction (FortiOS)
• Fortinet Docs: ZTNA HTTPS access proxy example
• Fortinet Docs: FortiOS 8.0 ZTNA configuration simplification
• Fortinet Docs: FortiOS 8.0 ZTNA service connector
• Fortinet Docs: ZTNA for UDP traffic
• Fortinet Community: Alternatives to SSL VPN web mode
• Fortinet Community: ZTNA resource access through Microsoft Entra ID