FortiSASE Security Posture Audit

Comprehensive audit of Fortinet FortiSASE cloud-delivered security services.
Unlike traditional perimeter firewall audits that focus on on-premises policy
chains, this skill evaluates the FortiSASE-specific architecture: Secure Web
Gateway (SWG) policy coverage, Zero Trust Network Access (ZTNA) application
gateway posture, thin edge FortiGate integration health, FortiClient endpoint
compliance enforcement, and FortiGuard cloud security service currency.

Covers FortiSASE tenants with SWG, ZTNA, SD-WAN overlay, and FortiClient
endpoint management. For on-premises FortiGate-specific audits, see the
fortigate-firewall-audit skill. Reference references/api-reference.md
for FortiSASE REST API endpoints and FortiCloud authentication patterns.

When to Use

• - Secure Web Gateway policy review — verifying web filter profiles, application control, and URL category enforcement across all SWG policies
• ZTNA application gateway audit — assessing zero trust access rules, posture tag enforcement, and application definitions
• Thin edge FortiGate security assessment — validating tunnel status, SD-WAN overlay configuration, and security policy consistency between cloud and edge
• FortiClient endpoint compliance gap analysis — checking EMS integration, compliance rules, ZTNA tag assignment, and on/off-fabric detection
• SD-WAN overlay security validation — confirming security controls are applied consistently across all overlay paths and that SLA violations do not bypass inspection
• SSL/TLS inspection coverage review — evaluating deep inspection profile deployment, certificate distribution, and inspection exemptions
• FortiGuard service subscription verification — ensuring all subscribed services (AV, IPS, web filter, DNS filter) are active and signatures are current
• Tenant configuration drift detection — comparing current FortiSASE configuration against organizational baselines or prior audit snapshots

Prerequisites

• - FortiSASE admin portal access or API token with read-only permissions (FORTISASE_API_TOKEN environment variable)
• FortiCloud account with IAM permissions sufficient to query tenant configuration, endpoint status, and service health
• Understanding of FortiSASE topology — Points of Presence (PoPs), thin edge sites, endpoint deployment scope, and ZTNA application definitions
• FortiClient EMS integration details — EMS server address, ZTNA tag definitions, compliance rule sets, and endpoint group assignments
• FortiGuard subscription status — which services are licensed (FortiGuard AV, IPS, Web Filter, Application Control, DNS Filter, Inline CASB, DLP)
• Knowledge of expected SWG and ZTNA policy baselines for comparison against current configuration
• Network diagram or inventory showing thin edge FortiGate models, firmware targets, and SD-WAN SLA definitions

Procedure

Follow this audit flow sequentially. Each step builds on prior findings.
The procedure moves from tenant discovery through SWG policy analysis, ZTNA
assessment, firewall policy review, thin edge validation, SSL inspection,
endpoint compliance, FortiGuard health, and logging infrastructure.

Step 1: Tenant and Topology Discovery

Authenticate to the FortiSASE API via FortiCloud IAM and enumerate the
tenant topology.

CODEBLOCK0

After authentication, enumerate tenant resources:

CODEBLOCK1

Record: tenant name, region, PoP locations and their status, thin edge
site count and registration status, total licensed endpoints versus
connected endpoints, and license expiration dates. Identify any PoPs
in degraded state or thin edges showing as offline.

Flag license utilization above 90% as a capacity Warning — approaching
the licensed endpoint limit may prevent new endpoint connections.

Step 2: Secure Web Gateway Policy Audit [SWG]

Retrieve all SWG-related security profiles and policies.

CODEBLOCK2

For each web filter profile, evaluate:

• - URL category coverage: Check that all FortiGuard URL categories have

an explicit action (allow, block, monitor, warning, authenticate). Categories left at default may create unintended access. Count categories with explicit actions versus total categories.

• - Safe Search enforcement: Verify safe search is enabled for search

engines and YouTube restricted mode where required by policy.

• - Content filtering: Check file type blocking by protocol (HTTP, FTP),

ActiveX/Java/cookie filtering settings.

For application control, evaluate:

• - Application categories: Review which application categories are set to

block, monitor, or allow. High-risk categories (P2P, proxy, remote-access, botnet) should have explicit block actions.

• - Application overrides: Check for individual application overrides that

contradict category-level policy.

• - Unknown application handling: Verify the action for applications that

cannot be identified.

Verify that antivirus and IPS profiles are bound to SWG firewall policies.
An SWG policy without AV and IPS binding passes traffic uninspected for
malware and exploits — this is a Critical finding for internet-bound traffic.

Step 3: ZTNA Application Gateway Assessment [ZTNA]

Evaluate ZTNA rules, application definitions, and posture tag enforcement.

CODEBLOCK3

For each ZTNA access proxy rule:

• - Posture tag enforcement: Verify that ZTNA rules require device posture

tags (e.g., compliant OS, AV running, patch level current). Rules without posture tags allow access from non-compliant devices — flag as High.

• - User/group-based access: Confirm rules restrict access by user identity

or group membership, not just network location. ZTNA rules relying solely on source IP contradict zero trust principles.

• - Application definitions: Review ZTNA server definitions — verify the

correct backend servers, ports, and SSL settings are configured. Check for wildcard or overly broad application definitions.

• - Rule ordering: ZTNA rules evaluate top-down. Verify that more specific

rules precede broader rules. Identify shadow rules that never match due to a preceding broader rule.

• - Authentication method: Verify SAML/LDAP/RADIUS authentication source

integration and that MFA is enforced for sensitive applications.

Calculate the ZTNA posture tag coverage ratio: rules with posture tag
requirements divided by total ZTNA rules. A ratio below 80% indicates
insufficient device compliance enforcement.

Step 4: Firewall Policy Review [SWG] [ZTNA]

Audit the firewall policies that govern both SWG and ZTNA traffic flows.

CODEBLOCK4

For each firewall policy, evaluate:

• - Overly permissive policies: Policies with srcaddr "all",

dstaddr "all", service "ALL", and action accept are Critical findings — they accept all traffic without restriction.

• - Security profile binding: Verify every accept policy has antivirus,

web-filter, application-control, IPS sensor, and SSL inspection profile bound. Calculate the profile binding coverage percentage.

• - Rule ordering and shadow detection: Evaluate policies in sequence

order. Identify shadow rules — rules that can never match because a preceding rule with broader criteria matches all their traffic first.

• - Disabled policies: Policies with status disable create audit

confusion. Flag for cleanup.

• - Logging configuration: Verify logtraffic is set to all or INLINECODE10

on security-relevant policies. Policies with logtraffic disable create visibility gaps.

• - Schedule-based policies: Policies with time-based schedules may create

security windows during off-schedule periods. Validate schedule alignment with intended access windows.

Summarize: total policies, accept versus deny, UTM profile coverage ratio,
shadow rule count, and disabled policy count.

Step 5: Thin Edge FortiGate Integration [Thin Edge]

Validate thin edge FortiGate registration, tunnel health, and policy
consistency.

CODEBLOCK5

For each thin edge site:

• - Registration and tunnel status: Verify the thin edge is registered and

its IPsec/SSL tunnel to the nearest FortiSASE PoP is established. Tunnels in down state mean site traffic is not protected by FortiSASE — Critical finding.

• - SD-WAN overlay configuration: Review SD-WAN SLA definitions (latency,

jitter, packet loss thresholds). Verify health-check targets are reachable and meaningful. Check that SLA violation failover does not bypass security inspection.

• - Security policy consistency: Compare the thin edge local firewall policy

with the FortiSASE cloud policy. Identify discrepancies where thin edge local rules may override or conflict with centralized cloud policy.

• - Firmware currency: Check the thin edge FortiOS version against the

recommended firmware target. Thin edges running firmware more than one major version behind are a High finding due to unpatched vulnerabilities.

• - Dual-tunnel redundancy: Verify thin edges have tunnels to at least two

PoPs for redundancy. Single-tunnel configurations create a single point of failure.

Step 6: SSL/SSH Inspection Configuration [SWG] [ZTNA]

