Fortinet ZTNA: The Complete Guide to Configuring Zero Trust Network Access

December 10, 2025.

Fortinet's Zero Trust Network Access (ZTNA) represents a fundamental shift in network security, moving away from traditional "trust but verify" models to a strict identity-centric approach where no device or user is inherently trusted. Unlike conventional VPNs that grant broad network access, ZTNA provides application-specific secure access based on continuous verification of user identity, device security posture, and contextual factors.

The architecture combines multiple Fortinet products: FortiGate firewalls as access gateways, FortiClient EMS for endpoint management and tagging, and FortiClient agents on user devices. This integrated ecosystem enables organizations to implement granular access controls that dynamically adjust based on real-time risk assessments, significantly reducing the attack surface compared to traditional perimeter-based security models.

Key Insight: According to Fortinet's deployment guide, "a device inside the network is trusted no more than a device outside the network." This principle underscores the core philosophy of Zero Trust—continuous verification regardless of location.

Core Components of Fortinet ZTNA Architecture

Essential Products and Licensing

Fortinet ZTNA implementation requires several integrated components:

• FortiGate firewall (version 7.0 or later) with ZTNA licensing included in FortiOS
• FortiClient EMS for endpoint management (version 7.0 or later)
• FortiClient agents deployed on all endpoints
• Optional components: FortiAnalyzer for logging/analysis, FortiAuthenticator for centralized authentication

Table: ZTNA Component Requirements and Functions

---

Deployment Models: Access Proxy vs. Secure Access

Fortinet offers two primary ZTNA deployment approaches:

ZTNA Access Proxy eliminates traditional VPNs by providing secure SSL-encrypted access to specific applications. This model includes:

• HTTPS Access Proxy for web applications
• TCP Forwarding Access Proxy (TFAP) for non-web applications like RDP and SSH

ZTNA Secure Access enhances traditional VPN connections with additional identity and posture checking layers, typically used for:

• Local "On-net" users accessing internal resources
• Remote users who still require full VPN connectivity

Step-by-Step Configuration Guide

Phase 1: Prerequisites and Feature Enablement

Before configuring ZTNA, ensure your environment meets these requirements:

1. FortiGate models with more than 2GB RAM (ZTNA is not supported on 2GB RAM models)
2. FortiOS 7.0 or higher with appropriate licensing
3. Feature visibility enabled: Navigate to System > Feature Visibility and enable "Zero Trust Network Access"
4. Explicit Proxy enabled (for full ZTNA policies): In System > Feature Visibility, enable "Explicit Proxy" under Security Features

Phase 2: FortiClient EMS Integration

The FortiClient EMS serves as the central management point for endpoints and security posture evaluation.

Configuring EMS Connector (GUI Method):

1. Navigate to Security Fabric > Fabric Connectors
2. Double-click the FortiClient EMS card
3. Set Status to Enabled for an EMS server
4. Enter a name and the IP address/FQDN of your EMS server
5. Click OK and accept the EMS server certificate when prompted

CLI Configuration:

config endpoint-control fctems     edit <ems-id>         set server <server IP or domain>     next end 

For FortiClient EMS Cloud deployments, set fortinetone-cloud-authentication enable in the CLI configuration.

Phase 3: Security Posture Tags Management

Formerly called ZTNA tags, security posture tags are generated from tagging rules configured on FortiClient EMS based on endpoint posture checks. These tags enable dynamic access control decisions.

Viewing Synchronized Tags:

• GUI: Go to Policy & Objects > ZTNA > Security Posture Tag tab
• CLI: Use diagnose firewall dynamic address or diagnose firewall dynamic list

Creating Tag Groups:

config firewall addrgrp     edit <group name>         set category ztna-ems-tag         set member <members>     next end 

Phase 4: ZTNA Server Configuration

The ZTNA server defines the access proxy VIP (Virtual IP) that clients connect to and maps these connections to backend real servers.

Creating a ZTNA Server for HTTPS Access Proxy (GUI):

1. Navigate to Policy & Objects > ZTNA > ZTNA Server tab
2. Click Create New and enter a server name
3. Select an interface (IP and port auto-populate)
4. Choose a default certificate for client connections
5. Configure service/server mappings:
   • Set Service to HTTPS
   • Set Virtual Host to Any Host or Specify (for host-based filtering)
   • Configure path matching (substring, wildcard, or regex)
   • Add real server IP and port

Important Note: Starting in FortiOS 7.6.4, certificate verification of the real server is enabled by default. You can adjust this setting using:

config realservers     edit <id>         set verify-cert {enable | disable}     next end 

Phase 5: ZTNA Policy Configuration

Fortinet offers two methods for configuring ZTNA policies:

Simple ZTNA Policy (Recommended for Most Use Cases):

1. Go to Policy & Objects > Firewall Policy
2. Click Create New and enter policy name
3. Set Action to Accept and Type to ZTNA
4. Configure Incoming Interface and Source
5. Add allowed security posture tags or tag groups
6. Select the ZTNA server
7. Enable security profiles as needed

Full ZTNA Policy (Legacy Method):

1. Ensure Explicit Proxy is enabled in Feature Visibility
2. Navigate to Policy & Objects > Proxy Policy
3. Configure similar settings with additional granular controls

Phase 6: Optional Authentication Configuration

For enhanced security, integrate user authentication with ZTNA:

