MFA for Sophos Firewall WebAdmin, VPN Portal and activate remote access

Administrative access and remote access portals should not only be protected with username and password. With Multi-Factor Authentication, MFA for short, the Sophos Firewall also requires a second factor, for example a time-based OTP code from a Authenticator app.

The article explains how to plan, activate and test MFA sensibly. The focus is on WebAdmin, VPN Portal and remote access.

Classification and access protection

MFA is an important protection for logins, but only one building block. First, it should be clear which access is protected, which source of identity is behind it and whether the service even has to be accessible from the respective network.

Which authentication article fits?

MFA is only part of access security. Depending on the goal, the first thing to consider is accessibility, identity source, portal, VPN client or published web application:

This separation is important: MFA protects logins, but it does not automatically limit which networks WebAdmin, SSH or portals can be reached from. Conversely, a narrow device access rule does not replace a second factor. Good access security combines reachability, identity source, MFA, logging and tested fallback access.

When MFA makes sense

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

Typical areas of application:

• Registration on WebAdmin.
• Registration on 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 does not replace proper access restrictions. SSH, WebAdmin and portals should still only be accessible from trustworthy networks or via clearly defined management access.

MFA is not a replacement for Device Access

MFA protects the login process. However, it does not reduce the attack surface of a service. If WebAdmin, User Portal, VPN Portal or SSL VPN are reachable from across the internet, these services will continue to be hit by bots, scanners and brute force attempts. This creates unnecessary log entries, support effort and risk.

That’s why you should always combine MFA with availability controls:

If a portal needs to be accessible worldwide, you should at least combine MFA, valid certificates, logging, restrictive user groups and regular review processes. For publicly accessible firewall services, the question is not just whether an attacker can log in, but whether the service needs to be widely accessible at all.

Additionally restrict access with ACL rules

Before activating MFA, you should check from where WebAdmin, SSH, User Portal and VPN Portal can actually be reached.

The menu path is System > Administration > Device access.

There are two relevant areas:

• Local service ACL: Basic 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, one should not generally enable WebAdmin and SSH for the WAN zone. It is better to limit it to:

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

If SSH is required, access should be additionally restricted and ideally used with a public key. This fits Connect Sophos Firewall via SSH.

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

Select MFA variant and plan rollout

Before activation, you should decide whether the local Sophos OTP function is sufficient or whether an existing MFA platform should be integrated via RADIUS, NPS or SSO. The rollout is then planned so that administrators and users do not lock themselves out.

Requirements

Before activation you should check:

• The firewall system time is correct.
• A working NTP server is configured.
• Users exist locally, through AD, LDAP, RADIUS, or other supported authentication service.
• The affected users can log in to the User Portal or the respective service.
• At least one administrative fallback access is available.> ⚠️ You have to be particularly careful with Admin-MFA. MFA should not be enabled directly for all administrators without first verifying a test user, a second administrator, and fallback access. Incorrect MFA configuration can result in locking yourself out of the WebAdmin or VPN Portal.

Sophos MFA or external MFA?

There are basically two ways for MFA on the Sophos Firewall: you use the local OTP function of the firewall or connect an external MFA solution via RADIUS or SSO. Both variants are legitimate, but solve different problems.

The local MFA of the Sophos Firewall manages OTP tokens directly on the firewall. This is usually the quickest way to secure WebAdmin, portals and remote access with a second factor. No additional RADIUS infrastructure or identity provider is required.

Advantages of Sophos’ own 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 need 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 login mask, there is no separate OTP field.
• Users have to enter password and token directly one after the other on certain portals.

In larger environments, an external MFA solution may make more sense. Typical variants are RADIUS with a MFA-capable backend, Microsoft NPS with Entra-MFA extension or another RADIUS-compatible MFA system. Depending on the SFOS version and remote access model, Microsoft Entra ID SSO for WebAdmin, VPN Portal as well as Sophos Connect with SSL VPN or IPsec VPN can also fit.

The important distinction is: Entra ID is not simply the same mechanism as the local Sophos OTP feature. Either Entra MFA is indirectly integrated into the authentication flow via RADIUS/NPS or an SSO model is used if the service and client used support this.

Users often find an external MFA more convenient because they are using the same MFA as for Microsoft 365 or other business services. This does not create a second MFA world with an additional app, additional token and different login behavior.

The disadvantage of an external solution is the higher complexity. RADIUS, groups, timeouts, challenge behavior and fallback must be carefully planned and tested.| Variant | Advantage | Disadvantage | Typical use | | — | — | — | — | | Sophos OTP on the firewall | Quickly set up, no additional infrastructure, managed directly in SFOS | Additional token, separate from Microsoft 365 or Entra ID, depending on the portal Password+OTP in a field | Small environments, local users, fast hardening of WebAdmin and VPN | | External MFA via RADIUS | Existing MFA platform can be used, central user processes are retained | RADIUS, NPS, timeouts, groups and client behavior must be tested cleanly | AD/Microsoft 365 environments with many VPN users | | Entra ID SSO | Familiar Microsoft login, better user experience, central identity processes | Not usable identically for every scenario, depending on SFOS version, service and client | WebAdmin, VPN Portal and Sophos Connect if SSO fits the operating model |

Decision support

The right MFA variant depends less on the firewall than on the existing identity operation.

If Microsoft Entra ID is planned directly as an SSO source for VPN Portal or Sophos Connect, Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal also fits. This is a different operating model than the classic Sophos OTP function and should not be equated with RADIUS-MFA untested.

MFA plan

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

This order has proven successful:

1. Prepare test users or pilot group.
2. Check NTP and time of firewall.
3. Enable MFA for the test area.
4. Test registration with Authenticator app.
5. Only then integrate additional user groups.

A separate user group is recommended for service providers. This makes it possible to specifically force MFA and remove access later more easily.

For administrators you should also plan:

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

Activate MFA and set up tokens

When prerequisites, groups and fallback are clarified, MFA can first be activated for a pilot group. Only after successful tests should you include additional users or administrators.

Activate MFA on the Sophos Firewall

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

1. Log in to the WebAdmin of the Sophos Firewall.
2. Open Configure > Authentication.
3. Switch to the Multi-factor authentication tab.
4. For 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 only applies to selected users or groups.
5. Activate Generate OTP token with next sign-in if you want users to set up their token themselves the next time they log in.
6. Under Require MFA for, select which services MFA is required for.
7. Save the configuration with Apply.

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 manner first.

If web applications are published via Web Server Protection, an appropriate WAF authentication policy is also required. The process is in Sophos Firewall Secure WAF with MFA.

Prepare for rollout and operations

MFA is not just a switch in the firewall. After activation, login behavior, support questions and emergency access change. Therefore, before the broad rollout, it should be clear who issues tokens, who resets lost tokens and how the reaction will be outside of office hours.

These points have proven useful for operation:

• Test pilot group with real users, not just administrators.
• Document a second admin and break glass access.
• Inform helpdesk about password+OTP behavior.
• Set token reset process for new smartphones or lost devices.
• Check Log Viewer and authentication logs after rollout.
• Test external MFA via RADIUS with realistic timeouts.
• Check Device Access and ACL exceptions regularly.

Especially with remote access, you should test MFA together with the affected VPN rules, user groups and client profiles. A working WebAdmin login does not automatically prove that SSL VPN, IPsec Remote Access or Sophos Connect work the same.

Plan fallback and break-glass

MFA increases security, but can also lock out legitimate admins if the token, time, authentication server or groups do not match. That’s why a fallback plan is needed before activation.

At least these points should be documented:

• Who has a second tested admin access?
• Is access possible from a management network or admin VPN?
• Is the local default admin protected as an emergency account but not used for everyday use?
• How to reset a lost or broken OTP token?
• Who can reset tokens for administrators?
• How do you react outside of office hours?
• Is there a current backup before the change?The fallback must not mean that unprotected admin access remains permanently accessible from the Internet. It is better to have an emergency account with clear documentation, a narrow access path and regular reviews.

MFA for the default admin

The local default user admin is a special case. MFA for this user is not activated directly in the Multi-factor authentication tab.

The menu path is System > Administration > Device access.

There you can activate MFA for default admin. You should only do this if:

• the system time is correct,
• a second administrator was tested,
• access works via a trustworthy management network,
• and it is clear how you can regain administrative access in an emergency.

The following applies to the default admin: Do not deactivate it, do not make it accessible unprotected on the Internet and do not use it as a normal day user. It is a break glass or emergency account.

Other administrators should not assume that they can edit or delete the MFA token of the default admin like a normal user token. This access must be consciously planned and tested via your own device access path.

Set up tokens for users

Once activated, the user needs to set up their second factor. If Generate OTP token with next sign-in is active, the user logs in to the User Portal or VPN Portal and scans the QR code with a Authenticator app.

Suitable apps include:

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

The code generated is time-based. If the time on the firewall or smartphone differs significantly, the login will fail.

If the User Portal is disabled, users may not be able to set up their tokens themselves. In this case, you either have to provide the portal in a controlled manner or prepare tokens administratively.

Token algorithm and app switching

Sophos Firewall supports hash algorithms SHA1, SHA256 and SHA512 for OTP tokens. Old environments can still work with SHA1, but for new rollouts you should prefer SHA256 or SHA512. This must match the Authenticator app used.

These points are important for operation:

• No longer schedule new tokens with old app assumptions.
• Use a Authenticator app that supports the selected hashing algorithm.
• If you change apps or lose your smartphone, delete the old token and have the QR code regenerated.
• Only use hardware tokens if the algorithm, time step and secret can be managed properly.
• Test a pilot group before a SHA256/SHA512 migration instead of switching all tokens at once.

The old Sophos Authenticator app should no longer be scheduled as the new default app. In many environments, Microsoft Authenticator, Google Authenticator, 1Password, Bitwarden, or Sophos Intercept X for Mobile are more realistic options. What is less important is the brand name of the app, but rather whether TOTP, hash algorithm, backup/restore behavior and helpdesk process fit together.

Important note about password and tokens

Depending on the Sophos service, there is no separate form field for the OTP code. This always leads to confusion, especially with the VPN Portal or remote access logins. In these cases, the user often has to enter the password and OTP code one after the other.

Example:

Passwort: MeinSicheresPasswort
OTP-Code: 123456
Eingabe:  MeinSicheresPasswort123456

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

This behavior should be tested and documented before rollout because it is perceived differently depending on the service and login mask.

Test and control operation

A successful WebAdmin test is not enough. Each affected login surface must be tested separately because the portal, VPN client, user group and authentication server may react differently.

Test login

MFA should first be tested with a user who is not the only administrator.

These points should be checked:

• Registration on WebAdmin.
• Registration on VPN Portal.
• Login to the remote access service.
• Behavior in case of incorrect OTP code.
• Behavior after an OTP code expires.
• Access with a user who is not in the MFA group.
• Login with password and attached OTP code.
• Access via scheduled ACL rules.

Only when these tests are successful should MFA be rolled out to other groups.

Test matrix by service

A MFA test should not only consist of a successful WebAdmin login. Depending on the service, other portals, groups, profiles and log files apply. This matrix helps to examine the most important cases separately:

Each test should also check whether Device Access or a local service ACL rule intentionally allows the service. If the token works but the portal is accessible from the wrong network, the MFA configuration is only part of the problem solved.

Logs and operational control

After the rollout, you should check whether MFA events can be traced during operation. This is important for support cases, security reviews and incident response.

Useful checkpoints:- Check for authentication events in the Log viewer.

• Distinguish failed logins from incorrect password, incorrect OTP and expired OTP.
• Document VPN portal and remote access tests with time and user.
• For external RADIUS, also check RADIUS server, NPS logs or identity provider logs.
• For longer storage, plan Central Reporting or Syslog/SIEM.

For local log files and service mapping, Sophos Firewall Troubleshooting: Services and Logs fits. If authentication and portal events are to be evaluated long-term, Sophos Firewall send Syslog to SIEM is suitable.

Troubleshooting

OTP code is not accepted

First check the system time of the firewall and the time of the smartphone. TOTP is time dependent. Even a significant deviation can lead to valid codes being rejected.

You can check issued tokens under Authentication > Multi-factor authentication. If a single token keeps missing the mark, you should not immediately change the entire MFA configuration. First check token time drift, app used, hash algorithm and time step.

User does not see QR code

The user must be eligible for MFA and log in to the correct portal. Additionally, it should be checked whether the user is found via 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 accessible or the token must be created administratively.

Portal cannot be reached through Device Access

If users cannot set up their token even though MFA has been activated correctly, one should not delete the token first. Often the required portal cannot be reached from the current network via System > Administration > Device access or a local service ACL rule.

Check first:

• Which portal is used for token setup?
• What zone or source does the user come from?
• Is access intentionally allowed or accidentally blocked?
• Is there a narrower ACL exception instead of a broad release?

Administrator is locked out

In this case, use the prepared fallback access. If a fallback does not exist, access must be assessed via console, support, or recovery paths depending on the situation.

MFA does not work for remote access

Check whether the remote access configuration uses the same user group for which MFA was activated. Often the error is not with MFA itself, but with different groups in VPN and authentication rules.

Client profiles must also match the current configuration. After making changes to VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO or RADIUS, affected Sophos Connect profiles should be reimported or redistributed.

User only enters the password

If a separate OTP field is not displayed, the user must enter the password and OTP code one after the other. This is one of the most common support cases after activating Sophos OTP.

External MFA does not work reliably

For RADIUS-based MFA solutions, timeouts, challenge behavior and groups must fit neatly. If Push-MFA, Call-MFA or challenge responses are used, you should test the entire login process with the affected client.

MFA was activated for the wrong group

If MFA works for some users and not others, you should compare groups technically first. Not only the visible display names are relevant, but the actually imported or matched groups from AD, LDAP, RADIUS or Entra ID. A user can successfully authenticate and still not end up in the group for which MFA is required.

Operational checklist and recommendation

After technical activation, MFA needs a simple operating process: Who resets tokens, who checks logs and how is it checked that portals are not unnecessarily widely accessible?

Operations checklist

• System time and NTP checked.
• Pilot group defined and tested.
• MFA not directly activated for all administrators at the same time.
• Second admin and break glass access documented.
• Device Access and Local Service ACL tested for WebAdmin, User Portal, VPN Portal and SSL VPN.
• Access from permitted and prohibited source networks tested.
• User informed about password+OTP behavior.
• Token reset process documented for lost smartphones.
• Authenticator app, hashing algorithm and token migration documented.
• Remote Access tested with real clients and current profiles.
• RADIUS/Entra timeouts tested if external MFA is used.
• Logs and central storage checked.

Operating recommendation

MFA should be standard for administrative access. MFA is particularly important for WebAdmin, VPN Portal and all users with remote access authorization.

For small environments, Sophos’ own OTP function is often sufficient. In Microsoft 365 or Entra ID environments, an external MFA over RADIUS may be more convenient because users do not have to learn a second MFA world.

Regardless of the MFA variant, the following applies: first restrict access with ACL rules, test Admin-MFA carefully, inform users about password + token and only then roll it out widely.

FAQ