Skip to content
Avanet

Enable MFA for Sophos Firewall WebAdmin and VPN

Administrative access and remote access portals should not be protected only by username and password. With Multi-Factor Authentication, or MFA, Sophos Firewall requires a second factor as well, such as a time-based OTP code from an authenticator app.

This guide shows how to plan, enable and test MFA properly. The focus is on WebAdmin, VPN Portal and Remote Access.

When MFA is useful

MFA should be enabled at least for all accounts that can access administrative interfaces or remote access functions.

Typical use cases:

  • Sign-in to WebAdmin.
  • Sign-in to VPN Portal.
  • SSL VPN or Sophos Connect Remote Access.
  • Access for external service providers.
  • Access for privileged administrators.

MFA reduces the risk of stolen passwords, but it does not replace clean access restrictions. SSH, WebAdmin and portals should still be reachable only from trusted networks or through clearly defined management access.

Restrict access additionally with ACL rules

Before enabling MFA, check from where WebAdmin, SSH, User Portal and VPN Portal are reachable at all.

The menu path is System > Administration > Device access.

There are two relevant areas:

  • Local service ACL: General access per zone, for example LAN, VPN or WAN.
  • Local service ACL exception rule: Targeted exceptions for individual source networks, hosts or support access.

For production environments, WebAdmin and SSH should not be enabled generally for the WAN zone. It is better to restrict access to:

  • a management IP,
  • an admin network,
  • a VPN network,
  • a dedicated support host,
  • or a clearly defined FQDN or host exception.

If SSH is required, access should also be restricted and ideally used with a public key. See also: Connect to Sophos Firewall over SSH

⚠️ MFA protects against stolen credentials, but not against unnecessarily exposed services. WebAdmin, SSH and portals should never be reachable more broadly than necessary.

Requirements

Before enabling MFA, check the following:

  • The firewall system time is correct.
  • A working NTP server is configured.
  • Users exist locally, through AD, LDAP, RADIUS or another supported authentication service.
  • The affected users can sign in to the User Portal or the relevant service.
  • At least one administrative fallback access exists.

⚠️ Be especially careful with admin MFA. Do not enable MFA directly for all administrators without first testing a test user, a second administrator and fallback access. An incorrect MFA configuration can lock you out of WebAdmin or VPN Portal.

Sophos MFA or external MFA over RADIUS?

Sophos Firewall includes its own MFA solution. OTP tokens are managed directly on the firewall. This is quick to set up and works without additional infrastructure.

Advantages of Sophos built-in MFA:

  • No additional RADIUS or identity provider integration required.
  • Fast rollout for local users and small environments.
  • Tokens can be generated and managed directly on the firewall.
  • Suitable for WebAdmin, User Portal, VPN Portal, SSL VPN Remote Access and IPsec Remote Access.

Disadvantages:

  • Users may have to maintain an additional authenticator app or token.
  • The token is separate from Microsoft 365, Entra ID or other existing MFA processes.
  • Depending on the sign-in form, there is no dedicated OTP field.
  • For certain portals, users must enter password and token directly after each other.

In larger environments, an external MFA solution via RADIUS may be more suitable. MFA is then implemented, for example, through Microsoft Entra ID, NPS with the MFA extension or another RADIUS-compatible MFA service. This is often more comfortable for users because they can use the familiar Microsoft 365 MFA or an existing company solution.

The disadvantage of an external solution is the higher complexity. RADIUS, groups, timeouts, challenge behaviour and fallback must be planned and tested carefully.

Plan MFA

For production environments, it is usually better to enable MFA first for a small pilot group.

This order has proven useful:

  1. Prepare a test user or pilot group.
  2. Check NTP and the firewall time.
  3. Enable MFA for the test area.
  4. Test sign-in with an authenticator app.
  5. Only then add further user groups.

For service providers, a dedicated user group is recommended. This makes it possible to enforce MFA specifically and later remove access more easily.

For administrators, also plan:

  • Who is the first test admin?
  • Is there a second admin with working access?
  • Is access possible through a management network or VPN?
  • Is the default admin protected separately?
  • Is it documented how a lost token is replaced?

Enable MFA on Sophos Firewall

