FortiGate Best Practices Part 4: Hardening Administrative Access

In Part 1 we covered firewall objects and threat feeds. Part 2 focused on network segmentation. Part 3 addressed virtual patching. In this part, I want to tackle something that is arguably the most critical attack surface on any FortiGate deployment: administrative access.

The FortiGate management plane has been a repeated target for threat actors. Vulnerabilities like CVE-2022-40684 (authentication bypass), CVE-2022-42475 (SSL-VPN heap buffer overflow), and CVE-2023-27997 (heap overflow in SSL-VPN) were all exploited in the wild specifically because management and VPN services were exposed to the internet. The recommendations in this post are designed to minimize that exposure and ensure that even if a vulnerability is discovered, an attacker has as few paths as possible to reach it.

1. Enable a Pre-Login Disclaimer Banner

This is a short one but it should be the very first thing you configure on a new FortiGate. A pre-login disclaimer banner displays a legal notice before the administrator (or anyone attempting to access the device) is presented with the login prompt. It is a simple configuration that takes less than a minute but carries significant legal weight.

In many jurisdictions, unauthorized access to a computer system can only be prosecuted if the prosecution can demonstrate that the individual was clearly notified that access was restricted. Without a banner, a defense attorney can argue that there was no explicit indication the system was off-limits. A properly worded disclaimer removes that ambiguity entirely. It establishes that access is authorized personnel only, that all activity is monitored and logged, and that unauthorized access may result in legal action. Courts in the United States and elsewhere have upheld the presence of login banners as evidence that an intruder was warned and proceeded anyway.

Beyond the legal dimension, compliance frameworks such as NIST 800-53 (AC-8), PCI DSS, HIPAA, and CIS Benchmarks for FortiGate all require or strongly recommend displaying an access notification banner on network devices.

CLI Configuration

config system replacemsg admin "pre_admin-disclaimer-text"
    set buffer "WARNING: This system is for authorized use only. All access and activity are monitored, recorded, and subject to audit. Unauthorized access is strictly prohibited and may result in disciplinary action and/or criminal prosecution."
end

config system global
    set pre-login-banner enable
end

You can also configure a post-login disclaimer that requires the administrator to acknowledge and accept the terms before proceeding:

config system global
    set post-login-banner enable
end

config system replacemsg admin "post_admin-disclaimer-text"
    set buffer "By continuing, you acknowledge that all actions on this device are logged, monitored, and attributable to your account. Misuse of this system will result in revocation of access and may result in legal action."
end

GUI: Navigate to System > Settings, scroll to Administrator Settings, and enable Pre-Login Banner and/or Post-Login Banner. To customize the banner text, go to System > Replacement Messages and edit the admin disclaimer messages.

I recommend enabling both pre-login and post-login banners. The pre-login banner warns before authentication. The post-login banner requires explicit acknowledgment after authentication, creating a documented record that the administrator accepted the terms of use for that session.

2. Remove All Administrative Access from the WAN Interface

This is the single most important hardening step you can take. There is no reason for the FortiGate's HTTPS management interface, SSH, or any other administrative protocol to be reachable directly from the internet. Every service you expose on the WAN interface is an attack surface that you must defend indefinitely against every threat actor on the planet.

CLI Configuration

config system interface
    edit "wan1"
        unset allowaccess
    next
end

This removes HTTPS, SSH, PING, HTTP, TELNET, SNMP, and any other administrative access from the WAN interface entirely.

GUI Steps

1. Navigate to Network > Interfaces
2. Edit your WAN interface
3. Under Administrative Access, disable all protocols: HTTPS, HTTP, SSH, PING, TELNET, SNMP, RADIUS
4. Click OK

Where Should Management Live?

Management access should only be enabled on a dedicated internal interface or management VLAN that is not routable from the internet. Ideally, you have a dedicated management interface (many FortiGate models have a labeled MGMT port) or a management VLAN that is restricted to your administrator workstations.

config system interface
    edit "mgmt"
        set allowaccess https ssh ping
        set ip 10.0.99.1 255.255.255.0
    next
end

If your FortiGate does not have a dedicated management port, create a management VLAN on one of your internal interfaces and restrict access to that VLAN.

Access Management Remotely via VPN Only

If you need to manage the FortiGate remotely, the correct approach is to connect via VPN first and then access the management interface through the VPN tunnel. This way, the management interface is never directly exposed to the internet. Your VPN becomes the single controlled entry point, and it can be further protected with MFA, geo-blocking, and the local-in policies we covered in Part 1.

For SSL-VPN deployments, the SSL-VPN portal itself will still need to listen on the WAN interface. In that case, protect it aggressively with local-in policies, geo-blocking, and the FMWP virtual patching covered in Part 3. But the HTTPS management GUI and SSH should never share that exposure.

3. Change Default Administrative Ports

