FortiSASE Secure Internet Access (SIA) extends FortiOS-based security policy to remote users and sites through cloud-delivered firewall and secure web gateway services. Current FortiSASE 7.4 architecture supports agent-based remote users through FortiClient, agentless browser-based users through explicit proxy, and site-based users through FortiGate, FortiExtender, FortiAP, Branch On-Ramp, or related secure-edge patterns. SIA applies capabilities such as IPS, application control, web and DNS filtering, antimalware, sandboxing, and anti-botnet/C2 controls at FortiSASE security points of presence.
Within Fortinet Security Operations, the critical design decision is traffic steering. Security policy only applies to traffic that reaches the FortiSASE inspection path, so endpoint type, location, protocol mix, branch architecture, and private-app needs must be mapped before choosing an agent, proxy, or site tunnel.
The existing SASE architecture article provides the vendor-neutral context.
Agent-based SIA is the broadest remote-user model
Current FortiSASE recommends FortiClient agent mode for managed Windows, macOS, Linux, Android, and iOS endpoints where all internet traffic should be secured.
The endpoint establishes a tunnel to a FortiSASE security PoP and receives policy from the service.
This is the preferred model when the organization needs more than browser traffic protection and can manage endpoint software.
Agentless SIA protects web traffic only
Browser-only or unmanaged devices can use a PAC/proxy configuration to send HTTP/HTTPS traffic to the FortiSASE secure web gateway.
Other protocols bypass FortiSASE in this mode.
Use this for Chromebooks, BYOD/browser-only cases, or environments where installing FortiClient is not possible, while clearly documenting that non-web traffic is outside the SIA proxy path.
Site-based SIA extends cloud inspection to branches
FortiSASE can receive branch traffic through supported FortiGate secure-edge, Branch On-Ramp, FortiExtender, FortiAP, or other documented site-steering architectures.
Users behind the branch device then receive cloud security policy without an agent on every endpoint.
Choose this for IoT, servers, shared devices, or locations where endpoint agents are impractical.
On-net detection prevents unnecessary backhaul
Current FortiSASE architecture supports managed FortiClient endpoints that can detect they are on a protected corporate network and avoid sending traffic to FortiSASE when an on-premises FortiGate already provides the desired inspection.
This can reduce cloud bandwidth and latency.
Define on-net criteria carefully so an endpoint cannot falsely classify an untrusted network as corporate and bypass cloud inspection.
Identity and device posture should influence policy
FortiSASE supports user authentication through enterprise sources such as SAML, LDAP/AD, and RADIUS depending on deployment.
FortiClient/EMS context can add endpoint posture and ZTNA tags.
Use identity, user group, device state, application, URL category, and destination to build policy rather than relying only on source IP that changes as remote users roam.
Internet access and private access should be designed together
Current FortiSASE architecture distinguishes SIA from Secure Private Access (SPA) using ZTNA for private TCP applications.
Agent-based FortiClient users can use ZTNA to reach private resources behind a FortiGate access proxy while SIA protects internet traffic.
FortiGate ZTNA Tags provides the posture-tagging context.
IPsec remote-agent support is now a current 7.4 design option
FortiSASE supports remote-user connectivity using IPsec in addition to historical SSL-based tunnel behavior.
Current guidance includes version-specific recommendations and transition behavior for existing instances.
Plan tunnel migration with maintenance windows, client versions, authentication compatibility, and rollback rather than changing the transport on the whole remote workforce at once.
Security profiles should be consistent with on-premises FortiGate policy
SIA is most valuable when web, application, IPS, malware, DNS, sandbox, and C2 policy aligns with the organization’s FortiGate standards.
Do not assume “same FortiOS engine” automatically means identical profiles; review exceptions, category overrides, SSL inspection, and application policy explicitly.
Use common policy naming and ownership so SecOps can understand controls across branch, campus, and SASE.
PoP selection and user experience should be measured
FortiSASE relies on global security PoPs, so user latency depends on geography, ISP path, tunnel setup, DNS, and application destination.
Track tunnel stability, latency, throughput, loss, login failures, and application performance by region and endpoint type.
Security adoption suffers quickly if users learn that bypassing the corporate path makes applications faster.
Logs should prove steering and inspection
Monitor which endpoint/profile/steering method was used, user identity, PoP, policy, application, destination, security profile results, and tunnel state.
Send high-value SIA telemetry into FortiAnalyzer or the organization’s SIEM so remote-user incidents can be reconstructed.
FortiAnalyzer Detection Rules provides the event-handler layer for turning logs into actionable detections.
FortiSASE internet access succeeds when traffic steering and security intent stay aligned
The mature design uses FortiClient for managed all-protocol endpoints, agentless proxy for web-only cases, site steering for branches/shared devices, identity/posture-aware policy, consistent inspection, measured PoP experience, and central logging.
SASE policy is only as complete as the traffic path feeding it, so every bypass and alternate connection method should be intentional and visible.
Traffic steering should be documented per user/device population. Managed laptops, mobile devices, unmanaged browser-only devices, branches, IoT, servers, and guest networks may each use different SIA methods. Create an architecture matrix that states steering method, supported protocols, authentication source, security profiles, private-access method, logging, and failover behavior for every population.
Agent profiles should be environment-aware. Current FortiSASE designs can apply different endpoint profiles when a corporate-managed device is on-premises versus remote. Use on-net detection only with strong signals such as trusted network attributes or managed posture; weak rules can let a remote endpoint bypass FortiSASE because it happens to match a common local subnet.
Split tunneling should be governed as a security exception. Windows FortiClient supports application-based split tunneling in some current IPsec-agent designs, while other platforms may use full tunnel. Every excluded application or destination should have an owner and business reason because split traffic is outside the same FortiSASE inspection and logging path.
Proxy-based agentless SIA should account for applications that ignore system proxy settings or use QUIC/UDP/non-HTTP protocols. Browser protection may be complete while native applications connect directly. Test the actual device/application portfolio and block or manage unsupported traffic through another control when policy requires full internet inspection.
Identity-provider and directory availability is part of SIA resilience. SAML, LDAP, or RADIUS failures can affect thousands of remote users simultaneously. Maintain multiple identity paths where supported, test certificate/signing-key rotation, and define break-glass or continuity procedures that do not simply bypass security for everyone during an IdP incident.
TLS inspection policy should be consistent across FortiGate and FortiSASE where the same applications/users move between office and remote locations. Differences in certificate trust or exemption categories create confusing behavior. Manage enterprise CA distribution centrally and test pinned, mutual-TLS, finance/health, and privacy-sensitive applications before forcing deep inspection broadly.
FortiSASE internet access should include DNS as a security/control-plane dependency. DNS filtering and domain-based policy require reliable DNS steering, and private application access may use separate internal namespaces. Monitor resolution latency/failure and avoid configurations where bypassed DNS leaks user intent outside the expected security path.
PoP resilience should be exercised with user failover. Simulate an unavailable preferred location or transport and observe reconnect time, new public egress IP, SaaS geolocation, MFA/session impact, and application persistence. A service can have many global PoPs while a client’s configured policy still makes one path a practical single point of failure.
Operational reporting should correlate FortiSASE logs with endpoint/FortiClient health and on-premises FortiGate activity. When a user transitions from office to remote, SecOps should still recognize the same identity/device and apply consistent detection. Unified telemetry is one of the major SASE advantages only if naming, tags, and forwarding stay consistent.
Service rollout should include application discovery before enforcement. Inventory SaaS, private web apps, conferencing, developer tools, software update services, and high-bandwidth destinations, then baseline category/application policy. Aggressive blocking on day one can create so many exceptions that users and administrators lose trust in the SASE design.
Dedicated public egress IP requirements should be identified early for SaaS allowlists, payment providers, partner APIs, and location-sensitive services. If applications trust source IP, changes in FortiSASE PoP or egress design can cause outages. Document which services depend on fixed egress and test failover behavior.
Device offboarding should remove FortiSASE registration, certificates/tokens, and endpoint-management state, not only disable the user. Lost or retired devices can retain configuration and credentials that matter if the account is later re-enabled or another user receives the device.
Security and network teams should share ownership of SIA. Network engineers manage reachability, PoPs, tunnels, DNS, and performance; security owns inspection, identity/posture policy, malware/URL controls, and exceptions. A joint operating model avoids the common failure where each team assumes the other owns the user-impacting problem.
Policy exception requests should identify the steering method they affect. A destination bypass in agentless proxy mode is different from a split-tunnel exclusion in FortiClient agent mode or a branch routing exception. Record the exact path so future reviews understand which traffic leaves FortiSASE inspection.
Measure adoption by percentage of expected traffic and users under SIA, not merely enrolled endpoints. A laptop can be enrolled while applications bypass through local proxy settings, split tunnel, or alternate networks. Telemetry should verify that the designed traffic actually reaches FortiSASE.
Traffic steering should be verified for SaaS, internet, and private destinations under both normal and failover conditions. Security inspection is useful only if the selected path is stable enough that operators can explain why a user reached a particular enforcement point.
