Sophos Firewall v23: Progress, Limitations, and Open Questions

I have been testing Sophos Firewall v23 in my homelab for nearly two weeks. My first assessment is mixed: I like the new rule view, and the REST API is a good approach. At the same time, the interface still feels like a product whose individual sections were developed at different times. One new table does not make administration modern throughout.

That matters more to me in this release than the number of new features. I want to maintain rules clearly, automate recurring tasks, and move between sections without encountering a different interaction model each time. v23 makes progress, but leaves some fundamental wishes unanswered. This is my first experience report, supplemented by a technical assessment of the larger changes.

Sophos Firewall v23 is currently in its Early Access Program (EAP). Based on the release pattern of previous years, I expect the final version in December 2026. I have been testing the firmware in my homelab for nearly two weeks, but have not deployed it in production. My impressions of usability are personal observations; HA and WAF performance figures come from Sophos.

Rule management: a better filter does not replace every group view

The new rule view is one of the changes I like in my homelab. The continuous table with customizable and frozen columns, search, and filters is a good step in my view. Being able to display destinations, services, and protection profiles side by side makes more sense than opening several rules for every comparison. Persistent device identity and HA status also fit administration where keeping track of the system matters.

The disagreement over groups is nevertheless understandable. In early feedback, administrators criticize the new view for not reproducing the familiar collapsible groups. For large rule sets, a long table can remain difficult to navigate despite its filters. This concerns safe administration, rather than personal taste alone.

The separate Sophos explanation of rule management clarifies that existing groups and rule order remain intact, the new table exposes group membership as a column, and both views are currently available through a switch. Groups are not being removed. The new view presents them differently. Discussed tag-based organization is a possible future development, rather than a committed feature of the current build.

I like the new view, but I also understand the criticism from administrators with very large rule sets. With thousands of rules, filters and presentation particularly need to keep the effective order understandable. A group is not a separate security boundary independent of the global order.

What still bothers me after nearly two weeks is the lack of consistency in the interface. Design and functionality do not match across all sections. Functions such as cloning are not available throughout according to the same interaction model, and responsive layouts are not equally well implemented everywhere. This becomes particularly noticeable when moving between configuration sections.

I expect comparable tasks in an administration tool to work in comparable ways. Cleaning up a rule set or creating several similar configurations calls for consistent interaction. One successful view makes the differences elsewhere in the product more apparent. I want Sophos to improve the interface across section boundaries.

HTTP/2 for WebAdmin is welcome, but does not solve that problem. It can improve delivery of page resources, especially over higher-latency connections. It changes neither the interaction model nor automatically the time needed for configuration changes. This report does not provide a controlled before-and-after performance measurement.

REST API: the progress lies in a verifiable workflow

I consider the REST API one of the most useful approaches in v23. Not every recurring administration task belongs in a manually operated interface. API keys, OpenAPI 3.0, and an integrated guide provide a useful foundation for custom tools. Keys, expiration, and allowed IP hosts are managed under Administration > API access.

For me, the practical value lies in controlled workflows: a tool reads the existing state, identifies a specific difference, changes a value deliberately, and retrieves the saved result again. That could make recurring work across multiple sites easier to track. This is a useful application, rather than a multi-site rollout I have already demonstrated.

An API alone does not make automation reliable. An unreachable site needs to appear as a failure. Retries must not create duplicate objects, and partial failures need a log. Those are the qualities against which I judge an integration.

API keys belong on a controlled automation host, with limited validity and restricted network access. The interactive guide can send real requests to the firewall. Write examples are therefore actual configuration changes and deserve the same review as changes made through the UI.

Complete coverage of existing tasks remains an open question for me. Existing XML automation can only be replaced when the OpenAPI file for the specific build actually describes the required operations. Sophos still explicitly assigning WAF changes to the XML API is a good reason to look closely. My assessment of the REST API is therefore: the right direction, with decisive details in coverage, error handling, and permissions.

The WAF becomes more useful, but capacity remains finite

The Web Application Firewall gains actions per site path entry. This is useful functionality for published applications and partly closes a gap with the former SG/UTM9. The four actions have distinctly different security effects:

A redirect changes the client’s destination; it is not an internal backend switch. A WebSocket exception does not add another protection layer. For an application with a protected portal and a WebSocket channel, you need to decide deliberately where each inspection takes place. A working connection says nothing about whether its traffic was inspected.

Up to 128 paths can be grouped in a single site path route entry. The WAF rule limit is 100 by default, with an option to increase it to 200. According to the guide, existing WAF rules migrate to the new model with Protect as the default action. The guide explicitly describes support through the UI and XML API. That does not automatically establish that every WAF workflow is already available through the new REST API.

The second major change concerns processing: Sophos is moving the WAF to Apache Event MPM. The vendor describes better worker utilization and greater resilience under concurrent requests. The roughly 800 parallel requests mentioned in the launch announcement refer to potential saturation of the previous architecture, rather than a universal old rule limit or a guaranteed new throughput figure.