The MFA settings are located under Configure > Authentication > Multi-factor authentication.

  1. Sign in to the Sophos Firewall WebAdmin.
  2. Open Configure > Authentication.
  3. Go to the Multi-factor authentication tab.
  4. Under One-time password (OTP), select who MFA should apply to:
    • No OTP: MFA is disabled.
    • All users: MFA applies to all users.
    • Specific users and groups: MFA applies only to selected users or groups.
  5. Enable Generate OTP token with next sign-in if users should set up their token themselves at the next login.
  6. Under Require MFA for, select the services that should require MFA.
  7. Save the configuration with Apply.
Sophos Firewall - Multi-factor authentication settings under Authentication
Sophos Firewall - Authentication > Multi-factor authentication

Typical options under Require MFA for are:

  • User portal
  • Web admin console
  • VPN portal
  • SSL VPN remote access
  • IPsec remote access
  • Web application firewall

Depending on the environment, MFA can be applied differently for individual services or user groups. For administrators, MFA should be enforced consistently, but tested in a controlled way first.

MFA for the default admin

The local default user admin is a special case. In the MFA screen, Sophos notes that MFA for this user is not enabled directly in this tab.

The menu path is System > Administration > Device access.

There you can enable MFA for default admin. Do this only when:

  • the system time is correct,
  • a second administrator has been tested,
  • access through a trusted management network works,
  • and it is clear how administrative access can be restored in an emergency.

For the default admin, the rule is: do not disable it, do not expose it unprotected to the internet and do not use it as a normal day-to-day user. It is a break-glass or emergency account.

Set up tokens for users

After activation, the user must set up the second factor. If Generate OTP token with next sign-in is active, the user signs in to the User Portal or VPN Portal and scans the QR code with an authenticator app.

Suitable apps include:

  • Microsoft Authenticator.
  • Google Authenticator.
  • 1Password.
  • Bitwarden.
  • Other TOTP-compatible authenticator apps.

The generated code is time-based. If the time on the firewall or smartphone differs significantly, sign-in fails.

If the User Portal is disabled, users may not be able to set up their tokens themselves. In that case, you must either make the portal available in a controlled way or prepare tokens administratively.

Important note about password and token

Depending on the Sophos service, there is no separate form field for the OTP code. This often causes confusion, especially with VPN Portal or Remote Access sign-ins.

In these cases, the user often has to enter the password and OTP code directly after each other.

Example:

Password: MySecurePassword
OTP code: 123456
Input:    MySecurePassword123456

This should be clearly communicated to users before the rollout. Otherwise it looks to the user as if the password is wrong, even though only the OTP code is missing.

Sophos describes this behaviour in its own OTP documentation: OTP token.

Test sign-in

Test MFA first with a user who is not the only administrator.

Check the following:

  • Sign-in to WebAdmin.
  • Sign-in to VPN Portal.
  • Sign-in to the remote access service.
  • Behaviour with an incorrect OTP code.
  • Behaviour after an OTP code has expired.
  • Access with a user who is not in the MFA group.
  • Login with password and appended OTP code.
  • Access through the planned ACL rules.

Only after these tests are successful should MFA be rolled out to further groups.

Common mistakes

OTP code is not accepted

Check the firewall system time and the time on the smartphone. TOTP is time-dependent. Even a significant time difference can cause valid codes to be rejected.

User does not see a QR code

The user must be eligible for MFA and sign in to the correct portal. Also check whether the user is found through the expected authentication source.

If the User Portal is disabled, the user may not be able to set up the token themselves. The portal must then be made temporarily reachable or the token must be created administratively.

Administrator is locked out

Use the prepared fallback access. If no fallback exists, access must be reviewed depending on the situation through console, support or recovery paths.

MFA does not apply to Remote Access

Check whether the Remote Access configuration uses the same user group for which MFA was enabled. The issue is often not MFA itself, but different groups in VPN and authentication rules.

User enters only the password

If no separate OTP field is shown, the user must enter password and OTP code directly after each other. This is one of the most common support cases after enabling Sophos OTP.

External MFA is unreliable

For RADIUS-based MFA solutions, timeouts, challenge behaviour and groups must match cleanly. If push MFA, call MFA or challenge responses are used, test the full login process with the affected client.

Recommendation

MFA should be standard for administrative access. It is especially important for WebAdmin, VPN Portal and all users with Remote Access permissions.

For small environments, Sophos built-in OTP function is often sufficient. In Microsoft 365 or Entra ID environments, external MFA via RADIUS can be more convenient because users do not need to learn a second MFA world.

Regardless of the MFA variant, the same rule applies: restrict access with ACL rules first, test admin MFA carefully, inform users about password+token and only then roll it out broadly.

Further Sophos information: