Skip to content
Avanet

Enable MFA for Sophos Firewall WebAdmin and VPN

Sophos Firewall

For the local OTP feature, open Authentication > Multi-factor authentication, select Specific users and groups first, enable the required services and test everything with a pilot group. All users should only be used after successful testing.

MFA protects WebAdmin, VPN Portal and Remote Access against the use of stolen passwords alone. However, it does not replace restrictive access rules or a tested emergency login. This article therefore covers the process from secure activation to app selection, recovery and troubleshooting.

Enable Sophos OTP securely

Before activation

Clarify the following points before making the first change:

  • The firewall has the correct time under Administration > Time, ideally provided by NTP.
  • Users and groups are available locally or through AD, LDAP or another authentication server.
  • A pilot group and a second tested administrator exist.
  • The console and recovery procedure are known for the default admin.
  • A current backup and a documented token reset process are available.

For classic Active Directory, Add Active Directory to Sophos Firewall explains how to configure the user source.

Under Administration > Device access, specify the zones from which WebAdmin, User Portal, VPN Portal and other local services can be reached. Local service ACL exception rules further restrict access to management networks, VPN networks or known source addresses. Secure Sophos Firewall access: configure Device Access correctly explains the hardening process in detail.

SSH is not one of the services protected by Sophos OTP. Restrict it through Device Access and use a public key where possible; the procedure is described in Connect to Sophos Firewall via SSH.

⚠️ MFA reduces the risk posed by compromised passwords, but it does not reduce the attack surface of a publicly accessible service. WebAdmin, SSH and portals should never be exposed more broadly than necessary.

Before negative tests, also check Administration > Admin and user settings > Login security > Block login. Several deliberate failed attempts can block the source IP for WebAdmin, CLI, VPN Portal and User Portal, which may also lock out a fallback administrator on the same network. A second source or console access should therefore be available.

Configure MFA for a pilot group

  1. Sign in to WebAdmin and open Authentication > Multi-factor authentication.
  2. Under One-time password (OTP), select Specific users and groups first.
  3. Open Add users and groups, select the pilot group and apply the selection.
  4. Enable Generate OTP token with next sign-in when using an authenticator app.
  5. Under Require MFA for, select only the sign-in interfaces that are actually required.
  6. Under OTP hash algorithm, choose an algorithm supported by the intended app.
  7. Change the optional OTP timestep settings only if the app supports the same timestep; the default is 30 seconds.
  8. Select Apply to save.
Sophos Firewall Authentication > Multi-factor authentication with user selection, protected services and OTP hash algorithm
This screen defines the MFA users, protected services and OTP hash algorithm. The displayed All users and SHA1 values are not rollout recommendations.

The user options mean:

  • No OTP: MFA is disabled.
  • All users: MFA applies to all users; only use this after the pilot.
  • Specific users and groups: MFA applies only to the selected accounts or groups.

When Generate OTP token with next sign-in is enabled, users register a software app at their next login. User Portal is then selected automatically as an MFA service. When the option is disabled, hardware or manually managed tokens are assigned under Issued tokens.

Select services deliberately

Under SFOS 22, the following services are available under Require MFA for:

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

MFA for User Portal also applies to Captive Portal and Client Authentication Agents. Remote access users must first register their token through VPN Portal or User Portal.

For WAF, selecting the service alone is not sufficient. From SFOS 22, Webserver Protection, a form-based Authentication Policy and its assignment to the WAF rule are required. The complete procedure is described in Secure Sophos Firewall WAF with MFA.

Choose the appropriate MFA model

Local Sophos OTP

Sophos OTP manages tokens directly on the firewall and does not require additional RADIUS or identity provider infrastructure. It is particularly suitable for normal local users, small environments and rapidly hardening WebAdmin or Remote Access.

The trade-off for simple deployment is a separate token outside established Microsoft 365 processes. Users and the help desk must know how to enrol the app, enter password-plus-OTP and handle device changes.

RADIUS or Entra ID SSO

