Sophos Firewall: Best Practices for Network Security

Firewalls used to be the place where attacks were stopped. Today, they are among the most attractive targets themselves. That makes sense: a firewall sits in a privileged position between the internet, site networks, cloud services, VPN access and internal applications. Anyone who finds a vulnerability, a weak password or a misconfiguration here is no longer standing outside the door, but often already inside the building.

That is why it is no longer enough to treat a firewall only as a policy engine for allow and deny rules. Modern network security needs three pillars: hardening, protection and detection and response. The attack surface must be reduced before an attack, attacks must be blocked cleanly while they are happening, and afterwards it must be possible to detect quickly what happened.

I have been working with Sophos Firewall environments of very different sizes and industries for many years. The following recommendations are therefore not meant as a theoretical feature list, but as the things that repeatedly prove useful in real customer environments, migrations, audits and support cases.

Why firewalls are so strongly in focus

A firewall is a worthwhile target for attackers because it is exposed, privileged and often business-critical. In addition, many environments run firewalls, VPN portals or remote management access for years. Not every environment is patched cleanly, not every management surface is truly isolated and not every login is protected by multi-factor authentication.

In practice, three recurring causes are especially visible in successful attacks:

• Vulnerabilities in firewalls and edge systems, especially when patches are installed late or not at all.
• Compromised credentials and identity attacks, often without MFA or with weak MFA configuration. The Sophos Active Adversary Report 2026 lists identity-related causes as the root cause in 67.32% of the cases analyzed.
• Exposed systems, such as RDP, VPN portals, User Portals or admin interfaces that are directly reachable from the internet.

The key point behind this: many attacks today are no longer spectacular “break-ins”. Very often, attackers simply log in. If a user account, admin password or VPN access has been compromised, the first step initially looks to the firewall like legitimate use.

The three pillars of modern network security

Sophos describes modern network protection as a spectrum from proactive to reactive:

1. Hardening: Reduce the attack surface, remove outdated systems, use secure products, review configurations and restrict access.
2. Protection: Block attacks, control encrypted traffic and use Web, IPS, Zero-Day and Application Control features sensibly.
3. Detection and Response: Detect suspicious activity, isolate compromised devices, correlate threat data and respond automatically.

Many firewalls are traditionally strong in the second pillar. They block traffic, inspect packets, detect known patterns and enforce policies. That is important, but no longer sufficient. If the firewall itself is misconfigured, if Remote Access runs without MFA or if an unpatched system remains productive, there is a structural problem that no single IPS rule can solve cleanly.

My experience shows that the best results do not come from one magic feature, but from clean baseline configuration, regular reviews and a firewall that is integrated into the broader security process.

Pillar 1: Hardening before the attack

Hardening is the part of security work that rarely gets applause, but makes the difference in an incident. It is about less attack surface, fewer legacy systems, fewer open management paths and less dependence on manual reactions.

Reduce infrastructure and remove old systems

The easiest way to reduce an attack surface is sometimes the most uncomfortable one: switch things off. Every old appliance, forgotten VPN service, management portal and unsupported server is an additional attack point. Systems at the network edge, or systems that indirectly enable privileged access to internal networks, are especially critical.

For Sophos Firewall admins, this means in concrete terms:

• Regularly check which firewalls, REDs, VPN gateways, WLAN controllers, reverse proxies and Remote Access components are still productive.
• Remove end-of-life or end-of-support systems from privileged positions.
• Consolidate functions when this reduces complexity: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting and central management should be aligned as cleanly as possible.
• Document which services really need to be reachable from the internet.

The goal is not to put as much as possible into one product. The goal is to avoid blind legacy systems. A small, current and well-controlled infrastructure is almost always safer than a large, historically grown environment with many “it has always been that way” exceptions.

Secure management access consistently

One of the most important best practices is simple: the Web Admin Console and the User Portal should not be unnecessarily reachable from the WAN. If remote administration is necessary, it should happen through Sophos Central, a dedicated management network, ZTNA or another controlled path.

In customer environments I repeatedly see that the issue is not the most complex attack technique, but an old admin access, a historically grown portal or a “temporary” exception that was never removed. Exactly these places belong in a regular firewall review.

The following points should be checked in every Sophos Firewall environment:

• Enable MFA for administrators, especially for the default admin and all accounts with extensive rights.
• Enforce MFA for VPN and portal logins if such access is still used.
• Avoid WAN access to the Admin Console and User Portal or restrict it strongly to dedicated source networks.
• Configure strong password rules for users and administrators.
• Secure SSH, ideally with public key authentication and without broad WAN exposure.
• Enable central backups and protect backup access, because configuration backups can contain sensitive information.
• Enable notifications and logging so security-relevant events do not disappear in daily operations.

Backups are often underestimated. A firewall backup does not only contain harmless settings, but information about networks, rules, certificates, VPNs and internal structures. Backups must therefore be encrypted, stored in a controlled way and tested regularly.

Set Device Access and Local Service ACL consciously

When discussing WAN access, Sophos Firewall specifically requires a discussion about Device Access and Local Service ACL. The Device Access matrix defines by zone which local firewall services are reachable: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, VPN portals and other services.

The best practice is very simple, but effective: from the WAN zone, only what is really needed should be reachable. Admin access, SSH and User Portal do not belong broadly on the internet. If exceptions are necessary, they should be limited through Local Service ACL Exception Rules to specific source IP addresses or management networks.

Country rules as minimum protection

If fixed source IP addresses are not realistic, I recommend working at least with country rules. Access from only a few relevant countries is still much better than global reachability. Alternatively, countries can be blocked if the company has no relation to them and employees or admins do not typically travel there. This is not a replacement for MFA, strong roles and clean ACLs, but it reduces unnecessary noise and many automated access attempts.

From my perspective, this is one of the first points in every firewall review. Many risky configurations do not arise from bad intentions, but because a service was briefly opened for a migration, a support case or a test and was never closed again. These details distinguish a firewall that merely runs from a firewall that is operated cleanly.

Check Login Security and admin roles

MFA is important, but the login layer consists of more than a second factor. Administrators should use personal, traceable accounts and should not permanently work with a shared full admin. Role-based permissions help separate support, reporting or helpdesk access from actual firewall administration.

Failed login attempts should also be limited, sessions should end cleanly and admin access should be restricted to defined networks. A login disclaimer can make legal sense in some environments, but it is not a replacement for real technical controls. Strong password policies, short inactive sessions, brute-force protection and least privilege are more important.

Avoid patch fatigue: Hotfixes must work quickly

Patching is one of those topics where theory and practice are far apart. Of course every admin knows that firmware updates are important. In reality, however, they mean maintenance windows, risk assessment, HA planning, communication with business departments and sometimes downtime. This leads to patch fatigue: updates are postponed because they are cumbersome.

This is exactly where the time factor becomes dangerous. Identity attacks are now the dominant root cause, but vulnerability exploitation remains a real vector, especially for edge systems such as firewalls, VPNs and other internet-facing services. The Sophos Active Adversary Report 2026 cites CVE-2024-40766 in SonicOS as an example, visible in a large part of the confirmed exploit cases in the dataset. At the same time, the median time between vendor advisory or patch and observed exploitation was 322 days. That is a very clear signal: patch fatigue is not an abstract operational problem, but an attack window.

Sophos Firewall takes an important step here: Automated Hotfixes allow security-relevant live patches without a classic maintenance window. For admins this is extremely valuable, because the critical protection effect does not wait until the next available maintenance slot.

Still, Hotfixes do not replace a clean update strategy. Hotfixes close the dangerous gap between a discovered vulnerability and the regular firmware upgrade. The best practice is therefore:

• Keep Hotfixes enabled.
• Check firmware versions regularly and document firmware update preparation.
• Read upgrade paths and compatibility notes in advance.
• Prepare backups and a rollback plan.
• Plan HA clusters and remote sites separately.

Do not treat VPN as proof of trust

Remote Access VPN was the standard for years. The problem: classic VPN often thinks in networks, not in applications. Anyone who connects successfully is already in a trusted area from the perspective of many environments. If the endpoint is compromised or credentials have been stolen, an attacker can move on from there.

Zero Trust Network Access (ZTNA) does not solve this problem by magic, but through a better principle: Trust nothing, verify everything. Access is not granted broadly to a network, but evaluated per user, device, state and application. A device must be healthy and compliant, the identity must be verified and the policy decides granularly which application is reachable.

ZTNA is not an automatic Sophos decision

The important point is this: ZTNA is not a decision that must automatically mean Sophos ZTNA. Depending on the environment, specialized ZTNA, SSE or SASE providers may be functionally further ahead, offer better integrations or fit the organization better. What matters is not the vendor name, but whether identity, device posture, application access, logging and operations work together cleanly.

