Zero Trust Network Access (ZTNA) and Secure Remote Access
This domain tests ZTNA concepts and the FortiClient EMS 7.4 configuration that supplies identity, device posture, and destination policy. Expect questions on the roles of FortiClient, EMS, and FortiGate, how ZTNA tags are produced, and why a user can authenticate but still not reach an application.
ZTNA architecture
- FortiClient is the endpoint client. EMS manages profiles, compliance rules, ZTNA tags, and destination rules. FortiGate can act as the ZTNA gateway, and EMS can act as a ZTNA proxy depending on the design.
- ZTNA is application-level access, not a full tunnel. Users reach defined destinations rather than an entire network.
- ZTNA tags represent endpoint posture, such as compliant antivirus or OS version. FortiGate policies can match both user identity and ZTNA tags.
- SSO/SAML can provide identity, while EMS provides device context. Both are needed for a true zero-trust decision.
Configuration flow
- In EMS, define ZTNA destinations with host, port, and protocol. Scope each rule to user groups and required tags, and choose whether traffic uses the EMS proxy or a FortiGate gateway.
- Ensure the EMS server certificate is trusted by endpoints; ZTNA clients validate the destination and proxy/gateway certificates.
- On FortiGate, configure the EMS connector, enable the ZTNA gateway role where used, and create firewall policies that match ZTNA tags and users.
- On FortiClient, the ZTNA configuration arrives through the assigned profile after registration and check-in.
Worked example
A contractor needs HTTPS access to a CRM server at 10.20.30.40:443. The administrator creates a compliance rule requiring antivirus and a supported OS, producing the tag ztna-compliant. A ZTNA destination rule allows TCP 443 to 10.20.30.40 for the Contractor group and requires ztna-compliant. FortiGate policy permits ZTNA traffic from that tag and group. The contractor authenticates, the endpoint receives the tag, and the destination rule is delivered. Reasoning: identity alone is not enough; the endpoint must also satisfy posture.
Traps that cost marks
- The endpoint never receives the tag because the compliance rule was not evaluated or assigned.
- Certificate SAN mismatch or an untrusted EMS certificate breaks ZTNA connection setup.
- The FortiGate is not connected to EMS, so tag-based policy cannot be enforced.
- The user is in the wrong group, or the destination rule is scoped to a group the user does not match.
- Assuming ZTNA replaces VPN for every application; ZTNA is destination-specific.