Sophos Firewall v22 MR2: Features, Fixes and Upgrade Notes

On 14 July 2026, Sophos released Sophos Firewall OS 22.0 MR2 Build 546. The maintenance release is smaller than a major release, but it is far more than a simple bug-fix package: it introduces controls for post-quantum cryptography, more precise detection of generative AI applications, a new Chromebook extension, a less disruptive STAS default setting and updated Let’s Encrypt trust chains. At the same time, Sophos has fixed 53 documented issues affecting the firewall, HA, IPsec, authentication, logging, WAF, reporting and other components.

MR2 is therefore primarily an operational and stability release. The new features are interesting, but for many production environments, the resolved kernel crashes, failsafe triggers, HA problems and VPN errors are the more compelling reasons to update.

Detecting and controlling post-quantum cryptography

The most notable new security feature concerns post-quantum cryptography (PQC). This term describes cryptographic methods designed to resist attacks by sufficiently powerful quantum computers in the future. The current risk is not limited to the possibility that such a computer may one day become available. For particularly sensitive data, the principle of harvest now, decrypt later already matters today: encrypted traffic is recorded and stored so that it can be decrypted later using more powerful technology.

SFOS 22.0 MR2 detects both pure and hybrid key-exchange methods based on ML-KEM. In 2024, the National Institute of Standards and Technology standardised the method as FIPS 203. It is based on the mathematical Module Learning With Errors problem. NIST defines three parameter sets—ML-KEM-512, ML-KEM-768 and ML-KEM-1024—with different security and performance characteristics.

ML-KEM does not directly encrypt the subsequent web traffic. It is a Key Encapsulation Mechanism used to establish a shared secret between client and server over a public channel. Symmetric session keys are then derived from this secret and used to encrypt and authenticate the actual data efficiently.

With a pure PQC key exchange, the security of the negotiation depends entirely on the post-quantum method. Current TLS implementations more commonly use hybrid methods, combining ML-KEM with a classical method such as X25519. A correctly designed hybrid negotiation aims to keep the session protected for as long as at least one of the two components remains secure. This property depends on the specific construction, however, and is not automatically guaranteed for every conceivable hybrid method. The approach reduces the risk of relying completely on a comparatively new cryptographic method during an early migration phase.

Sophos has not yet disclosed which ML-KEM parameter sets are detected or the exact IPS signature IDs. The only publicly documented detail is that SFOS 22.0 MR2 can detect and control pure and hybrid ML-KEM negotiations.

Detection and policy control through IPS

With TLS 1.3, the client advertises its supported key-exchange groups in the ClientHello. This metadata is transmitted before the encrypted application session is established. IPS can therefore identify the use of a PQC or hybrid method from the TLS negotiation without having to decrypt the subsequent HTTP content.

Sophos provides new IPS patterns for this purpose. For them to be evaluated, IPS Protection must be active, a valid Network Protection licence must be available and the relevant IPS policy must be assigned to a firewall rule. Within a dedicated policy, actions for matching signatures can include:

allowing the traffic,
logging it,
dropping individual packets or the entire session,
terminating the TCP session with a reset, or
disabling the signature.

The PQC signatures introduced in MR2 are disabled by default. This is sensible because current browsers, cloud platforms, CDNs and TLS libraries increasingly use hybrid PQC methods as a normal part of their operation. If Sophos shipped these signatures with a blocking default action, legitimate web and API connections could be interrupted. In the initial feedback thread, Sophos also explains that the default is disabled because PQC TLS is becoming more common and could otherwise generate a large number of unnecessary alerts.

I would not enable the new signatures in blocking mode immediately. A better approach is to create a separate IPS policy for a limited test group and initially log matches only. You can then use Log Viewer to determine which browsers, applications and destinations use ML-KEM. Only once the cryptographic policy to be enforced is clear—and the legitimate services that would be affected are known—would I use Drop session or Reset. PQC is not inherently suspicious: in most cases, a match merely shows that an application is already using modern TLS methods.

