Sophos Firewall SFOS 22 Upgrade Check: Find Blockers

Before upgrading to SFOS 22, confirm that the platform, upgrade path, and configuration support the target release. This check covers SFOS 22.0 MR2 Build 546 from July 14, 2026 and complements the general Sophos Firewall firmware update guide.

Hard upgrade and restore blockers

• XG or SG hardware: SFOS 22 is not supported. Instead of upgrading, migrate to XGS or to a virtual, software, or cloud platform.
• Legacy Remote Access IPsec: From SFOS 22.0 MR1, the configuration must be migrated or removed before the upgrade.
• Legacy CLI VLAN Tagging on a bridge interface: From SFOS 22.0 MR2, system vlan-tag must be replaced with supported VLAN interfaces.
• Backup with Legacy VLAN Tagging: To restore to SFOS 22.0 GA or later, clean up the source configuration and create a new backup.
• Storage or upgrade path: If the firmware page reports insufficient storage or an invalid upgrade path, resolve the cause first.

If a blocker applies or any point remains unclear, do not start the upgrade.

Direct upgrade path to SFOS 22.0 MR2

For the target covered here, SFOS 22.0 MR2 Build 546, Sophos supports a direct upgrade from the following versions:

• SFOS 22.0: MR1 Build 490 and GA Build 411 or 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261, or GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272, or 237, and GA Build 169
• Older versions: any SFOS 20.0, 19.5, or 19.0 version

⚠️ If the current version is not on this list, do not confirm the warning for an unsupported migration. Otherwise, the firewall restarts with factory settings and the current configuration is lost. A backup can likewise be restored only from a version whose configuration migration is supported.

For an older or unlisted version, a supported intermediate path must be planned first. The version list also does not replace the other checks: platform, storage, legacy dependencies, and the restore plan must all be suitable.

Check before the maintenance window

Platform and legacy dependencies

• Document the model and current firmware so that the upgrade path listed above and a possible restore remain traceable.
• Treat XG and SG hardware as a migration, not a normal upgrade.
• Replace UTM9 SSL VPN tunnels and RED 15, RED 15w, and RED 50 before the upgrade.
• Under Network > Interfaces, correct names that end in ten or more digits. Such names can hide interfaces in WebAdmin after the upgrade.

Storage, backup, and access

Partition usage can be checked roughly in the Advanced Shell:

df -kh

Warnings on the firmware page must be resolved before the upgrade. The reference code identifies what is blocking the upgrade:

• FWDS501: The Primary Disk or one of its partitions is too small for SFOS 22. FWDS501: Enlarge the Primary Disk before SFOS 22 explains how to identify the affected partition and whether the existing installation can be enlarged or the firewall must be redeployed.
• FWDS502: /var does not have enough free space. In 4. Device Console, system firmware check-disk-space shows the required space and the data areas involved. Reports or logs should only be cleaned up in a controlled manner after required data has been secured; the procedure is described under Check disk space and manage reports.
• FWDS503: The /content partition is too small. Sophos requires a factory reset with downtime and loss of the current configuration. After creating a fresh backup and securing the SSMK, enter RESET in uppercase through the serial console and select option 2; this deletes the custom configuration and resets the pattern signatures to the state of the active firmware. Then restore the backup, test the functions, and only then perform the upgrade. Local reports are not restored.
• FWDS504: The SSD firmware is outdated and must be updated before the SFOS upgrade.
• FWDS505: Sophos Support must verify the SSD health. A local SMART check can document values for Support, but it does not clear the blocker.

In an HA cluster, check each node separately because the two appliances may show different reference codes.

Before starting, also ensure the following are available:

• a fresh backup stored externally and the matching Secure Storage Master Key
• local administrator access or alternative access outside the normal VPN path
• a defined fallback path with an owner and decision point
• for HA, a healthy, synchronized cluster with stable HA links and Monitored Ports

Details on backup and recovery are available in Create or restore a Sophos Firewall backup.

Configurations with particular risk

Legacy Remote Access IPsec

From SFOS 22.0 MR1, an existing Legacy Remote Access IPsec configuration blocks the upgrade. Affected users, pools, and profiles must first be migrated to the current Remote Access IPsec configuration, SSL VPN, ZTNA, or another suitable design. The procedure is described in Migrate Legacy Remote Access IPsec before SFOS 22 MR1.

Policy-based IPsec and NAT

Production policy-based Site-to-Site tunnels should be checked before and after the upgrade with a specific test flow. This includes Source, Destination, Service, Traffic Selectors, the peer, and the expected firewall and NAT rule. For problems, see IPsec VPN troubleshooting and Understand NAT on Sophos Firewall.

SMTP via DNAT

If an internal mail server is published via DNAT, the maintenance plan should include several actual incoming test messages, not just a port test. Under NC-184583, Sophos lists sporadically dropped SMTP connections after an upgrade to SFOS 22.x; GA Respin Build 411 is explicitly listed as affected, and there is no public workaround. The exact version scope, evidence collection and Support escalation are described under Publishing a Server via DNAT on Sophos Firewall.

Legacy VLAN Tagging on bridges

Legacy CLI VLAN Tagging on bridge interfaces has three consequences:

• On GA and MR1, traffic from or to the firewall can fail while transit traffic continues.
• From MR2, the upgrade is blocked.
• An affected backup cannot be restored to SFOS 22.0 GA or later.

Before cleanup, document the bridge, VLAN IDs, IP addresses, zones, switch trunks, and dependent services. Then create supported VLAN interfaces with the bridge as Parent and generate a new backup. The special case is described in Check Sophos Firewall bridge VLANs before SFOS 22.

STAS

For an upgrade to MR1, set Restrict client traffic during identity probe to No under Authentication > STAS. MR2 fixes the MR1 issue and uses No as the default for new configurations; existing values and user-based rules should still be checked. See Configure STAS on Sophos Firewall for details.

Maintenance window and validation

• Before: Rule out blockers, have the backup and SSMK available, check HA synchronization, and document VPN, test, and fallback paths.
• During: Do not make parallel changes to routing, VPN, or switching; monitor status and HA failover.
• After: Check firmware, interfaces, internet access, firewall rules, VPN, NAT, HA, STAS, DNS, DHCP, Central, and Log Viewer.

A green tunnel or a successful Policy Test does not prove that production traffic works. Test critical connections with real packets, Log Viewer, Packet Capture, and the Firewall and NAT Rule ID. When problems occur, do not change several areas at the same time.

The upgrade is complete when the defined tests succeed and the target version, HA status, test results, and outstanding follow-up work have been documented.

FAQ