ConfigSentry Technical Security Report

The default built-in administrator account named admin is still enabled. Leaving the default administrator account active makes credential guessing easier because attackers already know a valid username, increasing the risk of brute-force attempts, credential-stuffing, unauthorized management access, and poor administrator accountability.

Create one or more named administrator accounts with appropriate access profiles, strong authentication, and trusted host restrictions, then disable the default admin account if the operational and support model allows it.

Recommended configuration:
config system admin
edit "<named-admin>"
set accprofile "super_admin"
set password <strong-password>
set trusthost1 192.0.2.10 255.255.255.255
next
edit "admin"
set status disable
next
end

Before disabling the default admin account, confirm that at least one named emergency or break-glass administrator exists, MFA and trusted hosts are configured where supported, credentials are stored securely, and operational recovery procedures are documented.

This active FortiGate administrator account is configured without multi-factor authentication or approved external authentication. Administrator accounts provide privileged access to firewall configuration, security policy, VPN settings, routing, logging, and other sensitive controls. If an administrator password is guessed, reused, phished, leaked, or stolen, an attacker may be able to access the firewall using only a single authentication factor.

Enable MFA for local FortiGate administrator accounts, or move administrator access to an approved external authentication workflow that enforces MFA.

Review all active administrator accounts and confirm that each one is protected by FortiToken, email-based two-factor authentication, SMS-based two-factor authentication where acceptable, or centrally managed remote authentication with MFA enforced by the identity provider.

Disable or remove unused local administrator accounts. Where local emergency or break-glass administrator accounts are required, restrict their use, protect them with MFA where supported, store credentials securely, and monitor their usage.

Example configuration using FortiToken:
config system admin
edit <admin-name>
set two-factor fortitoken
set fortitoken <token-serial>
next
end

This active FortiGate administrator account uses remote authentication, but the firewall configuration export does not prove whether the external authentication provider enforces MFA. Remote authentication can be an appropriate control when MFA, account lifecycle management, and access policy are enforced by the identity provider, RADIUS, TACACS+, LDAP, or SAML workflow.

Verify that the remote authentication path for this administrator account enforces MFA and is managed through an approved identity process.

Recommended checks:
- Confirm which remote authentication server or group is used by this administrator account.
- Confirm MFA is enforced by the identity provider or remote access workflow.
- Confirm disabled or departed users are removed through central identity lifecycle controls.
- Confirm administrator access is restricted to approved groups.
- Confirm emergency or break-glass accounts are separately controlled, monitored, and reviewed.

If MFA is not enforced externally, enable FortiGate MFA for the account or move administrator access to an approved MFA-protected authentication workflow.

Example local FortiToken configuration:
config system admin
edit <admin-name>
set two-factor fortitoken
set fortitoken <token-serial>
next
end

A WAN-facing FortiGate interface allows interactive administrator login services.

Remove interactive administrator access from interfaces that are internet-facing, external, or otherwise reachable from untrusted networks. Services such as HTTPS, HTTP, SSH, and Telnet expose the FortiGate management plane and can increase the risk of credential attacks, vulnerability probing, brute-force attempts, and accidental public administration exposure.

Recommended configuration:
config system interface
edit <wan-or-external-interface>
set allowaccess ping
next
end

Use a dedicated management interface, internal management VLAN, VPN, ZTNA, or controlled jump-host path for administrator access instead. If remote administration is genuinely required, restrict it with administrator trusted hosts and local-in policy controls, require MFA, disable insecure protocols such as HTTP and Telnet, and ensure all administrative access is logged and monitored.

Before removing access, confirm that administrators have a working approved management path so the firewall is not accidentally locked out.

This policy appears to allow traffic from an internet, WAN, or external interface directly toward a likely Cardholder Data Environment (CDE), Payment Card Industry (PCI), payment, Point of Sale (POS), or cardholder-data destination without an obvious DMZ or segmented inspection tier.

Internet-facing payment systems should normally be placed behind a dedicated DMZ, reverse proxy, WAF, VPN, ZTNA, or other controlled inspection layer.

Example configuration:
config firewall policy
edit <policy-id>
set srcintf "<wan-or-external-interface>"
set dstintf "<dmz-or-inspection-interface>"
set srcaddr "<approved-remote-source>"
set dstaddr "<dmz-published-payment-service>"
set service "HTTPS"
set logtraffic all
next
end

Then use a separate tightly controlled policy from the DMZ or inspection tier to the CDE destination, restricted to the exact required source, destination, and service. If this policy is intentional, confirm the CDE classification, segmentation design, source restrictions, logging, monitoring, and compensating controls are documented.

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

The firewall policy publishes VIP 'VIP_RDP_SERVER' with sensitive exposed service or port 3389, RDP.

Sensitive management or high-risk services should not normally be exposed directly through public VIP publication. Restrict the policy source to trusted remote addresses, VPN client ranges, partner ranges, or a controlled jump-host path. Where possible, avoid publishing administrative services directly to the Internet.

Recommended approach:
config firewall policy
edit <policy-id>
set srcaddr <trusted-source-or-vpn-range>
set dstaddr <specific-vip-object>
set service <required-specific-service-only>
set logtraffic all
next
end

If the service must remain externally reachable, confirm there is a documented business requirement, source restriction, logging, monitoring, and compensating controls such as VPN, ZTNA, MFA, IPS, or application-layer protection.

Administrator account admin does not restrict all administrative login sources with trusted hosts. IPv4 and IPv6 trusted hosts are not restricted. FortiOS trusted hosts work as a whitelist: when trusted hosts are configured, matching sources are allowed and all other login sources are implicitly denied. Leaving trusted host entries blank, unset, or unrestricted can allow administrator login attempts from unauthorized locations.