Basic Authentication Scheme:

config authentication scheme     edit <name>         set method basic         set user-database <auth server>     next end 

Authentication Rule:

config authentication rule     edit <name>         set status enable         set protocol http         set srcintf <interface>         set srcaddr <address>         set dstaddr <address>         set ip-based enable         set active-auth-method <active auth scheme>     next end 

Design Considerations and Best Practices

Critical Planning Questions

Before deployment, address these design considerations:

• What specific applications require ZTNA protection?
• How will users resolve application addresses (DNS considerations)?
• Which user groups should access each application?
• Where will authentication services reside?
• What security postures are required for endpoint access?
• Where is the optimal location for the EMS server?
• How will FortiClient endpoints be provisioned and onboarded?

Common Deployment Scenarios

Remote Web Application Access:

1. Configure HTTPS access proxy for web applications
2. Implement security posture tags for device compliance
3. Apply ZTNA policies with tag-based restrictions
4. Enable logging to FortiAnalyzer for monitoring

TCP Application Access (RDP/SSH):

1. Configure TCP forwarding access proxy
2. Set up ZTNA connection rules for specific applications
3. Implement certificate-based device authentication
4. Test connectivity with posture-compliant devices

Avoiding Common Pitfalls

1. Not a Full VPN Replacement: As noted in community discussions, "ZTNA is basically a fancy web-vpn" with limited connectivity compared to traditional VPNs. For full tunnel requirements, consider IPsec VPN or FortiSASE.

2. Certificate Management: Ensure proper certificate lifecycle management for both server and client certificates.

3. Performance Considerations: ZTNA processing adds overhead; ensure adequate FortiGate resources for expected user counts.

4. Failover Planning: Implement redundancy for critical components like EMS servers and FortiGate clusters.

Migration Strategy from Traditional VPN

Fortinet recommends a phased migration approach:

1. Assessment Phase: Identify applications suitable for ZTNA access proxy
2. Pilot Phase: Deploy ZTNA for a limited user group and application set
3. Expansion Phase: Gradually migrate more applications and users
4. Optimization Phase: Refine policies based on usage patterns and security requirements

The deployment guide emphasizes reducing "reliance on dial-up VPN by adding device authentication with role-based application access" while maintaining VPN for scenarios requiring full network access.

Troubleshooting and Verification

Connectivity Verification Steps

1. Verify EMS Connectivity: Check FortiGate to EMS communication in Security Fabric
2. Test Tag Synchronization: Confirm security posture tags appear in FortiGate
3. Validate Certificate Exchange: Ensure client certificates are properly issued and synchronized
4. Test Application Access: Verify both allowed and denied access scenarios

Monitoring and Maintenance

• Regular Review: Periodically audit ZTNA policies and tags
• Log Analysis: Use FortiAnalyzer to monitor access patterns and security events
• Performance Monitoring: Track resource utilization on FortiGate devices
• Update Management: Keep all components updated with latest firmware and security patches

Frequently Asked Questions

What's the difference between ZTNA and traditional VPN?

ZTNA provides application-specific access based on continuous verification of user identity and device posture, while traditional VPNs typically grant broad network-level access once authenticated. ZTNA follows a "never trust, always verify" principle regardless of whether the device is inside or outside the network perimeter.

Can ZTNA replace my existing VPN completely?

Not always. ZTNA is ideal for specific application access, particularly web and common TCP applications. However, for scenarios requiring full network access or support for non-standard protocols, traditional VPN (like IPsec) may still be necessary. Many organizations implement both, using ZTNA for most remote access while maintaining VPN for edge cases.

What are security posture tags and how are they created?

Security posture tags (formerly ZTNA tags) are dynamic labels applied to endpoints based on their security state. They're created on FortiClient EMS through tagging rules that evaluate endpoints against criteria like:

• Antivirus status and definition currency
• Operating system patch level
• Disk encryption status
• Network location (on-net/off-net)
• File presence/absence checks These tags synchronize automatically to FortiGate for policy enforcement.

How does certificate authentication work in ZTNA?

FortiClient EMS acts as a certificate authority, issuing unique client certificates to each endpoint during EMS registration. The FortiGate receives the EMS CA certificate to verify client certificates. This creates a cryptographic identity chain where the FortiGate can authenticate devices without storing individual client certificates.

What are the licensing requirements for ZTNA?

• FortiGate: ZTNA functionality is included in FortiOS, but Unified Threat Protection or Enterprise Protection bundles are recommended
• FortiClient EMS: Licensing is included with the FortiClient ZTNA license
• FortiClient: Requires ZTNA license for each endpoint
• FortiAnalyzer: Licensed by anticipated log volume (recommended for monitoring)

Is ZTNA suitable for both internal and external users?

Yes. Fortinet ZTNA implements consistent access policies regardless of user location. The same security posture checks and access controls apply whether users are:

• Remote employees accessing from outside the network
• Internal users accessing applications from within the corporate network
• Third-party contractors requiring limited application access

How do I troubleshoot ZTNA connection issues?

Follow this systematic approach:

1. Verify FortiClient to EMS connectivity
2. Check certificate validity on both client and FortiGate
3. Confirm security posture tags are synchronized
4. Validate ZTNA policy configuration and rule order
5. Check FortiGate logs for connection attempts and policy matches
6. Test with basic policies first, then add complexity gradually