Set up Sophos Firewall administrators and profiles securely

For day-to-day administration, each person should have their own account. First, create a suitable Device access profile, then add a local user with User type: Administrator under Authentication > Users. The profile determines what the administrator can view or change. MFA, login sources, and Device Access also protect the login and restrict WebAdmin access.

Keep the default administrator admin as a tested emergency account rather than using it as a shared day-to-day login. This keeps changes attributable to individuals and prevents an error in a restricted profile from blocking the final recovery path.

Set up a local administrator in eight steps

1. Check the backup, default administrator, and recovery access. Keep an existing admin session open until the test succeeds.
2. Document the role and required permissions, for example diagnostics only or also changes to network objects.
3. Create a custom profile under Profiles > Device access > Add and leave unneeded areas set to None.
4. Under Authentication > Users > Add, enter a personal username and set User type to Administrator.
5. Assign the new profile, a strong unique password, and the business email address.
6. Under Administrator advanced settings, restrict Schedule for device access and Login restriction for device access where appropriate.
7. Verify that Local remains available under Authentication > Services > Administrator authentication methods. Then configure MFA and WebAdmin access from the management network.
8. Test the account positively and negatively in a private browser window. Only then migrate more accounts or deactivate old access.

⚠️ Do not use a new profile in production until a second working administrator and a documented recovery path are available. The built-in Administrator profile grants full access and should be assigned only to the smallest necessary group.

Understand the five protection layers

Several settings work together for administrator access. They serve different purposes and do not replace one another:

• User account: Identifies the person. Personal accounts make changes traceable; team accounts such as firewalladmin obscure attribution.
• Device access profile: Uses None, Read-only, and Read-write to define which menus and functions are visible or editable. The permissions also apply to the API. None prevents the administrator from viewing the relevant configuration in WebAdmin or retrieving it through the API. Read-only, by contrast, allows reading but not changes.
• Schedule and Login Restriction: Limit when and from which IPv4 addresses this specific administrator account can use WebAdmin.
• Device Access and Local Service ACL: Define the zones and sources from which WebAdmin is reachable at all. Configure Device Access and Local Service ACL securely explains the implementation.
• MFA and Audit Trail: MFA adds protection beyond the password. Audit Trail helps attribute supported changes to an identity, source, and console. Data Anonymization in logs and reports additionally requires at least two personal authorizers with separate accounts.

A read-only profile, for example, does not protect against password theft. MFA, in turn, does not prevent attacks against an unnecessarily public login page. Only the combination reduces both permissions and attack surface.

Login disclaimers and customized messages only add visible notices to these layers. Acceptance extends neither the Device Access profile nor the network authorization and replaces none of the five controls.

Default admin, local accounts, and central identities

The default admin user has the permissions of the built-in Administrator profile. It is suitable as a local emergency account, but not as a shared day-to-day account. Its password, MFA, console access, and recovery procedure must be documented and tested independently of personal accounts.

During first-time configuration, the factory password of the default super administrator must be changed. The new password must not be a commonly used password or a dictionary word: the firewall checks it against a corresponding database and prompts for a change if it finds a match. This screening is already part of initial setup, not only the creation of personal accounts.

When upgrading from 18.0 MR3 or earlier or 17.5 MR14, a one-time password change for the default super administrator is required to benefit from stronger password protection. This is not a universal requirement for every firmware upgrade.

Store the current password in an access-controlled password vault. If you move to an earlier firmware version that uses this password, you will need it to sign in there. Before a firmware rollback, ensure that the password needed by the earlier version and independent recovery access are available; do not assume that the password most recently set in the newer firmware also applies there.

Personal local administrators suit small teams, isolated firewalls, and a deliberate fallback. Larger teams can manage admin roles through Microsoft Entra ID SSO for WebAdmin, TACACS+ with local profile assignment, or Sophos Fusion administration roles. A user marked Managed by Central under Authentication > Users is managed in Sophos Fusion and cannot be edited locally.

For SFOS 23, Google Workspace OIDC with admin group mapping describes another centralised sign-in option with a separate service account, local Device Access profiles, and rollback planning and verification.

Automations do not receive a personal day-to-day account. Use a separate service account for the XML API, with its own owner, limited permissions, and a fixed source allowlist. Secure Sophos Firewall XML API access covers the complete protection path.

Plan the Device access profile

Sophos provides several non-editable standard profiles under Profiles > Device access:

• Administrator: Full access to WebAdmin and the API. Sophos also describes the profile as having full CLI access; however, direct SSH login in SFOS still accepts only the default username admin.
• Audit admin: Read and write access to logs and reports.
• Crypto admin: Read and write access to security certificates.
• HAProfile: Read-only access to the Auxiliary Appliance in an HA cluster.
• Security admin: Write access to functions except profiles, logs, and reports.

These profiles are useful starting points, but they are not automatically the right roles for every environment. A custom profile is better when a person needs only a clearly limited area of responsibility.

Derive permissions from the role

The profile name alone has no technical effect. A profile named ReadOnly can still contain write permissions. What matters is the full permissions matrix, including expanded submenus.

For example, a help desk account can be planned as follows:

• Set diagnostics, logs, and the configuration areas required for support to Read-only.
• Grant Read-write only if the team must perform a specifically named change itself.
• Leave administrator profiles, certificates, and all unneeded product areas set to None.
• For every write permission, define one example of what should be allowed and one example of what must explicitly remain prohibited.

A network operations profile can have broader read access and, for example, change selected network areas. It still does not need full access to administrators, certificates, or other independent security functions. Least privilege does not mean showing as few menus as possible, but granting exactly the permissions required for the assigned role.

Create a custom profile

1. Open Profiles > Device access.
2. Select Add.
3. Enter a unique name, for example SFOS-NOC-Limited.
4. Select None, Read-only, or Read-write for every visible menu.
5. Use Expand to open the submenus and restrict differing permissions more precisely.
6. Select Save.
7. Recheck the profile against the documented tasks and negative tests.

SFOS-NOC-Limited is only an example name. Adapt it to the team and role. Also document the permissions that were actually assigned, because the name does not explain the permissions matrix.

Change existing permissions without locking yourself out

To inspect an existing profile, open Profiles > Device access and select Edit for that profile. Use Expand to open the submenus and see the complete existing permissions matrix; when only inspecting it, do not change or save any permissions. Standard profiles remain non-editable: Edit only lets you inspect them, and permissions can be changed only in custom profiles.

A profile change affects every administrator assigned to that profile. Before tightening it, document the current profile name, the complete expanded permissions matrix, and every assigned account. The prior state also includes the order under Authentication > Services > Administrator authentication methods, the schedule, login restriction, WebAdmin allowances under Administration > Device access, and the current password-complexity and Block login values. A current configuration backup, an open session for a second full administrator, and tested console access are prerequisites, but they are not the rollback itself.

Rather than editing a shared profile in place, create the more restrictive profile separately and assign it to exactly one pilot account first. Move additional accounts one at a time only after the positive test, negative test, and audit check. An error then cannot affect all administrators at once.

The safe rollback uses the still-open full-admin session to restore the exact documented previous values: reassign the pilot account to its former profile and return any changed authentication methods, ordering, schedule, login restriction, Device Access, or lockout values to their respective prior state. If that session is no longer usable, use the pretested second administrator or local console. Restore a complete backup only in a planned recovery window because it also rolls back unrelated changes.

Create a personal local administrator

Enter the user details

1. Open Authentication > Users.
2. Select Add.
3. Under Username, enter a permanent personal name, for example m.mueller. SFOS stores it in lowercase and automatically converts uppercase letters; the username cannot be changed later.
4. Enter a clear display name and the business email address.
5. Set User type to Administrator.
6. Under Profile, select the previously tested SFOS-NOC-Limited profile.
7. Set a long, unique password and transfer it securely. If the firewall detects a commonly used password or dictionary word, it requires a stronger password.

m.mueller is an example and must be replaced with the unique identity of the responsible person. Functional names such as noc-admin should be used only when they represent a single technical identity with its own owner. Multiple people must not share a password.

Restrict time and login source

Two additional controls are available under Administrator advanced settings:

• Schedule for device access: Allows WebAdmin logins only during the selected schedule. This suits temporary support or defined operating hours. For an on-call service, the schedule must not unintentionally block necessary emergency work.
• Login restriction for device access: Allows WebAdmin login only from selected IPv4 addresses or an IPv4 range. For an admin jump host, for example, 10.20.30.25 can be used as the Selected node.

The address 10.20.30.25 is an example from a private network. Replace it with the fixed address of the relevant jump host or management workstation. For changing client addresses, an admin VPN or dedicated management network is usually cleaner than a large IP range.

Access Time for regular users and groups controls internet access, while Schedule for device access controls WebAdmin access under Administrator advanced settings. These are not the same setting.

Keep local authentication available