For me, the additional path actions are a tangible improvement. I assess the performance promises separately: even better queuing can leave an application unusably slow. Response times, error rates, and backend latency matter more than the number of accepted connections. I am not providing a WAF benchmark under comparable load here. More configurable rules do not produce a proportionately larger appliance.

The new HTTP/2 support for WebAdmin should also not be confused with WAF protocol support. In the supplied Reddit thread, HTTP/2 for the WAF is discussed as a future request. A reply expresses interest, without a commitment. I will not turn that into a v23 feature, much less a promise of HTTP/3.

High availability: 300 ms does not mean uninterrupted applications

The HA changes are among the most interesting parts of this release. Sophos states that the peer failure detection window falls from four seconds to 300 milliseconds. That produces the vendor’s figure of approximately 13 times faster detection.

This number describes failure detection. It does not guarantee that a phone call, VPN, or application operates normally again after 300 ms. Takeover by the remaining node, traffic delivery by neighboring devices, and the behavior of existing sessions also contribute to the result. A ping alone is a poor representation of that.

HA monitoring also includes specific hardware components such as the SSD. A node can still respond over the HA link while its storage is already causing problems. Using hardware health as a failover criterion therefore makes sense. Continuing on a healthy node does not replace investigating the cause or replacing faulty hardware.

Prioritized HA heartbeat processing through a path separated from normal data traffic is equally relevant. According to Sophos, priority adapts to system load. This should reduce the risk of delayed keepalives under heavy CPU or traffic load being mistaken for device failure. The guide describes substantially fewer missed heartbeats and unexpected failovers, rather than absolute immunity to false failovers.

I consider these architectural changes sensible. Faster detection offers little benefit if a cluster switches unnecessarily under load. Production acceptance therefore depends on both qualities together. My homelab impressions so far do not establish a measured HA interruption time or stability under production load.

DNS and patch status: two different kinds of trust

DNS over HTTPS encrypts transport to the chosen resolver. DNSSEC validates the signature chain of signed DNS data. They complement each other: DoH alone does not authenticate a DNS answer, and DNSSEC does not make a query confidential. The resolver still sees what it is asked to resolve, and not every zone is signed.

Sophos describes DoH to Sophos or a generic provider, alongside simplified DNS Protection activation. This does not mean that every client automatically uses the intended DNS path. Browsers with their own DoH settings, internal resolvers, and private namespaces belong in the design. What matters to me is that internal and external names continue to resolve through the intended path, and that filtering and DNSSEC validation produce understandable decisions.

The new hotfix view is less spectacular but very useful operationally. Under Backup and Firmware, applied security updates become visible with CVE, description, date, severity, and advisory link. The guide also names the Log Viewer, email notifications, and Central Firewall Reporting.

A firmware version alone therefore does not fully describe the patch state. A hotfix entry can help establish that a specific correction was applied. It proves neither that every vulnerability has been fixed nor that a previously vulnerable firewall was never compromised.

Recurring firmware schedules in Sophos Fusion complement that transparency with staged rollouts and per-firewall overrides. Major updates can be included optionally. For me, a test group should come first, followed by checking critical functions and then the next group. Automation reduces manual work; it does not replace a recovery plan.

DHCP, mDNS, and routing deserve their own acceptance tests

The DHCP service moves to the new Control Plane. Sophos describes better lease processing, more reservations, firewall checks ahead of the service to mitigate floods, and additional UI settings. This is more than a cosmetic change. For a fundamental service such as DHCP, leases, renewals, reservations, and custom options deserve attention. Reaching a website does not establish that PXE or a rarely restarted specialist device also receives the correct configuration.

The mDNS reflector enables service discovery across selected VLANs or subnets with IPv4 and IPv6. Interfaces and services can be selected. It does not automatically permit the subsequent data connection. A printer can become visible while the print job fails because the necessary rule is missing. Conversely, a guest network should not discover internal devices simply because reflecting every service is the easiest setting. Negative tests belong in acceptance testing here.

For routing, Sophos updates FRR and adds a unified console. BFD for BGP and static routes is explicitly described as experimental for standalone deployments. BFD detects forwarding path failures and should not be confused with the HA heartbeat. For me, its experimental status is a clear reason to avoid making it a production dependency yet.

IPv6 IPoE, 4in6 tunnels including IPIP/DS-Lite, and VNE-aware DDNS expand connectivity options, including Japan’s Xpass. Improvements to tunnel endpoints and MTU/MSS are useful where the provider requires this model. They do not amount to a universal solution for every IPv6 issue. For IONOS Cloud, Sophos describes deploying an official image through Bring Your Own Image, without a Marketplace listing and with manual lifecycle management.

Identity: the firewall upgrade does not provide every prerequisite