This is also my general stance in Sophos projects: I do not automatically choose Sophos for every topic. If a third-party solution for ZTNA, SSE, Threat Intelligence, SIEM or NDR fits better technically, then that is the better recommendation. A good security architecture does not come from maximum vendor lock-in, but from cleanly integrated components with clear responsibility.

For pure Sophos environments, the integration can still be interesting because ZTNA, Endpoint, Firewall and Sophos Central can be used together. A compromised or non-compliant device can lose access without an admin first having to rebuild firewall rules manually. It is also worth looking at the ZTNA Gateway on the Sophos Firewall. In mixed or larger environments, however, one should compare deliberately and not automatically set the existing firewall vendor as the ZTNA platform.

Anyone still relying heavily on SSL VPN or IPsec Remote Access should at least check these points:

• Enforce MFA for every Remote Access login.
• Remove old or unused VPN users.
• Control group import from AD or Entra ID so Remote Access is not enabled unintentionally.
• Reduce split tunnel, allowed networks and permissions to the minimum.
• Plan a step-by-step migration to a suitable ZTNA, SSE or SASE solution, especially for internal web apps, RDP, SSH, administration portals and business applications.

Segmentation against lateral movement

When attackers get in with valid credentials or through an exposed service, internal segmentation decides how far they can move. A firewall should therefore not only be a perimeter gateway, but should cleanly separate internal zones: users, servers, management, IoT, guest networks, production, backup and especially critical systems do not belong blindly in the same trust model.

In practice, this means building VLANs and zones not only for tidiness, but protecting them with real firewall rules. Between user and server networks, only the required applications should be allowed. Management access belongs in dedicated admin networks. IoT and printer networks should not be able to talk freely to servers. Backups and domain controllers deserve especially restrictive rules and good logging.

This closes the loop with the statement “attackers log in”. If a compromised account has access to an application but not to the whole network, an incident does not automatically become a full compromise.

In new projects, I therefore plan segmentation as early as possible. It is still possible afterwards, but significantly harder because applications, exceptions and historical dependencies first have to be untangled.

Make misconfigurations visible

A firewall can be technically very powerful and still become dangerous through bad configuration. Rules that are too broad, “Any” objects, weak authentication, missing IPS policies, disabled pattern updates or open portals are typical examples. The difficult part is that in grown environments, these risks are not always immediately visible.

The Sophos Firewall Health Check addresses exactly this problem. It checks dozens of settings against best practices and benchmarks and shows in the Control Center where configurations are risky or deviate from recommended standards. Results are prioritized by risk, lead directly to the affected settings and can be fixed or consciously overridden depending on the situation.

The Health Check is especially helpful for recurring operational processes:

• after a new firewall rollout,
• after larger rule changes,
• before and after firmware upgrades,
• before audits,
• after migrations from old hardware,
• as a regular quarterly check.

But this is also important: a Health Check does not remove the need for admin judgement. Not every recommendation fits every environment. Some points have compliance or operational reasons, others are clear security gaps. The key is to evaluate deviations consciously and not let them grow unnoticed.

From my perspective, the Health Check is especially strong as an ongoing operational tool. It is not only useful for the first go-live, but also a good starting point for quarterly reviews, audit preparation and cleaning up old rule sets.

Secure by Design: harden the firewall itself

From my perspective, we need not only security products, but secure security products. That is an important difference. A firewall must not only block attacks against other systems; it must also be hardened against attacks itself.

For Sophos Firewall, this includes several layers:

• Hardened kernel and modernized architecture: The newer Xstream architecture relies more strongly on isolation, modularization, containerization and privilege separation. This reduces certain vulnerability classes and limits impact through better isolation. Mitigations against side-channel and CPU vulnerabilities are also included. This makes the platform more robust, but not immune to vulnerabilities.
• Automated Hotfixes: Security fixes can be distributed very quickly and without a classic maintenance window.
• Remote Integrity Monitoring: The integrated Sophos XDR Linux Sensor can monitor system integrity in real time, such as unauthorized configuration changes, rule exports, suspicious program execution or file tampering. This is valuable only if the function is enabled, licensed, integrated and monitored in operations.
• Secure Central management: Administration can take place through Sophos Central without exposing management ports broadly to the internet.
• Health Check: Risky configurations become directly visible.
• Encrypted backups: Configuration data is transmitted and stored securely.