Under Authentication > Services > Administrator authentication methods, the local database must be selected for personal local administrators. The default super administrator admin is exempt from this methods list, but newly created local administrators are not.

Do not remove the local method until the new account has been tested successfully in a separate browser. With external authentication servers, the order determines where a login attempt is sent first. Changes to this order therefore belong in the same acceptance and rollback plan as the account itself.

Secure MFA and restrict access

MFA should be enabled for interactive administrators. Add personal administrators under Authentication > Multi-factor authentication for Web admin console. The default admin user has a separate setting under Administration > Device access > MFA for default admin. Enable MFA for Sophos Firewall WebAdmin explains pilot groups, token registration, login security, and recovery. Test MFA with one new administrator first, not with all accounts at the same time.

WebAdmin also remains restricted to management networks, VPN, or narrowly defined sources. An active Login restriction for device access does not make broad WAN access safe. Conversely, a Local Service ACL does not replace a personal account and its permissions profile.

A successful WebAdmin test does not enable SSH. SFOS accepts only the username admin for direct SSH login, so a personal local WebAdmin account is not tested as an SSH account. SSH also requires a separate Device Access decision. Public-key management for the default admin and secure SSH access are covered separately in Connect to Sophos Firewall using SSH.

Under Administration > Admin and user settings, there are two separate sections: Administrator password complexity settings for administrators and User password complexity settings for users. Select Enable password complexity check separately in each section and specify the required complexity. The administrator setting does not replace the user setting. Choose values according to your password policy; no fixed minimum length or character count is presented here as a product requirement. Before a change, document both settings and their previous values. After saving, reopen the page and check both sections separately while keeping tested recovery access available.

Under Administration > Admin and user settings, Administrator password complexity, the session timeout, and Block login complement the account settings. These values apply system-wide and should therefore not be tightened aggressively for one account. Before a change, record the checkbox state, failed-attempt count and time window, and block duration exactly; also keep a second management source or console access available. Once the threshold is reached, Block login blocks the source IP for all services, so the web admin console, CLI, VPN portal, and user portal no longer open from that address. One failed attempt below the threshold doesn’t test this blocking behavior; Sophos also states that a failed CAPTCHA doesn’t count as a failed sign-in attempt. In production, first verify only that the values were saved and valid sign-ins still work from both management sources. If an actual lockout test is required, run it in a maintenance window from an isolated test source until the threshold is reached. Then verify the expected block, wait for the documented block duration or use the independent recovery path, and confirm a valid sign-in afterwards. If behavior is unexpected, use the open recovery session to restore the recorded prior values exactly.

Log out admin session after ends inactive WebAdmin sessions after 10 minutes by default. Clearing the option doesn’t keep the session open indefinitely: SFOS still signs it out automatically after 30 minutes. Clearing the option is therefore not a method for permanent admin sessions; verify the actual behavior with a test session.

Test permissions and login safely

Keep the existing admin window and an independent recovery path available during testing. Repeated intentional failed logins are unsuitable because Block login can temporarily block the shared source IP for other login services.

1. Open a private browser window and access WebAdmin through the intended FQDN from the allowed management network.
2. Sign in with the new account and MFA.
3. Check that all required menus are visible and the intended information can be read.
4. If the profile includes write permissions, make a harmless, pre-approved test change with an immediate rollback.
5. Open an area set to None or Read-only. The account must not be able to save a prohibited change there.
6. Test a controlled login from a disallowed source no more than once. If the result is unclear, evaluate the settings and logs first rather than generating more failed attempts.
7. Check the test change and the administrator used in the Configuration Audit Trail. Not every object produces the same level of detail there; also verify the technical effect in the affected function.
8. Sign out, sign in again, and only then migrate the next account.

In an HA cluster, also test a fresh login to the now-active node after a planned failover. An existing WebAdmin session or its seamless continuation is not a reliable success criterion. Logs and reports aren’t synchronized between HA devices, so check Log viewer > System and the relevant authentication events on both devices during troubleshooting.

Firmware acceptance is also part of the SFOS 22.0 check. Since 22.0 MR1, changes made to a single firewall through Sophos Fusion (formerly Sophos Central) record the Sophos Fusion user identity in the firewall Log Viewer and in Sophos Fusion; Entra ID SSO sessions also re-evaluate Conditional Access policies. Verify this attribution with a harmless test change after an update. Before every rollout, check the target build, supported upgrade path, and version-specific blockers in the SFOS 22 upgrade check and approve them in the change; its release and known-issue review governs the rollout decision.

A visible menu does not prove that write access works. A hidden menu does not prove that other assigned functions are correct. Positive testing, negative testing, and audit attribution therefore belong together.

Review and remove accounts safely

Regularly review administrator access against its owner, role, profile, MFA, login source, and last use. Temporary support accounts also require a documented end date. For a time-limited Avanet case, follow the dedicated procedure in Set up Avanet support access on Sophos Firewall.

Distinguish this from the vendor access under Diagnostics > Support access. It generates an access ID for the selected duration, allowing Sophos Support to reach WebAdmin and the shell without receiving administrator credentials. The firewall establishes this connection over TCP 22 to *.apu.sophos.com; upstream systems must permit that path. Share the access ID only through the active support case, monitor the status during the work, and turn off Support access immediately afterwards, even if the selected duration hasn’t expired.

For offboarding, a controlled process is safer than immediate deletion:

1. Check whether the account is used in API scripts, password vaults, documentation, or support processes.
2. Under Authentication > Users, set the status to inactive.
3. In a private browser, verify that a new login is no longer possible.
4. Review active WebAdmin sessions and recent changes separately. Do not treat deactivation as proof that every existing session ended immediately.
5. Remove or rotate MFA tokens, secrets, and external assignments associated with the account.
6. After the agreed observation period, delete the user if no dependency remains.
7. Delete an unused custom profile only after it is no longer assigned to any administrator.

The default administrator remains outside this normal offboarding process. If its password or MFA access is lost, Recover the Sophos Firewall admin password helps prepare the recovery path.

Troubleshoot common problems

The account exists, but WebAdmin login fails

Check these points in order:

• User type is actually set to Administrator.
• The user status is active and the password is correct.
• Local is selected under Administrator authentication methods.
• Schedule for device access allows the current time.
• Login restriction for device access includes the actual IPv4 source address.
• The MFA token, system time, and registration are correct.
• Block login has not blocked the source IP after failed attempts.
• Device Access or a Local Service ACL allows HTTPS from this source.

If the login page is not reachable at all, start the analysis with Device Access, routing, and the source address. If it is reachable but rejects only this account, investigate the user, profile, authentication method, schedule, login restriction, and MFA first.

For time correlation, use the Authentication section in Log Viewer and access_server.log for authentication and authorization. syslog.log provides additional system and admin-triggered events. Changes to supported objects are checked separately in configuration-audit.log.

The account sees too much or too little

Check the assigned profile and its expanded submenus. Read-only and Read-write can be set differently within one main menu. Then test again with a new login rather than relying only on the profile name.

For Managed by Central, the role comes from Sophos Fusion and is not changed on the local user. With Entra SSO, the role or group mapping of the Entra server determines the local Device access profile.

WebAdmin works, but the API or SSH does not

The Device access profile also applies to API permissions, but the API additionally requires API access to be enabled and the source to be allowed. SSH is a separate local service and is not an appropriate success test for a restricted WebAdmin profile. An account does not receive SSH access merely because WebAdmin login works.

NC-177609 is documented specifically for SFOS 22.0 GA Respin Build 411: after an upgrade, API-based configuration changes by a migrated user can be rejected when MFA is active and the request doesn’t include a one-time token. If the symptom matches exactly, record the build and the account’s migration status. The documented workaround requires automation to use a dedicated least-privilege API account with MFA disabled or with an explicit MFA exclusion; MFA remains enabled for interactive administrators. The designated API owner must approve and document this exception, assign an account owner and review date, restrict the source and API permissions, vault and rotate the secret, monitor use, and remove the exception when it is no longer required. After the change, validate with a harmless read request and then an approved controlled write operation with rollback. Secure Sophos Firewall XML API access, together with the designated API owner, owns this workflow; do not infer fix status from a later build.

Operations checklist

• The default administrator and recovery path are tested and not shared.
• Each person uses a separate account.
• Profiles are derived from roles, and expanded submenus have been reviewed.
• Full access is limited to the smallest necessary group.
• MFA, schedule, and login source suit the intended use.
• WebAdmin is reachable only from the intended management sources.
• Positive and negative permission tests have been completed.
• Changes can be attributed to a personal administrator in the Audit Trail where supported.
• The prior state and cross-account rollback for profile, authentication, and lockout changes are documented.
• In HA, a fresh login and separate logs on both devices have been checked.
• API and support accounts have their own owners and lifecycles.
• Offboarding covers status, sessions, MFA, secrets, and dependencies.

FAQ