FortiGate Multi-Factor Authentication: Setup Guide

You can add multi-factor authentication (MFA) to a FortiGate in two ways. You can assign a second factor to local users, such as a FortiToken, email or SMS code. Or you can point the firewall at an outside authentication server over RADIUS or SAML, and let that server ask for the second factor. Either way, the firewall checks the password and then a one-time code before it lets a VPN user or an administrator in. This guide covers both routes, the prerequisites, and what to check when a login fails.

TL;DR

• FortiGate supports MFA on user and administrator accounts. The simplest path is a FortiToken assigned to a local user. The scalable path is RADIUS to a central authentication server.
• FortiToken needs a FortiGuard subscription on the firewall. Email and SMS codes need a working mail or SMS service configured first.
• SSO is not MFA. It passes an identity along. A second factor only happens when the policy or backend demands one.
• When logins fail, test the RADIUS or LDAP path from the CLI, check shared secrets and group matching, and confirm the firewall clock is right.
• The accounts around the firewall matter too: protect the admin’s own password vault and email with strong, unique credentials and MFA.

What MFA on a FortiGate actually protects

A FortiGate has two kinds of logins worth protecting: the people who connect through it (remote VPN users, and anyone who authenticates to a firewall policy) and the people who manage it (administrators on the web GUI or SSH). A stolen password is enough to compromise either one if there is no second factor.

Fortinet describes two-factor authentication as adding a second piece of information to a username and password logon, generally something you know plus something you have, such as a token or certificate. One community write-up of the feature notes it can be applied to both user and administrator accounts, and that it does not work with explicit proxies. That last point matters if you run an explicit web proxy policy: plan a different control for that traffic.

The exact menus and options depend on your FortiOS version. The examples below follow Fortinet’s own documentation, and the menu names (User & Authentication, FortiTokens, User Definition) have been stable across many releases. Always confirm against the administration guide for the firmware you run.

Choosing your MFA method

FortiGate gives you several ways to deliver the second factor. Here is how they compare in practice.

The Fortinet FortiToken guide says FortiToken Mobile and hardware tokens work for RADIUS, LDAP and 802.1X wireless as well as FSSO, and that the firewall needs a FortiGuard subscription to support FortiToken. Check your licensing before you promise your team a rollout date.

Which one should you pick?

For one firewall and a few dozen users, local users with FortiToken Mobile are quick to deploy and need no extra server. Once you manage several firewalls, or you need the same MFA for VPN, Wi-Fi and applications, move authentication to a central RADIUS or SAML service so you enrol each person once.

Treat email and SMS as a fallback rather than your main method. They depend on the mail or phone network being available, and the code is only as safe as the inbox or SIM that receives it.

Enable MFA for local FortiGate users

This is the shortest route and works for both VPN users and administrators who are defined on the firewall itself.

Step 1: Register the token

On the FortiGate, go to User & Authentication > FortiTokens and select Create New for a hardware token, entering its serial number. Mobile tokens are provisioned from the same area. Fortinet’s guide to registering and assigning tokens lays out this sequence.

Step 2: Configure the email or SMS service

FortiToken Mobile activation codes travel by email or SMS. Under System > Advanced, configure the email service. The same guide notes that the default mail port is 25, so confirm that your mail relay accepts the firewall and change the port if your relay requires another.

Step 3: Turn on two-factor for the user

1. Go to User & Authentication > User Definition and edit the user.
2. Enable Two-factor Authentication.
3. Set the authentication type to FortiToken and choose the token from the list.
4. Enter the user’s email address, or enable SMS and enter a phone number.
5. Select OK, then check FortiTokens to confirm the token shows as assigned to the right person.

The user receives an activation code by the method you chose. Activation codes expire after a configurable period, which you set in the CLI, so tell users to activate promptly after you assign the token.

Step 4: Apply it to the VPN or admin login

Put the user in a user group, then reference that group in the SSL VPN or IPsec VPN settings and in the firewall policy that allows VPN traffic. For administrators, create the admin account with the same two-factor option enabled. After that, a login asks for the password first and then the token code.

Test with a non-privileged account before you switch your own admin account. Keep one tested emergency admin path so a token problem cannot lock you out of the box.

Use RADIUS and a central authentication server

A RADIUS design keeps users and tokens off the firewall. The firewall acts as a RADIUS client and sends each login to the server. The server verifies the password and the one-time code and returns accept or reject.

Fortinet’s own cookbook for its authentication appliance walks through a push-notification MFA recipe for SSL VPN. The pattern is the same whichever RADIUS-capable server you use:

1. Create the user on the authentication server and assign a token license.
2. Add the FortiGate as a RADIUS client, using its IP address and a shared secret.
3. On the FortiGate, create a RADIUS server entry that points to the authentication server with the same secret.
4. Create a user group on the FortiGate that uses that RADIUS server.
5. Reference the group in the SSL VPN settings and the VPN firewall policy.

The cookbook’s recipe uses the same logic: connect the firewall to the RADIUS server, then create an SSL VPN that gives remote users internal access. It also adds that when a user must enter both a password and a token passcode, that is two-factor authentication.

The same book includes a recipe for SAML with the authentication appliance acting as an identity provider proxy for a cloud directory. If your company already uses a cloud identity platform such as Microsoft Entra ID, that path lets users keep one login and one MFA prompt across the VPN and their other apps.

Prerequisites that trip people up

