Sophos Firewall Firmware Update: Preparation and Best Practices

A Sophos Firewall firmware update should only be approved once the upgrade path, backup, access, system health, HA, and recovery path are clear. Perform a Sophos Firewall firmware update explains the actual installation in WebAdmin or through Sophos Fusion (formerly Sophos Central).

⚠️ Before every update: A current backup, the Secure Storage Master Key belonging to that backup, and a specific rollback plan must be available. For SFOS 22 or later, also complete the SFOS 22 upgrade check.

Approval in ten points

A firmware change is ready when all ten questions can be answered with yes:

1. The current version, target version, and supported upgrade path are documented.
2. The release notes and known issues have been checked for the platform and configuration in use.
3. The license and support entitlement permit the installation.
4. A fresh backup, backup password, and matching Secure Storage Master Key are available.
5. Free storage, system health, and, for affected XGS Appliance models, the SSD firmware meet the requirements.
6. HA status, roles, and synchronization are healthy; both nodes meet the requirements.
7. The maintenance window, owners, cutoff time, and rollback criteria are defined.
8. Local or alternative management access is prepared.
9. Tests for WAN, VPN, DNS, NAT, WAF, authentication, and critical applications are defined.
10. Monitoring, communication, and change evidence are prepared.

If one of these points is missing, do not start the update under time pressure. Postponing a maintenance window is cheaper than an unplanned reimage or on-site visit.

Check the version, platform, and entitlement

A fixed operating process checks at least once a month in Sophos Fusion or under Backup & Firmware > Firmware whether an update is available. New release notes and announced maintenance releases must also be monitored actively. Every MR belongs in the update plan because even a maintenance-only release can contain important security fixes. Installation, testing, and rollback still take place in a controlled maintenance window.

Release notes and upgrade path

Before the change, compare the current SFOS version, target version, and supported path in the release notes. Also review the known issues for the platform, HA, VPN, routing, authentication, and the features actually in use.

Sophos Firewall may display a warning for an unsupported migration path. If the change is confirmed anyway, the firewall can start with the factory configuration and lose the existing configuration. Automatic rollback does not protect an unsupported upgrade path. Use only an approved path; for an incompatible version change, a reimage followed by a restore is the proper method.

⚠️ Platform limit: SFOS 21.0 GA and later versions do not support XG and SG Series hardware appliances. For these devices, plan a migration to XGS Appliance before upgrading.

The SFOS 22 upgrade check records the direct source versions and blocker interpretation for SFOS 22.0 MR2 Build 546. Treat that matrix as build-specific, not as a universal SFOS 22 path; for any other target build, verify its supported source versions and applicable blockers in the current release notes immediately before the change.

Explicitly rule out two hard SFOS 22 blockers:

• SFOS 22.0 MR1 and later: Remaining legacy remote access IPsec configuration blocks the upgrade. Resolve the old configuration using Sophos’s current migration guidance; merely disabling it is not sufficient approval.
• SFOS 22.0 MR2 and later: Legacy VLAN tagging configured through the CLI on bridge interfaces blocks the upgrade. Identify affected bridges and resolve the legacy configuration according to the release notes first.

The separate upgrade check covers other SFOS 22 topics such as storage requirements, interface names, STAS, SSD firmware, and platform support. For other target versions, use their current release notes.

⚠️ Before the first upgrade to SFOS 21 or later: Go to Certificates > Certificate authorities and search for the reserved Let’s Encrypt CA names. An existing entry with exactly the same name can stop the migration because of NC-146082. Don’t delete the CA blindly; first secure and check the backup, private key, dependent certificates, and services.

License and support

Starting with SFOS 19.0 MR1, three free moves to GA, MR, or EAP versions are available without Enhanced Support or Enhanced Plus Support. Afterwards, the firmware can still be downloaded but not installed; Install is disabled.

Pattern updates, hotfixes, reimages, mandatory firmware upgrades, and assistant firmware upgrades are exempt from this support rule. Before the maintenance window, still verify that:

• Administration > Licensing shows the expected license and support entitlement.
• Sophos Fusion lists the correct firewall and serial number.
• The target version and download are available.
• Support access, contacts, and the escalation path are known.

If external access is needed for the change, test it beforehand. For Avanet, see Set up support access to Sophos Firewall.

Check automatic hotfixes separately

