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.
• 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.

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 Central administration roles. A user marked Managed by Central under Authentication > Users is managed in Central and cannot be edited locally.

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.

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. 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, 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 the sake of a single account. In particular, Block login can block the source IP for all login services after failed attempts; a second management source or console access must be available before testing.

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.

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.

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 Central 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.

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 permissions tests have been completed.
• Changes can be attributed to a personal admin account in Audit Trail where supported.
• API and support accounts have their own owners and lifecycles.
• Offboarding covers status, sessions, MFA, secrets, and dependencies.

FAQ