Sophos Firewall: Best Practices for Modern Network Security

Firewalls have long been the place where attacks are repelled. Today, they are themselves one of the most attractive targets. This is logical: A firewall sits in a privileged position between the internet, site networks, cloud services, VPN accesses, and internal applications. Anyone who finds a vulnerability, a weak password, or a misconfiguration here is often not just at the door but already inside the building.

That’s why it’s no longer enough to view a firewall merely as a policy engine for allow and deny rules. Modern network security requires three pillars: hardening, protection, and detection and response. You need to reduce the attack surface before an attack, block cleanly during an attack, and quickly detect what happened afterward.

I have been managing Sophos Firewall environments in very different sizes and industries for many years. The following recommendations are therefore not meant as a theoretical feature list, but as what has repeatedly proven itself in real customer environments, migrations, audits, and support cases.

Why Firewalls Are So Strongly in Focus

A firewall is a lucrative target for attackers because it is exposed, privileged, and often business-critical. Additionally, many environments operate firewalls, VPN portals, or remote management accesses for years. Not every environment is cleanly patched, not every management surface is truly isolated, and not every login is secured by multi-factor authentication.

In practice, three recurring causes for successful attacks are particularly evident:

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

The main idea behind this: Many attacks today are no longer spectacular “break-ins.” Very often, attackers simply log in. If a user account, an admin password, or a VPN access is compromised, the first step for the firewall initially looks like legitimate use.

The Three Pillars of Modern Network Security

Modern network security can be understood as a spectrum from proactive to reactive:

1. Hardening: Reduce the attack surface, remove outdated systems, use secure products, check configurations, restrict access.
2. Protection: Block attacks, control encrypted traffic, sensibly use web, IPS, zero-day, and application control functions.
3. Detection and Response: Detect anomalies, isolate compromised devices, correlate threat data, and respond automatically.

Many firewalls are traditionally strong in the second pillar. These systems block traffic, inspect packets, recognize known patterns, and enforce policies. This 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, you have a structural problem that no single IPS rule can cleanly solve.

My experience shows: The best results are not achieved through a single magical function, but through clean basic configuration, regular reviews, and a firewall that is integrated into the rest of the 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 emergency. It’s about less attack surface, fewer legacy systems, fewer open management paths, and less reliance on manual reactions.

Reduce Infrastructure and Remove Old Systems

The simplest way to reduce an attack surface is sometimes the most inconvenient: turn things off. Every old appliance, every forgotten VPN service, every management portal, and every unsupported server is an additional attack point. Systems that are at the network edge or indirectly allow privileged access to internal networks are particularly critical.

For Sophos Firewall admins, this means specifically:

• 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 if it reduces complexity: Firewall, SD-WAN, DNS Protection, ZTNA, threat feeds, reporting, and central management should be as well-coordinated as possible.
• Document which services really need to be accessible from the internet.

The goal is not to cram 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 more secure than a large, historically grown environment with many “it’s always been like this” 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 accessible from the WAN. If remote administration is necessary, it should be done via Sophos Central, a dedicated management network, ZTNA, or another controlled way.

I often see in customer environments that it’s not the most complicated attack technique that’s the problem, but an old admin access, a historically grown portal, or a “temporary” exception that was never removed. These are exactly the places that belong in a regular firewall review.

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

• Enable MFA for administrators, especially for the standard admin and all accounts with extensive rights.
• Enforce MFA for VPN and portal logins, if such accesses are still used.
• Avoid WAN access to 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 accessibility.
• Enable central backups and protect backup access, as configuration backups can contain sensitive information.
• Activate notifications and logging, so that security-relevant events are not overlooked in operation.

The point about backups is often underestimated. A firewall backup contains not only harmless settings but also information about networks, rules, certificates, VPNs, and internal structures. Therefore, backups must be encrypted, stored in a controlled manner, and regularly tested.

Set Device Access and Local Service ACL Deliberately

When talking about WAN access, you must specifically talk about Device Access and Local Service ACL on the Sophos Firewall. In the device access matrix, it is determined zone by zone which local firewall services are accessible: HTTPS admin, user portal, SSH, ping, DNS, captive portal, VPN portals, and other services.

Best practice here is very simple but effective: Only what is really needed should be accessible from the WAN zone. Admin access, SSH, and user portal do not belong broadly on the internet. If exceptions are necessary, they should be limited to specific source IP addresses or management networks via Local Service ACL Exception Rules.

Country Rules as Minimum Protection

If fixed source IP addresses are not realistic, I recommend at least working with country rules. Access from only a few relevant countries is still significantly better than worldwide accessibility. Alternatively, you can block countries with which the company has no connection and where no employees or admins are typically traveling. This is not a substitute 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 any firewall review. Many risky configurations do not arise from malicious intent but because a service was opened briefly for a migration, a support case, or a test and was never closed again. These are exactly the details that distinguish a firewall that just runs from a firewall that is really cleanly operated.

Check Login Security and Admin Roles

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

