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.

The main procedure configures local Sophos OTP. RADIUS and Entra ID SSO are compared later as alternatives.

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. In SFOS 23, also select Share QR code: Email sends the QR code to the user’s email address at the next VPN Portal or User Portal sign-in. Portals shows it in User Portal and VPN Portal after the next VPN Portal, User Portal or WebAdmin sign-in. This selection does not apply to the default-admin wizard described below.
  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.

After selecting Apply, complete the flow immediately with a pilot user: depending on the selected service, first sign in to User Portal or VPN Portal using the password only, register the QR code or Base32 key in the authenticator app, and then open a fresh session with <password><passcode>. A deliberately incorrect code must be rejected and the attempt must appear in Log viewer. Only consider All users after this positive and negative test.

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.

For externally authenticated users, removal from an MFA group doesn’t take effect immediately on the first subsequent login. Sophos requires one more sign-in with MFA; only later sign-ins no longer require the OTP. Therefore, verify a group change with a fresh session and at least two controlled sign-ins.

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 registers the QR code in a compatible app. In SFOS 22, the QR code is displayed; administrators can also register the token in WebAdmin when MFA is enforced there. In SFOS 23, delivery follows Share QR code: with Email, use the emailed QR code; with Portals, use the QR code displayed in the portals. A WebAdmin sign-in can trigger the portal display with Portals; it is not an email trigger. Enrolment applies only to users and groups for which MFA is configured.

For initial enrolment in SFOS 23 with Generate OTP token with next sign-in set to ON, the following applies to the selected MFA users: a generated QR code expires if it is not used to sign in within 24 hours of generation. To generate a new one, the user signs in to VPN Portal or User Portal using only the password; the new QR code is delivered according to Email or Portals. Then register it in the app and verify a fresh sign-in with <password><passcode>. This QR lifetime is separate from the 300-second first-passcode window. The flow does not apply to an issued token with status OFF or manual seed reissue; do not assume it for SFOS 22 or for every default-admin wizard flow.

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.

Setting the token status to OFF prevents the user from signing in; it does not grant password-only access. This is neither deletion followed by re-enrolment nor the one-login MFA skip through the Device Console.

If a smartphone is lost or the app is changed, first verify the user’s identity. Immediately before deletion, check under Authentication > Multi-factor authentication that Generate OTP token with next sign-in is ON; in SFOS 23, also set Share QR code to Email or Portals. If manual mode OFF is intentional, prepare manual reissue with a new seed instead; the automatic QR flow below does not apply. Only then delete the old token under Issued tokens. The user signs in to VPN Portal or User Portal once using only the password and registers the new QR code: SFOS 22 displays it, while SFOS 23 emails it or displays it in the portal according to the selection. Then verify a fresh sign-in with <password><passcode>. An old token should not continue to exist in parallel without control.

For this app-change/replacement flow in SFOS 23, a generated QR code expires if it is not used to sign in within 24 hours of generation. Signing in again using only the password generates a new QR code, delivered through Email or Portals again. The 24 hours concern the QR code, not the 300-second first-passcode window explained below. Do not assume this QR lifetime for SFOS 22 or for every default-admin wizard flow.

Manually provision a hardware or software token

If the firewall must not generate a QR code, leave Generate OTP token with next sign-in turned off. Tokens that are already registered continue to work; for new users, enter the seed manually under Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). The button name is narrower than the function because the same dialog can also provision a software token manually.

First choose OTP hash algorithm and the timestep required by the specific token or authenticator app. For Secret, use the following rules:

  • For a hardware token, enter the individual key supplied by the manufacturer.
  • For a software token, use a unique and sufficiently random hexadecimal seed. If the app requires Base32, convert this seed locally with a controlled offline tool.
  • Never enter a production seed on a public conversion website or place it in a ticket, unencrypted email, or shell command that is retained in history. Anyone who knows the seed can generate valid OTP codes.

If the individual token differs from the global Default token timestep, turn on Use custom timestep only for that token and enter the interval it actually supports. Without this option, the global default applies; verify app and hardware compatibility before saving.

Then select the exact intended user and click Save. Hand over the hardware token or Base32 seed once through a protected channel. Test one correct and one deliberately incorrect passcode, and synchronize the time offset under Issued tokens if necessary. If the seed may have been exposed, do not continue using the token; delete it and issue a new token with a new seed.

Issue additional one-time passcodes under control

If access to the app or hardware token is only temporarily unavailable, edit the affected user under Authentication > Multi-factor authentication > Issued tokens. Under Additional codes, use the plus button to generate additional passcodes, then click Save to assign them to the token. The firewall automatically removes each code from the list after it is used.

Verify the user’s identity before issuing the codes. Hand them over once through a protected channel to that user only; don’t place them together in an unprotected ticket or email. Additional codes don’t replace reissuing a permanently lost or potentially copied token: delete the old token and register a new one with a new seed.

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.

Sophos Intercept X for Mobile supports a custom token timestep. Most other authenticator apps only support the default of 30 seconds, so the global value shouldn’t be changed solely for one app.

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.

Existing SHA1 tokens can remain after an upgrade from a version earlier than SFOS 22 because earlier SFOS versions generated MFA tokens using SHA1. Selecting a stronger global algorithm doesn’t convert these existing tokens.