Hotfixes are neither a firmware slot nor a pattern update. SFOS 22 checks for available hotfixes every 30 minutes and installs them automatically by default. Sophos recommends not changing this setting. Read the status in the Device Console before and after a firmware change:

system hotfix show

For SFOS 22, Sophos states that installed hotfixes remain after a firmware upgrade. By contrast, the version-specific list in SFOS 23 is reassessed after every version change, as explained in the following section. If the check shows that automatic installation is disabled, first determine who turned it off and why. Without a documented exception, turn it back on:

system hotfix enable

system hotfix disable only turns off automatic installation and is not a general troubleshooting step. An enabled status also does not prove that a specific hotfix has already been applied or that the download path works. For a specific fault, also verify the build, time, internet access, logs, and the Sophos fault reference.

SFOS 23: Verify applied security updates

In SFOS 23, Backup & firmware > Hotfix: Security updates shows which hotfix security updates have been applied since switching to the currently running SFOS version. Hotfixes correct the running system without a firmware upgrade and must not be confused with the list of available firmware images. Automatic hotfix installation must be enabled; it is enabled by default. system hotfix show checks this setting, not whether a specific security fix has been applied.

For change evidence before and after the firmware change:

1. Document the active SFOS version, build, and time of the check, and open the Hotfix: Security updates page.
2. Sort the entries by application date and record the updates related to the issue being investigated. For publicly disclosed vulnerabilities, the Advisory column links to the corresponding security advisory. Internal fixes may appear without a CVE ID or advisory link.
3. For HA, include both appliances in the post-update check: The current Primary receives the hotfix, synchronizes with the Auxiliary, and the hotfix is also applied there. A successful check on one appliance does not replace evidence for the cluster.

A vulnerability may appear more than once because several hotfixes may be needed to resolve it fully. A single matching entry therefore does not provide blanket proof of complete protection. For a specific security fix, compare the requirements of the corresponding security advisory with the running build and the updates actually applied.

Notifications and logs: Under System services > Notification list, in the Firmware section, enable Email for Security updates. SNMP notifications are not available for these updates. Hotfix security updates also appear in the Log viewer; their audit logs are generated and forwarded to Sophos Fusion for Central Firewall Reporting. These notification and logging statements apply to hotfix security updates, not to every hotfix correction in general. A missing email alone therefore proves neither success nor failure.

After a version change: SFOS first installs the new firmware and then applies the hotfixes available for that version. The previous hotfix list is removed and replaced by the list for the new version; it is not a cross-version archive. The same fix may appear again because it was applied independently to the new version. If earlier fixes are already included in the new firmware, they may not appear as separate hotfix entries.

An empty list only means that no hotfix security updates have yet been applied and displayed for the current version. It proves neither a lack of protection nor complete protection or working automatic installation. If anything is unclear, check the active version and build, CLI setting, security advisory, release notes, and logs together; do not disable automatic installation as a precaution or decide to roll back based on an empty page.

Prepare backup, recovery, and evidence

Backup, SSMK, and firmware slots

Download a fresh configuration backup before the update and verify which Secure Storage Master Key belongs to it. Also record the backup password, administrator access, active firmware version, and target version in the change.

Sophos Firewall keeps no more than two firmware versions: one active and one inactive. Each partition has its own configuration state. A rollback therefore activates not only the previous firmware but also its configuration. Changes made after the upgrade can be lost when reverting.

Automatic rollback is available from SFOS 20.0 for certain configuration migration failures. It is a safety feature, but it does not replace a backup or root-cause analysis and is unavailable for an unsupported upgrade path.

The complete process is covered in Back up or restore Sophos Firewall. If a normal version change is not possible, see Reimage Sophos Firewall OS with a USB drive.

Define rollback criteria in advance

Before starting, define how long an issue will be analyzed and when recovery begins. A rollback makes sense when WAN, HA, central VPNs, or production-critical published services cannot be stabilized within the agreed window. For a single rule, object, or external service, targeted troubleshooting is often better.

For a normal maintenance release, a backup, screenshot of the firmware page, maintenance window, and test result are sufficient evidence. For larger changes, Sophos Firewall Config Studio helps compare configurations, while the audit trail records changes during the maintenance window.

Check system health, storage, and HA

Storage and SSD

Before a larger upgrade, check in WebAdmin that:

• Control center shows no unresolved critical warnings.
• Backup & Firmware > Firmware shows the expected firmware slots.
• Diagnostics > Log viewer contains no recurring system or migration errors.
• Relevant services are stable.
• Firewall Health Check contains no open findings that affect the change.

After signing in through SSH, open Device Management > Advanced Shell and check the free storage:

df -kh

If a partition is almost full, do not blindly delete files, logs, or reports in the Advanced Shell. First identify the cause and use the documented cleanup method. See Check Sophos Firewall storage and manage reports.

SFOS 22 may require additional storage. Some XGS Appliance models must also receive an SSD firmware update first; WebAdmin displays a notification when this is required. In an HA cluster, each node is assessed separately. If one appliance does not meet the requirements, it can block the entire upgrade.

For older appliances or I/O, database, and reporting issues, also check SSD health with SMART. Without a specific finding, manual changes to databases or file systems are not a useful preparation step.

Sophos lists a restart before the upgrade only as an optional way to clear the memory cache. It is not a requirement and creates an additional interruption. Therefore, restart only in the maintenance window, after saving relevant logs and confirming the management recovery path. If the firewall shows unexplained instability, stop the upgrade; a restart must not replace root-cause analysis or merely make the system appear healthy temporarily.

HA cluster

HA does not need to be disabled for a normal firmware update. Before approval, however, both appliances must be connected, synchronized, and clearly identifiable as primary and auxiliary. An HA update still needs a maintenance window because failover can briefly interrupt individual sessions, VPN tunnels, or pings.

Before starting, document:

• Roles, HA status, and synchronization.
• HA link health.
• Firmware, storage, and SSD requirements for both nodes.
• Alternative management access.
• Expected failover and possible brief interruptions.

Do not update the auxiliary appliance separately. The implementation article explains the exact sequence of auxiliary update, failover, and update of the previous primary. Additional HA scenarios are covered in Sophos Firewall HA cluster: variants and maintenance.

Pattern updates are installed on the primary and then synchronized to the auxiliary. Hotfixes and their status must be considered separately and checked on both devices after the maintenance window.

Plan the maintenance window, Central, and tests

Maintenance window and access

A maintenance window covers more than the installation time:

• Start time, latest cutoff, and rollback decision.
• Owners for the firewall, network, servers, applications, and support.
• Local contact, out-of-band access, or a second management path.
• Communication path if WAN or remote access fails.
• Maintenance mode for monitoring and alerting.
• Test sequence for the most important business processes.

For remote sites, do not rely solely on Sophos Fusion or the existing VPN connection. If that exact path fails during the update, a defined access or escalation route must remain available.

Schedule firmware through Sophos Fusion

Central-managed firmware upgrades are prepared and monitored under My Products > Firewall Management > Firewalls. The Task Queue is for group policies and MDR/API configuration tasks and does not show firmware upgrades.

Only target versions that have reached the Available to all phase of the release process can be installed through Central. Scheduled updates start according to the timezone set on the firewall, not the administrator’s browser time. For international sites, record the timezone, local maintenance window, and target version in the change.

A status icon spins next to the firewall during the upgrade and disappears when it finishes. The active firmware version must still be checked locally afterwards. If an automatic rollback occurs, Central shows a corresponding message next to the firmware version.

Real functional tests

A ping alone does not prove that the firewall works correctly after the update. Define specific tests in advance with source, destination, and expected result:

• Internet access and DNS resolution.
• DHCP, VLANs, WAN uplinks, and SD-WAN routes.
• Site-to-site VPN, remote access VPN, and RED.
• Firewall rules, NAT, and published services.
• WAF, Web Protection, and TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID, and other central authentication.
• Mail flow and business-critical applications.
• Syslog, SIEM, and monitoring.

Validate after the update

After the restart, first check the active version and expected inactive slot under Backup & Firmware > Firmware. Then:

• Check Control center for new warnings or an automatic rollback.
• Verify interfaces, WAN, SD-WAN, HA roles, and synchronization.
• Validate VPNs, RED, DNS, DHCP, rules, NAT, WAF, and authentication with the prepared tests.
• Check pattern and hotfix status.
• Verify Sophos Fusion synchronization as well as monitoring, syslog, and SIEM.
• Record the result, times, deviations, and any follow-up work in the change.

If a single function fails, 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.

FAQ