Fortinet FCSS_SASE_AD-24: FortiSASE Administration

The Fortinet FCSS_SASE_AD-24 exam represents the FortiSASE 24 Administrator generation, positioned between the earlier version 23 curriculum and the current FortiSASE 25 Administrator exam. The architecture remains centered on secure internet access, secure private access, identity-aware policy, endpoint onboarding, ZTNA, security-profile groups, hybrid-network integration, monitoring, and reporting.

Version 24 should be approached as an evolution of the SASE operating model rather than a completely different product. The durable questions are still: how does a user or branch reach the service, how is identity established, what endpoint context is available, which policy matches, what inspection occurs, and how does the session reach the public or private destination?

If you are moving from FortiSASE 23, use those questions to identify what actually changed instead of relearning the entire architecture from scratch.

Start with the traffic path for each supported access method

Different users can reach FortiSASE through endpoint tunnels, proxy-oriented workflows, branch connections, or other supported access methods. Each method determines which traffic enters the service and which endpoint or identity information is available. An administrator should be able to state where the client sends traffic before discussing web filtering or application control.

Draw one path for a roaming laptop accessing the internet, one for a branch user, and one for a user accessing a private application. Label authentication, point of presence, policy evaluation, inspection, and egress. This diagram becomes the reference for both configuration and troubleshooting.

If the path is wrong at the onboarding or routing layer, tuning security profiles later in the flow will not solve the problem.

Authentication should be designed for user experience and policy precision

SASE policy becomes more useful when users and devices can be identified reliably. Authentication methods, identity-provider integration, certificates, and FortiAuthenticator-related services can all contribute depending on the deployment. The goal is enough assurance to make access decisions without creating repeated or confusing authentication prompts.

For private application access, the identity requirement is especially important because the service is deliberately not exposed to every authenticated user. Group membership, device context, and policy conditions should align with application ownership and business need.

When authentication fails, identify the stage: client redirect, identity-provider session, certificate validation, token exchange, group information, or policy mapping. Identity troubleshooting is more precise when it follows the actual transaction.

ZTNA separates access to applications from access to networks

A zero-trust access design grants access to specific resources based on verified identity and context rather than giving a user broad network reach after a VPN login. FortiSASE private-access workflows can apply that model to applications distributed across data centers or cloud environments.

Candidates should understand the private-application definition, connector or network reachability, identity rule, endpoint posture or tag conditions, and policy. A user can authenticate successfully yet still fail because the private application is unreachable from the service or because the device does not meet the required posture.

Troubleshoot identity, application publishing, and network reachability as separate layers.

Security inspection should be matched to risk and application behavior

Web filtering, application control, malware scanning, IPS, and SSL inspection can provide cloud-delivered enforcement for internet traffic. The correct profile set depends on risk, privacy, application compatibility, and organizational policy. Deeper SSL inspection improves visibility but also introduces certificate and application-compatibility considerations.

When a business application fails, determine the exact inspection component involved before creating an exception. A certificate-pinned application may fail under full inspection; a site may be blocked by category; an upload may trigger malware controls. Each condition should lead to a different, narrowly scoped response.

Monitoring should confirm that the exception solves only the intended case and does not create a broader bypass.

Branch integration makes SASE part of the enterprise WAN

FortiSASE can protect more than individual remote users. Branches can send internet-bound or private-application traffic through the service, often alongside FortiGate and SD-WAN. This lets organizations apply cloud-delivered security consistently while retaining local network and WAN controls.

The design should identify which traffic goes directly to FortiSASE, which uses private connectivity, and which remains local. Backhauling everything may increase latency; sending too much directly may bypass required controls. Policy and routing need to reflect the intended application path.

A branch troubleshooting case should therefore examine the underlay, FortiGate or SD-WAN steering, SASE onboarding, policy, and destination rather than blaming the cloud service automatically.

Visibility should be organized around users, applications, and policy outcomes

FortiView, dashboards, logs, and reports can show application usage, users, threats, bandwidth, policy matches, and other operational information. The administrator should be able to pivot from a user complaint to the relevant session and from a security event to the affected identity or endpoint.