Restrict each administrator account to approved management hosts or management subnets for both IPv4 and IPv6 where IPv6 administration is possible.

Recommended IPv4 configuration:
config system admin
edit "<admin-name>"
set trusthost1 192.0.2.10 255.255.255.255
set trusthost2 198.51.100.0 255.255.255.0
next
end

Recommended IPv6 configuration:
config system admin
edit "<admin-name>"
set ip6-trusthost1 2001:db8:100::10/128
set ip6-trusthost2 2001:db8:200::/64
next
end

Do not configure a broad trusted host such as 0.0.0.0/0 or ::/0. To remove an unwanted trusted host entry, unset the relevant trusthost field. After applying the change, confirm administrator access still works from approved management locations and is denied from unauthorized sources.

Administrator account radius-admin does not restrict all administrative login sources with trusted hosts. IPv4 and IPv6 trusted hosts are not restricted. FortiOS trusted hosts work as a whitelist: when trusted hosts are configured, matching sources are allowed and all other login sources are implicitly denied. Leaving trusted host entries blank, unset, or unrestricted can allow administrator login attempts from unauthorized locations.

Restrict each administrator account to approved management hosts or management subnets for both IPv4 and IPv6 where IPv6 administration is possible.

Recommended IPv4 configuration:
config system admin
edit "<admin-name>"
set trusthost1 192.0.2.10 255.255.255.255
set trusthost2 198.51.100.0 255.255.255.0
next
end

Recommended IPv6 configuration:
config system admin
edit "<admin-name>"
set ip6-trusthost1 2001:db8:100::10/128
set ip6-trusthost2 2001:db8:200::/64
next
end

Do not configure a broad trusted host such as 0.0.0.0/0 or ::/0. To remove an unwanted trusted host entry, unset the relevant trusthost field. After applying the change, confirm administrator access still works from approved management locations and is denied from unauthorized sources.

The FortiGate administrator password policy is disabled or too weak, increasing the risk that local administrator accounts can use short, simple, reused, or easily guessed passwords. Weak administrator passwords make management-plane compromise more likely, especially if an account is exposed through VPN, HTTPS, SSH, trusted-host misconfiguration, credential reuse, or brute-force attempts.

Enable the administrator password policy and require passwords to be at least 12 characters long with lowercase letters, uppercase letters, numbers, and non-alphanumeric characters.

Recommended configuration:
config system password-policy
set status enable
set minimum-length 12
set min-lower-case-letter 1
set min-upper-case-letter 1
set min-number 1
set min-non-alphanumeric 1
end

Where supported by the operational environment, consider using stronger requirements than the minimum shown above, especially for local break-glass administrator accounts. Combine password complexity with MFA, restricted trusted hosts, named administrator accounts, administrator audit logging, and centralized authentication where appropriate.

Administrator lockout and retry protection is not configured strongly enough, allowing repeated failed login attempts without an effective delay or lockout. Weak lockout settings increase the risk of brute-force attempts, password guessing, credential-stuffing, and noisy management-plane attacks against FortiGate administrator accounts.

Configure a low administrator login failure threshold and a meaningful lockout duration so repeated failed login attempts are throttled.

Recommended configuration:
config system global
set admin-lockout-threshold 3
set admin-lockout-duration 60
end

Use a threshold of 1 to 5 failed attempts and a lockout duration of at least 30 seconds. A slightly longer duration, such as 60 seconds or more, is usually preferable for internet-exposed or sensitive management environments.

This should be combined with MFA, strong administrator passwords, named administrator accounts, restricted trusted hosts, VPN or jump-host management access, and administrator audit logging.

HTTPS administration explicitly allows TLS 1.1.

The FortiGate HTTPS administration service is configured with TLS 1.1 in the list of permitted SSL/TLS versions. This means the management interface may allow administrators or clients to connect using an outdated encryption protocol.

TLS 1.1 is deprecated and should not be permitted for administrative access. Even when management access is restricted to trusted networks, administrative sessions should use modern cryptographic protocols to help protect credentials, session tokens, and sensitive configuration activity. Allowing older protocols can increase the risk of downgrade attacks, weak encryption, and exposure of management traffic if the connection path is intercepted or otherwise untrusted.

Remove TLS 1.1 from the permitted HTTPS administration protocol list. Configure HTTPS administration so that only TLS 1.2 or newer is allowed, preferably including TLS 1.3 where supported by the FortiOS version and administrator client compatibility.

Before applying the change, confirm that approved browsers, jump hosts, automation tools, and management platforms can connect using TLS 1.2 or TLS 1.3. After applying the change, test HTTPS administrative access from an approved management workstation.

Example configuration:
config system global
set admin-https-ssl-versions tlsv1-2 tlsv1-3
end

HTTPS administration minimum protocol is lower than TLS 1.2.

The FortiGate HTTPS administration service is configured with a minimum SSL/TLS protocol version lower than TLS 1.2. This means clients may be allowed to negotiate SSLv3, TLS 1.0, or TLS 1.1 when connecting to the management interface.

Legacy protocols such as SSLv3, TLS 1.0, and TLS 1.1 are deprecated and provide weaker protection for administrative sessions. HTTPS administration protects sensitive activity, including administrator login, session handling, and firewall configuration changes. Allowing clients to negotiate older protocols increases the risk of weak encryption, downgrade attacks, and exposure of management traffic if the connection path is intercepted or exposed.

Set the minimum permitted protocol for HTTPS administration to TLS 1.2 or higher. This prevents clients from negotiating SSLv3, TLS 1.0, or TLS 1.1 when connecting to the FortiGate management interface.

Before applying the change, confirm that approved browsers, jump hosts, automation tools, and management platforms support TLS 1.2 or newer. After applying the change, test HTTPS administrative access from an approved management workstation.

Example configuration:
config system global
set ssl-min-proto-version TLSv1-2
end