To migrate from SHA1 to a stronger algorithm:

  1. Test the pilot app with SHA256 or SHA512.
  2. Enable Generate OTP token with next sign-in. In SFOS 23, also select Email or Portals under Share QR code before Apply.
  3. Select the new algorithm under Authentication > Multi-factor authentication.
  4. Select Apply to save.
  5. Delete old SHA1 tokens under Issued tokens. To delete the default admin token, you must be signed in as that user; another administrator cannot delete it. Keep the tested fallback and console access ready beforehand.
  6. Have ordinary users sign in to VPN Portal or User Portal with their password only and register the QR code or Base32 key again in an app supporting SHA256/SHA512. In SFOS 23, QR delivery follows Email or Portals. For the default admin, re-enrolment after deletion instead starts with a password-only WebAdmin sign-in, not User Portal or VPN Portal; follow the enrolment flow shown there. This is SHA migration, not Use an existing token in the re-enable wizard. Do not assume an additional Share QR code selector in the wizard for this exception.
  7. Perform controlled login tests with a correct and 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.

Limit the timestep and tolerance windows

Under OTP timestep settings, configure not only the interval for new passcodes but also two verification windows. The three values have different effects:

  • Default token timestep sets the interval at which the app or hardware token generates a new passcode. The default is 30 seconds. A change only applies to newly generated tokens and doesn’t modify existing tokens.
  • Maximum verification code offset determines how many timesteps an unused passcode remains valid. With the default value 2 and a 30-second timestep, unused passcodes from the previous 60 seconds are also accepted.
  • Maximum initial verification code offset applies to the first passcode after the QR code is scanned. With the default value 10 and a 30-second timestep, the window is 300 seconds if the passcode hasn’t already been used.

These windows don’t replace accurate time. First check NTP on the firewall and the endpoint time, then keep each offset as small as is practical for the deployed apps and hardware tokens. A larger window accepts an intercepted, unused passcode for correspondingly longer. After a change, test a newly issued pilot token; don’t assume that an existing token uses the changed timestep.

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. Its dedicated wizard is under Administration > Device access, not under Issued tokens > Add token (for hardware tokens) for normal users.

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.

Before starting, also check the time, app/hardware compatibility and Block login as described above. New hardware and software tokens inherit the algorithm from Authentication > Multi-factor authentication > OTP hash algorithm; it is not selected independently in the default-admin wizard. A successful QR scan does not prove algorithm compatibility. The app and Base32 restrictions explained above still apply.

  1. Sign in to WebAdmin as the default admin and open Administration > Device access.
  2. Turn on MFA for default admin and click Apply.
  3. Select the appropriate token method in the wizard and click Next. Then complete the relevant branch:
  • Configure a hardware token: Enter the individual key supplied by the device manufacturer and the timestep matching the hardware token. Click Next, then enter the default admin’s password immediately followed by the current hardware passcode as <password><passcode>, without spaces or separators. Click Validate and, after successful validation, finish with Apply.
  • Generate a software token: Install a compatible authenticator app on the mobile device and scan the displayed QR code. Enter the default admin’s password immediately followed by the current app passcode as <password><passcode>. Click Validate and, after successful validation, finish with Apply.
  • Use an existing token: If a hardware or software token already exists for the default admin and MFA is only being turned back on, select this branch and enter the password immediately followed by the current passcode. To set up a new software token instead, select Generate a software token and register the QR code in the app. This choice is not a migration of existing SHA1 user tokens.

The first Apply starts the setup flow; new hardware and software tokens still require Validate and the final Apply. If validation fails, first check password-plus-passcode, time, timestep and algorithm rather than repeatedly guessing. Keep the existing session open during verification and, after completing setup, test a separate fresh WebAdmin session as the default admin with the password plus a new passcode. Treat setup as complete only after a successful login and secure storage of the one-time codes; the second administrator does not replace default-admin token management or the console recovery procedure described below.

Recovery through the Device Console

Menu options 6 and 7 only appear when MFA for default admin has already been configured under Administration > Device access. If they are absent, do not assume a console fault; first verify this setting and that the account is the actual default admin user. The options do not apply to other administrator accounts.

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.

To synchronise, open Authentication > Multi-factor authentication > Issued tokens, select Synchronize token time offset for the affected token, enter the current passcode generated by the app or hardware token and click Check. The time offset synchronises with the firewall, correcting the time drift. Then perform a controlled fresh-login retest; keep fallback available and review Block login before further failed attempts.

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. In SFOS 22, administrators can also enrol in WebAdmin when WebAdmin MFA is active. In SFOS 23, first check Share QR code: with Email, check the inbox after the portal sign-in rather than expecting a portal QR display; with Portals, the QR code is displayed in the portals, including after a triggering WebAdmin sign-in. The portal and source must also be allowed under Administration > Device access. For initial enrolment or app replacement in SFOS 23 with token generation enabled, also check the 24-hour lifetime explained above: if the QR code was not used to sign in during that period, sign in to VPN Portal or User Portal using only the password and register the new QR code delivered according to Email or Portals.

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.