In addition, Sophos relies on proactive monitoring of the installed firewall base. Telemetry from firewalls can help detect signs of attacks or manipulation earlier. When a pattern becomes visible, Sophos can support customers or partners specifically and roll out Hotfixes broadly and quickly.

These points are less spectacular in daily operations than a new firewall rule or a blocked attack in the log. In the long term, however, they are decisive. A hardened product reduces the likelihood that the firewall itself becomes the entry point. But it does not replace a clean patch process, monitoring or regular configuration review.

What to expect from a firewall vendor

Secure by Design is not only a product property, but also a vendor question. Customers should expect vendors to handle vulnerabilities transparently, communicate lifecycle information clearly, roll out security fixes quickly and build products so that misconfigurations and compromised components become visible as early as possible.

The responsibility is shared. Vendors must deliver secure products and respond transparently. Customers must install updates, replace EOL systems, use MFA and review operations regularly. Both belong together.

Pillar 2: Protection during the attack

Hardening is the foundation. After that, the firewall still has to do what it is used for: control traffic and block attacks. With Sophos Firewall, this includes IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection and Threat Intelligence Feeds, among others.

Sophos relies heavily on the Xstream architecture for this. Trusted traffic can be processed more efficiently, compute-intensive tasks such as crypto operations run through optimized paths, and more performance reserve remains for traffic with higher risk, such as Deep Packet Inspection, TLS Inspection and Zero-Day Protection.

TLS Inspection is a good example of the balance between security and operations. Without decryption, a large part of modern traffic remains invisible. With poorly planned TLS rules, however, support cases, certificate problems or performance bottlenecks appear quickly. The best practice is therefore not “decrypt everything blindly”, but classify cleanly:

• critical user groups and servers first,
• cleanly exclude banking, health, privacy and known problematic categories,
• test block and warning pages,
• document certificate distribution,
• actively evaluate logs.

My recommendation is not to start TLS Inspection as an all-or-nothing project. A clean rollout with clear user groups, exceptions, test windows and log evaluation is better. Visibility increases without overwhelming the helpdesk on day one.

Threat Feeds also belong in this protection area. Such feeds help block known malicious IPs, domains or URLs directly at the network edge. In newer Sophos Firewall versions, they are much more strongly integrated into Active Threat Response and protection mechanisms.

Threat Feeds become especially interesting when not only generic lists are used, but curated third-party feeds with current context. One example is Cybora.io, where malicious IPs and domains from various sources and firewall telemetry are consolidated into usable feeds. I described how such feeds can be used on firewalls in more detail in the article Threat Intelligence Feeds for the Firewall.

Here too, Threat Feeds must be tested and observed. Feeds that are too aggressive, missing allowlist processes or unclear responsibilities can block legitimate traffic and cause more harm than benefit in operations. Good feeds are not a replacement for a rule review, but an additional building block with its own tuning.

The classic SFOS hardening controls should also not be forgotten: Spoof Protection, appropriate DoS settings and Geo-IP blocking can reduce simple, noisy or obviously unwanted access. This does not replace a clean policy, but it removes unnecessary noise from the firewall and blocks attack paths that have no legitimate purpose in many environments.

Here I recommend a pragmatic approach: control the major risks cleanly first, then sharpen protection functions step by step and prove with logs what really works. An overloaded policy that nobody understands anymore is not a long-term security gain.

Pillar 3: Detection and Response after the first signal

The most interesting part of modern network security is the response. A firewall should not work in isolation, but use signals from Endpoint, Server, NDR, MDR, XDR and Threat Intelligence. Sophos can play ecosystem advantages here, but only if these integrations really fit the environment.

Ecosystems only help when they fit

Synchronized Security and Security Heartbeat are good ideas: the firewall can consider the state of endpoints and restrict or block communication for compromised devices. In reality, however, more and more companies use Microsoft Defender or other endpoint solutions. In that case, this part of the Sophos ecosystem works only partially or not at all. That is exactly why one should not automatically take everything from the same vendor just because it is offered as an integrated ecosystem.

My recommendation here is clear: what matters is what fits the company and can be implemented cleanly. If Microsoft Defender, another EDR, a third-party NDR or an external SIEM is the better foundation, then the firewall should be integrated cleanly into that architecture. More important than cross-selling is that logs arrive in the right place, alerts are understood and someone regularly checks what the systems report. Without log analysis, tuning and an incident process, even the best integration helps little.

