Fortinet NSE7_ESN_AR-7.6: Fortinet ZTNA Design Patterns
Fortinet Zero Trust Network Access authorizes access to applications using user identity, device identity, and endpoint security posture rather than treating network location as sufficient trust. FortiClient EMS supplies endpoint context and certificates, while FortiGate can enforce access through ZTNA application gateways and policy.
Within network security platforms, ZTNA should be treated as an application-access architecture, not simply a replacement label for VPN. The strongest design narrows each user or device to the resources it needs and continuously uses identity and posture as part of authorization.
Start with the protected application
Inventory the application, protocol, hostname, real server, authentication method, user population, sensitivity, and expected client type before creating ZTNA policy. Application boundaries determine whether HTTP access proxy, TCP forwarding, SSH proxy, or another supported pattern fits.
Build device trust through EMS
FortiClient EMS shares endpoint information and security posture with FortiGate. Tagging rules can represent conditions such as managed status, operating system, security software, or other posture attributes available to the environment.
Use certificates as device evidence
Fortinet ZTNA can use client certificates issued through the EMS trust relationship to establish device identity. Certificate lifecycle therefore becomes part of access reliability: issuance, renewal, revocation, trust chain, and time synchronization all matter.
Separate user authentication from posture
A trusted device does not prove that the current user is authorized for the application. Where the application requires user authentication, integrate the appropriate identity source and MFA method instead of relying only on device tags.
For auditability, keep a mapping from business application owners to the ZTNA server, rule, identity groups, posture tags, certificate dependencies, and backend services that protect that application. This makes access reviews concrete and helps teams remove policy when an application is retired instead of leaving unused gateways and broad authorization rules in place indefinitely.