Additionally, failed login attempts should be limited, sessions should be cleanly terminated, and admin access should be restricted to defined networks. A login disclaimer can be legally useful in certain environments but is not a substitute for real technical controls. More important are strong password policies, short inactive sessions, brute force protection, and least privilege.

Avoid Patch Fatigue: Hotfixes Must Act Quickly

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

This is where the time component is dangerous. Identity attacks are now the dominant root cause, but vulnerability exploitation remains a real vector, especially for edge systems like firewalls, VPNs, and other internet-facing services. The Sophos Active Adversary Report 2026 cites CVE-2024-40766 in SonicOS as an example, which was 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. This is a pretty 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 protective effect does not only occur when the next free maintenance window comes.

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

• Keep hotfixes enabled.
• Regularly check firmware versions and document the firmware update preparation.
• Read upgrade paths and compatibility in advance.
• Prepare backups and rollback plans.
• 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 is successfully connected is already in a trusted area from the perspective of many environments. If the endpoint is compromised or credentials are stolen, an attacker can move on from there.

Zero Trust Network Access (ZTNA) solves this problem not by magic but by a better principle: Trust nothing, verify everything. Access is not granted to a network as a whole 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 accessible.

ZTNA Is Not an Automatic Sophos Decision

It is important to note: ZTNA is not a decision that automatically has to speak for Sophos ZTNA. Depending on the environment, specialized ZTNA, SSE, or SASE providers may be functionally further along, offer better integrations, or fit better organizationally. The decisive factor is not the manufacturer’s name, but whether identity, device state, application access, logging, and operation work together cleanly.

This is also my fundamental attitude in Sophos projects: I do not automatically rely on Sophos for every topic. If a third-party solution for ZTNA, SSE, threat intelligence, SIEM, or NDR fits better technically, that is the better recommendation. A good security architecture is not created by maximum manufacturer loyalty but by well-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 having to manually change firewall rules first. It is also worth looking at the ZTNA Gateway on the Sophos Firewall. In mixed or larger environments, however, one should consciously compare and not automatically set the existing firewall manufacturer as the ZTNA platform.

Anyone who still relies heavily on SSL VPN or IPsec remote access today should at least check these points:

• Enforce MFA for every remote access.
• Remove old or unused VPN users.
• Control group import from AD or Entra ID to ensure remote access is not unintentionally activated.
• Reduce split-tunnel, allowed networks, and permissions to the minimum.
• Plan a gradual 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

If attackers enter with valid credentials or through an exposed service, internal segmentation determines 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 network, production, backup, and particularly critical systems should not blindly be in the same trust model.

Practically, this means: Build VLANs and zones not just out of a love of order, but secure them with real firewall rules. Only the necessary applications should be allowed between user and server networks. Management accesses belong in dedicated admin networks. IoT and printer networks should not freely communicate with servers. Backups and domain controllers deserve particularly restrictive rules and good logging.

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

In new projects, I plan segmentation as early as possible. Retrofitting is still possible but much more tedious because applications, exceptions, and historical dependencies must then be untangled.

Make Misconfigurations Visible

A firewall can be technically very powerful and still become dangerous due to incorrect configuration. Too broad rules, “any” objects, weak authentication, missing IPS policies, disabled pattern updates, or open portals are typical examples. The difficulty is: In grown environments, you don’t always immediately see such risks.

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. The results are prioritized by risk, lead directly to the affected settings with a click, and can be fixed or consciously overridden depending on the situation.

The Health Check is particularly helpful for recurring operational processes:

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

However, it is also important: A health check does not relieve admins of thinking. Not every recommendation fits every environment. Some points have compliance or operational reasons, others are clear security gaps. The key is to consciously evaluate deviations and not let them grow unnoticed.

From my perspective, the Health Check is particularly strong as an ongoing operational tool. It is not just something for the first go-live but a good starting point for quarterly reviews, audit preparation, and the cleanup of old rule sets.

Secure by Design: Harden the Firewall Itself

In my view, it takes not only security products but secure security products. That is an important difference. A firewall should not only block attacks on other systems but must be hardened against attacks itself.

For Sophos Firewall, this includes several layers:

• Hardened kernel and modernized architecture: The newer Xstream architecture relies more on isolation, modularization, containerization, and privilege separation. This reduces certain classes of vulnerabilities and limits impacts 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. However, this is only valuable if the function is activated, licensed, connected, and monitored in operation.
• Secure Central Management: Administration can be done via Sophos Central without opening management ports broadly to the internet.
• Health Check: Risky configurations become directly visible.
• Encrypted Backups: Configuration data is transmitted and stored securely.

Additionally, Sophos relies on proactive monitoring of the installed firewall base. Telemetry from firewalls can help detect signs of attacks or manipulations earlier. If a pattern becomes visible, Sophos can specifically support customers or partners and roll out hotfixes very quickly.

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

What to Look for in a Firewall Manufacturer

Secure by Design is not just a product feature but also a manufacturer question. Customers should expect manufacturers to handle vulnerabilities transparently, communicate lifecycle information clearly, roll out security fixes quickly, and build their products so that misconfigurations and compromised components are detected as early as possible.