Review deep inspection profiles and their deployment coverage.

CODEBLOCK6

Evaluate:

• - Deep inspection deployment: Identify which firewall policies use

deep-inspection versus certificate-inspection. Policies using only certificate inspection cannot inspect encrypted payload — AV and IPS profiles see only connection metadata on HTTPS traffic.

• - Inspection exemptions: Review exempt lists in SSL inspection profiles.

Overly broad exemptions (entire categories or wildcard domains) reduce inspection coverage. Document each exemption with business justification.

• - Certificate deployment: Verify the FortiSASE CA certificate is

deployed to all managed endpoints. Endpoints without the CA certificate will encounter TLS errors or bypass inspection.

• - Protocol-specific inspection: Check inspection settings for HTTPS,

SMTPS, IMAPS, POP3S, and FTPS. Verify all relevant protocols are included in the inspection scope.

• - Performance impact assessment: Deep inspection increases latency and

resource consumption. Review PoP capacity metrics to ensure deep inspection is sustainable at current traffic volumes.

Step 7: FortiClient Endpoint Compliance [Endpoint]

Assess FortiClient EMS integration and endpoint compliance posture.

CODEBLOCK7

Evaluate:

• - EMS integration health: Verify FortiClient EMS is connected and

synchronizing. Check last sync timestamp — sync delays exceeding 15 minutes may indicate connectivity issues.

• - Compliance rule evaluation: Review compliance rules for each endpoint

group: - OS patch level (days since last patch, minimum OS version) - Antivirus status (real-time protection enabled, signatures current) - Vulnerability scan results (critical/high vulnerability count) - Firewall status (endpoint firewall enabled) - Disk encryption status (required for endpoints accessing sensitive data)

• - ZTNA tag assignment: Verify that compliance evaluation results in

correct ZTNA tag assignment. Non-compliant endpoints should receive a non-compliant tag that restricts ZTNA access. Check for endpoints with missing or stale tags.

• - On-fabric vs off-fabric detection: Verify FortiClient correctly

detects whether the endpoint is on-fabric (corporate network) or off-fabric (remote). Off-fabric endpoints should route through FortiSASE SWG; on-fabric endpoints may use local FortiGate. Misconfigured detection can create security gaps.

• - Endpoint compliance percentage: Calculate the percentage of managed

endpoints meeting all compliance rules. Rates below 85% indicate systemic compliance issues requiring remediation campaigns.

Step 8: FortiGuard Service Validation [SWG] [ZTNA]

Verify subscription status and signature currency for all FortiGuard
security services.

CODEBLOCK8

Verify each FortiGuard service:

Service	Expected Status	Maximum Signature Age
FortiGuard Antivirus	Active, licensed	24 hours
FortiGuard IPS

Active, licensed | 7 days |
| FortiGuard Web Filter | Active, licensed | 7 days |
| FortiGuard Application Control | Active, licensed | 7 days |
| FortiGuard DNS Filter | Active, licensed | 7 days |
| FortiGuard Inline CASB | Active (if licensed) | 7 days |
| FortiGuard DLP | Active (if licensed) | 7 days |

Check FortiGuard server connectivity from each PoP. FortiSASE relies on
cloud-based FortiGuard queries for real-time web filter rating and DNS
filter lookups. Degraded connectivity forces fallback to cached data, reducing
detection efficacy for newly categorized threats.

Verify the update mechanism — FortiSASE should automatically receive
signature updates from FortiGuard. Check for update failures in the last 7
days and identify root cause (connectivity, license, service outage).

Step 9: Logging and Analytics [SWG] [ZTNA] [Thin Edge] [Endpoint]

Check FortiAnalyzer Cloud integration and log infrastructure health.

CODEBLOCK9

Evaluate:

• - FortiAnalyzer Cloud integration: Verify FortiAnalyzer Cloud (or

on-premises FortiAnalyzer) is connected and receiving logs from all FortiSASE components (SWG, ZTNA, thin edges, endpoints).

• - Log types forwarded: Confirm that traffic logs, UTM logs (AV, IPS,

web filter, application control), event logs, and ZTNA logs are all forwarded. Missing log types create investigation blind spots.