Changing default ports does not provide true security on its own since any port scan will discover the new ports quickly. However, it does reduce noise from automated bots and scripts that target well-known ports, and it eliminates the common conflict between the HTTPS management interface (port 443) and SSL-VPN (also port 443 by default).

Change HTTPS and SSH Admin Ports

config system global
    set admin-sport 8443
    set admin-ssh-port 2222
end

GUI: Navigate to System > Settings, scroll to Administrator Settings, and change the HTTPS and SSH port numbers.

Important: After changing the HTTPS port, you will need to access the GUI at https://<fortigate-ip>:8443. Make sure the new ports do not conflict with any other services running on the FortiGate. Document the port changes and communicate them to your team.

Disable HTTP Access Entirely

HTTP administrative access should never be enabled on any interface. If it somehow is, disable it and ensure HTTPS redirect is enabled:

config system global
    set admin-https-redirect enable
end

This ensures that any accidental HTTP connection attempt is redirected to HTTPS.

4. Disable Insecure Protocols and Enforce Strong Encryption

While you are hardening the management plane, take the opportunity to disable legacy protocols and enforce modern encryption standards.

Require TLS 1.2+ and Strong Ciphers

config system global
    set strong-crypto enable
    set ssl-min-proto-version TLSv1.2
    set ssh-hmac-md5 disable
    set ssh-cbc-cipher disable
    set ssl-static-key-ciphers disable
end

strong-crypto enable restricts FortiOS to only use strong ciphers (AES, 3DES) and strong digests (SHA) for HTTPS, SSH, TLS, and SSL functions. Disabling ssh-hmac-md5 and ssh-cbc-cipher prevents SSH sessions from using less secure MD5 and CBC algorithms. Disabling ssl-static-key-ciphers prevents TLS sessions from using static keys.

Reduce SSH Grace Time

The SSH grace time is the window between establishing the TCP connection and completing authentication. The default is 120 seconds, which is generous for brute-force attempts. Reduce it:

config system global
    set admin-ssh-grace-time 30
end

5. Eliminate the Default Admin Account

Every FortiGate ships with a default administrator account named admin with no password. This is the first thing every attacker tries. The admin account uses the super_admin profile, which has the highest level of access in FortiOS and cannot be restricted.

My recommendation is to replace the default admin account entirely. You cannot delete it outright because FortiOS requires at least one super_admin account to exist, but you can rename it, set an extremely strong password, lock it down with trusted hosts, and treat it as an emergency break-glass account that is never used for daily operations.

Step 1: Create a New Super Admin Account

First, create a new administrator account with the super_admin profile:

config system admin
    edit "fgt-emergency"
        set accprofile "super_admin"
        set password "extremely-strong-and-unique-password"
        set two-factor fortitoken
        set fortitoken <serial_number>
        set email-to "[email protected]"
        set trusthost1 10.0.99.0 255.255.255.0
    next
end

This emergency account should have:

• An extremely strong, unique password stored in a secure vault or safe
• FortiToken MFA enabled (every registered FortiGate includes two trial tokens)
• Trusted hosts restricted to your management subnet only
• An associated email address for notifications

Step 2: Rename the Default Admin Account

Log in with your new super_admin account and rename the default admin account:

GUI: Navigate to System > Administrators, edit the admin account, and change the User Name.

CLI:

config system admin
    edit "admin"
        set accprofile "super_admin"
        set password "different-extremely-strong-password"
        set trusthost1 10.0.99.0 255.255.255.0
    next
    rename "admin" to "fgt-legacy-admin"
end

Alternatively, if your environment allows it, you can disable the renamed account by setting trusted hosts to a non-routable address like 127.0.0.1/32, effectively locking it out while keeping it as a last-resort fallback.

Step 3: Set Lockout Policies

config system global
    set admin-lockout-threshold 3
    set admin-lockout-duration 300
end

This locks an admin account after three failed login attempts for five minutes. For environments with higher security requirements, you can reduce the threshold to one attempt, but be aware that this can create denial-of-service scenarios if an attacker intentionally triggers lockouts.

Step 4: Set Idle Timeout

config system global
    set admintimeout 5
end

The default idle timeout is five minutes, which is appropriate for most environments. Do not increase it. An unattended management session is a significant risk.

6. Use SAML SSO for Everyday Administrative Access

Once you have your emergency break-glass account secured, the next step is to configure SAML SSO for all routine administrative access. This integrates your FortiGate authentication with your organization's Identity Provider (IdP) such as Microsoft Entra ID (Azure AD), Okta, or FortiAuthenticator, centralizing authentication, enforcing your IdP's MFA policies, and providing a single pane of glass for access management.

The advantages of SAML SSO for admin access are significant. Administrators authenticate against your IdP, which means you get centralized credential management, conditional access policies, MFA enforcement at the IdP level, session logging, and immediate revocation when an administrator leaves the organization or changes roles. No local passwords to manage, rotate, or forget.

Configure FortiGate as a SAML Service Provider