TLS negotiation control through Web Protection

In addition to IPS, Web Protection directly controls the TLS methods that can be negotiated. Sophos states that web sessions cannot negotiate PQC algorithms unsupported by the firewall. This serves a different purpose from detection by IPS: IPS classifies the visible negotiation and applies a policy action, while Web Protection ensures that a protected web session is established only with a cryptographic method supported by the SFOS processing path.

This is particularly important for TLS Inspection. In this scenario, the firewall is not simply a passive device in the data path. It must terminate the TLS session, validate or reissue certificates, and negotiate compatible cryptographic parameters on both sides. An algorithm supported by the browser and destination server is therefore not necessarily suitable for every inspection engine placed between them.

PQC key exchange also changes the TLS negotiation at a technical level. Hybrid key shares are larger than traditional X25519 values and can cause a ClientHello to span multiple packets. Such connections are valid under TLS, but they can place noticeably greater demands on older middleboxes, proxies or inspection engines that have not been updated. The new MR2 support is therefore not merely an additional signature; it is also a compatibility adjustment for a TLS stack that is currently evolving.

Sophos does not currently document in detail whether Web Protection terminates the session when it encounters an unsupported PQC method, falls back to a classical method, or behaves differently depending on the processing path. No specific fallback behaviour should therefore be inferred from the release announcement. The only clear point is that unsupported PQC negotiations must not bypass the protection layer unchecked.

After the upgrade, environments using TLS Inspection should test the following in particular:

Test current versions of Chrome, Edge, Firefox and Safari against commonly used SaaS and cloud services.
Access the same destinations once through a rule with TLS Inspection and once without it.
Check TLS Inspection exceptions, certificate errors and block pages.
Review IPS and Web Protection logs for new PQC messages, handshake errors and resets.
Test business-critical applications with their own TLS libraries, API clients or Java runtimes separately.
If problems occur, use Packet Capture to determine whether the TLS handshake itself fails or only the protected application session is interrupted.
Only then decide whether an explicit Allow, Drop or Reset action is required.

Generative AI with Synchronized Application Control

MR2 improves the categorisation of generative AI applications. The key limitation is already contained in the feature name: the additional visibility comes through Synchronized Application Control. Sophos Endpoint detects applications locally and shares this information with the firewall through Security Heartbeat. SFOS can then classify the application more precisely in reports and Application Control rules.

This helps with applications that communicate through general web protocols, shared CDNs or changing destinations and are difficult to identify reliably using traditional firewall signatures alone. A more precise category makes it easier, for example, to distinguish ordinary web applications from GenAI tools and to evaluate which users or devices are using such applications.

However, the feature is not a universal CASB or DLP system. It does not automatically analyse confidential prompt content, and without a compatible Sophos Endpoint, the same level of application visibility is not available. In Microsoft Defender or mixed endpoint environments, DNS, web, TLS, proxy or SSE/CASB controls therefore remain relevant.

A useful policy requires more than the new category:

Sophos Endpoint and Security Heartbeat must be connected correctly.
Unknown applications in Synchronized Application Control must be classified regularly.
Firewall rules require an appropriate Application Control policy with logging enabled.
Approved GenAI services, corporate accounts and data-protection requirements must be defined.
Sensitive data requires additional DLP, browser, endpoint or SaaS controls.

A blanket block on all GenAI applications is rarely the best first measure. A tiered policy is more useful: allow approved corporate services, log or block unknown and unreviewed services, and assess usage against actual business requirements.

Authentication: Chromebook, STAS and eDirectory

MR2 changes three technically distinct areas of user identification. In everyday operation, they all affect the same critical question: whether the firewall can identify a user reliably and assign the correct policy.

Chromebook User ID with Manifest V3

The new Sophos Chromebook User ID Extension supports Chrome Manifest V3. Manifest V3 is Chrome’s current extension platform and changes permissions, background processes and the way extensions handle network events, among other things. Without the new version, the previous Sophos extension would eventually stop receiving regular updates.