• - Log retention: Verify log retention period meets compliance

requirements (typically 90-365 days depending on regulatory framework).

• - Alert policies: Review configured alert policies for security events.

At minimum, alerts should cover: malware detection, IPS critical severity, ZTNA authentication failures, thin edge tunnel down, FortiGuard update failures, and endpoint compliance drops.

• - Threat detection dashboards: Verify SOC-relevant dashboards are

configured for SWG threat activity, ZTNA access patterns, and endpoint compliance trends.

Threshold Tables

SWG Policy Coverage

Metric	Normal	Warning	Critical
URL categories with explicit action	>90%	70-90%	<70%
AV profile bound to SWG policies

100% | 80-99% | <80% | | IPS sensor bound to SWG policies | 100% | 80-99% | <80% | | Application control profile bound | >95% | 75-95% | <75% | | High-risk app categories blocked | 100% | 80-99% | <80% | | SSL deep inspection on internet policies | >80% | 50-80% | <50% |

ZTNA Tag Enforcement

Metric	Normal	Warning	Critical
ZTNA rules with posture tag requirement	>90%	70-90%	<70%
Endpoint posture tag compliance rate

>85% | 65-85% | <65% | | ZTNA rules with user/group restriction | 100% | 80-99% | <80% | | MFA enforcement on sensitive apps | 100% | 80-99% | <80% | | ZTNA tag propagation latency | <5 min | 5-15 min | >15 min |

Thin Edge Health

Metric	Normal	Warning	Critical
Tunnel status	Up (all edges)	1-2 edges degraded	Any edge down
Firmware currency

Current or N-1 | N-2 | >N-2 or EOL | | SD-WAN SLA compliance | >95% | 80-95% | <80% | | Dual-tunnel redundancy | All edges dual-tunnel | >80% dual-tunnel | <80% dual-tunnel | | Policy consistency (cloud vs edge) | 100% match | Minor drift | Major drift |

FortiClient Compliance

Metric	Normal	Warning	Critical
Endpoints compliant (all rules)	>90%	75-90%	<75%
OS patch currency (<30 days)

>90% | 70-90% | <70% | | AV signatures current (<24h) | >95% | 80-95% | <80% | | Vulnerability scan (no critical) | >90% | 75-90% | <75% | | EMS sync status | Connected, <15min | Connected, 15-60min | Disconnected or >60min |

FortiGuard Service Health

Metric	Normal	Warning	Critical
Subscription status	All active	Expiring <30 days	Expired or inactive
AV signature age

<24 hours | 24-72 hours | >72 hours | | IPS signature age | <7 days | 7-14 days | >14 days | | Web filter DB age | <7 days | 7-14 days | >14 days | | FortiGuard connectivity | All PoPs connected | Intermittent | Disconnected |

Decision Trees

SWG Policy Gap Prioritization

CODEBLOCK10

ZTNA Access Policy Remediation Path

CODEBLOCK11

Thin Edge Security Posture Improvement

CODEBLOCK12

Report Template

CODEBLOCK13

Troubleshooting

FortiCloud API Authentication Failures

FortiCloud API authentication requires a valid API client ID and credentials
with appropriate IAM permissions. Common issues:

• - Token expiration: FortiCloud bearer tokens have a limited TTL

(typically 1 hour). Implement token refresh logic for long-running audits.

• - IAM permission scope: The API user must have read-only access to

FortiSASE resources. Insufficient permissions return 403 Forbidden on resource endpoints but may succeed on authentication.

• - Multi-factor authentication: If MFA is enforced on the FortiCloud

account, API authentication may require an API-specific account without MFA or use of service account credentials.

• - Rate limiting: FortiCloud API enforces rate limits (typically 60

requests/minute). Implement exponential backoff for 429 Too Many Requests responses. Batch queries where possible.

Thin Edge Tunnel Flapping

Thin edge tunnels that repeatedly establish and drop indicate underlying
connectivity or configuration issues:

• - WAN link instability: Check the thin edge WAN interface for errors,

