Sophos Firewall v22 MR2: Update or New Risk?

Sophos Firewall v22 MR2 is here. Build 546 was released on July 14, 2026, and delivers a manageable but useful mix of security features, authentication changes, certificate updates, and more than 50 fixes.

On paper, this is a conventional maintenance release. In practice, it contains exactly the combination that now makes me look twice at Sophos updates: new IPS detection logic, changed user-mapping behavior, new certificate chains, and a long list of kernel crashes, HA problems, failsafe conditions, VPN faults, and reporting outages.

That is not entirely positive. More than 50 fixes show that Sophos is cleaning up, but also how many serious defects remained in GA and MR1. I already criticized this firmware quality in Sophos Firewall: No CVEs, but Bugs (v21.5 to v22).

I will install MR2 on one of my Sophos Firewalls right away. Not because I blindly trust a day-one release, but because I want to see whether Build 546 finally settles the v22 branch or once again introduces more bugs than it fixes. I will pay particular attention to HA, logging, IPsec, WebAdmin responsiveness, STAS, and stability after pattern updates.

At the same time, Sophos creates an odd contrast. Config Studio 2.6 now occupies considerable space in official firewall updates. The external browser tool gains template merging, better search, multi-file diffs, migration analysis, and hardware compatibility data. Yet almost nothing visibly changes in the firewall interface used every day.

I therefore consider MR2 technically important but strategically sobering. The security engine gains capabilities while modern administration workflows are once again moved into Config Studio.

The Key Points

SFOS 22.0 MR2 is Build 546 and follows MR1 Build 490. Sophos highlights seven main areas:

• detection and control of post-quantum cryptography
• improved categorization of generative AI applications
• a new Manifest V3 Chromebook User ID extension
• changed default STAS behavior
• early notice that Novell eDirectory support ends in SFOS 23.0
• new Let’s Encrypt trust chains and improved email notifications
• Config Studio 2.6 with new analysis, migration, and comparison features

There are also more than 50 fixes. Operationally, several matter more than the new features because they address kernel crashes, HA failures, failsafe conditions, VPN faults, and reporting performance problems.

My short assessment:

• Anyone already on v22 GA or MR1 and affected by a listed defect has a concrete reason to install MR2.
• Anyone running a stable 21.5 installation should not rush solely for PQC or Config Studio.
• Put PQC signatures into observation mode first, not immediately on Drop.
• STAS environments must verify how unauthenticated traffic is handled during an identity probe after upgrading.
• HA, IPsec, WAF, mail, and reporting deployments need real functional tests, not a glance at green status indicators.
• Config Studio 2.6 is useful, but it does not prove that SFOS WebAdmin is becoming more modern. If anything, it suggests the opposite.

The hardware boundary remains important: SFOS 22.0 no longer supports XG and SG hardware appliances. MR2 is intended for XGS, virtual, software, and supported cloud installations. An organization still using XG hardware cannot treat MR2 as the normal next firmware step.

Detecting and Controlling Post-Quantum Cryptography

The most technically interesting addition is control of post-quantum cryptography, or PQC. This does not mean the Sophos Firewall suddenly protects against quantum computers. It concerns modern key-exchange mechanisms designed to resist future attacks by powerful quantum computers.

MR2 focuses on ML-KEM. Standardized in 2024 as FIPS 203, it relies on the assumed hardness of the Module Learning With Errors problem. NIST defines three parameter sets:

• ML-KEM-512, with the smallest keys and data volume
• ML-KEM-768, the middle and currently particularly common option
• ML-KEM-1024, with a higher security level but greater processing and transmission overhead

Sophos only refers generally to pure and hybrid ML-KEM-based key-exchange algorithms. It does not disclose which parameter sets, TLS groups, or signature IDs are covered. Administrators should therefore not assume that every conceivable ML-KEM variant is detected.

What a KEM Actually Does

ML-KEM does not encrypt the entire data stream directly. In simplified terms, a Key Encapsulation Mechanism has three operations:

1. KeyGen creates an encapsulation key and its corresponding decapsulation key.
2. Encaps uses the public encapsulation key to create a ciphertext object and a shared secret.
3. Decaps uses the private decapsulation key at the other end to recover the same secret.

The protocol derives symmetric session keys from this secret. Payload data remains protected by fast symmetric algorithms such as AES or ChaCha20. ML-KEM replaces the vulnerable asymmetric part of key negotiation, not all TLS data encryption.

