FCSS FortiSASE 25 Administrator cheat sheet

Deployment is cloud-hosted (Fortinet-managed) with a per-tenant portal; there is no on-prem appliance to size, only licensed seat count and region selection.

Provisioning order: activate license and tenant, set region/PoP, configure identity (local or IdP/SSO via SAML), onboard users/groups, then assign security profiles and policies.

Region selection determines which PoP users egress from; choose the region closest to user populations because traffic is backhauled to the tenant PoP, not the branch.

A tenant is bound to one region at creation; changing region later means a new tenant and re-onboarding, so validate geography before provisioning.

FortiSASE is licensed per user seat; concurrent connected endpoints consume seats, and inactive/disabled users do not, so license math uses active user count.

SSO uses SAML 2.0 with an external IdP (e.g., Entra ID, Okta); group claims drive policy matching, so group names in the IdP must match group objects referenced in FortiSASE policy.

FortiClient/FortiSASE Client registration uses an invitation (email or code) or preconfigured installer with tenant/EMS settings embedded; users cannot self-register without a valid invitation.

Administrative roles are separate from endpoint roles: an admin account with read-only or super-admin rights does not consume a user seat, and API tokens are scoped to admin profiles.

Secure Private Access (SPA) publishes internal applications to remote users through the FortiSASE PoP using ZTNA-style access, without exposing the app directly to the internet.

SPA requires a FortiGate (or supported SD-WAN hub) acting as the private access node with an IPSec tunnel to FortiSASE; the tunnel carries user traffic from PoP to internal resources.

SD-WAN integration uses FortiSASE as a cloud on-ramp: branch FortiGate forms an IPSec overlay to the PoP, and SD-WAN rules steer selected traffic (SaaS, internet, private apps) into that overlay.

Private access policy matching uses destination (internal subnet/FQDN), user/group, and application; unmatched traffic falls to the default internet (secure web gateway) path.

Health checks on the SD-WAN overlay determine path selection; if the FortiSASE tunnel fails SLA, SD-WAN rules fail over to a secondary member (e.g., direct internet or backup tunnel).

Split tunneling is controlled on the endpoint/branch: only traffic matching FortiSASE destinations is sent to the PoP, keeping bulk or latency-sensitive traffic local.

Routing loops are avoided by ensuring the branch does not route the FortiSASE PoP public IPs back into the tunnel; those destinations must stay on the underlay.

Private access nodes must have consistent internal routing to the published subnets; FortiSASE cannot resolve internal addresses that the access node itself cannot reach.

Secure Internet Access (SIA) is the SWG function: endpoint or branch traffic is tunneled to the PoP, inspected, and egressed to the internet from the PoP IP.

Web filter profiles match URL category, URL/domain, and FortiGuard category; action order is typically exempt/allow, block, then monitor, and the first matching rule wins.

FortiGuard category ratings are queried in the cloud; uncategorized or newly registered domains use the 'Unrated' category, so a policy for Unrated is required to control them.

SafeSearch enforcement and YouTube education mode are separate web-filter options; they only apply to supported search engines/providers and do not block other video sites.

Static URL filter entries support wildcards and can override FortiGuard category actions; exact-match static entries take precedence over category-based actions.

SSL inspection is required for HTTPS category enforcement because the URL and SNI are encrypted; without inspection, only the domain/SNI and IP are visible.

Bandwidth and application visibility come from the same PoP egress; per-user or per-group web-filter profiles are assigned through policy, not per endpoint.

Blocked-page replacement and user override (with or without authentication) are profile options; override requires a valid user identity and a configured override group.

SSL inspection modes: certificate inspection (SNI/CN only, no decryption) versus deep inspection (full MITM with a FortiSASE CA certificate trusted by the endpoint).

Deep inspection requires the endpoint to trust the FortiSASE/FortiClient CA; without trust, users see certificate errors and inspection fails closed or open per profile.

Certificate-pinned applications and some financial/health sites break under deep inspection; use exemption lists by category or destination to avoid breakage.

DNS filtering resolves against FortiGuard DNS; blocked categories return a sinkhole/block page, and DNS over HTTPS must be disabled or intercepted for DNS filtering to apply.

Antivirus scans files in transit at the PoP; protocols covered depend on the profile (HTTP/S, FTP, SMTP, IMAP, POP3, CIFS) and file size limits apply before scanning stops.

IPS inspects traffic signatures at the PoP; it requires the traffic to be decrypted for HTTPS, so IPS effectiveness on TLS depends on deep inspection being enabled.

Application control identifies applications by signature and can allow/block/shape; it works with or without SSL inspection but sees fewer applications (only SNI-level) without decryption.

Profiles are applied per policy rule; a flow is inspected only by the profiles attached to the matching rule, so profile coverage must be verified per rule, not globally.

FortiSASE Client is the endpoint agent that creates the secure tunnel to the PoP; it can be deployed standalone or managed through EMS/FortiClient Cloud.

ZTNA on the endpoint uses per-application tunnels (ZTNA tags/application destinations) rather than a full-tunnel VPN, so only published apps are reachable.

ZTNA access requires three elements: a client with the ZTNA destination configured, a user identity (SSO), and a policy on the access broker/FortiGate permitting the user to the app.

FortiClient EMS provides endpoint telemetry and compliance; FortiSASE can consume EMS/FortiClient Cloud tags to gate access on endpoint posture (e.g., antivirus running, OS patch level).

Telemetry/registration: the endpoint registers to the tenant with its invitation; the device record shows status (registered, connected) and is the unit that consumes a seat.

Full tunnel vs split tunnel is a client setting; full tunnel sends all traffic to the PoP, split tunnel sends only matching destinations, which affects both inspection coverage and latency.

ZTNA tags are dynamic; if a posture check fails, the tag is removed and the policy no longer matches, dropping the user without deleting the device record.

Client upgrades are pushed from EMS/FortiClient Cloud; a mismatched client version can fail to establish the tunnel, so version compatibility with the tenant must be checked during troubleshooting.

FortiSASE logs are cloud-hosted and viewed in the portal (Log & Report); log types include traffic, web filter, security (AV/IPS), and admin/event logs.

Log retention is bounded by the license/plan; export or forward logs (syslog) if retention beyond the portal window is required for compliance.

Traffic logs show the policy rule, user, source, destination, application, and action; the matched rule ID is the fastest way to find why traffic was allowed or blocked.

Web-filter logs show the FortiGuard category and the action; if the category is 'Unrated', the block is a policy decision on Unrated, not a FortiGuard outage.

Troubleshooting tunnel issues: verify the endpoint shows connected, the PoP region is reachable, and the client certificate/CA trust is valid; failed SSL inspection shows as certificate errors in the browser.

Use the portal's endpoint/device status and the client's own diagnostics (connection status, logs) to separate client-side failures from PoP-side policy denials.

Policy order matters: an earlier allow rule can bypass a later block; review rule order in the policy table before assuming a profile is broken.

DNS failures present as resolution errors while the tunnel is up; confirm DNS settings are pushed by the client profile and that DoH is not bypassing FortiGuard DNS.