Administrator SSH access allows legacy SSH version 1 compatibility, which weakens the security of FortiGate management access.

Disable SSH version 1 compatibility for FortiGate administrator access. SSHv1 is an obsolete management protocol and should not be permitted on firewall administration services. Even when administrators normally use SSHv2, leaving SSHv1 compatibility enabled increases exposure to legacy protocol negotiation, weak cryptographic behaviour, and unnecessary management-plane attack surface.

Administrative CLI access should use SSHv2 only, with access limited to trusted management networks, VPN users, jump hosts, or dedicated administrator workstations. This control should be combined with MFA for administrator accounts, restricted trusted hosts, strong admin authentication, and logging of administrative activity.

Recommended configuration:
config system global
set admin-ssh-v1 disable
end

After applying the change, confirm that legitimate administrators can still connect using SSHv2 and that SSH management is only reachable from approved source networks.

Strong cryptography is disabled, which can allow weaker cryptographic algorithms to remain available for FortiGate security and management functions.

Enable the FortiGate strong cryptography baseline so supported administrative and security functions use stronger cryptographic behaviour.

Recommended configuration:
config system global
set strong-crypto enable
end

After applying the change, verify that administrator access, VPN services, monitoring systems, and any integrated security tools continue to connect successfully. If an older client or integration depends on weaker cryptography, upgrade or replace that client rather than weakening the firewall cryptographic baseline.

Static-key TLS cipher suites are enabled, which can weaken FortiGate management-plane TLS security.

Disable static-key TLS cipher suites for FortiGate administrative services. Static-key TLS ciphers do not provide modern forward secrecy, meaning that if a private key is compromised later, previously captured TLS sessions may be at greater risk of decryption. Firewall management interfaces should only offer modern TLS cipher suites that support stronger key exchange and current cryptographic expectations.

This setting should be disabled alongside other management-plane hardening controls, including restricting HTTPS/SSH administration to trusted management networks, disabling obsolete TLS protocol versions, using a trusted administrator certificate, enabling MFA for administrators, and logging administrative access.

Recommended configuration:
config system global
set ssl-static-key-ciphers disable
end

After applying the change, confirm that approved administrators and management tools can still connect using modern TLS clients. If an old browser, scanner, or management platform requires static-key ciphers, upgrade or replace that client rather than weakening the firewall management plane.

No persistent FortiGate logging destination is enabled and fully configured.

A firewall without persistent logging can lose critical evidence needed for incident response, troubleshooting, change review, compliance reporting, and investigation of administrator activity.

Enable at least one retained logging destination so security, traffic, system, VPN, and administrative events are preserved beyond the local session/runtime log buffer.

Preferred options are centralized logging to FortiAnalyzer, FortiAnalyzer Cloud, or a managed syslog/SIEM platform. When using remote syslog or FortiAnalyzer, make sure the destination is not only enabled but also has a valid server value configured. Local disk logging may provide retained on-box logs where supported, but centralized logging is normally preferred so logs survive device failure, compromise, or replacement.

Example configuration:
config log syslogd setting
set status enable
set server "192.0.2.50"
set port 514
end

Example FortiAnalyzer configuration:
config log fortianalyzer setting
set status enable
set server "192.0.2.60"
end

After enabling persistent logging, confirm log delivery by generating a test event and verifying that it appears in the FortiAnalyzer, FortiAnalyzer Cloud, syslog, SIEM, or approved retained logging platform.

No enabled valid remote logging destination was detected in the configuration export. The firewall does not appear to be sending logs to an external syslog collector or FortiAnalyzer. Without remote logging, security events, administrator activity, VPN events, traffic logs, and incident evidence may be unavailable if the firewall is compromised, rebooted, replaced, or loses local log history.

Configure centralized remote logging using an approved secure transport, such as encrypted syslog where supported or FortiAnalyzer.

Recommended checks:
- Send security and event logs to a central collector.
- Use encrypted transport where supported.
- Restrict logging traffic to approved management or logging networks.
- Confirm logs are retained, searchable, and protected from unauthorized access.

Example encrypted syslog configuration:
config log syslogd setting
set status enable
set server "192.0.2.50"
set enc-algorithm high
end

Example FortiAnalyzer logging configuration:
config log fortianalyzer setting
set status enable
set server "192.0.2.60"
set enc-algorithm high
set certificate-verification enable
set ssl-min-proto-version TLSv1-2
end

Administrator audit logging and automatic configuration revision backup are both disabled. Without these controls, it may be difficult to determine who made a change, what was changed, when it happened, and whether the change was authorized. This reduces visibility during incident response, troubleshooting, compliance review, and post-change investigation.

Enable administrator audit logging and configuration revision backup so administrative activity and configuration changes can be reviewed after the fact.

Example configuration:
config system global
set cli-audit-log enable
set revision-backup-on-logout enable
end

Administrator audit logs should also be sent to a persistent logging destination such as FortiAnalyzer, FortiAnalyzer Cloud, syslog, or a SIEM. Local audit history is useful, but centralized retained logging is preferred because it helps preserve evidence if the firewall is rebooted, replaced, misconfigured, or compromised.

After enabling these settings, make a controlled test change with an administrator account and confirm that the activity is visible in the local logs and in the approved retained logging platform.

This interface allows insecure administrator access using HTTP and/or Telnet. These protocols do not provide the protection expected for firewall management access: Telnet sends administrative sessions without encryption, and HTTP exposes management traffic without TLS.

Remove HTTP and Telnet from interface administrative access. FortiGate administrator access should use secure management paths such as HTTPS or SSH, and only from trusted management networks, VPN users, ZTNA paths, or controlled jump hosts.

Example Configuration:
config system interface
edit <interface-name>
set allowaccess ping https ssh
next
end