The practical concern is Harvest now, decrypt later: an attacker records encrypted traffic today, hoping to decrypt it years later with a cryptographically relevant quantum computer. That matters less for short-lived information, but health records, government communications, intellectual property, and other long-term confidential data may need protection longer than the time until a new class of attack becomes viable.

Pure and Hybrid Are Not the Same

With pure PQC key exchange, negotiation security depends only on the new post-quantum method. A hybrid exchange combines a classic mechanism with ML-KEM. One example already common in real TLS implementations is X25519MLKEM768: both X25519 and ML-KEM-768 contribute to the resulting secret.

That is sensible during migration. If ML-KEM later reveals an implementation error or mathematical weakness, the classic component remains. If a sufficiently powerful quantum computer breaks the classic elliptic curve, ML-KEM remains. Hybrid exchange is therefore a migration bridge, not pointless double encryption.

However, X25519MLKEM768 is an actual technical example, not a claim that Sophos detects only or primarily that group. The MR2 documents do not say so.

What IPS Does

The Intrusion Prevention System receives signatures that can detect pure and hybrid ML-KEM key exchange. Administrators can create IPS rules and select actions such as Allow, Drop, or Reset.

A firewall can technically see offered and selected key exchange in the TLS handshake: the client advertises supported groups and key shares in ClientHello, and the server confirms its choice in ServerHello. This occurs before the encrypted application stream begins, so detection is possible without reading later HTTPS content.

Sophos does not document where Snort or the SFOS IPS pipeline evaluates these fields, which TLS versions are covered, or whether behavior differs between proxy, DPI, and uninspected FastPath traffic. The release notes confirm the capability, not its internal data-path implementation. Production policies therefore require testing against firewall and IPS logs.

The actions have different effects:

• Allow permits the connection and, with logging, is suitable for discovery.
• Drop silently discards matching packets; the client typically sees a timeout or failed handshake.
• Reset actively terminates the TCP connection; the failure appears faster but may look different in client and application logs.

The signatures are disabled by default, which is the correct choice. PQC is no longer laboratory technology: major browsers, cloud services, and web platforms already test or use hybrid methods. Blanket blocking could break legitimate applications and websites.

A sensible rollout is therefore:

1. Enable the signatures with traffic allowed and logged.
2. Observe for days or weeks which applications and destinations use ML-KEM.
3. Determine whether internal cryptography policy prohibits or explicitly requires particular methods.
4. Only then enforce selectively with Drop or Reset.

In the first community discussion, an administrator could not find matching IPS signatures using PQC, KEM, or quantum. The pattern update may not yet have arrived, or the names may differ. Hours after release, this is not enough to establish a product defect, but it exposes a documentation problem: a capability is only manageable if its signature name, SID, category, and log fields can be found.

Before changing policy, I would verify:

• Is IPS enabled and the Network Protection subscription valid?
• Which IPS pattern version is installed?
• Under which name and SID do the new signatures appear?
• Do hits appear in the IPS log and central reporting?
• Is detection consistent with DPI exceptions, TLS inspection, and FastPath?
• Which browsers, operating systems, cloud services, and internal applications trigger hits?

What Web Protection Does

Sophos also says Web Protection prevents web sessions from negotiating unsupported PQC algorithms. That differs from an IPS signature. IPS detects patterns and applies an action; Web Protection participates in the controlled TLS and web workflow and prevents a connection from using a method the firewall cannot process or policy does not permit.

This matters most with TLS inspection. The firewall terminates the client’s TLS session and establishes a second TLS session to the destination. There are two handshakes and two sets of session keys. A browser and server may support PQC while the inspection component between them cannot correctly process an offered group.

Without controlled behavior, failures become hard to diagnose: the client offers a new group, the firewall cannot fully relay the handshake, the server chooses an unexpected variant, or fallback behaves differently than intended. MR2 is meant to prevent unsupported PQC negotiation in web sessions.

What Sophos does not describe matters too: there is no separate PQC policy matrix for Web Protection, supported-group list, or precise statement on whether an unsupported offer is removed, rejected, or replaced through classic fallback. This should not be confused with configurable IPS actions.

The feature is useful, but it does not replace a cryptography strategy. Organizations must still know which TLS connections are decrypted, where exceptions exist, and whether PQC is merely observed or enforced.

Better Visibility for Generative AI Applications

The second security addition improves categorization of generative AI applications through Synchronized Application Control.

The principle is established: Sophos Endpoint sees which local process opens a connection and shares application context with the firewall through Security Heartbeat. SFOS can then associate a session with a program even when port, destination IP, and encrypted traffic are insufficient.

