Enable MFA for Sophos Firewall WebAdmin and VPN

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

The following procedures distinguish between the documented MFA features of SFOS 22 and SFOS 23. In particular, Share QR code and the QR validity period described must not be applied to SFOS 22. The app restrictions relate to the documented Sophos registration procedure, not to every current app version indiscriminately. Before rollout, the installed SFOS build, the mobile operating system, the specific app version and every required service are therefore checked with the pilot group.

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

Sign in to WebAdmin and open Authentication > Multi-factor authentication.
Under One-time password (OTP), select Specific users and groups first.
Open Add users and groups, select the pilot group and apply the selection.
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.
Under Require MFA for, select only the sign-in interfaces that are actually required.
Under OTP hash algorithm, choose an algorithm supported by the intended app.
Change the optional OTP timestep settings only if the app supports the same timestep; the default is 30 seconds.
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.

For Email, check before the pilot that the correct user address is configured and delivery works. The QR code contains the token secret: protect mailbox access and do not include the QR code or Base32 key in unprotected tickets or screenshots. If delivery fails, first check the address and email sending; do not trigger a login block through repeated failed login attempts. For a pilot without email delivery, Portals is the documented alternative; portal access must be possible from the intended network.

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 under CLI Main Menu > 2. System Configuration.

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.

The list may also contain manually prepared tokens without a user assignment; a user can be assigned to these later. Manually assigned tokens also appear, as do tokens belonging to users and administrators who have registered the QR code. A list entry alone therefore does not prove a successful MFA login: check the user assignment, token status and actual login before handover.

After deletion, the old token’s passcode is invalid and must not be appended during the password-only registration login. Deletion cannot be undone by entering the old code again; the safe recovery method is controlled reissuance. Before deletion, therefore, check portal access, delivery or manual seed handover, and fallback. For multiple users, proceed in stages and approve each new registration before migrating the next group.

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.

In manual mode too, first configure Specific users and groups with the pilot group and the required services under Require MFA for, select the compatible algorithm and timestep, and save with Apply. Then, in the Add token (for hardware tokens) dialogue, select OTP hash algorithm for the token to be created before completing Secret, the user and, where applicable, Use custom timestep, and saving with Save. Selecting a global default alone replaces neither token assignment nor the subsequent pilot login.

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.

API automation: separate settings from token state

For API automation, OTPSettings and OTPTokens serve two different purposes: the settings define the MFA scope, services and global settings; the token record belongs to an individual issued token. Changing a setting does not replace user assignment, enrolment or the pilot login.

Under OTPSettings, use the documented switch values 0 and 1, not GUI labels or Enable/Disable:

otp turns OTP off or on. allUsers=0 restricts the scope to explicitly selected users or groups; it does not itself enable OTP. Keep the selection narrow for the pilot rather than setting allUsers=1. The example shows the selection under otpUsers/user, but the parameter table does not define a user ID encoding for it. Do not construct identities from names or assumed IDs.
tokenAutoCreation controls automatic token generation, not the state of an already issued token. otpUserPortal, otpVPNPortal, otpSSLVPN, otpWebAdmin and otpIPsec represent User Portal, VPN Portal, SSL VPN Remote Access, WebAdmin and IPsec Remote Access. Select only the required services; when reviewing the configuration, also take account of the automatic User Portal selection in the GUI flow.
Only SFOS 23 documents the optional qrCodeVia, with exactly email or portal. The GUI labels Email and Portals are not literal API values. No API default is documented; this field is absent from the SFOS 22 reference.

Treat the time values separately: OTPSettings/defaultTimeStep is the global token interval, OTPSettings/maxTimeStepsInterval is the ongoing verification window, and OTPSettings/maxInitialTimeStepDiff is the window for first use. By contrast, OTPTokens/timeStep is the interval for the individual token. The API specifies validation limits of 10–300 seconds, 0–10 timesteps, 0–600 timesteps and 10–300 seconds respectively. These are neither operational recommendations nor API defaults; the default columns are empty. The GUI defaults described above and app compatibility remain separate from these limits.