The Entra ID enhancement concerns Synchronized User ID working with Sophos Endpoint. It is not simply a new name for the existing portal login. The guide describes hybrid environments with local AD and Entra ID, mapping through UPN and sAMAccountName respectively, and Windows endpoint support starting with the stated endpoint version 2025.1. An Entra ID environment alone does not provide that identification. Endpoint version, licensing, and existing SSO configuration need to fit.

Google Workspace is described as an OpenID Connect identity provider for the Captive Portal, VPN Portal, Sophos Connect, and WebAdmin, including IdP-enforced MFA. The guide specifies a single IdP for a given set of services. Authentication and authorization remain separate checks: a valid Google account must not inadvertently acquire administrative privileges.

For MFA onboarding, the QR code can be delivered by email. According to the guide, this is the default for new deployments, while existing and migrated deployments retain portal onboarding. Unused codes expire after 24 hours. An enrollment QR code contains the secret relevant to the authenticator; the mailbox and re-enrollment process need corresponding protection. Email delivery alone is not secure identity verification.

For shared servers, Sophos describes SATC with an XDR Sensor alongside an existing endpoint or AV solution. This is intended to enable user-specific policies even when multiple sessions share one server IP. Supported operating systems, licensing, and the specific combination with third-party software need checking before deployment.

The new Chromebook extension uses Manifest V3 and is intended for all supported SFOS versions. It is therefore not an exclusive reason to upgrade to v23. On shared devices, my main interest is whether identity mapping reliably ends after logout and user changes.

AI and NDR: the decision needs to remain visible

The Firewall Assistant in Sophos Fusion focuses on firewall rules in phase one. It reads configuration and answers questions. Its deliberate exception is creating a new rule, disabled and placed last in the table. Review and activation remain with the administrator. According to the guide, its data access matches what that administrator can see through Fusion SSO.

I like that boundary. A draft still needs checking against specific objects, services, users, protection profiles, and rule position. Even a disabled rule is already a saved configuration change. A well-worded assistant response is not evidence of security.

The Generative AI web category and related application filters help control sanctioned AI services in the Sophos AI Defense context. Allowing a domain does not establish which data belongs in a prompt. Network controls do not provide complete content inspection of every upload or replace data classification. Additional Sophos services, licenses, and their own capabilities need separate consideration.

For NDR Essentials and NDR Active Threat Intelligence, Sophos describes additional alerting without automatic endpoint isolation or a red Heartbeat status. This separates visibility from immediate blocking. It does not mean that every Active Threat Response action is disabled. Where a response is not automatic, an alert needs an owner and an escalation path.

Smaller changes include ID-based references for email Content Control Lists and versioned web category definitions in the backend. Those details rarely receive top billing, but they can matter for consistent configuration during upgrades and restores.

Migration comes before the upgrade

The most important change is outside the AI section: Sophos is removing the native eDirectory server type. According to the v23 authentication documentation, an existing eDirectory configuration must be migrated to a supported authentication type and removed before upgrading. Otherwise, the upgrade fails.

For affected environments, this is a real migration project. A successful login through a replacement integration does not establish that automatic user identification, group mapping, and every rule built on them still work. Anyone relying on directory SSO needs to verify the new identity mapping separately. I would complete that transition before changing firmware so that subsequent authentication problems can be isolated.

EAP1 is another boundary. Sophos directs support during the Early Access Program to its community forums. For me, this build belongs in a controlled test environment with a recovery plan. A public announcement does not approve it for my own critical infrastructure.

What the early feedback actually establishes

The supplied EAP1 feedback thread includes criticism of the rule view and a report from a VMware user: following an upgrade from 22.0.1, ping and SSH were reachable, but WebAdmin remained unavailable after 30 minutes. In a later reply captured by the search index, the same user reported that the interface became reachable after approximately 40 minutes.

This is one report, with no cause reproduced by me. I treat it neither as a general VMware defect nor as a normal upgrade duration. It does highlight the need to check management access, the upgrade window, and recovery deliberately. Early threads change quickly; replies and counterexamples belong in the assessment alongside the original problem report.

In the Reddit release thread, WAF questions also show which gaps continue to concern operators. That is useful context, but neither a benchmark nor a complete list of confirmed product defects.

My first assessment after nearly two weeks

After nearly two weeks in my homelab, I like the direction of Sophos Firewall v23, but the release does not yet feel coherent throughout. The new rule view is a good step. The REST API is the right approach for controlled automation of recurring tasks. The interface still has differences in design, functionality, and responsive layouts that I do not expect from modern firewall administration.

HA, WAF, and patch transparency matter more to me technically than the AI label. Their announced improvements deserve attention. My first tests replace neither a load comparison nor experience with a production cluster. For those areas, vendor figures and acceptance in the relevant environment remain decisive.

I am continuing to test v23 in my homelab. This initial phase is still too early for me to deploy it in production. Before the final version arrives, I particularly want Sophos to make the good new rule view a standard for the rest of the interface: consistent actions, usable layouts at different window sizes, and fewer differences between comparable tasks. That would help me more in daily work than another isolated feature on the release list.

Until next time,
Joe

FAQ