The simplified data path is:

1. An application on a protected endpoint opens a network connection.
2. Sophos Endpoint knows the process name, path, and local context.
3. Security Heartbeat links endpoint and firewall visibility.
4. SFOS maps the otherwise unknown or coarsely identified session to an application.
5. The application appears in Synchronized Application Control and can be categorized.
6. An Application Filter policy allows, blocks, or shapes the traffic.

In Connection List, Resolve application info can request endpoint data for unidentified connections. The application list supports searches by name, path, category, or endpoint. Sophos specifies a maximum of 15,000 managed applications and retains only the five most recent occurrences per application and endpoint to conserve memory.

MR2 improves the classification of generative AI applications. Sophos Endpoint should identify them more accurately and pass that information to SFOS. The Generative AI category can then be used in Application Filters and reports.

This provides:

• Visibility: clearer reporting on generative AI applications in use
• Rules: more targeted permission, restriction, or blocking
• Inventory: a better basis for security and privacy teams to separate approved from unapproved AI services

Useful, yes—but “detecting generative AI” must not be overstated. Synchronized Application Control primarily answers which application created the connection. It does not automatically reveal:

• the user’s prompt
• the uploaded file
• whether personal or confidential data was included
• whether a browser session is private or business use
• whether an approved service invoked an embedded AI function

A desktop client with a unique process path is easier to identify than ten AI services inside one browser process. URL categorization, TLS inspection, and cloud-app detection may add information, but they are different detection layers.

The value also depends on Sophos Endpoint, active Security Heartbeat, and enabled Synchronized Application Control; initial activation occurs through Sophos Central. SFOS alone, or endpoints outside the heartbeat path, will not provide the same depth.

The right expectation is better application attribution and therefore a better policy foundation—not a complete answer to which AI services may be used or what data may be processed there.

I would not block the entire Generative AI category immediately. First establish which hits came from endpoint context, firewall signatures, or web categorization. Otherwise productive functions in Microsoft 365, developer tools, browsers, or support platforms may be blocked without understanding actual use.

Authentication and User-Mapping Changes

MR2 introduces three independent authentication topics. Two require preparation; the third is an early migration warning.

Chromebook User ID with Manifest V3

The Sophos Chromebook User ID Extension now uses Manifest V3, Chrome’s current extension platform.

Sophos requires the old extension to be uninstalled and the new one installed. A silent in-place update is not enough. Schools and businesses with managed Chromebooks should prepare the transition through Google Admin policies, test with a pilot group, and then roll it out broadly.

The extension is only one component of the SSO path. Sophos expects, among other things:

• an AD, LDAP, or Google Secure LDAP server configured on the firewall
• Chromebooks on the SFOS-protected network
• user addresses in the registered Google Workspace domain
• a certificate for encrypted communication with a matching CN
• Sophos communication port 65123 by default
• JSON configuration exported from SFOS and stored in Google Workspace
• access to accounts.google.com, Google API hosts, and Chrome Web Store

The extension is deployed under Devices > Chrome > Apps and extensions > Users and browsers. Force install is sensible in production so users cannot remove it. The Sophos User ID app must also be marked trusted under API Controls, or OAuth may fail.

After migration, test the complete chain rather than merely checking installation:

1. The user signs in to the Chromebook.
2. The extension reaches the firewall over the intended network and certificate.
3. The user appears under Live users.
4. A user-based rule actually matches the user or group.
5. Mapping disappears correctly after sign-out or a device change.

Without the new extension, future updates may stop. Depending on the design, this can break user attribution and therefore user-based firewall or web policies. In a school, filtering may fail even though the firewall, internet link, and Chromebook all appear “online.”

STAS No Longer Blocks by Default During Identity Probes

For Sophos Transparent Authentication Suite, MR2 changes the default of Restrict client traffic during identity probe to No.

STAS maps IP addresses to users observed on Windows domain controllers:

1. The user signs in to the Windows domain.
2. The domain controller writes a security audit event—typically Event ID 4768 on newer Windows versions.
3. STAS Agent reads the username and IP address.
4. The agent sends data to the collector over TCP 5566 by default.
5. The collector reports successful mappings to the firewall over UDP 6060.
6. When SFOS sees traffic from an unknown IP, it can query the collector on port 6677.
7. The firewall adds group membership from the configured AD server and applies user-based rules.