Only enable the management services that are genuinely required on each interface. For internet-facing or untrusted interfaces, avoid exposing interactive administrator access entirely unless there is a documented exception with trusted hosts, local-in policy restrictions, MFA, logging, and monitoring.

No IPv4 or IPv6 local-in policies are configured. Traffic destined directly to FortiGate interfaces may still be permitted by interface administrative access settings, so management-plane services such as HTTPS, SSH, HTTP, Telnet, SNMP, BGP, RIP, or RIPng may not be protected by an explicit top-down local-in policy set.

Configure explicit IPv4 and IPv6 local-in policies to allow only approved management and routing sources, then deny unauthorized local-in traffic.

Recommended IPv4 pattern:
config firewall local-in-policy
edit 1
set intf "mgmt"
set srcaddr "Trusted_Admin_Sources"
set dstaddr "all"
set action accept
set service "HTTPS" "SSH"
set schedule "always"
next
edit 10
set intf "wan1"
set srcaddr "Approved_BGP_Peers"
set dstaddr "all"
set action accept
set service "BGP"
set schedule "always"
next
edit 99
set intf "any"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "ALL"
set schedule "always"
next
end

Recommended IPv6 pattern:
config firewall local-in-policy6
edit 1
set intf "mgmt"
set srcaddr "Trusted_Admin_Sources_IPv6"
set dstaddr "all"
set action accept
set service "HTTPS" "SSH"
set schedule "always"
next
edit 10
set intf "wan1"
set srcaddr "Approved_BGP_Peers_IPv6"
set dstaddr "all"
set action accept
set service "BGP"
set schedule "always"
next
edit 99
set intf "any"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "ALL"
set schedule "always"
next
end

If the FortiGate participates in routing protocols, add explicit local-in allow rules for approved BGP, RIP, or RIPng peers before the final deny rule. Local-in policies are evaluated top-down, so allow rules for trusted management or routing sources should appear before the catch-all deny.

Certificate 'expired_cert_test' in VDOM 'root' has expired. Expired VPN certificates can prevent tunnel negotiation, client authentication, or other certificate-based VPN functions from working correctly.

Renew or replace the expired certificate. After importing the replacement certificate and private key, confirm that the related VPN configuration is updated and the tunnel or remote access service still works.

Example configuration:
config vpn certificate local
edit <entry-name>
set certificate "<BASE64_OR_PEM_CERTIFICATE>"
set private-key "<BASE64_OR_PEM_PRIVATE_KEY>"
next
end

This firewall policy allows cleartext or weak legacy services such as Telnet, HTTP, FTP, TFTP, POP3, or IMAP. These protocols can expose credentials, session data, file transfers, email content, or administrative traffic without modern encryption, increasing the risk of interception, credential theft, tampering, and lateral movement if the traffic crosses an untrusted, shared, wireless, WAN, VPN, or segmented network boundary.

Replace cleartext services with encrypted alternatives wherever possible, such as SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and IMAPS/POP3S instead of IMAP/POP3.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "SSH"
next
end

If a cleartext protocol is still required for a legacy dependency, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy protocol can be removed.

This firewall policy allows cleartext or weak legacy services such as Telnet, HTTP, FTP, TFTP, POP3, or IMAP. These protocols can expose credentials, session data, file transfers, email content, or administrative traffic without modern encryption, increasing the risk of interception, credential theft, tampering, and lateral movement if the traffic crosses an untrusted, shared, wireless, WAN, VPN, or segmented network boundary.

Replace cleartext services with encrypted alternatives wherever possible, such as SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and IMAPS/POP3S instead of IMAP/POP3.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "SSH"
next
end

If a cleartext protocol is still required for a legacy dependency, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy protocol can be removed.

This firewall policy allows cleartext or weak legacy services such as Telnet, HTTP, FTP, TFTP, POP3, or IMAP. These protocols can expose credentials, session data, file transfers, email content, or administrative traffic without modern encryption, increasing the risk of interception, credential theft, tampering, and lateral movement if the traffic crosses an untrusted, shared, wireless, WAN, VPN, or segmented network boundary.

Replace cleartext services with encrypted alternatives wherever possible, such as SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and IMAPS/POP3S instead of IMAP/POP3.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "SSH"
next
end

If a cleartext protocol is still required for a legacy dependency, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy protocol can be removed.

This firewall policy allows cleartext or weak legacy services such as Telnet, HTTP, FTP, TFTP, POP3, or IMAP. These protocols can expose credentials, session data, file transfers, email content, or administrative traffic without modern encryption, increasing the risk of interception, credential theft, tampering, and lateral movement if the traffic crosses an untrusted, shared, wireless, WAN, VPN, or segmented network boundary.

Replace cleartext services with encrypted alternatives wherever possible, such as SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and IMAPS/POP3S instead of IMAP/POP3.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "SSH"
next
end

If a cleartext protocol is still required for a legacy dependency, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy protocol can be removed.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This firewall policy allows outbound traffic from an internal, DMZ, or restricted interface toward an internet-facing interface using overly broad source, destination, or service definitions.

Outbound internet access should still follow the principle of least privilege. A policy that allows broad internal sources, unrestricted destinations, or the ALL service can permit more traffic than is required for normal business use. This reduces control over egress traffic and can make it harder to detect or contain compromised hosts, malware callbacks, unauthorized cloud access, data exfiltration, or traffic that should be routed through approved proxy, inspection, or filtering services.

Where outbound access is required, the policy should be limited to approved source networks, approved destinations where practical, and specific services or service groups.

Review the policy to confirm which internal systems, users, applications, and services require outbound internet access. Use FortiGate logs, policy hit counts, web/proxy logs, and application requirements to identify the actual traffic being used.