According to Sophos, an in-place update is not available. The old extension must be uninstalled and the new one installed. In managed Chromebook environments, this should be handled through the Google Admin console or the endpoint-management platform in use:

Remove the old Sophos Chromebook User ID Extension from forced installation.
Add the new Manifest V3 version and assign it to the target groups.
Sign in with a test user.
Verify on the firewall that the username and IP address are mapped correctly.
Trigger a user-based firewall or web policy and check the result in Log Viewer.

The order matters. If the old extension is removed before the new version has been deployed, user mapping will temporarily be unavailable. Rules may then fall back to a more general policy or block access.

For the complete Device Access, certificate, firewall-rule, JSON-policy and API Controls workflow, see Set up Chromebook SSO with Google Workspace.

STAS no longer blocks during identity probing by default

With the Sophos Transparent Authentication Suite (STAS), the firewall queries which Active Directory user is associated with an IP address when it encounters a new or changed client. The Restrict client traffic during identity probe setting determines whether the client can already send traffic while this check is in progress.

MR2 changes the default value to No. Traffic is therefore allowed to continue while the firewall checks the user and destination address. This reduces brief interruptions that can be noticeable with new sessions, user changes, roaming or delayed responses from the STAS Collector.

The convenience comes with a trade-off: during the probe, the firewall must use whatever identity context is currently available. Environments with very strict user-based rules should therefore verify which policy applies during this brief window. After the update, do not simply assume that existing configurations will automatically adopt the same value. Check the current value, the intended behaviour and the actual logs.

Novell eDirectory support ends with SFOS 23.0

MR2 also displays an end-of-life notice for the Novell eDirectory Authentication Server. Support will end with SFOS 23.0. eDirectory continues to work in MR2; the message is an advance warning rather than an immediate removal of functionality.

We will not miss this integration. None of our customers still uses Novell eDirectory, and it has not played a role in new projects for a long time. The few environments that still depend on it have until SFOS 23.0 to migrate to a supported identity source. In addition to the Authentication Server, the review must cover imported groups, firewall rules, VPN permissions, web policies, Captive Portal and user-based reports.

Let’s Encrypt and certificate operations

SFOS 22.0 MR2 updates support for new Let’s Encrypt root and intermediate certificates. It now recognises the YE Root, YE1, YE2, YR Root, YR1 and YR2 chains. This prepares automatic certificate issuance and renewal on Sophos Firewall for the current and upcoming Let’s Encrypt chains.

This matters because a correct ACME request alone is not enough. The firewall, remote endpoint and clients must also be able to build and validate the issued certificate chain correctly. Outdated trust stores can otherwise cause apparently inexplicable certificate errors even though the leaf certificate itself is valid.

Let’s Encrypt email notifications now also include the firewall hostname and serial number. In environments with multiple appliances, this makes it easier to identify which device triggered a renewal notice, error or other certificate message. However, the serial number is inventory-relevant device information, so notifications should be sent only to controlled recipients and mailboxes.

After the upgrade, it is worth performing a complete certificate test:

Check the ACME status and next renewal date.
Verify the hostname, DNS resolution and challenge reachability.
Validate the certificate chain in a browser or with an external TLS test.
Review WAF, WebAdmin, User Portal and VPN certificates separately.
Check delivery of the new email notification and review its recipient list.

Config Studio 2.6 expands analysis and migration capabilities

Alongside MR2, Sophos highlights Firewall Config Studio 2.6. The tool runs in a browser outside the firewall and is therefore not technically a WebAdmin function embedded in Build 546. However, it complements operations precisely where SFOS itself still offers only limited analysis and comparison capabilities.

The main features in version 2.6 are:

Merge templates: A baseline configuration can be combined with an industry- or deployment-specific template. This speeds up standardised rollouts but does not replace checks for conflicting objects, interfaces or rules.
Enhanced Global Search: Objects can be searched globally and opened directly where they are used. This is particularly helpful in large rule sets and when cleaning up unclear dependencies.
Improved Configuration Report: Firewall, NAT and TLS rules show not only referenced object names but also their values and details. This makes reviews easier to understand without opening each object separately.
Migration Insights: After a conversion, Config Studio shows the proportion that was migrated successfully. The percentage is a guide, not an acceptance test: VPNs, authentication, certificates and vendor-specific features that were not transferred still require manual review.
Multi-file Configuration Diff: Multiple configuration states can be compared to trace the backup in which a change, error or unwanted deviation first appeared.
Backup restore compatibility: The tool helps determine whether a backup can be restored to a different Sophos Firewall model.
Flexi Port and port-speed reference: Port layouts, Flexi modules and supported speeds up to 25, 40 or 100 Gbps can be compared before hardware migrations.

Config Studio 2.6 is covered in detail in Sophos Firewall Config Studio 2.6: Migration Built In. The practical workflow for reports, comparisons, editing and controlled reimport is described in Using Sophos Firewall Config Studio.

The 53 issues fixed in Build 546

Sophos lists more than 50 stability, reliability and security fixes. The following overview includes all 53 IDs from the official release notes. It does not replace an individual support assessment, but it shows which function was affected and why the fix matters in operation.

Firewall, kernel, HA and system stability

NC-180331 – Incorrect memory handling in algif_aead and algif_skcipher: Closes a Linux kernel vulnerability in cryptographic components.
NC-181331 – A full configuration partition placed the firewall in failsafe mode: Reduces the risk of an outage caused by exhausted configuration storage.
NC-180974 – A kernel crash in sdwan_profile triggered an HA failover: Stabilises SD-WAN environments and prevents unnecessary role changes in the cluster.
NC-178354 – Kernel crash during SD-WAN rule matching: Prevents crashes while evaluating SD-WAN rules.
NC-178413 – An empty value in Services caused an ipset error and failsafe mode: Handles damaged or incomplete service objects more robustly.
NC-177934 – Firewall entered failsafe mode after upgrading to SFOS 22.0 GA: Resolves a direct upgrade consequence in earlier v22 builds.
NC-177441 – The initial primary HA device entered failsafe mode after upgrading to SFOS 22.0 GA: Improves primary-node startup stability after the upgrade.
NC-177467 – The auxiliary device failed to start because of a very high number of simultaneous unauthenticated SSH connections: Important for exposed or heavily scanned HA systems; this exact fix is being watched closely for XGS 5500 HA in the initial MR2 feedback.
NC-173031 – Imported Application Policies were not synchronised automatically to the auxiliary device: Ensures more consistent policy states across both HA nodes.
NC-177536 – Firmware upgrade to SFOS 22.0 GA failed on the primary HA device: Stabilises the upgrade path in HA clusters.
NC-178745 – An HA device restarted automatically because of an out-of-memory condition: Reduces unplanned restarts caused by the logging subsystem.
NC-180110 – The primary HA device entered failsafe mode because the logging daemon did not start: Prevents a logging startup error from taking the entire primary node out of service.
NC-180933 – Administrators could not sign in to the WebAdmin console: Restores administrative GUI access.
NC-177769 – The eBPF service stopped responding after a pattern update: Stabilises the accelerated data path after signature updates.
NC-180152 – Interface updates took longer in SFOS 22.0 GA than in 21.5: Reduces delays when applying interface changes.
NC-179462 – Repeated warnings while reading hardware statistics: Removes unnecessary log noise on XGS appliances.

Firewall rules, user traffic and routing

NC-181741 – Traffic from unauthenticated users was dropped every hour: Prevents regular interruptions in environments with unauthenticated traffic.
NC-178903 – SATC users lost internet access after upgrading to SFOS 22.0 GA: Restores user-based access with Sophos Authentication Thin Client.
NC-178141 – Certain ICMP error messages were dropped by Local ACL after the GA upgrade: Improves Path MTU Discovery and troubleshooting scenarios in which ICMP is technically required.
NC-178197 – Application traffic stopped intermittently with an application-based Bandwidth Policy: Stabilises QoS for rules that manage bandwidth based on detected applications.
NC-180226 – The GUI showed no error for a duplicate MAC address in Spoof protection trusted MAC: Prevents silent misconfigurations in the Spoof Protection exception list.
NC-181299 – The GeoIP database assigned an IP address to the United Kingdom instead of Germany: Corrects country assignment for GeoIP rules and reports.

