Perform a Sophos Firewall Firmware Update

This article shows how to perform a Sophos Firewall firmware update: obtain the image, install it in WebAdmin, schedule an update through Sophos Central, and roll back to the previous firmware if necessary.

The upgrade path, backup, HA status, test plan, and rollback criteria should already be clear. See Sophos Firewall Firmware Update: Preparation and Best Practices. Before moving to SFOS 22 or later, also complete the SFOS 22 upgrade check.

⚠️ Check the platform: SFOS 21.0 GA and later versions no longer support XG and SG hardware appliances. For these devices, determine before the update whether a migration to XGS Appliance is required.

Firmware update in seven steps

1. Check the active version, target version, and supported upgrade path.
2. Create a fresh backup and have the Secure Storage Master Key available.
3. Under Backup and firmware > Firmware, check the active and inactive firmware slots.
4. Download the target version directly or upload a suitable image.
5. Start the version change with Install or Upload and boot.
6. After the restart, check the active version and, for HA, both appliances.
7. Verify WAN, VPN, DNS, NAT, published services, and logging with real tests.

The firewall terminates existing sessions and restarts when changing versions. A maintenance window is also required for HA because individual sessions, VPN tunnels, or pings may be briefly interrupted during failover.

Check before starting

Before uploading, confirm at least the following:

• The current version, target version, and supported upgrade path are documented.
• A current firewall backup, backup password, and Secure Storage Master Key are available.
• HA status and synchronization are healthy if a cluster is used.
• Remote sites have an alternative access method, such as a local contact, out-of-band access, or management VPN.
• The release notes and Known Issues for the target version have been checked for relevant platform, VPN, interface, and migration notes.

Moving from SFOS 19.0 MR1 or later to another firmware version requires Enhanced Support or Enhanced Plus Support for unlimited changes. Without this subscription, three firmware upgrades to GA, MR, or EAP releases are free. After that, firmware can still be downloaded but not installed; Install is disabled. Moving to 19.0 MR1 itself, Pattern Updates, hotfixes, reimaging, and Mandatory or Assistant Firmware Upgrades are exempt.

Sophos Firewall shows no more than two firmware versions: one active and one inactive. The inactive version is either the previous version or a compatible image uploaded manually. Each partition has its own configuration. A later rollback therefore also activates the configuration of the previous partition.

Don’t confuse the configuration language with the WebAdmin language

On the same page, SFOS 22 provides a configuration language selector under Factory reset with default configuration language. This sets the language of the default objects in the configuration database, not the display language of the WebAdmin interface.

⚠️ Warning: Clicking Apply resets the firewall to factory settings and removes the custom configuration and Secure Storage Master Key. Keep the key available for a later restore or import. A backup is still required as a recovery path, but it can’t be used to combine the existing configuration with the new language: restoring the backup also restores the configuration language stored in it. This selection therefore belongs in the initial deployment, not in a normal firmware maintenance window.

Obtain SFOS firmware

For registered firewalls, Sophos Central is the safest starting point: Open Licensing > Firewall licenses from the profile menu, expand the firewall, and select its assigned firmware under Downloads. Other downloads opens packages for the other platform types. This selection doesn’t replace the upgrade-path check, but it reduces the risk of choosing a package for the wrong appliance class.

Official download pages:

• Hardware appliances: SFOS firmware for hardware appliances. In the filename, SF300 identifies the XG series and SF310 the XGS Appliance series. An SF300 package is only suitable for a firmware release that still supports XG; it doesn’t make SFOS 21 or later compatible with XG.
• Software appliances: SFOS firmware for software appliances. These packages start with SW- and contain the platform identifier SFW. They are for an installation with a software-appliance license, not a virtual or cloud appliance.
• Virtual and cloud appliances: SFOS firmware for virtual and cloud appliances. These packages start with VI-; the identifier before the build number must match the environment: AMI for AWS, AZU for Azure, HYV for Hyper-V, KVM for KVM, VMW for VMware, and XEN for Xen.

Before downloading, record the active version and verify it separately against the supported upgrade path. Then check three values in the filename: target release, exact build number, and platform identifier. For example, HW-22.0.2_MR-2.SF310-546.sig is an XGS Appliance package for SFOS 22.0 MR2 Build 546. If the same release has multiple builds, use the build approved for the planned upgrade path—not the modification date or simply the highest number. The public directories don’t validate the model, license, or upgrade entitlement; these details must agree with Licensing > Firewall licenses, the running system, and the release notes.

After downloading, compare the locally calculated SHA-256 checksum character for character with the Checksum column in the same directory. If it differs, delete the file and download it again. The checksum detects transfer errors, but doesn’t authenticate the source by itself.

Do not bypass image verification: SFOS verifies the unchanged .sig package before installation, upgrades, and downgrades, including in air-gap environments. The digital signature using RSA and SHA-512 confirms the source and integrity; SFOS also checks the package internally with an MD5 checksum. MD5 replaces neither the SHA-256 transfer check nor signature verification. Therefore, don’t rename, modify, or repackage a rejected image. Download it again from an official Sophos source and verify the platform, license, build, and upgrade path.

Before uploading, the platform, appliance series, active version, and target path must match the image. Incompatible images are rejected. An incompatible version change requires a reimage; automatic rollback isn’t available for an unsupported upgrade path.

Manual upload is also suitable for air-gapped environments. License synchronization and Pattern Updates remain separate operational processes, as described in Sophos Firewall air-gap licensing and Pattern Updates.

An unclaimed software, virtual, or AWS/Azure BYOL firewall must first be claimed in Sophos Central before moving to SFOS 22.0 or later. Then verify the supported upgrade path and the version that is actually active; claiming alone does not enable Central Management.

Install firmware manually

1. Sign in to Sophos Firewall WebAdmin.
2. Open Backup and firmware > Firmware.
3. Under Firmware, select Upload next to the inactive firmware version.
4. In the pop-up window, select the appropriate image from the administrator’s endpoint.
5. Select Upload firmware to stage the image without starting it.
6. Select Upload and boot when the maintenance window is active and the restart should begin immediately.

The three actions differ significantly:

• Upload firmware: Loads the image into the inactive slot without starting it. A later restart for another reason also won’t switch automatically to this version.
• Upload and boot: Uploads the image, terminates existing sessions, and immediately starts the firewall with the new version.
• Boot firmware image: Starts a compatible version already present in the inactive slot. It boots that exact version, not automatically the latest available version.

Boot with factory default configuration isn’t a rollback action. It also closes all sessions, but starts the selected firmware with factory settings and removes the custom configuration. Although this action doesn’t clear the Secure Storage Master Key, use it only as part of a planned recovery procedure with a verified backup and management access—not for a normal update.

Firmware update in an HA cluster

HA doesn’t need to be disabled before the update. On a connected cluster, start the process on the Primary: The Auxiliary appliance is updated and restarted first, followed by failover and then the update of the former Primary. If a Preferred Primary is defined, a failback may occur at the end.

Don’t update the Auxiliary appliance separately. An HA device in standalone mode can’t be updated through the normal cluster process. Roles, HA link, and synchronization must therefore be clear before starting. Pattern Updates are updated on the Primary and then synchronized to the Auxiliary. Sophos Firewall HA clusters: variants and maintenance explains additional special cases.

Update directly in WebAdmin or through Central

Update directly in WebAdmin

With a valid entitlement, the firewall can download available firmware directly:

1. Open Backup and firmware > Firmware.
2. Under Latest Available Firmware, select Check for new firmware.
3. Select Download for the required version.
4. After the download, start Install.
5. Wait for the restart and sign in again.
6. Check the active version in the upper-left corner of the Control center and under Backup and firmware > Firmware.

Schedule firmware through Sophos Central

Sophos Central shows a blue arrow icon when a firmware update is available. Only target versions that have reached Available to all in the release process can be installed through Central.

1. Open My Products > Firewall Management > Firewalls.
2. Select the blue arrow icon for the firewall, then select Schedule upgrade.
3. If several versions are offered, select the target version.
4. Select Immediately or At and, for At, set the date and time.
5. Select Schedule upgrade. If a recurring firmware schedule already exists, override it or skip an occurrence for the individual firewall instead.

Central uses the timezone configured on the firewall. Five icons next to the firmware version show its status:

• Blue arrow: Update available.
• Gray clock: Update scheduled.
• Blue spinning circle: Update in progress.
• Green tick: Update successful.
• Red warning: Update failed.

Click the icon to see details or the version number to open the update status. Firmware updates appear neither in the Task Queue for group policies nor in the Firewall Task Queue for MDR and API jobs. Even after a green tick, check the active version locally in WebAdmin. If an automatic rollback occurs, Central shows a corresponding message next to the firmware version.

Missing action or failed update