An unknown IP enters Learning Mode. Previously, traffic was held or discarded during the probe by default. The documented default period is 120 seconds. If the collector does not answer, the IP may then remain unauthenticated for one hour and rules for unauthenticated traffic apply.

MR1 had a real operational defect here. Sophos documents NC-181885: with Restrict client traffic during identity probe = Yes, repeated probes could cause intermittent disruption or block the MR1 upgrade. MR2 is listed as the fix and also changes the default to No.

With No, client traffic continues during probing. That reduces disruption but changes the trade-off:

• Users experience fewer interruptions.
• The firewall may not yet have a confirmed identity.
• User-based rules and logging require scrutiny during the transition.

This is availability versus strict identity enforcement. With Yes, broken collector communication can block a client. With No, traffic may flow before identity is confirmed. Whether it matches a general network rule, an unauthenticated rule, or later a user rule must be tested in the local ruleset.

The release notes say the default changes to No; they do not clearly say that every deliberately configured existing value is overwritten. Verify the actual value after upgrading.

Also check:

• Are UDP 6060 and 6677 open between firewall and collector?
• Is the STAS service running and bound to the correct NIC?
• Are multiple collectors grouped for fault tolerance?
• Are clientless users configured for printers, IoT, and other non-domain devices?
• Do users map correctly after sleep, roaming, DHCP changes, and sign-out?
• Do rules during Learning Mode and the unauthenticated state match the security design?

This is crucial where identity is an access condition, not merely a reporting attribute.

Novell eDirectory Ends with SFOS 23.0

MR2 warns for the first time that Sophos will end support for Novell eDirectory authentication servers in SFOS 23.0.

eDirectory still works in MR2. This is advance notice, not immediate loss of service. Production users should nevertheless migrate to a supported authentication type before installing SFOS 23.0.

That migration involves more than replacing a server entry. Groups, firewall rules, web policies, VPN access, user portals, and reports may depend on the identity source. Different distinguished names, nested groups, search paths, and username formats mean that a successful LDAP test does not prove policy migration works.

STAS has also long lacked LDAP over SSL/TLS support for eDirectory, so complete removal is not entirely surprising. The replacement architecture should still be a proper project with test accounts, parallel groups, documented rule references, and rollback planning.

Let’s Encrypt: New Chains and Better Identification

Let’s Encrypt is gradually moving to new root and intermediate certificates. MR2 adds support for YE Root, YE1, YE2, YR Root, YR1, and YR2.

This Generation Y hierarchy contains two new roots with different key types:

• ISRG Root YE uses ECDSA P-384 and succeeds the previous ECDSA path.
• ISRG Root YR uses RSA 4096 and is the new RSA root path.
• YE1 and YE2 are ECDSA P-384 intermediates.
• YR1 and YR2 are RSA 2048 intermediates.

The roots are cross-signed by existing ISRG roots, allowing new chains to terminate at older trust anchors while browser and OS vendors add the new roots. The YE1, YE2, YR1, and YR2 intermediates became relevant for active issuance in 2026.

For SFOS this is primarily compatibility work. The firewall must recognize the new issuers and chains so automatic issuance, renewal, WAF use, and validation continue to work. Without updated trust chains, certificate operations could fail even when domain, port 80, and HTTP-01 validation are configured correctly.

That is awkward operationally because an ACME fault is easily misdiagnosed as DNS, DNAT, port 80, WAF-rule, or Terms of Service trouble when the actual cause is a new CA chain.

SFOS continues to use HTTP-01. The domain must resolve to the selected public WAN address, port 80 must reach the firewall, and a competing DNAT rule on the same address and port can prevent validation. MR2 does not change that model; it expands CA hierarchy support.

Let’s Encrypt email notifications now include the firewall hostname and serial number. This small change is valuable for MSPs and larger estates: a warning can finally be mapped to the correct device without investigating a generic message.

It is a practical quality-of-life improvement. Every system-generated firewall message should really contain hostname, serial number, model, and firmware. Backup emails already moved in that direction; Let’s Encrypt follows in MR2.

Config Studio 2.6: Every New Feature Explained

Sophos includes Config Studio 2.6 in the MR2 announcement even though it remains a separate browser tool rather than a new SFOS interface. For the underlying workflow, see Sophos Firewall Config Studio V2: More Than a Viewer, covering exports, Entities.xml, comparisons, and the editor.

Sophos says parsing, analysis, and report generation occur locally in the endpoint browser; the configuration is not uploaded to Sophos or another server. That matters because Entities.xml may contain internal networks, objects, policies, VPN definitions, certificate references, and organizational names.