With Active Threat Response, detected threats can be translated automatically into network decisions. And with NDR Essentials, the firewall gains additional visibility into suspicious network traffic, including where no classic endpoint agent is installed.

Automation needs runbooks

Automation needs guardrails. It should be clear which signals are allowed to block automatically, who lifts an isolation, how false positives are handled and how such processes are tested. Without runbooks, responsibilities and regular exercises, nobody knows in an incident whether a block was intended, correct or too aggressive.

What happens in an incident? A compromised device can be isolated, C2 communication interrupted, exfiltration blocked and an MDR or XDR analyst can trigger Active Threat Response without first manually building a rule in the firewall. This is especially valuable when an attack is detected outside normal business hours.

For admins, one point is especially important: the response must be fast enough. If an MDR or XDR analyst first has to call, write a ticket and a local admin then has to build a rule manually on Friday evening, the response time is too long. Automated response does not mean replacing people. It means that initial containment happens immediately and the team can investigate cleanly afterwards.

This automation is especially valuable in smaller IT teams. Not every company has a firewall specialist available around the clock. When Endpoint, Firewall, NDR, MDR and SIEM work together sensibly across vendors, time is gained, and time is often the most important factor during active attacks.

Practical checklist for Sophos Firewall admins

Anyone who wants to harden a Sophos Firewall today can start with this list:

Check immediately

• Are Hotfixes enabled?
• Is MFA active for administrators?
• Are the Web Admin Console and User Portal reachable from the WAN?
• Are SSL VPN or IPsec Remote Access protected with MFA?
• Are there unused local admin accounts?
• Are backups planned, encrypted and tested?
• Are Device Access and Local Service ACL reduced to the minimum?
• Are WAN-reachable services limited at least to relevant countries or known source networks?
• Are pattern updates and firmware versions current?

Within the next few weeks

• Run Health Check and prioritize findings.
• Review old firewall rules with “Any” as source, destination or service.
• Check admin roles, Login Security, session timeouts and brute-force protection.
• Inventory exposed services such as RDP, SSH, web servers, portals and NAT rules.
• Check internal zones and VLAN rules against lateral movement.
• Compare ZTNA, SSE or SASE options for typical Remote Access applications.
• Check Threat Feeds and DNS Protection.
• Enable Spoof Protection, DoS protection and Geo-IP blocking based on risk.
• Test TLS Inspection in a structured way and roll it out step by step.

Plan strategically

• Replace end-of-life systems.
• Align firewall, VPN, DNS, SD-WAN and ZTNA/SSE operations sensibly.
• Standardize central management, reporting and alerting, for example through Sophos Central, SIEM or existing security platforms.
• Define Syslog/SIEM export and log retention for forensic analysis.
• Integrate MDR/XDR/NDR signals into the incident process.
• Introduce recurring firewall hardening reviews.

Conclusion

Network Security Best Practices are not a one-off project, but an operating model. Because firewalls at the network edge are so privileged, they must be hardened, patched, reviewed and integrated into detection regularly.

My recommendation after many years with Sophos Firewall is therefore clear: a modern firewall must be more than a protection product. What matters is secure design, visible misconfigurations, fast security fixes and a response that works together with Endpoint, NDR, XDR and MDR in an incident.

Or in practical terms: if a firewall is so old that it belongs more in a museum than in a rack, it is not only an operational risk. It is an attack surface. And I keep exactly this attack surface as small as possible.

Support from Avanet

If support is needed for hardening a Sophos Firewall, Avanet is happy to help. I support IT teams as a long-standing Sophos specialist with firewall audits, Health Check reviews, rule set cleanup, Remote Access and ZTNA/SSE planning, update strategies and training.

An external view of management access, VPN configuration, old rules, WAN-exposed services and update status is often worthwhile. Many risks do not arise from one single wrong setting, but from grown exceptions that nobody questions anymore in daily operations.

If there is interest, a short message through the contact form is enough. Afterwards, it can be clarified together whether a compact firewall review, an audit or training makes the most sense for the respective environment.

FAQ

Further links

• Avanet Blog: Sophos Firewall v22: overview and all new features
• Avanet Blog: Threat Intelligence Feeds for the Firewall
• Avanet Blog: Sophos ZTNA Gateway on the Sophos Firewall
• Avanet Blog: Sophos NDR - eliminating blind spots in the network
• Avanet KB: Sophos Firewall firmware update - preparation and best practices

Sources

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report