IPsec and VPN

NC-180433 – Multicast over a VPN tunnel caused repeated firewall crashes: Important for routing, streaming or discovery scenarios using multicast over IPsec.
NC-178121 – Site-to-site IPsec connections moved to the wrong position in the failover group after drag and drop: Ensures that the configured tunnel priority is retained.
NC-171719 – SD-WAN routing issue with ESP traffic: Improves path selection for native IPsec/ESP in SD-WAN scenarios.
NC-180520 – The XFRM gateway remained unreachable with IPsec acceleration, an alias IP and inbound ESP traffic on a different WAN port: Fixes a complex multi-WAN edge case affecting accelerated IPsec tunnels.
NC-176855 – Low IPv6 throughput over route-based IPsec: Improves IPv6 performance in tunnel-based VPN designs.
NC-181687 – Creating an SSL VPN policy resulted in an internal server error: Restores policy creation in the new control-plane and HA architecture.
NC-175860 – Remote Access IPsec failed after an HA failover when the Appliance Certificate had been regenerated: Stabilises certificate-dependent remote access connections across role changes.

Authentication, Central and configuration management

NC-180824 – New AD users in a secondary AD group could not sign in to the VPN Portal: Corrects nested or secondary group membership handling for portal access.
NC-176806 – Microsoft Entra ID SSO failed because intermediate CAs were missing: Improves certificate validation for Entra ID sign-ins.
NC-160157 – Last access time remained after a user was deleted and appeared for a newly created user: Prevents misleading historical access data when an account is recreated.
NC-181175 – A Group Policy push from Sophos Central remained pending and was not applied: Resolves stuck group changes in central management.
NC-180513 – Configuration import from the Sophos Central view stopped working after the MR1 upgrade: Restores the Central-based import path.
NC-181904 – Quarantined emails could not be released through Sophos Central: Fixes the known Central workflow; local WebAdmin was previously the practical workaround.

The Central Firewall Task Queue should still be checked after the update. A fixed product issue does not guarantee that older stuck tasks or inconsistent group states will disappear automatically.

Logging and reporting

NC-181520 – Log Viewer was too slow: Improves response times during searches and troubleshooting.
NC-172912 – The System Graph flickered: Stabilises the display of system metrics.
NC-172020 – Firewalls without on-box reporting sent empty Traffic Dashboard PDFs: Prevents empty daily reports.
NC-169646 – On-demand PDFs contained incorrect charts and tables in Chrome: Corrects browser-based report generation.
NC-155252 – High disk I/O caused CPU spikes and internet outages lasting up to one minute: A particularly relevant stability fix for systems with intensive reporting and logging workloads.

NC-178745 and NC-180110 from the stability section also affect the Logging Framework, but their restart and failsafe consequences had a direct impact on the entire appliance.

Email, antivirus and Security Heartbeat

NC-180066 – SAVI and AVIRA pattern updates failed and stopped the antivirus service: Ensures that a pattern error does not terminate the entire AV service.
NC-177930 – Emails remained in the spool because of a mailpoller crash: Prevents blocked mail delivery in MTA mode.
NC-171602 – Firewall notifications failed DKIM validation: Improves the deliverability of signed system emails.
NC-176012 – A missing heartbeat was reported when two endpoints used the same docking station or USB interface: Reduces false heartbeat alerts when different devices use shared hardware.

If you use MTA mode, test the mail spool, quarantine, DKIM and Central release workflow after the update by following the steps in Sophos Firewall Mail Protection in MTA Mode.

WAF, Web Protection and RED