Replace the broad outbound rule with one or more narrower policies. Where possible, restrict the source address to approved internal networks, VLANs, servers, or user groups. Restrict the service to the required protocols and ports, such as DNS, NTP, HTTP, HTTPS, or approved application services. If the destination can be limited, use approved FQDN objects, destination address groups, internet service database objects, or known vendor/cloud ranges.

Avoid using ALL services for general outbound access unless there is a clearly documented business requirement. Consider routing user web access through approved security controls such as web filtering, SSL inspection, DNS filtering, proxy services, or application control where appropriate.

Place the new restrictive policies above the existing broad outbound policy and monitor traffic to confirm legitimate access still works. Once required traffic has been migrated, disable or remove the overly broad outbound policy.

Example configuration:
config firewall policy
edit <policy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

This internet-facing firewall policy accepts traffic from private or locally scoped source address ranges. Private IPv4 ranges (RFC1918) and IPv6 Unique Local Addresses (RFC4193) should not normally arrive from the public internet, so allowing them on an external-facing policy can indicate missing anti-spoofing controls and may allow spoofed traffic to reach internal, DMZ, VPN, or published services.

Restrict internet-facing policies to legitimate public source ranges, approved partner ranges, or trusted remote access sources. Remove RFC1918 IPv4 ranges and IPv6 ULA ranges from source objects used on WAN-facing policies unless there is a documented routed-private or VPN design that requires them.

Recommended policy correction:
config firewall policy
edit <policy-id>
set srcaddr "<approved-public-or-remote-source>"
next
end

Also enable source address validation on WAN-facing interfaces where supported:
config system interface
edit "<wan-interface>"
set src-check enable
next
end

After applying the change, confirm that legitimate inbound traffic still matches the intended policy and that spoofed private-source traffic is denied and logged.

This internet-facing firewall policy accepts traffic from private or locally scoped source address ranges. Private IPv4 ranges (RFC1918) and IPv6 Unique Local Addresses (RFC4193) should not normally arrive from the public internet, so allowing them on an external-facing policy can indicate missing anti-spoofing controls and may allow spoofed traffic to reach internal, DMZ, VPN, or published services.

Restrict internet-facing policies to legitimate public source ranges, approved partner ranges, or trusted remote access sources. Remove RFC1918 IPv4 ranges and IPv6 ULA ranges from source objects used on WAN-facing policies unless there is a documented routed-private or VPN design that requires them.

Recommended policy correction:
config firewall policy
edit <policy-id>
set srcaddr "<approved-public-or-remote-source>"
next
end

Also enable source address validation on WAN-facing interfaces where supported:
config system interface
edit "<wan-interface>"
set src-check enable
next
end

After applying the change, confirm that legitimate inbound traffic still matches the intended policy and that spoofed private-source traffic is denied and logged.

This enabled inbound firewall policy allows sensitive management, file-sharing, directory, remote-access, or database services directly from a WAN, internet, or external source interface without using a VIP-published service path. Exposing services such as SSH, RDP, VNC, SMB, WinRM, LDAP, MySQL, MSSQL, FTP, or Telnet directly from untrusted networks increases the risk of brute-force attacks, credential theft, exploitation of exposed services, lateral movement, and unauthorized administrative access.

Restrict inbound exposure of sensitive services. Limit access to explicitly approved remote source addresses, publish only hardened services where required, and use a controlled access design such as VPN, ZTNA, bastion hosts, reverse proxy, or tightly scoped VIPs.

Recommended configuration example:
config firewall policy
edit <policy-id>
set srcaddr "<approved-remote-source>"
set service "<approved-service>"
set logtraffic all
next
end

For administrative access, avoid exposing management protocols directly to the internet. Use MFA-protected VPN or ZTNA access, named administrator accounts, trusted hosts, logging, IPS, application control, and regular review of the rule justification.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled public inbound firewall policy does not enforce source IP reputation filtering at reputation level 3 or higher. For inbound internet traffic, reputation filtering should evaluate the source address so known malicious, high-risk, or unverified sources can be restricted before reaching internal, DMZ, VIP, or hosted services.

Configure source-direction IP reputation filtering on public inbound firewall policies and set the minimum accepted reputation level to at least 3.

Recommended IPv4 configuration:
config firewall policy
edit <policy-id>
set reputation-direction source
set reputation-minimum 3
next
end

Recommended IPv6 configuration where IPv6 policy reputation settings are available:
config firewall policy
edit <policy-id>
set reputation-direction6 source
set reputation-minimum6 3
next
end

After applying the change, confirm that legitimate inbound sources are not unintentionally blocked, review logs for reputation-based drops, and document any exception where reputation filtering is not suitable for a specific published service.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering missing or incorrectly configured. For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3 so traffic to known malicious, high-risk, or unverified destinations can be restricted before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering missing or incorrectly configured. For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3 so traffic to known malicious, high-risk, or unverified destinations can be restricted before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering missing or incorrectly configured. For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3 so traffic to known malicious, high-risk, or unverified destinations can be restricted before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering missing or incorrectly configured. For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3 so traffic to known malicious, high-risk, or unverified destinations can be restricted before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile. Inbound web services exposed from WAN, internet, external, or outside interfaces should have suitable web-layer inspection. HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile. Inbound web services exposed from WAN, internet, external, or outside interfaces should have suitable web-layer inspection. HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile. Inbound web services exposed from WAN, internet, external, or outside interfaces should have suitable web-layer inspection. HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile. Inbound web services exposed from WAN, internet, external, or outside interfaces should have suitable web-layer inspection. HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This firewall policy allows broad access between internal interfaces or internal security zones. Although the traffic is internal, the policy may still permit more access than required between networks, VLANs, users, servers, or application segments.

Broad internal access weakens network segmentation and can make it easier for compromised devices, malware, or unauthorized users to move laterally through the environment. Internal firewall policies should still follow the principle of least privilege by allowing only the required sources, destinations, and services.

