Fortinet FCSS_SASE_AD-23: FortiSASE Administration

The Fortinet FCSS_SASE_AD-23 exam represents the FortiSASE 23 Administrator generation. It introduced candidates to a cloud-delivered security model that brings secure internet access, zero-trust network access, endpoint onboarding, authentication, security profiles, policy, monitoring, and reporting into one service. Fortinet’s current FCSS SASE page now lists FortiSASE 25 Administrator as the available administrator version, so version 23 should be studied as an earlier stage of the same architecture rather than as the current scheduling target.

SASE becomes easier to understand when it is treated as a traffic and identity architecture, not a marketing label. Users can be at home, in a branch, on a managed laptop, using a browser-only workflow, or connecting to a private application. FortiSASE has to identify that user or device, bring traffic to a point of presence, apply the correct policy and security controls, and provide access without requiring every session to backhaul through a traditional data center.

The broader SASE model helps separate architecture from product detail: networking and security controls are delivered together from distributed cloud infrastructure, with identity and context influencing policy.

Secure internet access and private application access solve different paths

Secure internet access protects user traffic headed to public web and SaaS services. Secure private access focuses on applications that are not exposed publicly and should be reachable only by authorized users or devices. The same user may need both paths during one workday, but the routing, connectors, and policy goals differ.

For SIA, examine how endpoint traffic reaches FortiSASE, which security profile group is applied, and how web, application, malware, or inline cloud controls influence the session. For private access, identify the private application, the connector or network path that exposes it to the service, and the identity conditions required to authorize the connection.

Troubleshooting starts by determining which path the user is actually attempting. Changing internet-security policy will not repair a missing private-application connector.

Endpoint onboarding determines how traffic and posture become visible

FortiClient-based onboarding can provide secure connectivity, user and device identity, and endpoint context. Browser or proxy-oriented methods can support other use cases where a full endpoint agent is not appropriate. Each onboarding method creates different traffic paths and different information for policy.

Candidates should understand certificate distribution, endpoint registration, user authentication, tunnel establishment, and how endpoint tags or posture information are used. If a user cannot browse through FortiSASE, identify whether the problem occurs before authentication, during tunnel or proxy setup, or after policy evaluation.

A clean onboarding workflow also matters operationally because large organizations must enroll, update, and remove devices predictably rather than rely on manual troubleshooting for every user.

Identity and zero-trust tags make policy more precise than network location

Zero-trust network access is built around explicit identity and context rather than assuming a user is trusted because they are on an internal network. The ZTNA model uses user, device, application, and posture information to decide what a session may reach.

FortiSASE can use authentication methods and zero-trust tags to differentiate users and endpoints. A compliant managed laptop may receive access to a private application while an unmanaged device receives only internet access. The design should make those outcomes deliberate and explainable.

When access is denied, troubleshoot identity and tag generation separately from the application connector and policy. A correct policy cannot match an expected tag that the endpoint never received.

Security profile groups define the inspection stack

SASE security policy can include web filtering, application control, antivirus, intrusion prevention, SSL inspection, and other controls depending on the service and version. Grouping related controls makes policy reusable, but candidates should still understand which engine produced a block or warning.

Encrypted traffic creates the same visibility tradeoff seen on firewalls. Deeper inspection can identify more application and threat behavior, but it depends on certificate trust and application compatibility. A high number of unknown applications may indicate insufficient inspection rather than a failure of application control itself.

The FortiSASE architecture and security-feature practice is useful because it connects profiles with observable traffic behavior.

Hybrid networks connect branches and private resources to the cloud service

FortiSASE is not only for roaming users. Branches and private applications may be integrated so the same cloud-delivered policy can protect multiple access patterns. The architecture can include FortiGate, SD-WAN, IPsec, private-access connectors, and identity systems alongside the SASE points of presence.

Draw the path for a branch user accessing the internet, a remote user accessing a private application, and a branch-to-private-service flow. Identify where traffic enters FortiSASE, where identity is evaluated, and where policy enforcement occurs. This reveals whether a problem belongs to the branch underlay, SASE service, or private application path.

The design goal is consistent security without forcing every flow through an unnecessary location.

Monitoring should connect user experience with security decisions

FortiView, dashboards, logs, and reports help administrators understand application use, threats, policy hits, user activity, and service behavior. These tools are most useful when an administrator can start with a user complaint and find the exact session or policy outcome that explains it.

For performance complaints, separate endpoint connectivity, local internet quality, path to the nearest point of presence, SASE inspection, and destination performance. For blocked traffic, identify the user, device, policy, security profile, and exact engine decision. Monitoring is evidence, not a substitute for a traffic model.

Build a baseline of normal user and application behavior so changes are visible before they become widespread tickets.

Policy should be built from access requirements rather than product categories

Start policy design with who needs access to what, from which device state, using which application, and under what risk conditions. Then select the FortiSASE policy type and security controls that enforce that requirement. Beginning with a list of available features often produces overlapping rules that are difficult to audit.

Ordering and scope matter. A broad rule that matches too early can prevent a more specific access requirement from being evaluated. An exception created for one application can unintentionally bypass inspection for others if the matching criteria are too loose.

Review policy with test identities and applications rather than relying only on configuration syntax.

Version progression should preserve architecture while updating capabilities

FortiSASE 23 was followed by FortiSASE 24 and then FortiSASE 25. The current FCSS SASE page lists FortiSASE 25 Administrator as available. Candidates using version 23 material should therefore preserve the core SASE model—SIA, private access, identity, endpoint onboarding, security profiles, policy, monitoring, and hybrid connectivity—while comparing newer objectives for changes in supported capabilities and workflows.

The older FortiSASE 23 exam article in the inventory provides additional historical context, but current exam decisions should follow the Fortinet certification roadmap and current training pages.

You are ready when you can trace a remote or branch user from authentication through onboarding, point-of-presence access, policy, security inspection, and final application reachability—and identify the evidence that separates identity, network, policy, and destination failures.

A version-23 lab should focus on the enduring SASE workflow

Even if you no longer have a version-23 environment, you can practice the durable sequence using current training: onboard a test user, authenticate, send internet traffic through a security profile, publish one private application, apply a zero-trust condition, and use FortiView to explain the result. Then map the same tasks back to the version-23 terminology in older study material.

This approach keeps historical exam content technically useful without confusing old interface details with current exam logistics.

Policy migration between SASE versions should preserve business intent

When organizations move between FortiSASE generations, the migration should begin with the access requirements rather than a direct copy of every policy object. Document user groups, device conditions, internet categories, private applications, exceptions, dedicated egress needs, and reporting requirements. Then recreate those intentions using the current version’s supported policy structure.

This prevents outdated exceptions or obsolete onboarding assumptions from being carried forward simply because they existed in version 23. A migration is an opportunity to identify rules that no longer match a business requirement, profile groups that overlap, or private applications that should be segmented more precisely.

For study, compare one version-23 policy scenario with the equivalent version-25 approach. Explain what stayed conceptually the same and which operational procedure changed. That is a stronger transition skill than memorizing two interfaces independently.

Version 23 monitoring should be used to validate policy, not just report usage

A SASE service can show large amounts of application, user, and security data, but monitoring becomes useful only when it is connected to expected policy behavior. For a test user, record which point of presence handled the session, which policy matched, which security profile group inspected the traffic, which application was identified, and what egress identity the destination observed. This creates a baseline that makes later anomalies explainable.

Use the same baseline when reviewing older version-23 study material. If a dashboard name or interface location has changed in later versions, the evidence question remains the same: which user sent which traffic, through which access method, under which policy, and what happened to it? That keeps the material useful without confusing historical interface details with current operations.