NC-180200 – WAF stopped during nightly licence synchronisation on Home Edition: Prevents regular WAF outages in Home Edition installations.
NC-177457 – With WAF debugging enabled, the password was visible in reverseproxy.log: Closes a sensitive clear-text disclosure in the debug log. Existing debug logs should nevertheless be reviewed and protected or deleted in accordance with policy.
NC-176788 – ResponseFieldSize reverted to its default when the certificate in a WAF rule was changed: Preserves a deliberately configured size limit during certificate changes.
NC-167019 – Snort caused high CPU usage for Veeam traffic without an exception: Reduces load spikes during backup traffic; existing exceptions should still be reviewed to determine whether they remain necessary.
NC-178906 – The firewall entered failsafe mode with Failed to start Red server service: Stabilises the RED server service and prevents an appliance-wide failsafe condition.

Firmware, DDNS and user interface

NC-170200 – Multiple upgrade attempts within a few minutes caused firmware upgrades to fail: Makes Firmware Management more robust; parallel or rapidly repeated upgrade attempts should still be avoided.
NC-180219 – Cloudflare DDNS stopped working after upgrading to SFOS 22.0 MR1: Restores dynamic DNS updates for Cloudflare.
NC-181575 – The time field in Schedules was displayed incorrectly: Prevents misinterpretation when editing time-controlled rules.
NC-171424 – After deleting the only exception on the last page, the Web Exceptions list appeared empty: Returns users to the previous page instead of showing an apparently empty configuration.

Planning the upgrade and validating MR2

Sophos supports upgrades to v22 MR2 from all supported versions in the v21.5, v21 and v20 series. The firmware image can be obtained manually through Sophos Central, while automatic deployment to connected devices will be phased in over the coming weeks. According to Sophos, the update is available to licensed firewalls with Enhanced or Enhanced Plus Support at no additional firmware cost.

Despite the long list of fixes, MR2 should not be deployed to every system at once without testing. The public feedback thread was opened only on the release date. Initial posts ask specifically about XGS 5500 stability in active-passive HA and fix NC-177467. This is not evidence of a confirmed new MR2 issue, but it is a good reason to update HA systems and business-critical sites in stages.

Before the update

Verify the supported upgrade path and licence status.
Create a complete encrypted backup and keep it available externally.
Perform the SFOS 22 Upgrade Check.
Review outstanding Health Check findings in the Sophos Firewall Health Check.
Check HA status, SSD health, free partition space and pattern status.
Document critical functions: WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, authentication and Central Management.
Prepare the maintenance window, local console access and rollback decision criteria.

After the update

Verify Build 22.0 MR2 546, system status and active hotfixes.
For HA, check both nodes, synchronisation, roles and failover.
Test WAN, DNS, DHCP/DDNS, SD-WAN and internet access.
Test site-to-site and remote access VPNs, including IPv6 and failover.
Validate AD, Entra ID, STAS, SATC and portal sign-in with test users.
Check WAF, Let’s Encrypt, MTA, quarantine and notifications.
Review the Central Task Queue and recently applied group changes.
Search Log Viewer for new errors, failsafe notices, service restarts and PQC messages.
Update additional appliances only after a stable observation period.

The complete process for backups, maintenance windows and post-update checks is described in Preparing a Sophos Firewall Firmware Update.

Conclusion

Sophos Firewall v22 MR2 is a worthwhile maintenance release with an unusually broad mix of changes. Post-quantum cryptography and improved GenAI categorisation point to the direction in which network and application control are evolving. Chromebook Manifest V3, STAS and Let’s Encrypt are less spectacular, but they address concrete lifecycle and operational issues.

The strongest reason to install Build 546 remains stability: Sophos has fixed multiple kernel crashes, failsafe conditions, HA problems, VPN errors, a clear-text password in the WAF debug log, and significant outages affecting logging, reporting, antivirus and email. Precisely because these fixes reach deep into the system, the update should not be treated as a casual click. Backups, a staged rollout and targeted functional checks remain essential.