Local processing is not automatically risk-free. The browser still downloads the application from the internet. Highly sensitive environments should consider code version, browser cache, offline use, endpoint hardening, and secure storage. An Entities.xml file does not belong unmanaged in Downloads, tickets, or ordinary cloud synchronization.

Config Studio 2.6 now covers five work areas:

• Configuration Report with Policy Test, analysis, and global search
• comparison of two or more configurations
• visual editor with bulk editing and XML, API, or curl output
• migration from Sophos UTM, SonicWall, FortiGate, and Palo Alto Networks
• backup/restore, Flexi Port, transceiver, and model compatibility

Merge Templates

Merge Templates combines baseline configurations with industry-specific templates. An MSP could merge a technical baseline for logging, DNS, administrative access, and standard objects with a template for clinics, schools, or branches.

Reuse saves rebuilding every firewall from scratch, but conflict handling remains critical:

• What happens when identical object names contain different values?
• Are UUIDs, references, and rule order resolved consistently?
• Which interface and zone references do not fit the target model?
• Does the merge create duplicate or overlapping rules?
• Can a restrictive object be replaced by a broader template value?

After merging, Duplicate Analysis, Shadow Rule Analysis, Usage References, and a complete Policy Test are mandatory. A technically successful merge does not prove the resulting policy is secure.

Improved Global Search

Global search finds configuration objects and jumps directly to them. This matters in large rulesets where one host may be referenced by firewall, NAT, TLS, web, or VPN configuration. Depending on data type, values, paths, and referenced elements may also be searchable.

Direct navigation is especially valuable for generic names such as Server, LAN_Network, or historically grown host groups, where the name alone reveals little about the actual use.

Search is not Usage Reference. Search asks, “Where can I find this object or value?” Usage Reference asks, “Which other elements depend on it?” Safe changes require both views. This capability is also urgently needed in the firewall interface itself.

More Informative Configuration Reports

Reports now show not only reference names in firewall, NAT, and TLS rules, but also the values and details behind them. A reviewer can see which hosts or networks are inside Webserver-Gruppe, rather than trusting a clean-sounding name that might hide Any, an overly broad subnet, or obsolete entries.

The report also supports Policy Test and analysis. Policy Test identifies which rule or route matches specified source and destination values. Analysis detects issues including shadowing and duplication. Since SFOS evaluates firewall rules top-down and stops at the first match, ordering is security logic, not decoration.

Config Studio 2.6: Migration, Comparison, and Export

Migration Analysis with Success Rates

Config Studio reports migration and conversion information, including the successfully converted share. A percentage is a quick indicator, not an acceptance certificate.

Sophos distinguishes:

• Supported: migrated automatically without substantive change
• Partial: migrated with gaps that must be completed
• Manual: must be recreated manually on Sophos Firewall
• Not supported: not migrated
• Action required: requires a decision before export

A 95 percent conversion may omit precisely certificates, passwords, VPNs, NAT, or special routing. The useful output is the list of unresolved, partial, or automatically resolved elements—not the green percentage.

Vendor policy models genuinely differ. FortiGate rules may be more interface-oriented while SFOS uses zones; Palo Alto has other object, zone, and policy models. Config Studio can convert syntax and structures, but cannot prove that security semantics remain identical.

Multi-File Configuration Diff

Multi-File Diff compares two or more configurations over time. Config Studio orders files by modification date and marks fields as added, removed, or changed.

Side-by-Side, Unified, and Semantic views are available. Semantic comparison is especially useful because plain XML diffs are noisy due to order, IDs, and formatting. Entity- and field-level comparison aims to reveal the actual configuration change.

This helps reconstruct changes and troubleshoot defects that do not appear immediately after one maintenance window. But it requires regularly saved configurations, reliable timestamps, and secure export handling. A copied file’s modification date is not necessarily the time of the firewall change. For defensible history, record filename, export time, hostname, serial number, firmware, and change ticket together.

Without version discipline, Multi-File Diff cannot invent history. The feature would be much stronger in Central with an immutable audit history than through manual uploads.

Backup/Restore, Flexi Port, and Speed Reference

Config Studio can check backup/restore compatibility and port layouts across Sophos Firewall models. It also lists Flexi Port modules and supported standards and speeds up to 25, 40, or 100 Gbit/s.

Before hardware migration, it helps establish:

• whether a backup can generally be restored
• how many physical ports are available
• whether existing Flexi Port modules are compatible
• which interface standards and speeds are supported

