FortiSASE architecture for hybrid work has to support users who move among corporate offices, home networks, travel, contractor devices, and branch locations without making security depend on a single physical perimeter. The approved roadmap points to the former FortiSASE 25 Enterprise Administrator<\/a> exam, which Fortinet retired in July 2026. The current certification direction is NSE 7 SASE 26 Architect, reflecting a broader design focus that combines FortiSASE, secure private access, and SD-WAN.<\/p>\n Architecturally, the service is easier to reason about when it is divided into three outcomes: secure internet access (SIA) for web and internet traffic, secure private access (SPA) for private applications, and secure SaaS access (SSA) for cloud services. Users can reach FortiSASE through agent-based, agentless, or site-based steering methods, while private applications may be reached through ZTNA gateways, SD-WAN integration, or NGFW-based access. The general SD-WAN model<\/a> matters because branch and private-access design often depends on how paths are selected and how sites connect back to enterprise resources.<\/p>\n A sound design also distinguishes control dependencies from traffic paths. Identity providers, endpoint-management services, DNS, certificate infrastructure, logging, and management portals may sit outside the user\u2019s application path, yet failure in any of them can prevent policy from being evaluated or changed. Record those dependencies and their recovery order. For example, restoring a private application is not enough if users cannot authenticate or endpoints cannot obtain the posture state required by the access rule. Hybrid work becomes much easier to support when architects document both the data plane that carries sessions and the control services that make those sessions trustworthy. That dependency map should be tested during maintenance and failover exercises, not left as design documentation.<\/p>\n List the user types before selecting enforcement features. Managed employees with FortiClient, contractors on unmanaged laptops, branch users behind a FortiGate, and mobile users on personal devices have different steering and posture capabilities. The architecture should define how each population reaches the internet, SaaS, and private applications.<\/p>\n Map common journeys such as home user to Microsoft 365, contractor to one private web application, branch user to a data-center ERP system, and administrator to infrastructure management. A single global diagram can hide these differences; journey-based diagrams reveal which traffic is inspected by FortiSASE, which goes directly through ZTNA, and which uses SD-WAN or private connectivity.<\/p>\n Use the journeys to establish latency and availability expectations. Interactive collaboration, voice, VDI, large downloads, and administrative protocols tolerate different delays and path changes. Security policy should not be designed in isolation from user experience.<\/p>\n Document ownership for every journey as well. Network engineering may own branch steering, endpoint teams may own FortiClient, identity teams may own SAML and MFA, and application teams may own the private service. The architecture needs explicit handoffs because an access failure can cross all four domains. A useful operational model records the expected path, the responsible team, the evidence each team can collect, and the escalation point when the failure crosses a boundary. That turns a hybrid-work diagram into an operable service rather than a collection of products.<\/p>\n FortiSASE users connect to security and analytics points of presence that enforce policy. Choose PoP strategy around user geography, application location, connectivity, and data-residency requirements. Sending a user through a distant PoP can add avoidable latency even when the security policy is correct.<\/p>\n Consider what happens when the preferred PoP is unavailable. DNS, tunnel establishment, client steering, and route behavior should allow an alternate path without silently bypassing security. Test failover from representative regions because internet routing conditions differ by location.<\/p>\n Log-storage location can be a separate architectural concern from traffic processing. Privacy and regulatory requirements may constrain where telemetry is retained even if users are allowed to connect through a nearby enforcement point.<\/p>\n PoP selection should also account for where private applications are hosted. A user may be close to an enforcement point but far from the data center or cloud region that serves the application. Evaluate the whole path rather than only user-to-PoP latency. For applications with strict regional dependencies, compare several steering options and test them under peak conditions. Capacity planning should include tunnel counts, bandwidth, inspection features, and expected failover load so that an alternate PoP remains usable when traffic shifts during an incident.<\/p>\n FortiClient-based remote access provides a strong option for managed endpoints because the endpoint can establish connectivity to FortiSASE and contribute device posture or identity context. This supports more granular policy than treating every remote browser as an anonymous source.<\/p>\n Endpoint profiles should be designed around meaningful risk signals. Operating-system version, endpoint protection state, certificates, or management status can influence access, but a policy with dozens of fragile checks can generate help-desk noise without materially improving security.<\/p>\n Define remediation behavior. If a device fails posture, the user should know whether access is blocked, limited to remediation resources, or allowed with reduced privilege. A posture rule without a recovery path turns security into an operational dead end.<\/p>\n Endpoint onboarding deserves the same care as policy. Define how FortiClient is deployed, enrolled, upgraded, and removed; how certificates are issued and rotated; and what happens when a device is reimaged or transferred to another employee. Pilot upgrades before broad deployment because an endpoint-agent change can affect connectivity for an entire remote workforce. Keep emergency recovery procedures separate from normal user workflows, and restrict them so that a break-glass method cannot become a permanent bypass around posture checks.<\/p>\n Agentless access is useful for unmanaged or constrained devices that cannot run FortiClient. It can provide secure web gateway or private web application access without installing endpoint software. The concept is similar to clientless remote access<\/a>, where the browser becomes the access mechanism rather than a full network tunnel.<\/p>\n Agentless design has different visibility and control. The service may not have the same endpoint posture signals, and non-web protocols may require a different access method. Do not assume that agentless access is simply a lighter version of the managed endpoint architecture.<\/p>\n Restrict unmanaged devices to the applications and data that make sense for their risk. A contractor using a personal laptop may need one portal but not broad access to internal networks.<\/p>\n Browser-based access should therefore be designed application by application. Confirm supported authentication, session lifetime, file-transfer behavior, clipboard requirements, and how the application handles redirects, WebSockets, or other browser features. Sensitive applications may require restrictions on download or upload from unmanaged devices. When the required protocol cannot be safely published through the agentless model, use a managed endpoint path instead of weakening policy just to preserve a browser-only experience.<\/p>\n SIA protects access to the public internet and web applications with controls such as web and DNS filtering, application control, IPS, antimalware, sandboxing, and other FortiGuard security services. The policy question is which internet applications users need and what inspection is appropriate for those categories.<\/p>\n SPA addresses private company applications. ZTNA can expose specific applications through FortiGate access proxies, while SD-WAN or NGFW private-access designs can support different protocol and topology requirements. Choose the model based on application protocol, user type, and route architecture instead of forcing every private service through one mechanism.<\/p>\n SSA focuses on SaaS visibility and control. Inline CASB and related controls can apply policy to cloud applications, while API-based integrations may provide additional SaaS governance. Keep SaaS policy aligned with identity and data sensitivity so that sanctioned and unsanctioned use are distinguishable.<\/p>\n These three policy planes should share consistent identity and classification without becoming one undifferentiated rule set. A user who can browse a SaaS service from the internet should not automatically gain private application access simply because the same identity group appears in both policies. Maintain separate ownership, logging, and exception handling for SIA, SPA, and SSA, then correlate them through common identity and device context. This makes audits easier and reduces the chance that a change intended for web access accidentally expands private-network privilege.<\/p>\n Branches can reach FortiSASE using FortiGate secure-edge patterns, branch on-ramp, FortiExtender, FortiAP, or other supported site-based methods. The objective is to apply consistent internet security without requiring every endpoint at the site to behave like an individual remote user.<\/p>\n SD-WAN integration can also provide private-access paths toward data centers and cloud hubs. The distinction between overlay path selection and security enforcement should remain clear. A healthy tunnel does not guarantee that the correct application policy is applied, and a correct policy does not fix a bad WAN path.<\/p>\n The site\u2019s comparison of SD-WAN and traditional WAN options<\/a> can help teams choose where internet and private traffic should be steered. In FortiSASE architecture, the answer is often hybrid: some flows use SASE PoPs while others stay on optimized private or direct paths based on application and security requirements.<\/p>\n Branch design also needs a clear answer for local survivability. Decide which traffic can continue locally if the SASE connection is unavailable, which applications should fail over to another path, and which flows must stop rather than bypass inspection. Document route preference and health checks so failover is deterministic. At larger sites, test asymmetric-routing scenarios and stateful inspection during path changes, because a routing failover that moves only one direction of a session can create confusing application failures even while every individual link appears healthy.<\/p>\n Hybrid work depends on consistent identity. Integrate appropriate directory or SAML sources, group users by access need, and require stronger authentication for sensitive private applications. Authentication should work regardless of whether the user is at home, in a branch, or on a managed roaming endpoint.<\/p>\nStart with user populations and access journeys<\/h3>\n
Place security points of presence close to users<\/h3>\n
Use agent-based access where device context matters<\/h3>\n
Keep agentless access intentionally limited<\/h3>\n
Separate SIA, SPA, and SSA policy goals<\/h3>\n
Integrate branches without duplicating the remote-user design<\/h3>\n
Design identity and authentication as shared infrastructure<\/h3>\n