FCSS FortiSASE 25 Administrator common mistakes
FCSS FortiSASE 25 Administrator · Understand the traps and how to avoid them.
Treating FortiSASE as a single all-in-one box and assuming a web filter or antivirus profile configured once applies to every traffic path, instead of mapping each policy to its own path (secure internet access via the cloud PoP, secure private access to internal resources, and SD-WAN/overlay traffic).
Candidates study each domain in isolation and carry over habits from a single FortiGate, where one firewall policy chain governs both directions. In FortiSASE the internet-bound and private-bound paths are configured and enforced by different policy constructs, so a profile attached to one path silently does nothing for the other.
What to do instead
Before answering, ask 'which traffic path is this?' For each question, identify whether the traffic is internet-bound, private-access-bound, or overlay-bound, then name the policy object that actually enforces the control on that path. Build a one-page matrix of path versus enforcing object and review it before the exam.
Configuring a web filter or application control profile and expecting it to act on HTTPS traffic without confirming that SSL inspection is enabled and that the certificate is trusted by the endpoint.
Many modern controls only see the SNI and certificate metadata in an uninspected TLS session. Candidates assume 'block category X' works immediately, but with no deep inspection the firewall cannot match URL paths or content, and an untrusted inspection CA causes browser errors that look like a filtering failure.
What to do instead
Learn the dependency chain: SSL inspection profile attached to the policy, correct inspection mode (certificate inspection versus full deep inspection), and the inspection CA certificate distributed to endpoints via FortiClient or the management profile. When a scenario says HTTPS sites are not being categorized correctly, check inspection before touching the web filter.
Mixing up DNS filter, web filter, and application control when diagnosing why a specific destination was blocked, and choosing the wrong log or profile to remediate.
All three can block a session, and the resulting user page or log entry may look similar. Candidates who never learned the evaluation order guess, then pick a plausible-sounding but wrong fix such as editing the wrong profile or disabling a security profile entirely.
What to do instead
Memorize what each control keys on: DNS filter acts on the resolved domain at query time, web filter on the URL/domain/category of the request, application control on the detected application signature regardless of port. Practise reading a forward-traffic log to see which profile produced the block, then fix that profile only.
Assuming FortiClient and the FortiSASE client (or agent) are interchangeable, and describing endpoint onboarding steps that belong to the other component.
The two names appear in overlapping documentation and both touch endpoint security, but they serve different roles in registration, posture, and ZTNA tag collection. Candidates skim and conflate them, then answer questions about provisioning or posture with the wrong component.
What to do instead
Write a short comparison table: which component performs EMS-managed endpoint protection, which one establishes the secure access tunnel and reports ZTNA tags, and which one is provisioned by invitation or by EMS. Anchor each exam question to the component named in the stem rather than to your memory of the other one.
Answering ZTNA questions as if access is granted by network location or by a simple firewall rule, ignoring that access depends on user identity plus device posture tags evaluated by the access proxy.
Candidates with firewall backgrounds default to 'allow the subnet' thinking. ZTNA in FortiSASE is identity- and tag-driven, so an answer that permits a whole network segment is usually the distractor rather than the correct choice.
What to do instead
For every ZTNA question, identify three things: the identity source (which IdP or local user), the tag or posture condition, and the private application being protected. Reject answers that grant broad network-level access or that skip the posture check.
Describing SD-WAN integration as if the FortiSASE cloud PoP were a normal SD-WAN member that can be steered by any local rule, without accounting for how the overlay is established and which device terminates it.
SD-WAN concepts from on-premises FortiGate study do not map one-to-one onto cloud-delivered secure access. Candidates assume full control of path selection into the PoP and pick answers that ignore the supported integration model.
What to do instead
Study the supported topologies explicitly: which on-premises device forms the overlay to the service, what is advertised or steered over it, and where health checks and SLA rules actually live. When an answer claims the cloud service itself performs arbitrary SD-WAN rule matching, treat it as suspect.
Skipping the initial provisioning prerequisites and answering deployment questions as if a tenant exists with users, groups, and certificates already in place.
Deployment questions feel administrative and low-value, so candidates jump to security features. But many later scenarios hinge on whether the identity provider was integrated, whether the right licence and region were chosen, and whether the endpoint installer was generated correctly.
What to do instead
Build a deployment checklist in order: tenant and region, licence entitlement, identity provider integration and group mapping, endpoint provisioning, then policy. For scenario questions, ask 'has the prerequisite been completed?' before evaluating the proposed security configuration.
Diagnosing connectivity failures by changing security profiles first, when the actual cause is a missing route, an unresolved DNS name, or a client that never registered.
Security profiles are the most visible configuration and the easiest to blame. Candidates who lack a layered troubleshooting method make changes at the top of the stack while the fault sits at the bottom, wasting time and sometimes breaking working policy.
What to do instead
Adopt a fixed order: is the endpoint registered and connected, does DNS resolve, is there a route to the destination, is the session allowed by policy, and only then is a security profile blocking it. Practise locating the relevant log type for each layer so the evidence, not intuition, drives the fix.
Reading only the top-level traffic log summary and concluding 'blocked by policy' without opening the detailed log fields that identify the specific profile, category, or signature responsible.
Summary views compress many causes into one status. Candidates unfamiliar with the log field layout stop at the first plausible label and never reach the field that names the blocking profile or the rule that matched.
What to do instead
Learn the key fields to check in order: action, policy or rule identifier, the security profile that produced the verdict, the category or signature name, and the destination. Do a few hands-on exercises where you must name the exact blocking reason from a log entry before proposing a change.
Assuming a DNS filter block and a web filter block produce the same user experience and the same log evidence, then choosing remediation steps that do not match the observed symptom.
Both can stop a request, but one happens at name resolution and the other at the HTTP request. Candidates who have not compared the two failure signatures pick whichever control they studied most recently.
What to do instead
Create a side-by-side comparison: at what stage each control acts, what the user sees, which log records the event, and what change removes the block. When a stem describes a failure that occurs before any connection is made, DNS filtering is the likely layer; when it occurs after resolution, look at web filtering and inspection.