It does not replace migration design. LAGs, VLANs, bridges, HA, port names, zones, and interface mapping still require planning and verification.

Broader backup/restore compatibility applies to destinations from SFOS 20.0 MR2. Depending on source and target, the Backup-Restore Assistant maps interfaces. Physical ports can be reassigned, while VLANs and aliases follow parent interfaces and LAGs or bridges are rebuilt from mapped ports.

For Flexi Ports, mechanical fit is not enough. Model generation, form factor, transceiver, supported standard, port speed, breakout behavior, and SFOS version must all align. Config Studio speeds up reference work but cannot replace link and failover testing.

Dark Mode

The release notes also mention Dark Mode. It is a small usability improvement, not a firewall feature. Yet it is symbolic: even Dark Mode arrives first in external Config Studio while the local WebAdmin console has progressed only slowly in appearance and ergonomics for years.

What the Editor Can Output

The editor imports or creates configurations, performs bulk changes, and previews output as Import XML, API Request, or curl. It can also download XML or a TAR archive for import through Backup & firmware > Import export.

That power increases administrator responsibility. A generated API request is not automatically idempotent. A successful import does not prove that rule order, object use, NAT, VPN, and security policy are functionally correct. Put output into the change ticket, send the diff through review, and test the resulting firewall through real data paths.

More Than 50 Fixes Are the Real Reason for MR2

Sophos lists more than 50 reliability, stability, and security fixes. Not every fix affects every deployment, but several are operationally serious.

HA and Failsafe Are Not Edge Cases

Several fixes affect appliance operation, not one isolated feature:

• NC-181331: A full configuration partition could put the firewall into failsafe mode.
• NC-180110: The logging daemon failed on the primary, sending the HA device into failsafe.
• NC-177441: After upgrading to v22 GA, Postgres could put the original primary into failsafe.
• NC-178906: RED Server Service startup failure could trigger failsafe.
• NC-177467: The auxiliary failed to start under many concurrent unauthenticated SSH connection attempts.

Different causes, same operational result: services disappear, the firewall enters protection mode, or the HA peer is unavailable despite a previously green cluster view. After upgrading, HA status: Active-Passive is insufficient; test synchronization, service state, failover, and real traffic.

IPsec Fixes Reach Deep into the Data Path

• NC-180433: Multicast through a VPN tunnel could repeatedly crash the firewall.
• NC-171719: ESP traffic followed incorrect routing in an SD-WAN scenario.
• NC-180520: With IPsec Acceleration enabled, an XFRM gateway remained unavailable after upgrade when a tunnel was bound to an alias IP and ESP arrived on another WAN port.
• NC-176855: IPv6 throughput over route-based IPsec was impaired.
• NC-178121: Drag-and-drop could move site-to-site IPsec connections to incorrect positions in a Failover Group.

A tunnel status of Active proves nothing in these cases. Test XFRM interface, routing table, SD-WAN decision, ESP path, MTU, IPv4, and IPv6 separately. For Failover Groups, verify order and switching against documented priority.

Logging and Reporting Could Cause Outages Themselves

NC-155252 is particularly unpleasant: high reporting disk I/O caused CPU spikes and intermittent internet outages lasting up to one minute. An analysis subsystem affected the production data path.

NC-178745 covers an HA device reboot caused by out-of-memory in the Logging Framework, and NC-181520 improves Log Viewer performance. Together they show that SFOS logging is not a harmless side feature. Storage, database, Garner, Log Viewer, and Central Reporting are operationally closer to the system than the UI suggests.

After MR2, verify more than the arrival of new log lines:

• Are firewall, IPS, WAF, authentication, and VPN events complete?
• Is the timeline free of gaps?
• Does the external syslog collector still receive data?
• Are CPU, memory, and disk I/O stable under normal load?
• Are reports generated without affecting the data path?

Central Fixes Expose the Limits of a “Single Pane of Glass”

NC-181175 left group policies from Sophos Central pending. NC-180513 affected configuration import from Central View after upgrading to MR1. NC-181904 prevented quarantine email release through Central.

The common issue: the central interface may accept or display an operation without proving that the target firewall executed it. After a group policy push, verify on-device object, rule, order, and timestamp. A closed success dialog in Central is not technical proof of commit.

This is why I do not judge maintenance releases solely by feature-list length. A fix for a firewall entering failsafe or rebooting due to logging, Postgres, SD-WAN, or multicast is more valuable than a dashboard tile.