Review the policy to confirm which internal systems and applications actually require access. Use FortiGate logs, policy hit counts, and traffic analysis to identify the real source addresses, destination addresses, and services using this rule.

Replace the broad internal policy with one or more dedicated policies that only allow the required east-west traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Required services or service groups
4. Specific internal interfaces, VLANs, or zones
5. Security profiles
6. Schedules, where access is only needed at certain times

Place the new restrictive policies above the existing broad internal policy, then monitor traffic to confirm that legitimate access still works. Once the required traffic has been migrated, disable or remove the overly broad internal policy.

Example configuration:
config firewall policy
edit <policy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end


This IPsec phase 1 configuration allows one or more weak or legacy cryptographic proposals.

IPsec phase 1 proposals define the encryption and integrity algorithms that may be negotiated when establishing the VPN control channel. If weak proposals are left enabled, a peer may be able to negotiate outdated cryptography even when stronger options are also present.

Legacy algorithms such as DES, 3DES, SEED, MD5, and SHA-1 should not be used for new VPN deployments. These algorithms provide weaker protection than modern alternatives and may not meet current security, compliance, or vendor hardening expectations. VPN phase 1 should use approved modern proposals such as AES or ChaCha20-Poly1305 with SHA-256, SHA-384, SHA-512, or equivalent stronger PRF/integrity options.

Remove weak or legacy proposals from the IPsec phase 1 configuration.

Review the VPN peer requirements before making the change, especially for third-party or legacy site-to-site VPNs. Confirm that both ends of the tunnel support modern proposals, then update the phase 1 proposal list so that only approved cryptographic suites remain.

Recommended options normally include AES-128 or AES-256 with SHA-256 or stronger, AES-GCM with SHA-256 or stronger PRF, or ChaCha20-Poly1305 with SHA-256 or stronger PRF where supported. Avoid DES, 3DES, SEED, MD5, and SHA-1 based proposals.

After applying the change, re-establish the VPN tunnel and confirm that phase 1 negotiation succeeds using an approved proposal.

Example configuration:
config vpn ipsec phase1-interface
edit <entry-name>
set proposal aes256-sha256 aes128-sha256
next
end

VDOM 'root' allows weak SSL VPN cryptographic settings. The configured minimum TLS version is 'tls1-0' and the configured SSL VPN algorithm is 'medium'. Weak protocol or cipher settings can expose remote access VPN users and authentication traffic to obsolete cryptographic behaviour.

Configure SSL VPN to use TLS 1.2 or newer and high-strength cipher settings.

Recommended configuration:
config vpn ssl settings
set ssl-min-proto-ver tls1-2
set algorithm high
end

Also review any SSL VPN authentication rules and avoid rule-level cipher settings of 'any' or 'medium'. After applying the change, test approved FortiClient and browser-based access methods to confirm they still connect successfully.

VDOM 'root' uses a missing, default, factory, or self-signed SSL VPN server certificate on a WAN-facing listener. This can weaken user trust, increase certificate warning behaviour, and make it harder for users to verify that they are connecting to the legitimate remote access VPN service.

Install and select an approved SSL VPN server certificate issued for the VPN hostname.

Recommended configuration:
config vpn ssl settings
set servercert "<approved-vpn-server-certificate>"
set server-hostname "vpn.example.com"
end

After applying the change, confirm that the certificate chain is trusted by managed clients, the certificate name matches the VPN hostname, and SSL VPN users can connect without certificate warnings.

VDOM 'root' exposes SSL VPN on WAN-facing interface(s) wan1 without clear source-address restrictions. This may be intentional, but it increases the public attack surface for remote access authentication, vulnerability probing, credential stuffing, and brute-force attempts.

Restrict SSL VPN exposure to approved ingress interfaces and trusted source addresses where operationally possible.

Recommended configuration:
config vpn ssl settings
set source-interface "<approved-ingress-interface>"
set source-address "<trusted-remote-source>"
config authentication-rule
edit 1
set source-address "<trusted-remote-source>"
next
end
end

If broad internet exposure is required, document the exception and compensate with MFA, strong authentication, account lockout controls, geo/IP filtering where appropriate, logging, monitoring, and regular review of SSL VPN access.

The FortiGate administrator idle timeout is missing or set higher than 10 minutes, allowing inactive management sessions to remain open for longer than necessary. Long-lived idle sessions increase the risk of unauthorized access from an unattended workstation, shared admin jump host, browser left open, or compromised administrator endpoint.

Set the administrator idle timeout to 10 minutes or less.

Recommended configuration:
config system global
set admintimeout 10
end

After applying the change, confirm that administrator sessions expire after the expected idle period and that operational processes do not rely on unattended management sessions staying open.

Diffie-Hellman parameters are configured below the expected minimum strength. The current value is 1024 bits. FortiGate uses this setting for Diffie-Hellman exchange strength for HTTPS and SSH protocols, and values below 2048 bits do not meet the expected baseline.

Raise Diffie-Hellman parameters to at least 2048 bits, or higher if required by your approved cryptographic baseline.

Recommended checks:
- Use at least 2048-bit Diffie-Hellman parameters.
- Consider 3072 or 4096 bits where performance and policy requirements allow.
- Confirm administrator HTTPS and SSH access continue to work after the change.
- Document any legacy compatibility exception if a lower value is required.

Example configuration:
config system global
set dh-params 2048
end

Stronger example:
config system global
set dh-params 4096
end

Denied firewall traffic and/or local-in traffic visibility is not fully enabled or is not being sent to an enabled logging destination. Without these logs, denied connection attempts, traffic aimed directly at the FortiGate, management-plane probing, and policy troubleshooting evidence may be missing during security review or incident response.