FortiOS supports SAML-based admin authentication starting in FortiOS 6.2. The FortiGate acts as a SAML Service Provider (SP), and your IdP handles the authentication.

config system saml
    set status enable
    set default-profile "super_admin"
    set idp-entity-id "https://your-idp.example.com/entity-id"
    set idp-single-sign-on-url "https://your-idp.example.com/saml/sso"
    set idp-single-logout-url "https://your-idp.example.com/saml/slo"
    set idp-cert "REMOTE_IdP_Cert"
    set server-address "<fortigate-management-ip-or-fqdn>"
end

Create SSO Admin Accounts

SSO administrator accounts are automatically created when an administrator logs in via SAML for the first time, or you can pre-create them:

GUI: Navigate to System > Administrators, click Create New > SSO Admin, and enter the username that matches the SAML assertion.

CLI:

config system admin
    edit "[email protected]"
        set accprofile "prof_admin"
        set remote-auth enable
    next
end

Admin Profile Strategy

With SAML SSO, you should create role-based admin profiles rather than giving everyone super_admin:

• super_admin - reserved exclusively for the emergency break-glass account
• full_admin - read/write access to all features except super_admin-only functions, for senior network engineers
• security_admin - read/write for security profiles, read-only for network configuration, for security analysts
• readonly_admin - read-only access for auditors, helpdesk, and junior staff

config system accprofile
    edit "security_admin"
        set secfabgrp read-write
        set ftviewgrp read-write
        set authgrp read-write
        set sysgrp read
        set netgrp read
        set loggrp read-write
        set fwgrp read
        set vpngrp read
        set utmgrp read-write
    next
end

Map these profiles to groups in your IdP so that the correct profile is assigned based on SAML group membership.

Important Note on SSO and Trusted Hosts

Trusted hosts cannot be configured directly on SAML-based SSO administrator accounts. However, the SSO administrator must be able to reach the FortiGate GUI to log in. Since you have already restricted management access to your internal management network or VPN, this is inherently controlled by network access rather than trusted host settings.

7. FIDO2 and Passkeys for Phishing-Resistant Authentication

For the strongest possible administrative authentication, consider implementing FIDO2/passkey-based login. Traditional TOTP tokens and SMS-based MFA can be phished through real-time proxy attacks. FIDO2 passkeys are phishing-resistant by design because the authentication is cryptographically bound to the specific domain and cannot be relayed.

How It Works with FortiGate

FortiGate does not natively support FIDO2 as a direct login method. Instead, FIDO2/passkey authentication is implemented through your IdP:

1. Configure SAML SSO for admin authentication as described above
2. Configure your IdP (Entra ID, Okta, FortiAuthenticator, etc.) to require FIDO2/passkey authentication
3. When an administrator clicks "Single Sign-On" on the FortiGate login page, they are redirected to the IdP
4. The IdP prompts for FIDO2 authentication (hardware key like YubiKey or FortiToken 410, or platform passkey on a phone/laptop)
5. After successful authentication, the IdP sends the SAML assertion back to the FortiGate

Fortinet's own FortiToken 410 is a FIDO2 security key that works with FortiAuthenticator as the IdP. FortiToken Cloud also supports passkey enrollment, allowing administrators to use either a physical USB security key or their mobile phone as a passkey.

Recommended Authentication Strategy

Putting it all together, here is the admin authentication strategy I recommend:

Emergency break-glass account: Local super_admin account with a long, complex password stored in a physical safe or secure vault, protected by FortiToken hardware MFA, trusted hosts locked to the management subnet. This account is only used when the IdP is unavailable.

Day-to-day admin access: SAML SSO through your IdP with FIDO2/passkey enforcement. Administrators log in by clicking "Single Sign-On" on the FortiGate login page, authenticate via the IdP with their passkey, and are granted access based on their SAML group membership mapped to FortiGate admin profiles.

No shared accounts, no local passwords for daily use. Every administrator authenticates individually through the IdP, providing complete audit trails of who did what and when.

Wrapping Up

The management plane is the keys to the kingdom. If an attacker gains administrative access to your FortiGate, every other security control you have implemented is rendered meaningless. The recommendations in this post work together to create a layered defense:

• Enable pre-login and post-login disclaimer banners for legal protection and compliance
• Remove all admin access from the WAN and require VPN for remote management
• Change default ports to reduce automated scanning noise and avoid service conflicts
• Enforce strong encryption and disable legacy protocols
• Eliminate the default admin account and replace it with a secured break-glass account
• Use SAML SSO with your IdP for all routine admin access, with role-based profiles
• Implement FIDO2/passkeys for phishing-resistant authentication

None of these steps are complicated on their own. The difficulty is in the discipline to implement all of them consistently. Combined with the firewall hardening from Part 1, network segmentation from Part 2, and virtual patching from Part 3, you have a comprehensive security posture that addresses threats from the perimeter all the way to the management plane.

If you found this post helpful or would like assistance implementing these practices in your environment, feel free to reach out.