packet loss, or bandwidth saturation. SD-WAN health checks can trigger tunnel failover, but the root cause is the underlay network.

• - MTU mismatch: IPsec tunnels add overhead. If the path MTU is too

small, fragmented packets cause tunnel instability. Set the thin edge tunnel MTU to 1400 or enable DF-bit clearing.

• - NAT traversal: Thin edges behind NAT devices require NAT-T

(UDP 4500). Verify the upstream NAT device allows UDP 4500 and that the NAT session timeout exceeds the IPsec DPD interval.

• - DPD (Dead Peer Detection) sensitivity: Aggressive DPD intervals

(e.g., 5 seconds) on high-latency links cause false positives. Adjust DPD interval to 30 seconds with a retry count of 3.

FortiClient EMS Sync Delays

When FortiClient EMS synchronization with FortiSASE exceeds expected
intervals:

• - EMS connectivity: Verify the EMS server can reach FortiSASE cloud

endpoints (*.fortisase.com:443). Check firewall rules on the EMS host and any upstream proxies.

• - Endpoint count scaling: Large endpoint populations (>10,000) may

experience sync delays during full synchronization. Verify incremental sync is functioning.

• - EMS version compatibility: Ensure the FortiClient EMS version is

compatible with the current FortiSASE release. Version mismatches can cause sync failures or partial data updates.

• - Certificate trust: EMS-to-FortiSASE communication requires valid

TLS certificates. Expired or untrusted certificates cause silent sync failures.

FortiGuard Connectivity Behind Proxy

When FortiSASE PoPs or thin edges cannot reach FortiGuard update servers:

• - Proxy configuration: If the environment requires an outbound proxy,

configure FortiGuard to use the proxy for update downloads. Verify proxy authentication credentials if required.

• - DNS resolution: FortiGuard services require DNS resolution for

service.fortiguard.net, update.fortiguard.net, and related domains. Verify DNS is functioning on all PoPs and thin edges.

• - Port requirements: FortiGuard uses HTTPS (TCP 443) and may use

UDP 53/8888 for rating queries. Ensure these ports are permitted.

• - Regional server selection: FortiGuard uses anycast and regional servers.

Verify the nearest FortiGuard server is reachable and not blocked by geo-IP restrictions.

ZTNA Tag Propagation Delays

When ZTNA tags updated in FortiClient EMS do not reflect in FortiSASE
access decisions promptly:

• - Propagation pipeline: Tag updates flow from FortiClient agent to

EMS to FortiSASE. Each hop introduces latency. Normal propagation is under 5 minutes; delays beyond 15 minutes indicate a pipeline issue.

• - EMS-to-FortiSASE sync interval: Check the configured sync interval

between EMS and FortiSASE. Default intervals may be too long for time-sensitive compliance enforcement.

• - Tag caching: FortiSASE may cache ZTNA tags at the PoP level. Cache

TTL settings affect how quickly tag changes take effect. Review cache settings if tag changes are not applying within expected timeframes.

• - Compliance rule evaluation frequency: FortiClient evaluates compliance

rules periodically (default: every 5 minutes). Increasing evaluation frequency reduces the time between a compliance state change and the corresponding tag update.

PoP Capacity and Performance Limitations

When FortiSASE PoP performance degrades or capacity limits are approached:

• - Endpoint concentration: If too many endpoints connect to a single PoP,

performance degrades. Enable PoP load balancing or geo-steering to distribute endpoints across available PoPs.

• - Deep inspection overhead: SSL deep inspection significantly increases

per-session resource consumption. If PoP capacity is constrained, evaluate inspection exemptions for high-bandwidth, low-risk traffic (e.g., trusted SaaS platforms with their own security controls).

• - Traffic spikes: Sudden increases in endpoint connections (e.g., start

of business day across a time zone) can saturate PoP capacity. Review capacity planning and consider PoP pre-scaling if supported.

• - Regional PoP availability: Some regions have limited PoP presence.

Endpoints in underserved regions may experience higher latency. Review FortiSASE regional coverage against endpoint geographic distribution.