An existing MFA platform may fit central identity operations better when integrated through RADIUS or SSO. However, it requires service-specific testing:

  • VPN Portal does not support RADIUS with challenge MFA.
  • Sophos Connect does not support an OTP challenge. The client sends the password and OTP together in passwordotp format, but supports call and push MFA.
  • User Portal and WebAdmin additionally support challenge-based MFA.
  • With Entra ID SSO, MFA takes place at the identity provider; local Sophos OTP MFA cannot be added to the same SSO login.
  • Entra SSO with Sophos Connect requires at least client version 2.4 on Windows. WebAdmin SSO is not available on the HA auxiliary device.

For Remote Access, see the separate guide Configure Microsoft Entra ID SSO for Sophos Connect and VPN Portal. If Entra should instead control WebAdmin login and administrator roles, Entra ID SSO for Sophos Firewall WebAdmin covers role mapping, least privilege, the pilot login, and the local emergency login.

Sophos Connect or SSL VPN: which solution fits? helps with the choice of remote access model; also check the Sophos Connect client version before rollout.

Regardless of the model, start with a pilot group. Add more users only after WebAdmin, portals, actual VPN clients, groups, timeouts, logging and fallback have all been verified.

Set up tokens and the authenticator app

Register and manage tokens

When Generate OTP token with next sign-in is enabled, the user signs in to VPN Portal or User Portal and scans the QR code. Administrators can also register the token in WebAdmin when MFA is enforced there. The QR code only appears for users and groups for which MFA is configured.

Under Authentication > Multi-factor authentication > Issued tokens, issued tokens can be reviewed, temporarily disabled, deleted or added manually. Additional one-time codes can also be generated there, and a token’s time offset can be checked or synchronised.

If a smartphone is lost or the app is changed, delete the old token after verifying the user’s identity. The user then signs in to the portal once using only the password and registers the newly displayed QR code. An old token should not continue to exist in parallel without control.

App and hash algorithm must be compatible

SFOS 22 supports SHA1, SHA256 and SHA512. Sophos recommends SHA256 or SHA512, but the selected algorithm must be supported by the app:

  • Sophos Intercept X for Mobile and Google Authenticator support SHA256 and SHA512.
  • Microsoft Authenticator does not support these two algorithms in this Sophos workflow. Scanning the QR code may still succeed, but the subsequent login fails.
  • Duo Mobile and Okta Verify are among the apps listed by Sophos; their suitability for the QR code and algorithm must match the operating system and configuration in use.
  • Approve other TOTP apps only after a real pilot test.

On iOS, scanning the Sophos QR code does not work with Google Authenticator, Duo Mobile or Microsoft Authenticator. Create the account manually using the displayed Base32 key. Okta Verify requires manual Base32 enrolment on both iOS and Android. However, this does not resolve Microsoft Authenticator’s lack of SHA256/SHA512 support.

The former Sophos Authenticator app reached end of life on 31 July 2022 and should no longer be planned for new rollouts.

To migrate from SHA1 to a stronger algorithm:

  1. Test the pilot app with SHA256 or SHA512.
  2. Select the new algorithm under Authentication > Multi-factor authentication.
  3. Delete old SHA1 tokens under Issued tokens.
  4. Have users sign in using only their password and re-register the QR code or Base32 key.
  5. Perform controlled login tests with both a correct and an incorrect passcode.

Tokens using different algorithms can exist in parallel during the migration. However, tokens that are not deleted continue to use their old algorithm.

Enter the password and OTP correctly

For native Sophos OTP logins, the official format is <password><passcode>, without spaces or separators.

Example:

Password: MySecurePassword
OTP code: 123456
Input:    MySecurePassword123456

Sophos Connect can display a separate third input field through otp: true. The client appends the code to the password internally. This display does not change the format sent to the authentication server.

Secure and recover the default administrator

Enable MFA for the default admin

The local default admin user is not enabled through the normal user list. Open Administration > Device access, turn on MFA for default admin and configure the hardware or software token there.

Before doing so, verify that a second administrator, management access and console access work. Store additional one-time codes securely, for example in a password manager. The default admin remains an emergency account and should not be used for daily administration.

Other administrators cannot enable, disable, edit or delete the token of the default admin. The selected global OTP hash algorithm also applies to this token.

Recovery through the Device Console

If the token is only temporarily unavailable, use the Device Console to permit a one-time login without MFA:

  1. Enter 2 for System Configuration.
  2. Enter 6 for Skip multi-factor authentication for next Admin user login.
  3. Sign in to WebAdmin and check the token.

