ZTNA pilot for contractors exposes latency and posture gaps
Helio Systems has 2,500 employees and 600 contractors across 12 countries. Core applications run in two data centers, Dallas and Frankfurt; Microsoft 365 and Salesforce are SaaS. Remote access today uses SSL VPN on a FortiGate 1800F pair, peaking at 1,200 concurrent users. Contractors use unmanaged Windows and macOS devices, while employees use managed laptops enrolled in FortiClient EMS. The company is piloting FortiSASE with ZTNA, using Entra ID as IdP and FortiAuthenticator for MFA. In the pilot, contractors in Singapore and India access the Dallas ERP application through the nearest FortiSASE PoP and see 250-300 ms response times. ZTNA device-posture tags are not matching for 20% of managed macOS clients, and some contractors can reach the ERP login page but not the internal reporting service. The security team wants to retire SSL VPN within one quarter but must preserve contractor access without installing agents on unmanaged devices.
1. Choose the access architecture for contractors and employees, and justify ZTNA versus SSL VPN or IPsec dial-up in this context.
Read the worked answer
Architecture: use FortiSASE ZTNA as the policy enforcement point. Employees use FortiClient with EMS posture tags. Contractors use clientless/agentless ZTNA through the browser, with Entra ID SSO and FortiAuthenticator MFA, and receive per-application access only. Retire SSL VPN for broad access; keep a small break-glass SSL VPN or IPsec for network operations.
Why ZTNA over SSL VPN/IPsec: SSL VPN gives network-level access and is a poor fit for 600 unmanaged devices; IPsec dial-up requires a client and is harder to scale across 12 countries. ZTNA gives identity-aware, per-app access, hides internal IPs, and supports posture for managed devices and identity-only policy for contractors. It also integrates with FortiSASE PoPs and FortiAnalyzer logging.
Caveat: ZTNA does not remove physics. If the Dallas ERP is only in Dallas, Singapore users will still see WAN latency. Validate whether the 250-300 ms is PoP backhaul, application processing, or chatty protocols. Consider a regional application gateway or VDI for APAC contractors if the app cannot tolerate latency.
2. Explain the likely causes of the latency and tag mismatch, and what you would change in FortiSASE, EMS, and the application access rules.
Read the worked answer
Latency causes: traffic may be tromboning from the Singapore PoP to Dallas over an IPsec tunnel instead of using a local PoP-to-DC path; the ERP may be chatty; or PoP selection is suboptimal. Check FortiSASE PoP selection, the IPsec overlay to Dallas, and application response time. If the app is chatty, ZTNA policy cannot fix it; use a closer application gateway or desktop virtualization.
Tag mismatch: FortiClient EMS tags may not be syncing to FortiSASE because the EMS connector is not authorized, the macOS FortiClient is outdated, posture rules require a newer OS, or tag names/rule scopes differ. Verify EMS fabric connector status, endpoint registration, posture rule evaluation, and ZTNA policy tag references. For contractors, do not require device posture; use identity and conditional access.
Changes: scope ZTNA rules by user group and application, not broad subnets; enable split DNS for internal names; log ZTNA sessions to FortiAnalyzer; test a small contractor cohort before cutover.
3. How would you troubleshoot the reporting-service failure and prevent it from becoming a production blocker?
Read the worked answer
Troubleshoot: compare a working employee and failing contractor session in FortiSASE ZTNA logs. Check whether the reporting service uses a different hostname, port, or protocol than the ERP login page; whether DNS resolves to an internal IP; whether the ZTNA application definition includes only the web front end; and whether SSL inspection or a WAF profile is blocking the service.
Likely fix: add the reporting service as a separate ZTNA application or expand the application definition to the required FQDN/port; ensure the same user group and MFA policy apply; publish internal DNS through the ZTNA configuration; and verify the FortiGate/application gateway route to the reporting server.
Prevent blocker: build an application dependency map before cutover, test each service with a contractor account, and keep SSL VPN as a time-boxed fallback for unresolved apps. Do not widen access to 'all internal' to fix one service.