Enable logging for implicit-deny firewall policy traffic and local-in/local-traffic events, and make sure at least one retained logging destination is enabled and configured.

Recommended global visibility configuration:
config log setting
set fwpolicy-implicit-log enable
set local-in-allow enable
set local-in-deny-unicast enable
set local-in-deny-broadcast enable
end

Example syslog destination and local-traffic filter:
config log syslogd setting
set status enable
set server "192.0.2.50"
end
config log syslogd filter
set local-traffic enable
end

If using FortiAnalyzer, FortiAnalyzer Cloud, disk, or memory logging instead, confirm that the destination is enabled and that local-traffic logging is not filtered out. After changing the settings, generate a test denied connection and a test local-in event, then confirm both appear in the approved logging destination.

High availability is not fully configured for this FortiGate. A standalone firewall, missing HA group name, or missing heartbeat interface can leave a critical security boundary dependent on a single appliance, increasing the risk of outage during hardware failure, firmware issues, maintenance, power loss, or unexpected device instability.

Deploy or validate FortiGate high availability for critical security boundaries. Configure an approved HA mode, define a group name, and use dedicated heartbeat interfaces between HA members.

Recommended configuration:
config system ha
set mode a-p
set group-name "fg-ha-pair"
set hbdev "port3" 100 "port4" 50
end

After configuration, confirm cluster formation, heartbeat health, monitored interfaces, session pickup requirements, firmware alignment, failover behaviour, management access, and alerting. If this appliance is intentionally standalone, document the exception and confirm that the business accepts the availability risk.

NTP time synchronisation is disabled or not fully enabled, which can make FortiGate log timestamps and security event timelines unreliable.

Enable NTP time synchronisation using either FortiGuard or approved internal/external NTP servers.

Example configuration using FortiGuard:
config system ntp
set ntpsync enable
set type fortiguard
end

Example configuration using explicit NTP servers:
config system ntp
set ntpsync enable
set type custom
config ntpserver
edit 1
set server "192.0.2.10"
next
edit 2
set server "192.0.2.11"
next
end
end

After applying the change, confirm that the FortiGate has the correct time, timezone, and NTP synchronisation status.

Implicit firewall policy deny logging is disabled for one or more available IPv4 or IPv6 implicit deny settings. Traffic blocked by the implicit deny rule may not be recorded, reducing visibility into denied connection attempts, misconfigured policies, scanning activity, unauthorized access attempts, and traffic that reached the end of the rulebase without matching an explicit policy.

Enable implicit firewall policy logging for each available setting.

Recommended configuration:
config log setting
set fwpolicy-implicit-log enable
set fwpolicy6-implicit-log enable
end

If only one of these settings is available on this FortiOS version or device mode, enable the available setting. After applying the change, generate a controlled denied traffic test and confirm that the implicit deny event appears in the approved logging destination.

The accepted firewall policy does not have traffic logging enabled. Without logging on accepted policies, allowed sessions may not leave enough evidence for troubleshooting, security monitoring, incident investigation, user activity review, or validation of whether the rule is still required.

Enable traffic logging on accepted firewall policies.

Recommended configuration:
config firewall policy
edit <policy-id>
set logtraffic all
next
end

Where session start visibility is also required, enable start-of-session logging as well:
config firewall policy
edit <policy-id>
set logtraffic all
set logtraffic-start enable
next
end

If only end-of-session logging is required for a specific low-risk rule, use `set logtraffic all` and document the exception.

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 4 (Shadowed firewall policies - Test Rule 1).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 4 (Shadowed firewall policies - Test Rule 1).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile. The policy does not have a direct webfilter-profile configured and, if it uses a profile group, the referenced profile group does not include a webfilter-profile. Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile. The policy does not have a direct webfilter-profile configured and, if it uses a profile group, the referenced profile group does not include a webfilter-profile. Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile. The policy does not have an application-list set directly, and if it uses a profile group, the referenced profile group does not include an application-list. Inbound policies from WAN, external, or internet-facing interfaces are exposed to untrusted traffic, so missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

HTTPS administrative access is using the default TCP port 443. Using the default management port can make the administrative interface easier to identify during scanning and may increase exposure if management access is reachable from untrusted or broader networks.

Move HTTPS GUI administration to an approved non-default port and document the management access path.

Recommended checks:
- Confirm the new administration port is allowed only from trusted management networks.
- Confirm local-in policy, trusted hosts, or upstream firewall rules restrict access.
- Confirm administrators know the approved management URL and port.
- Confirm monitoring and documentation are updated.

Example configuration:
config system global
set admin-sport 8443
end

SSH administrative access is using the default TCP port 22. Using the default SSH management port can make the administrative interface easier to identify during scanning and may increase exposure if SSH administration is reachable from untrusted or broader networks.

Move SSH CLI administration to an approved non-default port and keep that management path limited to trusted sources.

Recommended checks:
- Confirm the new SSH administration port is allowed only from trusted management networks.
- Confirm local-in policy, trusted hosts, or upstream firewall rules restrict access.
- Confirm administrators know the approved SSH port.
- Confirm monitoring and documentation are updated.

Example configuration:
config system global
set admin-ssh-port 2222
end

Configuration revision backup on logout is disabled. Administrative configuration changes may not automatically create a revision history when an administrator session ends, making it harder to review, compare, or restore previous firewall configurations after an unintended or unauthorized change.

Enable configuration revision backup on logout so FortiGate automatically creates a configuration revision when an administrator logs out. After enabling it, confirm that revision history is being created as expected and include configuration revision review in operational change-control procedures.

Example configuration:
config system global
set revision-backup-on-logout enable
end

Automatic configuration backup before firmware upgrades is disabled, so a pre-upgrade restore point may not be created before firmware changes.

