Zero trust network access with Fortinet should be designed around applications, identities, devices, and explicit trust decisions rather than around the idea that a remote user receives a broad network tunnel. The roadmap\u2019s FortiSASE 25 Enterprise Administrator<\/a> destination is historical: that exam ended on July 15, 2026. Fortinet\u2019s current SASE architecture direction is NSE 7 SASE 26 Architect, where secure private access, FortiSASE, and SD-WAN are treated as parts of one distributed-access design.<\/p>\n The practical objective is straightforward: a user should reach the specific private application needed for a task, from an endpoint that satisfies the required posture, after identity is verified, without gaining unnecessary reachability to the surrounding subnet. That model complements multi-factor authentication<\/a> and application-aware access control. It also changes troubleshooting: teams must be able to prove identity, device state, policy match, gateway reachability, DNS, certificate trust, and application health independently.<\/p>\n A durable ZTNA design therefore starts before any access rule is created. Inventory applications, classify their sensitivity, identify user populations and protocols, decide which endpoints can be managed, and define how access behaves when posture or identity data is unavailable. The strongest architecture is not the one with the most checks; it is the one whose trust decisions are explicit, observable, and recoverable.<\/p>\n Begin with an application inventory rather than a directory-group export. Record application owners, URLs or service names, protocols and ports, hosting locations, authentication methods, data sensitivity, critical dependencies, and expected user populations. A private web portal, SSH administration service, database client, and thick desktop application have different publication and inspection requirements even when the same employees use them.<\/p>\n Group applications by risk and access pattern. Low-risk internal information may tolerate broader workforce access, while administrative consoles, production tooling, or regulated data should require narrower groups and stronger endpoint posture. Treat shared infrastructure such as DNS, certificate services, identity connectors, and monitoring as dependencies that can break an otherwise correct ZTNA rule.<\/p>\n For each application, write the expected access story in plain language: who connects, from what device class, through which access method, to which application identity, under what posture conditions, and what should happen when a condition fails. This statement becomes the reference for policy review and troubleshooting and prevents teams from expanding access merely because a network route happens to exist.<\/p>\n Prioritize application owners in this inventory process. Security teams can describe access controls, but only application owners can confirm which dependencies are legitimate and what failure looks like to the business. Require owners to validate the published name, protocol set, user groups, maintenance window, and rollback contact. This keeps the ZTNA catalog accurate when an application changes after the original deployment.<\/p>\n The gateway should be positioned so it can reach the protected application without turning the access path into a general-purpose bridge into the private network. On FortiGate-based designs, the ZTNA application gateway or access proxy becomes the controlled point where an authenticated, permitted session is proxied to the internal service. Routing and firewall policy behind that point still matter, but they should support only the required application path.<\/p>\n Avoid publishing applications from a segment that also exposes unrelated management interfaces or broad east-west reachability. Network segmentation limits the damage if an application or gateway is compromised. The site\u2019s discussion of network segmentation<\/a> is useful here because zero trust does not replace segmentation; it gives the segmentation boundary richer identity and device context.<\/p>\n High availability also belongs in gateway placement. If two FortiGates protect the application, confirm that certificates, policies, routes, health checks, and session behavior remain correct during failover. A redundant device pair that cannot reproduce the same access decision after a role change is not a resilient ZTNA service.<\/p>\n Consider the trust boundary on both sides of the gateway. The user-facing side needs protected authentication and exposure controls, while the back-end side should reach only the services required by the published application. If the proxy can connect broadly across a server segment, a compromise can inherit unnecessary reach. Use routing and firewall policy to constrain the gateway\u2019s server-side reachability as carefully as user-side authorization.<\/p>\n Identity should answer who the user is, while endpoint identity and posture answer what device is making the request and whether it meets access requirements. Directory groups or SAML claims can establish role context, and certificates can provide a stronger device-binding signal. single sign-on<\/a> can reduce repeated authentication, but session convenience should not be confused with authorization.<\/p>\n Posture tags should represent meaningful security states such as managed endpoint, current protection agent, approved operating-system level, or compliant configuration. Keep the number of tags manageable and document the source and freshness of each signal. A rule that depends on a posture value nobody can explain during an incident is brittle, even if it looked precise when first deployed.<\/p>\n Define stale and unknown states explicitly. If the endpoint has not checked in recently, a certificate has expired, or identity group data cannot be retrieved, the system should follow a documented failure behavior. Sensitive applications normally warrant fail-closed behavior or limited remediation access rather than silent fallback to a weaker rule.<\/p>\n Certificate lifecycle is especially important when device certificates are part of trust. Enrollment must prevent users from copying credentials to unmanaged systems, renewal must happen before expiry, and revocation must propagate quickly when a device is lost or decommissioned. Test what the access service does when certificate status cannot be checked so that an availability problem does not quietly weaken device assurance.<\/p>\n Managed endpoints can provide the richest context because FortiClient can participate in endpoint telemetry, posture assessment, certificate handling, and access steering. Standardize client enrollment, configuration, upgrade rings, and recovery before depending on endpoint state for production access. Agent reliability is part of application availability once ZTNA policy depends on it.<\/p>\n Design access so the client directs only the intended private services through the ZTNA path. Broad address-based steering can recreate a traditional remote-access tunnel and make application-level policy harder to reason about. Prefer stable application names and documented dependencies, with tightly bounded exceptions for protocols that cannot be represented cleanly.<\/p>\n Operational teams should be able to distinguish a client enrollment problem from a policy denial or gateway failure. Capture client version, certificate state, posture tags, identity, selected gateway, and the application being requested in the support workflow. That evidence reduces the temptation to solve every ticket by weakening policy.<\/p>\n Use deployment rings for client changes: test with IT staff and low-risk groups, then widen to representative business units before broad release. Record compatibility with endpoint protection, proxy settings, VPN coexistence, sleep\/resume behavior, and operating-system upgrades. A staged model gives engineering teams time to identify regressions before they affect a large percentage of remote users.<\/p>\n Agentless access can be valuable for contractors, partners, temporary workers, or devices on which endpoint software cannot be installed. The browser-oriented model resembles clientless remote access<\/a>: the user gains access to a published application rather than to a whole private address space. That narrower reachability is useful, but endpoint posture is generally more limited than on managed devices.<\/p>\n Choose applications for agentless publication intentionally. Verify authentication redirects, WebSockets, file transfer, clipboard behavior, downloads, uploads, and session timeout requirements. A legacy web application that depends on unusual browser behavior can fail through a proxy even though its login screen appears normally.<\/p>\n For unmanaged devices, reduce privilege where possible. Restrict high-risk downloads, require stronger authentication, shorten sessions, and avoid publishing infrastructure administration tools unless the risk has been explicitly accepted. If an application truly needs device-level assurance, move the user to a managed endpoint path instead of pretending browser access provides the same evidence.<\/p>\n Agentless sessions also need clear termination behavior. Verify that signing out of the application, closing the browser, expiring identity-provider sessions, and administrative revocation all produce the intended outcome. Long-lived browser sessions on unmanaged systems can undermine otherwise narrow access. Set idle and absolute timeouts according to application sensitivity rather than using one duration for every published service.<\/p>\n Each rule should connect a defined user or group, an endpoint state, and a specific application. This resembles dynamic access control<\/a> in principle: access changes according to attributes rather than relying only on a source IP range. Keep the condition set small enough that an administrator can explain why a session was allowed or denied.<\/p>\n Rule order and exceptions matter. Put narrow, sensitive policies where they cannot be shadowed by broader workforce rules, and make emergency access separately visible. Avoid permanent catch-all rules for troubleshooting. A temporary exception should have an owner, reason, expiration date, and a clear plan to remove it once the underlying problem is fixed.<\/p>\n Periodically compare policy groups with current application ownership and actual use. People change roles, contractors leave, applications are decommissioned, and posture standards evolve. Least privilege decays unless access is reviewed as a lifecycle process rather than as a one-time deployment activity.<\/p>\n Separate business exceptions from technical exceptions. A business exception may authorize a user outside the normal role for a defined period; a technical exception may relax a posture check while a known endpoint issue is repaired. Recording the category makes reviews more useful because the owner, evidence, and expiration criteria differ. Permanent exceptions should be redesigned into normal policy or removed.<\/p>\n ZTNA hides much of the private network from the user, but the gateway still needs reliable name resolution and reachability to the application. Document which DNS resolver answers each private name, where routes are learned, and whether the application resolves differently from user, gateway, or server networks. Split-DNS mistakes can look like authorization failures even when the policy is correct.<\/p>\n Certificates are equally important. Users must trust the certificate presented for the published service, the gateway must handle the application-side TLS relationship correctly, and certificate names must match the published application identity. Plan renewal and revocation before expiry becomes an outage. Where mutual TLS is used, document which side validates each certificate and how client identity is mapped.<\/p>\n For high-availability applications, test back-end health and failover through the ZTNA path instead of only from the server VLAN. A user-facing access service is healthy only when identity, gateway, DNS, network path, and application all work together.<\/p>\n When applications use several back-end services, model those dependencies explicitly instead of widening the gateway\u2019s destination range. An application may call an identity service, API, database, or file repository after the user connects. Tracing these flows during pilot testing prevents incomplete publication while preserving least privilege. Dependency maps also make future cloud migrations and server replacements much safer.<\/p>\n A useful ZTNA log should help answer who connected, from which device, to which application, under which posture, through which rule, and with what result. Retain authentication, endpoint, gateway, policy, and application evidence with synchronized timestamps. This turns troubleshooting from guesswork into reconstruction of the trust decision.<\/p>\n Build alerts for repeated authentication failure, unexpected posture changes, policy denials to sensitive applications, abnormal session volume, and access from unusual locations. The broader SIEM model<\/a> is relevant because correlation across identity, endpoint, and gateway records can reveal patterns that a single device log cannot.<\/p>\n Support runbooks should begin with the expected application path and then validate each dependency. Confirm name resolution, user identity, device identity, posture, policy match, certificate trust, gateway reachability, and back-end application health in that order or another documented sequence. A repeatable sequence is faster than changing several policies at once and hoping the symptom disappears.<\/p>\n Create service-level indicators for access success, not only security events. Authentication completion, posture-evaluation success, gateway connection time, application response time, and session termination errors show whether users can actually work. Trend them by region and endpoint population. A security control that repeatedly fails legitimate users will accumulate bypasses, so availability telemetry directly supports stronger policy.<\/p>\n Do not replace a broad remote-access VPN with ZTNA in one step. Select a small set of applications and a representative user group, run both access methods during a controlled period, and compare reliability, latency, support effort, and security visibility. The fundamentals in VPN access models<\/a> help identify which legacy uses are truly network-level and which can move to application-level access.<\/p>\n Move applications in waves based on protocol compatibility and business criticality. Keep a documented rollback path, but monitor every fallback use so that the old VPN does not become the permanent answer to unresolved design problems. Each exception should either be retired, redesigned, or explicitly accepted.<\/p>\nDefine protected applications before user groups<\/h3>\n
Place the ZTNA application gateway on the right trust boundary<\/h3>\n
Combine identity, certificates, and posture deliberately<\/h3>\n
Use agent-based ZTNA for managed endpoints<\/h3>\n
Handle agentless access as a separate risk model<\/h3>\n
Write least-privilege access rules that are explainable<\/h3>\n
Make DNS, routing, and certificates part of the application design<\/h3>\n
Monitor the trust decision, not just the tunnel<\/h3>\n
Migrate from network VPN access in controlled stages<\/h3>\n