• Install is disabled: Check whether the three free firmware upgrades have been used and whether Enhanced Support or Enhanced Plus is active.
• Central doesn’t show the blue arrow icon: Check the online and management status, entitlement, platform, and available target version. For a new release, Available to all may not yet have been reached.
• Central update doesn’t run despite being scheduled: Open the status icon and check locally whether the previous version remains active. Then rule out the timezone, Central management status, Available to all, upgrade path, local warnings, and an automatic rollback. On SFOS 21.5.1 MR1 Build 261, NC-181150 can temporarily prevent the firewall from receiving firmware metadata while other Central services continue to work. In this case, start the update again in Central or local WebAdmin; several attempts may be required. Sophos doesn’t name a fix version, only reliability improvements from SFOS 22.0 MR1. A missed update on another version doesn’t prove this issue.
• The upload is rejected: Check the platform type, appliance series, upgrade path, and file integrity. An incompatible change requires a reimage instead of another upload attempt.
• SFOS reports too many configured gateways: A firmware change is blocked when the number of gateways exceeds the maximum supported by the firewall. Before deleting anything, document dependencies in SD-WAN routes, static routes, VPNs, and failover configurations. Remove only gateways that are demonstrably unused in a controlled manner; if there is no safe replacement path, stop the change.
• Upload or installation fails despite a suitable image: Check free disk space and, for HA, the synchronization status of both appliances. Don’t upload the same image repeatedly before identifying the cause.
• The firewall rolls back automatically: Starting with SFOS 20.0, this happens for certain configuration migration errors. An alert appears locally in the Control center along with a log entry; a Central update also shows a message next to the firmware version. The local rollback alert is only visible for a migration from SFOS 19.5 MR2 or later; with an older source version, its absence does not disprove the rollback. The migration.log and migrationhash.log files are particularly relevant for identifying the cause.
• WebAdmin remains unreachable because of corrupt firmware: On an appliance with the loader, the SFLoader recovery procedure may be required. XGS Appliance doesn’t support SFLoader; for these devices, reimaging with a USB flash drive is the intended recovery path.

Don’t repeat an automatically rolled-back update without investigating the cause. Save the migration logs and involve Sophos or partner support if the findings are unclear.

This protection doesn’t apply to every update path. It is available for manually uploaded firmware, when checking for a new version locally, and for HA updates. However, there is no automatic rollback when the latest firmware is installed from the setup assistant or when a Mandatory Firmware Upgrade is performed. The same applies to an unsupported source version or upgrade path. In these cases, secure the backup, management access, and recovery path independently before starting.

Check after the update

After restarting, first check the expected active version under Backup and firmware > Firmware. Then verify the following with real connections:

• WAN uplinks, default gateway, SD-WAN routes, and key interfaces.
• HA status, roles, and synchronization.
• Site-to-site VPN, Remote Access VPN, and RED connections.
• DNS, DHCP, NAT, WAF, and important firewall rules.
• Web access, TLS Inspection, authentication, and published applications.
• Pattern and hotfix status match the expected state.
• Sophos Central synchronization, monitoring, Syslog, and SIEM data.

The tests should record more than “reachable” or “unreachable.” One adaptable outbound test is a client in the internal production network resolving a known DNS name and then opening an approved HTTPS site. Expect a DNS response, a successful TLS connection, and matching Log Viewer entries. Test a published application from an external connection so that you don’t accidentally validate only an internal hairpin path. Adapt the source network and destination to your environment, and record the timestamp and expected result in the test plan beforehand.

If only one rule, NAT rule, or WAF publication is affected, first use Log Viewer, Policy Test, Packet Capture, and the relevant service logs. See Test a firewall rule with Log Viewer, Policy Test, and Packet Capture and Sophos Firewall troubleshooting: services and logs.

Roll back to the previous firmware

A rollback starts the previous compatible firmware in the inactive slot and activates its associated configuration. Open Backup and firmware > Firmware and select the rollback or Boot firmware image icon for the previous firmware version. Configuration changes made since the upgrade may be lost. Until the go/no-go decision, make only unavoidable changes and document them separately. A rollback is no substitute for a backup or restore.

• Rollback: Move to the previously installed compatible firmware and its configuration.
• Downgrade: Move to an earlier compatible version that isn’t necessarily the direct predecessor.
• Reimage: Reinstall Sophos Firewall OS and then restore the configuration.

A rollback is appropriate when WAN, HA, key VPNs, or business-critical publications can’t be stabilized within the defined analysis window. For a single rule or external service, targeted troubleshooting is usually better. A user interface that only appears slow isn’t sufficient reason for a rollback.

Before selecting the action, document the active and new firmware versions, time, symptom, affected services, HA status, and tests already performed. This makes it clear later why the rollback was performed and which cause still needs investigation.

In an HA cluster, the same inactive firmware must be present on both appliances. Alternatively, disable HA and roll back each device separately. If the previous version wasn’t configured for HA, both devices start in standalone mode after the rollback and HA must be configured again.

After the rollback, recheck the active version, WAN, VPN, HA, rules, NAT, WAF, DNS, DHCP, Central synchronization, and logging. Then document the cause and the next maintenance window.