• Time. SAML and time-based codes depend on accurate clocks. Point the firewall at a reliable NTP source.
• Reachability. The firewall must reach the RADIUS server on its authentication port, and the server must allow the firewall’s address as a client.
• Group matching. If the server returns a group attribute, the name must match what the firewall expects, or the user authenticates but lands in no policy.
• Firmware. Menu paths and SSL VPN features change between FortiOS releases. Read the release notes for your version before an upgrade, and re-test MFA afterwards.

SSO and MFA are not the same thing

People often ask whether setting up single sign-on on a FortiGate counts as MFA. It does not. Fortinet’s user authentication documentation describes SSO as letting the firewall reuse an existing directory or Windows logon so users are not prompted again for permitted resources. That is convenience: the identity is passed along.

MFA is a separate requirement. It applies only when your policy or authentication backend demands an additional independent factor. A practical way to think about it: SSO answers who you are without asking again, and MFA makes sure that answer was backed by something the attacker would not have. If you use SSO with a cloud identity provider, enforce MFA there so the sign-in that the firewall trusts is already strong.

Test and troubleshoot a failing login

When MFA does not work, work from the network inward.

1. Confirm the server path. Use the FortiGate CLI diagnostic command to test RADIUS or LDAP authentication with a known user. A reject with a clear reason is better than a silent timeout.
2. Check the shared secret. A mismatch is the most common cause of RADIUS failure, and it is easy to get wrong when copying secrets between systems.
3. Check connectivity. Confirm routing, source interface and any upstream firewall rules between the FortiGate and the server.
4. Check group matching. The user may authenticate but not match the group in the policy.
5. Watch the transaction. Running the authentication daemon debug (fnbamd) in the CLI shows each step of the login as it happens, according to one practitioner’s authentication guide. Turn debugging off afterwards.
6. Check the clock. For SAML and time-based codes, confirm the firewall time is accurate.

If a user says the code is always wrong, check whether the token was assigned to the right account and whether the activation code expired before it was used.

Protect the credentials around the firewall

MFA on the firewall is only as good as the accounts that surround it. The administrator’s email receives the activation codes and password resets. The shared secret sits in a document somewhere. The VPN password may be reused on a dozen other sites.

That is where a password manager and a second factor on those accounts close the gap. Use a long, unique password for each admin account, keep RADIUS secrets and break-glass credentials in an encrypted vault rather than a spreadsheet, and turn on MFA for the email inbox that receives recovery messages. Our guides on what 2FA is and why it matters and the business benefits of two-factor authentication explain the reasoning in plain terms for non-specialists on your team.

Our perspective

Most firewall breaches we hear discussed start with a login, not an exploit: a reused password, an unprotected inbox, a shared admin credential. A second factor on the FortiGate is the right move, and we would go further and treat identity as the thing you are really defending.

That means three habits. First, every admin and VPN user gets a unique password that nobody has to remember, which is exactly what a password manager is for. Second, the second factor should be easy enough that people do not look for ways around it. This is why we put so much into passwordless MFA and biometric options, which remove the code-typing step while keeping the strength. Third, the secrets that make the infrastructure work, such as RADIUS secrets and emergency credentials, belong in an encrypted vault with access control, not in a shared file.

Our design is built for that whole picture: password management, MFA, single sign-on, and dark web monitoring, in plans that fit a single user or a managed service provider with many clients.

Mike

Put identity protection around your firewall with LogMeOnce

Once the FortiGate has MFA, bring the rest of your team’s logins up to the same standard. Our business plans cover password management, MFA and single sign-on for teams: Teams is $4.00 per month per user and Business is $7.99 per month per user, and Enterprise is available for larger organizations. See the business plans and comparison for what each tier includes.

For an individual administrator or a small shop, the password manager plans start with Professional at $2.50 per month, and our passwordless MFA page explains how to sign in without typing codes. If you would like to see how our two-factor options work first, read the two-factor authentication setup guide.

A rollout checklist

Before you enforce MFA for everyone, run through this list.

• Inventory who logs in: VPN users, admins, contractors, service accounts.
• Decide the method per group: tokens for admins, mobile tokens or push for staff, a fallback for lost devices.
• Confirm licensing, including the FortiGuard subscription for tokens.
• Fix time sync and the mail or SMS service.
• Pilot with IT first, then a small department.
• Document a recovery process for a lost phone, and who may approve it.
• Keep one tested emergency admin path.
• Re-test after every firmware upgrade.

FAQ

How do I enable multi-factor authentication on a FortiGate?

Register a FortiToken under User & Authentication, then edit the user, enable Two-factor Authentication and pick the token. Add the user to a group used by your VPN or admin policy. For many users, use a RADIUS server instead and point the firewall at it.

Can I use email for two-factor authentication on my FortiGate?

Yes. Fortinet’s token guide shows that you can enter a user’s email address when you assign two-factor authentication, and that email service must be configured on the firewall first. Treat email as a fallback, since anyone who controls the inbox controls the code.

Do I have to use FortiToken?

No. FortiToken is the built-in option, but a RADIUS or SAML setup lets an outside authentication service handle the second factor. If you use FortiToken, the firewall needs a FortiGuard subscription.

Is single sign-on the same as MFA on FortiGate?

No. SSO lets the firewall reuse an existing logon so users do not re-enter credentials. MFA requires an extra factor, and it applies only if your policy or authentication backend asks for one.

Sources

• Two-factor authentication, Fortinet GURU
• FortiToken 5.4 Comprehensive Guide, Fortinet
• FortiAuthenticator 6.2.0 Cookbook, Fortinet
• User Authentication, Fortinet Technical Documentation
• FortiGate Authentication Settings: Config & Methods, Infosec Monkey

Recommended

• Two-Factor Authentication Setup