FortiGate is the most widely deployed firewall among SMBs and mid-market organizations worldwide — and that ubiquity comes with a cost. Configurations drift. Admins add temporary rules that never get removed. Default settings that were acceptable in 2020 are exploitable in 2026. A disciplined security audit, run at least quarterly, is the only reliable way to catch these issues before they become breaches.
This checklist walks through the ten highest-impact control areas, grounded in the CIS FortiGate benchmark and real-world findings from hundreds of FortiGate configs analyzed on CRWLR. For each item you'll find the diagnostic question, the relevant CLI, and what a remediated configuration looks like.
What the CIS FortiGate Benchmark Covers
The Center for Internet Security publishes a FortiOS benchmark that maps controls to two implementation levels. Level 1 controls are the baseline — straightforward settings that every deployment should have enabled, with minimal operational impact. Level 2 controls go deeper, covering advanced hardening that may require testing in your environment before applying.
The benchmark organizes controls into four main categories:
- → Administrative access — trusted hosts, multi-factor authentication, management interface exposure, idle timeouts, and login banners
- → Logging and monitoring — syslog forwarding, event logging, disk logging retention, and SNMP hardening
- → VPN configuration — SSL-VPN portal exposure, IPsec cipher strength, IKE version, and pre-shared key hygiene
- → Firewall policies — overly permissive rules, security profile compliance, unused policies, and ANY/ANY entries
CIS benchmarks are a useful starting point, but they don't cover firmware CVE exposure, attack path analysis, or per-policy profile depth — areas where most real-world vulnerabilities live. The checklist below extends the benchmark with practical operational checks.
10-Point FortiGate Audit Checklist
1. Admin Access Controls
Every administrator account should have trusted hosts configured — IP ranges from which that admin is permitted to log in. Without trusted hosts, a compromised credential is a direct path to full firewall control from anywhere on the internet. Additionally, HTTPS-only management should be enforced and Telnet disabled; and all accounts with privilege level 15 should have two-factor authentication enabled.
Audit admin accounts and their trusted host settings with:
Look for accounts with trusthost1 0.0.0.0 0.0.0.0 — this means the account is accessible from any IP. Restrict to specific management subnets and enable two-factor fortitoken or two-factor email for each account.
2. WAN Management Exposure
Management services (HTTPS, SSH, ping) enabled on the WAN interface are one of the most common critical findings in FortiGate audits. Any of these services visible on the public internet expose your firewall to brute-force attacks and exploitation of any authentication bypass CVEs present in your FortiOS version.
Check the allowaccess setting on your WAN interface:
The allowaccess field on external interfaces should be empty or set to none. Management access should only be permitted on dedicated management interfaces or via an out-of-band path. If remote management is required, use a VPN tunnel and manage from there.
3. Password Policy
FortiOS ships with a relatively permissive default password policy. For a security appliance protecting your network perimeter, this is unacceptable. Your audit should verify that minimum password length is at least 12 characters, complexity requirements enforce mixed character classes, and account lockout activates after no more than five failed attempts.
Review the global password policy:
Set min-length 12, must-contain uppercase lowercase number non-alphanumeric, and expire-day 90. Enable lockout-threshold 5 and lockout-duration 300.
4. SSL-VPN Configuration
SSL-VPN has been one of the most heavily exploited attack surfaces in FortiGate deployments over the past three years, with multiple critical authentication bypass CVEs (CVE-2022-40684, CVE-2023-27997, CVE-2024-21762) actively exploited in the wild. Beyond firmware patching, your portal settings directly affect exposure: web mode increases attack surface unnecessarily if you only need tunnel mode, split tunneling without appropriate routing controls can leak traffic, and MFA is non-negotiable for any remote access portal.
Disable web mode if you only need tunnel access (web-mode disable). Require MFA for all portals. Consider restricting the SSL-VPN listening port from the default 443 and adding IP source restrictions to the portal.
5. IPsec VPN Crypto
Legacy IPsec configurations frequently contain weak cryptographic settings that were acceptable when the tunnel was first provisioned but no longer meet current standards. IKEv1 should be replaced with IKEv2 across all tunnels. Encryption should use AES-256; 3DES and DES should be absent. Diffie-Hellman groups below 14 (2048-bit) are considered weak and should be upgraded. Pre-shared keys as the sole authentication method are a risk, particularly when the same PSK is reused across multiple tunnels.
Flag any entry using ike-version 1, proposal des-md5, proposal 3des-sha1, or dhgrp 1 2 5. Each of these represents a cryptographic weakness that could allow an attacker to decrypt tunnel traffic.
6. Policy Review — ANY/ANY Rules and Stale Rules
Overly permissive firewall policies — particularly those using srcaddr all and dstaddr all — are the most direct path to lateral movement once an attacker has a foothold. Equally dangerous are stale rules: policies that were added for a temporary purpose and never removed, which may allow access to systems that no longer exist or have changed role. Checking hit counts lets you identify rules that have never matched traffic.
Policies with zero hit counts for 90+ days are candidates for removal or disabling. ALL/ALL policies in the implicit deny default zone should be reviewed for business justification and annotated with a comment. Any rule with action accept, source all, destination all, and service ALL should be treated as a critical finding.
7. Security Profile Compliance
FortiGate's value as a next-generation firewall comes from its security profiles — IPS, antivirus, web filter, application control, and DNS filtering. These profiles are worthless if they aren't applied to the right policies. Internet-facing policies (any policy where traffic exits to an external zone) should have, at minimum, IPS and antivirus profiles applied. Web filter should be applied to any policy permitting HTTP or HTTPS.
Identify policies where utm-status disable is set or where no profile fields are populated. These are gaps in your detection coverage. Note also whether profiles are operating in monitor mode — detection without blocking — which is common after initial deployment and often never changed to block.
8. SSL/TLS Inspection Coverage
The majority of modern malware command-and-control traffic and data exfiltration uses TLS. Without SSL inspection on outbound traffic, your IPS, antivirus, and web filter are blind to this threat class. Deep inspection — where the FortiGate terminates and re-originates TLS — provides visibility, but requires a trusted internal CA certificate deployed to endpoints. Certificate inspection is a lighter alternative that verifies the certificate chain without decrypting content.
For each outbound internet policy, verify that an SSL/SSH inspection profile is assigned. Policies without SSL inspection that carry HTTPS services represent uninspected traffic paths. Prioritize applying deep inspection to policies handling user web browsing and email before tackling server-to-server traffic.
9. Logging and SIEM Integration
A FortiGate that isn't logging to an external SIEM or syslog target means that any breach or policy violation leaves no durable record — an attacker can cover their tracks simply by waiting for local disk logs to rotate. Your audit should confirm that syslog forwarding is configured and active, that the severity threshold captures at least warning-level events, and that disk logging is enabled as a local buffer in case of connectivity loss to the log target.
Confirm status enable and a valid server address in the syslog config. Set facility local7 and format default for broad SIEM compatibility. Verify that log-traffic enable is set on internet-facing policies.
10. Firmware CVE Exposure
FortiOS has had more actively exploited CVEs than any other firewall platform in the past three years, with CISA's Known Exploited Vulnerabilities catalog listing multiple FortiGate vulnerabilities. Running an unpatched FortiOS version isn't a theoretical risk — it's a documented attack path used by nation-state actors and ransomware groups. Your audit must cross-reference the installed FortiOS version against both the CISA KEV catalog and Fortinet's own PSIRT advisories.
Take the version string and check it at fortiguard.com/psirt and against the CISA KEV feed. CRWLR performs this cross-reference automatically during a scan and flags CVEs where the vulnerable feature is actually enabled in your config — reducing false positives from generic version matching.
Common FortiGate Misconfigurations We See
Across hundreds of FortiGate configs analyzed on CRWLR, four misconfiguration patterns appear repeatedly — none of them obvious, all of them high impact:
local-in policy defaults allow management access from all zones
FortiGate's implicit local-in policy permits inbound connections to the firewall itself from any zone unless explicitly restricted. Most organizations configure trusted hosts on admin accounts but never add explicit local-in policies to block management ports at the zone level. An attacker who reaches any interface can still attempt to authenticate.
WAN interface with ping, HTTPS, and SSH enabled
The allowaccess field on wan1 is commonly set to https ssh ping — often because an admin needed temporary remote access and never removed it. This exposes the management plane directly to the internet and is the entry point for the majority of FortiGate compromises.
Security profiles assigned but operating in monitor-only mode
IPS and antivirus profiles default to monitor mode during initial deployment to avoid disrupting traffic. This setting is frequently never changed to block mode, meaning the FortiGate detects threats and logs them — but takes no action. During an incident, administrators are often surprised to find the appliance "saw" the attack and did nothing.
Orphaned address objects and unused policies
Address objects referencing decommissioned servers and firewall policies for systems that no longer exist are not just hygiene issues — they create ambiguity during incident response and can be exploited if an attacker provisions a new system at an old IP. CRWLR flags address objects that are defined but referenced by no active policy, and policies with zero hit counts over an extended period.
Run this checklist against your FortiGate in 60 seconds.
Upload your FortiGate config file and CRWLR checks all ten areas automatically — firmware CVEs, policy gaps, profile compliance, and more.
Start Free FortiGate Audit →No agents. No credentials. Raw config never stored.
FAQ
What FortiOS versions does the CIS benchmark cover?
The CIS FortiGate benchmark currently covers FortiOS 6.4 and 7.0. Many of the controls apply broadly across FortiOS 6.x and 7.x, but specific CLI paths and available settings differ between major versions. Fortinet deprecated several SSL-VPN and IPsec options between 6.4 and 7.4, so always cross-reference with the release notes for your specific version. If you're running FortiOS 6.2 or earlier, you should prioritize upgrading — these versions are end-of-support and receive no security patches.
How do I export a FortiGate config for offline audit?
From the GUI: System → Settings → Backup. Choose to back up the full configuration and optionally include private data. From the CLI: execute backup full-config ftp <server> <path> or execute backup config ftp for the standard config. For auditing purposes, the text configuration file (not the encrypted backup) is what you need — it's the .conf file that contains the full CLI representation of all settings. CRWLR accepts this format directly.
Does CRWLR store my FortiGate configuration file?
No. CRWLR parses your configuration file in memory at upload time, extracts the normalized security data needed for analysis, and discards the raw file. The configuration text is never written to disk or stored in any database. What is stored is the analysis output — findings, scores, and remediation recommendations — which contains no raw configuration data. This is described in detail in our privacy policy.
How often should FortiGate rules be reviewed for PCI DSS?
PCI DSS Requirement 1.3.2 and the supporting guidance in the PCI DSS v4.0 customized approach require that firewall rules be reviewed at least every six months. In practice, most organizations find that six-month reviews are too infrequent to catch configuration drift — particularly in environments where firewall rules are changed to support application deployments or vendor access on a weekly basis. A quarterly review cadence with automated scanning between reviews (using a tool like CRWLR) better matches the actual pace of change in most SMB environments. Any review must be documented with evidence for the QSA.
What is the difference between FortiAnalyzer and an independent audit tool?
FortiAnalyzer is Fortinet's centralized logging and reporting platform. It aggregates logs from FortiGate devices, provides compliance reports, and includes a configuration audit feature. As a Fortinet product, it has deep integration with FortiOS but has two limitations from an audit perspective: it requires a separate licensing and infrastructure investment, and it doesn't provide an independent view — Fortinet's own tooling assessing Fortinet's own devices. Independent audit tools like CRWLR apply checks derived from CIS benchmarks, CISA KEV data, and cross-vendor security research, and provide a second opinion that is not influenced by the vendor's support relationship with your organization. For compliance purposes, an independent assessment carries more weight than a vendor-supplied report.