Yet the number of fixes is not an automatic quality certificate. It shows defects were corrected—and how many serious defects existed before. Critical HA, VPN, or WAF environments should neither stay forever on an old build out of fear nor deploy MR2 everywhere untested on day one.

What Administrators Should Check Before Upgrading

Sophos recommends installing MR2 promptly for its security, stability, and performance fixes. That is reasonable, but “promptly” does not mean blindly in production.

Legacy VLAN Tagging on Bridges Blocks MR2

MR2 introduces a hard upgrade block for old CLI-based VLAN tagging on bridge interfaces. A configuration still using legacy system vlan-tag cannot upgrade to SFOS 22.0 MR2 or later.

It must be cleaned up or migrated beforehand. Backups containing this legacy configuration also cannot be restored to SFOS 22.0 GA or later, which matters in long-lived deployments modified through the CLI years ago.

Previous v22 Barriers Still Apply

• Legacy Remote Access IPsec must be removed or migrated before MR1 or MR2.
• SFOS 22 requires more storage; some desktop, virtual, or software appliances need adjustment.
• Policy-based IPsec behavior changed with GA and corresponding tunnels need validation.
• XG and SG hardware does not support SFOS 22.
• RED 15, RED 15w, and RED 50 have been unsupported since v21.5.

My Upgrade Procedure

For production firewalls, I would at minimum:

1. Create a current backup and store it externally.
2. Verify support, licensing, and the approved upgrade path.
3. Exclude legacy Remote Access IPsec and CLI VLAN tagging on bridges.
4. Check Control Center disk-space warnings.
5. For HA, verify both nodes, synchronization, and available firmware.
6. Document critical VPNs, WAF publishing, mail flows, SD-WAN rules, and authentication.
7. Install MR2 first on a representative test or less critical appliance.
8. Test logs, pattern version, HA, routing, DNS, VPN, WebAdmin, reporting, and central policy pushes.

A before-and-after test is particularly valuable with such a large fix list. Otherwise you know the firmware is newer, not whether critical data paths behave exactly as intended.

Since version 20, SFOS can automatically roll back firmware if configuration migration fails. This reduces the risk of starting with Factory Configuration, but does not cover every scenario, including unsupported upgrade paths and certain Setup Assistant flows. After automatic rollback, analyze migration.log and migrationhash.log.

Automatic rollback does not replace an externally stored backup, the Secure Storage Master Key, or console access. It primarily protects against failed configuration migration; it does not prove WAF, VPN, HA, or reporting are correct after a technically successful upgrade.

For my direct MR2 test, I will measure or trigger the same checks before and after:

• reboot and complete service startup
• WebAdmin login and responsiveness of large rule lists
• local and external log flow
• IPsec traffic, rekey, and failover
• Central Policy Push verified on the firewall
• pattern updates for IPS and Application Control
• STAS reauthentication and behavior of an unknown client IP
• HA synchronization and a controlled role change if the test system is clustered

Only then can I say whether MR2 is truly better in my environment. A successful installation and green Control Center are not enough.

What the First Community Reports Tell Us

The feedback thread opened on release day and is only hours old at the time of this assessment. It cannot prove that MR2 is stable or problematic.

Two discussions are nevertheless noteworthy:

• An operator of an XGS 5500 Active-Passive HA cluster asks specifically about test depth because NC-177467 affected the site for months under MR1. Sophos lists it as fixed in MR2; it concerns an auxiliary failing to start under many simultaneous unauthenticated SSH attempts.
• On PQC signatures, a Sophos employee confirms they are deliberately disabled. Because PQC TLS is increasing in browsers and applications, immediate enablement could generate many alerts. The recommended approach is Allow with logging first, and blocking only later if necessary.

That is the right early-release discussion: concrete tests, case IDs, and reproducible feedback rather than blanket “works” or “broken” claims. I will continue watching the thread for HA, IPsec, WAF, STAS, and reporting reports.

Config Studio Becomes the Spare-Parts Bin for an Old Interface

Now for the uncomfortable part.

Config Studio 2.6 is a good tool. Template merging, object search, resolved references in reports, multi-version comparisons, and hardware migration preparation are genuine administrator features. My criticism is not that Sophos builds them, but where it builds them.

Sophos now names Config Studio directly in firewall release notes and the official MR2 announcement. It increasingly looks like the strategic answer to problems that belong in WebAdmin or Sophos Central.

The local firewall UI remains old and often slow with larger configurations. Bulk changes are inadequate. Object usage, genuine global search, clean diffs, NAT cloning, rule-conflict detection, and a modern change workflow are missing where administrators work daily. Central closes only part of the gap.