The responsibility is shared. Manufacturers must deliver secure products and respond transparently. Customers must apply updates, replace EOL systems, use MFA, and regularly review operations. Both go hand in hand.

Pillar 2: Protection During the Attack

Hardening is the foundation. After that, the firewall must continue to do what it is used for: control traffic and block attacks. For Sophos Firewall, this includes IPS, web protection, application control, zero-day protection, TLS inspection, DNS protection, and threat intelligence feeds.

Sophos relies heavily on the Xstream architecture for this. Trusted traffic can be processed more efficiently, computationally intensive tasks like crypto operations run over optimized paths, and more performance reserve remains for deep packet inspection, TLS inspection, and zero-day protection for traffic with higher risk.

TLS inspection is a good example of the balance between security and operation. Without decryption, a large part of modern traffic remains invisible. However, poorly planned TLS rules can create support cases, certificate problems, or performance bottlenecks. Best practice is therefore not to “decrypt everything blindly,” but to 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. It is better to have a clean rollout with clear user groups, exceptions, test windows, and log evaluation. This increases visibility without overwhelming the helpdesk on the first day.

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

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

Again, it applies: Threat feeds must be tested and monitored. Too aggressive feeds, missing allowlist processes, or unclear responsibilities can block legitimate traffic and cause more harm than good in operation. Good feeds are not a substitute for a rule review but an additional building block with its own tuning.

Additionally, do not forget the classic SFOS hardenings: Spoof protection and appropriate DoS settings as well as geo-IP blocking can reduce simple, loud, or obviously unwanted accesses. This does not replace a clean policy, but it takes unnecessary noise away from the firewall and blocks attack paths that have no legitimate purpose in many environments.

I recommend proceeding pragmatically here: first control the major risks cleanly, then gradually sharpen the protection functions and use logs to prove what really works. An overloaded policy that no one understands anymore is not a long-term security gain.

Pillar 3: Detection and Response After the First Signal

The most exciting 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 If They Fit

Synchronized Security and Security Heartbeat are good ideas: The firewall can consider the state of endpoints and restrict or block communication with compromised devices. In reality, however, more and more companies are using Microsoft Defender or other endpoint solutions. Then this part of the Sophos ecosystem only works to a limited extent or not at all. That’s why you shouldn’t automatically take everything from the same manufacturer just because it’s offered as an integrated ecosystem.

My recommendation 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 basis, then the firewall should be cleanly integrated into this architecture. More important than cross-selling is that logs land in the right place, alarms are understood, and someone regularly checks what the systems report. Without log analysis, tuning, and incident process, even the best integration helps little.

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

Automation Needs Runbooks

However, 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, no one knows in an emergency whether a block was intended, correct, or too aggressive.

What happens in an emergency? A compromised device can be isolated, C2 communication is interrupted, exfiltration can be blocked, and an MDR or XDR analyst can trigger an active threat response without first manually building a rule in the firewall. This is particularly valuable if an attack is detected outside normal operating hours.

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

Especially in smaller IT teams, this automation is valuable. Not every company has a firewall specialist available around the clock. If endpoint, firewall, NDR, MDR, and SIEM work together sensibly across manufacturers, you gain time, and time is often the most important factor in active attacks.

Practical Checklist for Sophos Firewall Admins

If you want to harden your Sophos Firewall today, you can start with this list:

Check Immediately

• Are hotfixes enabled?
• Is MFA active for administrators?
• Are Web Admin Console and User Portal accessible from the WAN?
• Are SSL VPN or IPsec remote access protected with MFA?
• Are there any unused local admin accounts?
• Are backups planned, encrypted, and tested?
• Are device access and local service ACL reduced to the minimum?
• Are WAN-accessible services at least limited to relevant countries or known source networks?
• Are pattern updates and firmware versions up to date?

Within the Next Few Weeks

• Run a health check and prioritize findings.
• Check old firewall rules with “any” at source, destination, or service.
• Check admin roles, login security, session timeouts, and brute force protection.
• Inventory exposed services like 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.
• Activate spoof protection, DoS protection, and geo-IP blocking based on risk.
• Test TLS inspection in a structured manner and roll it out gradually.

Strategic Planning

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

Conclusion

Network security best practices are not a one-time project but an operational model. Especially because firewalls are so privileged at the network edge, they must be regularly hardened, patched, checked, and integrated into detection.

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

Or put practically: If a firewall is so old that it belongs more in a museum than in a rack, it’s not just an operational risk. It’s an attack surface. And I keep this attack surface as small as possible.

Support from Avanet

If support is needed in hardening a Sophos Firewall, feel free to contact Avanet. As a long-time Sophos specialist, I assist with firewall audits, health check reviews, rule cleanup, remote access and ZTNA/SSE planning, update strategies, and training for IT teams.

An external view of management accesses, VPN configuration, old rules, WAN-exposed services, and update status is often worthwhile. Many risks do not arise from a single incorrect setting but from grown exceptions that no one questions in everyday life.

If interested, a short message via the contact form is sufficient. Then it can be clarified together whether a compact firewall review, an audit, or training is most sensible 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 Network Blind Spots
• 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