If the device has been lost or the token is permanently unusable, reset MFA:

  1. Enter 2 for System Configuration.
  2. Enter 7 for Reset multi-factor authentication for Admin user.
  3. Confirm with y.
  4. Sign in to WebAdmin once using only the admin password.
  5. Follow the instructions to register MFA again, then test another login with MFA.

These two options change only the MFA state. If the default admin password is also unknown, the separate password recovery article explains the documented serial procedure for physical appliances and the limitations when both the password and MFA have been lost.

Test, review logs and roll out

Test every service separately

A successful WebAdmin login does not prove that portals and VPN clients work in the same way. Before a broad rollout, test:

  • WebAdmin: Sign in as the pilot administrator with a correct and a deliberately incorrect OTP.
  • Default admin: Verify the separate Device Access path and the documented recovery procedure.
  • User Portal and VPN Portal: Test QR or Base32 enrolment and login with <password><passcode>.
  • SSL VPN and IPsec Remote Access: Test actual clients and the exact user group used in production.
  • Sophos Connect: Where applicable, test the third OTP field, current client profiles and call/push behaviour.
  • RADIUS or Entra SSO: Verify timeouts, IdP logs and the challenge behaviour actually supported.
  • Device Access: Test access from an allowed and a disallowed source network.

Perform only a controlled number of failed attempts after reviewing Block login. The expected result is not merely a successful login: an incorrect code must be rejected, the attempt must be logged and the service must be reachable only from the intended networks.

Interpret authentication logs correctly

In Log viewer, review successful and failed logins together with the service, user, source, time and documented reason. Depending on the event, SFOS may only provide a generic message such as invalid credentials. Without additional evidence, do not infer whether the password, OTP or expired code alone caused the failure.

For external MFA, RADIUS, NPS or IdP logs are part of the same verification. Sophos Firewall troubleshooting: services and logs helps with local log files and service mapping. For longer retention and correlation, see Send Sophos Firewall Syslog to a SIEM.

Before the broad rollout

  • Pilot group successfully tested with all required services.
  • Second administrator, one-time codes and Device Console recovery documented.
  • Users informed about app enrolment and password-plus-OTP.
  • Token reset process defined for lost or new smartphones.
  • Device Access, login blocks and central log retention reviewed.
  • Responsibilities, timeouts and fallback defined for external MFA.

Troubleshooting

Token, QR code and input

OTP code is not accepted

First compare the time on the firewall and smartphone, the app in use, the hash algorithm and the timestep. Under Issued tokens, check and synchronise the time offset. After an algorithm migration, the old token must have been deleted and re-registered.

Plan a change of NTP server separately because the firewall reconnects existing IPsec tunnels when doing so.

QR code does not appear or cannot be scanned

The user must belong to the selected MFA group and sign in to VPN Portal or User Portal. Administrators can also enrol in WebAdmin when WebAdmin MFA is active. The portal and source must also be allowed under Administration > Device access.

On iOS, or with Okta Verify, use the Base32 key instead of scanning the QR code where the restrictions described above apply.

Login reports an incorrect password

For a native Sophos OTP login, enter the password immediately followed by the passcode. Without a separate OTP field, the password alone is incomplete.

Access, groups and Remote Access

Portal is not reachable

First check the zone, source and required service under Administration > Device access. A restrictive Local Service ACL Exception Rule is safer than a blanket WAN allowance.

MFA does not apply to Remote Access

The MFA and Remote Access configurations must use the same user group that is actually imported. Then re-import or distribute the client profile and test the connection with the actual client. The token must be registered through VPN Portal or User Portal before the first VPN connection.

MFA applies to only some users

Do not compare only the visible group names; verify the groups actually matched through AD, LDAP, RADIUS or Entra ID. After removing an AD user from an MFA group, one final login with MFA may still be required; only subsequent logins no longer require an OTP.

Lockout and external MFA

Administrator is locked out

For the default admin, use Device Console option 6 or 7 as described above. For another administrator, use the prepared second administrator from an allowed source, then review groups, token and login block status.

RADIUS or Entra MFA is unreliable

Check RADIUS timeouts, IdP logs, groups and the challenge behaviour of the specific service. A successful authentication-server test does not prove a production login through VPN Portal, Sophos Connect or WebAdmin. Test each of these paths separately.