This is more than visual design. A modern firewall interface should provide:

• candidate configuration instead of instantly distributed individual changes
• complete before/after diffs before commit
• dependency validation across objects, rules, NAT, VPN, and TLS
• atomic commit or a clear transaction state
• validated rollback to the last known state
• real user, time, and source attribution in the audit trail
• bulk operations with preview and conflict checking
• consistent API output for reproducible changes

Config Studio recreates pieces outside the system. It analyzes an export, produces XML or API requests, and helps with diffs. But a gap remains between that offline view and the firewall’s active runtime state. Sessions, dynamic routing, HA state, current patterns, certificate status, and loaded configuration are not the same as a local Entities.xml.

It would be excessive to claim from one announcement that Sophos will never fundamentally modernize SFOS. There is no confirmed statement. Still, the signal is poor: the most visible progress in usability, search, comparison, and configuration work once again lands outside the actual management interfaces.

The workflow stays fragmented:

1. Export configuration from the firewall.
2. Extract the archive and locate Entities.xml.
3. Load it into a separate browser tool.
4. Analyze, compare, or edit it there.
5. Export the result and return it through XML, API, or curl.

That is acceptable for an audit, but indirect for modern, safe, traceable administration. Config Studio is not solving one niche case; it receives exactly the low-hanging fruit Sophos administrators have requested for years.

If Sophos now presents Config Studio as a major item in normal firewall release notes, it can no longer be dismissed as a small helper. It is visibly part of the administration strategy. Sophos should explain which functions will eventually reach WebAdmin or Central and which will remain in the browser tool.

Without such a roadmap, the impression is that the old, slow, and increasingly unfriendly interface will remain while administrators are told to use Config Studio for modern workflows. That is not a confirmed Sophos plan, but it is the direction the product currently communicates.

Why This Gives UniFi an Easy Opening

UniFi is not a full replacement for every Sophos Firewall. Depending on licensing and architecture, Sophos offers deeper security, IPS, Web Protection, WAF, endpoint integration, MDR/XDR integration, and classic enterprise features. A fair comparison cannot erase those differences.

But perceived product quality is shaped by usability every day.

Ubiquiti visibly invests in design, mobile apps, consistent navigation, topology, simple adoption, and an interface understandable without years of product experience. Not every UniFi feature is technically deeper, but the product feels more modern—and that influences buying decisions more than traditional firewall vendors like to admit.

A small IT team does not only compare IPS data sheets. It asks:

• How quickly can I find a device, rule, or client?
• Can I inspect the environment sensibly from a phone?
• Can I understand warnings and dependencies without specialist knowledge?
• How many clicks does a routine change take?
• Does the product feel like one platform or several adjacent tools?

Sophos unnecessarily gives vendors such as Ubiquiti an opening here. Sophos Firewall can do more in security terms and remains the more sensible choice for many SMB environments. But if modern search, diffs, templates, and bulk changes require separate Config Studio while the core interface remains old and sluggish, Sophos loses trust at the most visible layer.

Good security needs more than a strong engine. It requires an interface in which people can understand rules, identify mistakes, and execute changes safely. Usability is therefore part of operational security, not a cosmetic extra.

Conclusion: Install MR2, but the Product Problem Remains

SFOS 22.0 MR2 is not a major feature release. It is an important maintenance release with useful additions.

PQC control arrives at the right time but should initially run in observation mode. Better generative AI detection helps visibility and policy but does not replace DLP or AI governance. Chromebook administrators must actively deploy the Manifest V3 extension. STAS should be less disruptive but requires deliberate identity-policy testing. Let’s Encrypt is prepared for its next certificate chains. And numerous fixes address defects capable of causing real production outages.

I will install MR2 after backup and preflight, then test these exact data paths. Anyone affected by the listed HA, VPN, reporting, Central, or failsafe defects has good reasons to update. Whether Build 546 ultimately runs more calmly or brings new regressions cannot be answered responsibly on release day.

My criticism remains clear: Config Studio 2.6 is useful, but its prominent role reinforces the impression that Sophos is moving modern administration into a side tool. This is not confirmation that a new SFOS interface has been abandoned, but it is a strategic warning sign.

Sophos has a strong firewall foundation. The company should finally give administrators a management experience worthy of that foundation. Otherwise, modern platforms will win not necessarily through better security, but because they take the person at the screen more seriously.

Until next time,
Joe

FAQ