Unknown application volume, unexpected destinations, or rising latency can become useful signals when compared with a known baseline. The key is to connect the metric to a traffic path and policy rather than treat dashboard colors as root causes.

For exam preparation, practice explaining what each view can prove and what additional evidence would still be needed.

Dedicated IP and policy identity can matter for external services

Cloud-delivered access can change the source addresses seen by SaaS platforms and partner systems. Dedicated egress addresses can help with allowlisting, regulatory requirements, or consistent identification when business services expect traffic from known locations. The design should understand why that fixed identity is needed and which traffic should use it.

Do not treat dedicated IP as a user-assignment mechanism. It is an egress and service-identity capability, not a substitute for user authentication or endpoint addressing. This distinction is important in scenarios where an external partner asks for a stable source IP while FortiSASE still applies user-based policy internally.

Document which applications depend on the dedicated address so changes do not unexpectedly break partner access.

Policy design should stay readable as the deployment grows

As more users, branches, and applications are added, SASE policy can become difficult to audit if rules are built as one-off exceptions. Use clear identity groups, application definitions, device conditions, and profile groups so the policy explains the access model. Specific rules should precede broad defaults where appropriate.

Review rules for shadowing and redundant exceptions. Test representative users from each major group and confirm the expected policy and inspection result. This is especially important after version upgrades or identity-provider changes because matching conditions can change even when the visible policy list looks the same.

A readable policy is easier to troubleshoot and safer to modify.

Move from version 24 to the current FortiSASE 25 exam deliberately

Fortinet’s current FCSS SASE page lists FortiSASE 25 Administrator as the available administrator exam. Version 24 material remains useful because the core architecture and administrative disciplines carry forward, but current candidates should compare the latest objectives and product behavior before scheduling.

Use the Fortinet roadmap for credential context and preserve the durable skills: traffic onboarding, identity, ZTNA, profile groups, hybrid integration, monitoring, dedicated egress, and policy design.

Readiness means you can explain how one user reaches both a SaaS application and a private application, which identity and device conditions are evaluated, which security controls inspect the sessions, and how you would isolate a failure without disabling the entire SASE policy stack.

Version comparison should be documented by capability, not screenshots

When comparing FortiSASE 24 with 25, build a simple matrix of architecture, onboarding, identity, private access, security profiles, policy, monitoring, branch integration, and operational tooling. Mark which concepts are unchanged, which gained new options, and which procedures moved. This is more reliable than comparing screenshots because it preserves the purpose of each feature.

Use the matrix to decide what needs fresh hands-on practice. A familiar concept with a changed interface may require only orientation, while a new access method or policy capability deserves a complete lab.

Troubleshooting should compare endpoint, service, and destination evidence

FortiSASE incidents can originate on the endpoint, in the path to the point of presence, inside policy or inspection, on a branch connection, or at the destination application. Build a troubleshooting worksheet with those stages and one evidence source for each. Endpoint logs can show onboarding or tunnel state; FortiSASE monitoring can show policy and security decisions; destination testing can prove whether the application itself is healthy.

This layered view is especially useful when only some users are affected. If all users at one branch fail while roaming users work, investigate branch steering and underlay connectivity. If one user fails from several networks, identity or endpoint posture becomes more likely. If every user fails for one private application, investigate publishing and application reachability.

The goal is to isolate the shared variable before changing policy. SASE centralization can make one wrong policy affect many users, but it can also make evidence easier to correlate when the administrator knows what to compare.

Operational handoffs should preserve the SASE traffic model

FortiSASE administration often crosses endpoint, identity, network, and application teams. A useful handoff should state the affected user group, onboarding method, branch or remote context, matched policy, security decision, private or internet destination, and the evidence already collected. This prevents every team from repeating the same initial checks or assuming the cloud service is responsible for all failures.

Practice writing a short incident summary after each lab. If the problem is identity, show the failed authentication or missing group. If it is a branch path, show the steering or tunnel evidence. If it is a security profile, name the engine and rule. If it is the destination, show that FortiSASE forwarded the session successfully. Clear handoffs are part of operating a distributed security service at scale.