For a token, active, autoCreated and lastLogin concern its status, origin and last successful login respectively, not the global MFA selection. Do not populate lastLogin or autoCreated as mandatory fields in an automation workflow. The token example is not a validated import schema either: it uses OTPTokens/user, whereas the table specifies userid. In its MFA help, Sophos requires an empty <tokenid/> for API imports; the token example also shows this, but the API table specifies a minimum length of 1 character. Do not resolve this contradiction by inventing IDs or assuming a universally valid write schema.

XML deletion is not a token import. The Delete OTP Token reference for SFOS 22 and SFOS 23 identifies an existing token by tokenid; a single string of 1–32 characters is documented. Before deletion, read the saved token record from a trusted, current view and verify its identifier and assignment to the exact intended user. Neither user nor userid nor the empty <tokenid/> from the import instructions replaces this deletion identifier. The table entry Mandatory: No does not authorise omitting or inventing the identifier, or deriving it from a username. If the identity or version-appropriate schema is unclear, do not delete the token; first clarify the assignment or schema.

Before XML deletion, keep the tested fallback, management access and console access available; the user verification and preparation for automatic or manual reissue described above still apply unchanged. The restrictions for the default administrator also remain in place. After the call, read the token inventory again and verify that the exact intended old token is no longer present and that other tokens remain unchanged. Then carry out the prepared reissue and verify a fresh, successful MFA sign-in; keep the fallback available until acceptance is complete. A response alone replaces neither this inventory check nor the MFA test.

The Delete reference lists 200 with the unresolved message symbol OTPTokenDeleted and 500 with OTPTokenNotThere. These are entries in the documentation, not confirmed runtime messages or guarantees of an HTTP status, repeatability or a safe automatic retry. Neither an executable XML request nor a request envelope is derived from them.

An API import is not equivalent to the manual Add token dialogue. Before a production import, check the backup and permitted API access, clarify the schema appropriate to the version, and do not store seeds in unprotected request logs. Afterwards, verify the saved settings, narrow user selection, service assignments and token status, and test the pilot login described above. A successful API call alone does not constitute MFA acceptance.

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:

Test the pilot app with SHA256 or SHA512.
Enable Generate OTP token with next sign-in. In SFOS 23, also select Email or Portals under Share QR code before Apply.
Select the new algorithm under Authentication > Multi-factor authentication.
Select Apply to save.
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.
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.
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.

Sign in to WebAdmin as the default admin and open Administration > Device access.
Turn on MFA for default admin and click Apply.
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.

The recovery options are under CLI Main Menu > 2. System Configuration, not in 4. Device Console. If you are already in the Device Console, first return to the Main Menu and select 2 for System Configuration.

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 CLI Main Menu > 2. System Configuration to permit only the next WebAdmin login by the default admin without MFA:

In the CLI Main Menu, enter 2 for System Configuration.
Enter 6 for Skip multi-factor authentication for next Admin user login.
Sign in to WebAdmin once using only the default admin password and check the token. Keep the tested fallback and console access available.
Then open a separate fresh WebAdmin session as the default admin using the password plus the current passcode in <password><passcode> format. Recovery is complete only after a successful MFA login; document the result and keep the fallback available until then.

If the token remains unusable, follow the reset and re-enrolment procedure below, then verify another fresh MFA login. The skip applies only to the next login; neither No OTP for everyone nor broader WAN access is a substitute for this check.

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

In the CLI Main Menu, enter 2 for System Configuration.
Enter 7 for Reset multi-factor authentication for Admin user.
Confirm with y.
Sign in to WebAdmin once using only the admin password.
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

If the pilot fails, rollout is halted. Using the tested second administrator, the normal pilot selection under Specific users and groups can be reset to the documented initial state; this neither affects the separate default administrator wizard nor restores deleted tokens. For external groups, the additional MFA login explained above must still be taken into account. Do not use either No OTP for everyone or broad WAN access as a blanket repair method. After a correction, test the affected services again in fresh sessions.

Pilot group successfully tested with all required services.
Second administrator, one-time codes and recovery through CLI Main Menu > 2. System Configuration 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.

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 option 6 or 7 under CLI Main Menu > 2. System Configuration 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.