Enabling this functionality helps preserve a known pre-upgrade configuration state before firmware changes are applied, making rollback, troubleshooting, and post-upgrade recovery safer if the upgrade introduces unexpected behaviour, configuration migration issues, or service disruption.

Enable automatic configuration backup before firmware upgrades.

Example configuration:
config system global
set revision-image-auto-backup enable
end

This control should be used alongside normal upgrade safeguards: take an external configuration backup before maintenance, confirm the target firmware path is supported, review release notes, schedule an approved maintenance window, and verify critical services after the upgrade completes.

This enabled firewall policy does not have a name configured. Unnamed policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy name describing the business purpose.

Example configuration:
config firewall policy
edit <policy-id>
set name "Allow HTTPS to customer portal"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

This enabled firewall policy does not have a comment or documented business justification. Undocumented policies are harder to review, approve, troubleshoot, and safely remove because the intended owner, purpose, and review context are not visible in the firewall configuration.

Add a clear policy comment describing the business purpose, owner, and review context for the rule.

Recommended comment content:
- Business purpose
- Application or service owner
- Source and destination context
- Approval or change reference
- Review or expiry context where applicable

Example configuration:
config firewall policy
edit <policy-id>
set comments "Purpose: allow HTTPS to customer portal; Owner: Web Team; Change: CHG123456; Review: quarterly"
next
end

Firewall change-management evidence cannot be verified from the firewall configuration export alone. The configuration can show the current firewall state, comments, and some revision settings, but it usually cannot prove that changes were requested, risk-assessed, approved, tested, implemented during an approved window, reviewed after deployment, or linked to a CAB/change ticket.

Review change-management records to confirm firewall changes are linked to approved requests and include appropriate evidence.

Recommended evidence to retain:
- Change ticket or request reference
- Business justification and rule owner
- Risk assessment and approval record
- Implementation date and approved change window
- Pre-change and post-change validation
- Rollback plan where applicable
- Post-implementation review or closure notes

Useful FortiGate configuration practices:
config system global
set revision-backup-on-logout enable
end

config firewall policy
edit <policy-id>
set comments "Ticket: CHG-12345 / Owner: Network Team / Purpose: Approved business access / Review: 2026-12-06"
next
end

If FortiManager, automation, or an external ITSM platform is used, confirm that firewall changes are traceable from the firewall policy or revision history back to the approved change record.

No clear external configuration backup method was detected in the firewall configuration export. This does not prove backups are missing, but the exported configuration does not show FortiManager registration or an obvious on-box automation/scripted backup method that would preserve configuration history outside the firewall.

Confirm that configuration backups are scheduled and recoverable in FortiManager, FortiGate Cloud, automation stitches, a configuration management platform, or an external backup system.

Recommended checks:
- Confirm backups run on a defined schedule.
- Confirm backups are stored outside the firewall.
- Confirm backup access is restricted.
- Confirm restore testing is performed periodically.
- Confirm backup retention meets operational and compliance requirements.

Example FortiManager configuration:
config system central-management
set type fortimanager
set fmg "192.0.2.50"
end

Example on-box scripted backup:
config system auto-script
edit "nightly-config-backup"
set interval 86400
set repeat 0
set script "execute backup config ftp backup.conf 192.0.2.50 backupuser <password>"
next
end

If FortiManager or another external platform performs backups, document the backup schedule, storage location, retention period, and restore test evidence.

Scheduled firewall rule review evidence cannot be proven from the firewall configuration export alone. The configuration can show current policy settings, but it usually cannot confirm whether each rule has a valid owner, business justification, last review date, next review date, approval record, or periodic recertification evidence.

Review your firewall governance records, change tickets, policy ownership records, or compliance evidence to confirm that firewall rules are reviewed on the required schedule.

Recommended evidence to retain:
- Rule owner or business owner
- Business justification
- Last review date
- Next scheduled review date
- Review outcome
- Approval or ticket reference

Optional policy comment example:
config firewall policy
edit <policy-id>
set comments "Owner: Network Team / Last reviewed: 2026-06-06 / Next review: 2026-12-06 / Ticket: CHG123456"
next
end

Firewall policy 2 (Broad Outbound Internet Access - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 3 (VIP Sensitive Services - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 4 (Shadowed firewall policies - Test Rule 1) appears shadowed by 2 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 5 (Shadowed firewall policies - Test Rule 2) appears shadowed by 3 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)
- policy 4 (Shadowed firewall policies - Test Rule 1)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 6 (Direct Internet to Cardholder Data Environment (CDE) - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 7 (Restrict cleartext services in firewall policies - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 8 (Require traffic logging on accepted firewall policies - Test Rule) appears shadowed by 3 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)
- policy 4 (Shadowed firewall policies - Test Rule 1)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 9 (Missing Anti-Spoofing Protection IPv4 - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 10 (Missing Anti-Spoofing Protection IPv6 - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 11 (Restrict permissive inbound management and database services - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 12 (TEMP vendor HTTPS access) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 13 appears shadowed by 2 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 12 (TEMP vendor HTTPS access)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

This enabled firewall policy appears to be temporary because the policy name or comments contain TEMP or TMP. Temporary firewall rules can become long-term exceptions if they are not tracked, reviewed, and removed after the original business need has passed.

Review this temporary firewall policy and confirm it has an owner, business justification, approval reference, expiry date, and removal plan.

Recommended checks:
- Confirm the rule is still required.
- Confirm the rule has a named owner.
- Confirm the approval or change reference is documented.
- Confirm an expiry or review date is recorded.
- Remove the rule if the temporary access is no longer required.

Recommended comment example:
set comments "TEMP: vendor access for migration; Owner: Network Team; Change: CHG123456; Expires: 2026-08-31"

Example removal command after expiry:
config firewall policy
delete <policy-id>
end