Effectively Using Sophos Firewall Health Check
The Sophos Firewall Health Check is an integrated examination of the firewall configuration. It shows in the Control Center whether important settings comply with recommended security and best practice guidelines. This is particularly useful for administrators as it makes risky configurations visible before they become a security or operational issue.
The Health Check was introduced with Sophos Firewall v22. The feature evaluates configurations against best practices and standards such as CIS benchmarks. With SFOS 22.0 MR1, the underlying CIS context was also updated.
Video Guide
Which Security Article Fits?
The Health Check is a good starting point, but not every finding is fully resolved in the Health Check article. For practical implementation, these entries are helpful:
| Situation | Better Entry |
|---|---|
| Collect, prioritise, and document findings | This article |
| WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping too broadly accessible | Secure Sophos Firewall Access: Configure Device Access Correctly |
| MFA for Admins, VPN Portal, or Remote Access missing | Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access |
| XML API or automation access is too open | Secure Sophos Firewall XML API Access |
| Firewall rules are too broad or unclear | Understand and Configure Sophos Firewall Rules Correctly |
| IPS should be activated or checked | Set Up and Safely Test Sophos Firewall IPS |
| TLS Inspection should be introduced | Properly Introduce Sophos Firewall TLS Inspection |
| Web Protection, categories, or instant alerts are relevant | Use Sophos Firewall Web Categories and Instant Alerts |
| DNS Protection should be operated via Sophos Central | Set Up Sophos DNS Protection with Sophos Firewall |
| Threat Feeds, NDR, or Active Threat Response should provide findings | Operate Sophos Firewall NDR and Active Threat Response |
| Configuration changes must be traceable | Check Sophos Firewall Audit Trail Logs |
This division prevents two typical mistakes: findings are either only viewed as dashboard notifications without being technically addressed, or protection functions are activated indiscriminately without clarifying logging, exceptions, and responsibilities.
What the Health Check is Intended For
The Health Check is not a classic system status or hardware sensor. It does not check if a power supply is defective or if an SSD is about to fail. Other operational checks are suitable for this, such as Check SSD Health or HA and hardware monitoring.
The Health Check answers these questions instead:
- Are administrative accesses too broadly opened?
- Is MFA activated for critical logins?
- Are firewall rules built too openly?
- Are backups, hotfixes, logging, or Central functions properly prepared?
- Does the configuration deviate from recommended security standards?
- Are there findings that should be resolved before an audit or go-live?
It is thus a good tool for hardening, review, and change control. However, it does not replace a clean architecture, rule documentation, or manual evaluation.
⚠️ A green Health Check does not automatically mean that the firewall is securely planned. It shows whether certain verifiable settings are correct. Network design, business logic, exceptions, user groups, and operational processes must still be professionally evaluated.
Do Not Misinterpret the Score as a Goal
The Health Check is helpful, but the score should not become an end in itself. Some points are clear security basics, such as MFA, hotfixes, password rules, restricted WebAdmin access, backups, or IPS. Other points are more dependent on the Sophos ecosystem, licensing, or the operational model.
Therefore, not every recommendation should be activated just to make the display green. An example is the Login disclaimer: In audit or compliance environments, a login notice may be required. In many normal operational environments, however, it mainly creates an additional click with each login and provides practically no technical security gain. If this only increases the Health Check score, the added value is limited.
Similarly, functions like DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control, or Sophos Central Reporting can be useful if they are licensed, understood, monitored, and truly used in operation. They should not be blindly activated just because the Health Check recommends them. The decisive factor is always: Does the measure reduce a real risk in this environment, and is there an owner for operation, exceptions, and false positives?
As a rule of thumb:
| Category | Evaluation |
|---|---|
| Internet-exposed management accesses, MFA, hotfixes, backups, password rules, IPS | Generally real security or operational basics. These points should be taken very seriously. |
| Logging, reporting, notifications, NTP | Important for operation and traceability. The specific path depends on the operational model. |
| DNS Protection, NDR, MDR threat feeds, X-Ops, Synchronized Security | Useful if the function is used, licensed, monitored, and integrated into processes. Not automatically better just because of the score. |
| Login disclaimer | Usually more of a compliance/notice function than a technical protective measure. Only activate if it is really required or desired. |
Open Health Check
The Health Check status appears in the Control center. The detailed view can also be found via the main menu:
Firewall health check
There you can see the number of configurations checked, the compliant points, and the non-compliant points. Sophos displays non-compliant entries by severity. The data is updated when a monitored configuration changes. This makes the Health Check suitable for direct follow-up after changes.
For the review, you should not only note the overall status. More important are the specific findings, the risk context, and the planned measure. A single critical finding regarding the WAN accessibility of WebAdmin is more important in operation than several low findings without internet exposure.
Overview of the 31 Health Check Examinations
The following list is based on the English Health Check view. The status is deliberately not listed because it varies per firewall. More important is which examination is meant and how it is professionally classified.
| No. | Examination | Module | Standard | Severity | Classification |
|---|---|---|---|---|---|
| 1 | Synchronized Application Control should be activated. | Active threat response | Recommended | Medium | Useful in Sophos Endpoint environments. In mixed or Microsoft Defender environments, first check if the function actually provides data. |
| 2 | NDR Essentials should be activated and monitor at least one interface. | Active threat response | Recommended | Medium | Only valuable if the monitored interfaces are sensibly chosen and findings are later evaluated. |
| 3 | Sophos X-Ops should be activated, Action Log and drop. | Active threat response | CIS | High | Security-relevant if Threat Feeds are actively used. False positives and logging must be checked. |
| 4 | MDR threat feeds should be activated, Action Log and drop. | Active threat response | Recommended | High | Only sensible if MDR or appropriate Threat Feed functions are licensed and operationally integrated. |
| 5 | A firewall rule should use Synchronized Security Heartbeat. | Active threat response and Advanced security | CIS | Medium | Strong added value with Sophos Endpoint. Without Sophos Endpoint, do not simply consider it a score topic. |
| 6 | Security Heartbeat should be activated. | Active threat response and Advanced security | CIS | High | Important if Sophos Endpoint is used. Otherwise, the endpoint design must first be clarified. |
| 7 | Login disclaimer should be activated. | Admin settings | CIS | Medium | Compliance topic. Technically little protective effect, but creates an additional click at login. |
| 8 | Hotfix setting should be activated. | Admin settings | CIS | High | Very important. Hotfixes should be active in productive environments if the change process allows it. |
| 9 | Inactive sessions should be terminated and logins blocked after failed attempts. | Admin settings | CIS | High | Clear login hardening. Especially important for exposed portals and admin accesses. |
| 10 | Password complexity should be configured for users. | Admin settings | CIS | High | Sensible, especially for local users and portals. For external IdP, also check its password and MFA policy. |
| 11 | Password complexity should be configured for administrators. | Admin settings | CIS | High | Basic hardening. Even more important are individual admins, MFA, and restricted access. |
| 12 | DNS Protection should be configured and active. | Advanced security | Recommended | Medium | Do not activate indiscriminately. DNS Protection is useful if Central DNS policies and reporting are truly used. |
| 13 | MFA should be active for Remote Access VPN logins. | Authentication | CIS | High | Very important for SSL VPN and IPsec Remote Access. Plan rollout with fallback admin and test users. |
| 14 | MFA should be active for WebAdmin Console and VPN Portal. | Authentication | CIS | High | Very important, especially if portals are accessible from less controlled networks. |
| 15 | Connections to authentication servers should be encrypted. | Authentication servers | CIS | Medium | Important for AD/LDAP/RADIUS connections. Avoid unencrypted authentication. |
| 16 | Backups should be planned on the firewall or in Sophos Central. | Backup & restore | CIS | Low | Low severity, but extremely important in an emergency. Also test the restore process. |
| 17 | Public-key authentication should be activated for SSH. | Device access | Recommended | High | Very sensible. Additionally, allow SSH only from trusted networks. |
| 18 | User Portal should not be accessible from the WAN zone. | Device access | Recommended | High | Correct in many environments. If WAN access is necessary, restrict it heavily and use MFA. |
| 19 | WebAdmin Console should not be accessible from the WAN zone. | Device access | CIS | High | One of the most important points. Never open WebAdmin broadly to the internet. |
| 20 | MFA should be configured for the default admin. | Device access | CIS | High | Important, but better is also a clean admin process with personal admin accounts. |
| 21 | Notification emails should be configured for system and security events. | Notification settings | CIS | Low | Operationally important. Alternatively or additionally, integrate monitoring, Syslog, SIEM, or Central Alerts. |
| 22 | Automatic pattern updates should be activated. | Pattern updates | CIS | High | Basic operation. Without current patterns, many protection functions lose value. In air-gap environments, a manual pattern and licensing process is needed instead. |
| 23 | A web policy should be selected in a firewall rule. | Rules and Policies | Recommended | Medium | Sensible for user web traffic. Do not blindly apply to server-to-server or special traffic. |
| 24 | Zero-day protection should be selected in a firewall rule. | Rules and Policies | CIS | High | Sensible for appropriate web and download paths. Consider license, performance, and false positives. |
| 25 | IPS should be activated and an IPS policy should be selected in a firewall rule. | Rules and Policies | CIS | High | Very important protection point. IPS must be appropriately chosen and logged per traffic path. |
| 26 | An application control policy should be selected in a firewall rule. | Rules and Policies | CIS | Medium | Sensible for client internet rules. Test first for critical traffic. |
| 27 | An SSL/TLS inspection rule should use Action Decrypt. | Rules and Policies | CIS | High | Do not activate blindly. TLS Inspection requires CA distribution, exceptions, pilot phase, and troubleshooting process. |
| 28 | An allow rule should not use Any everywhere in network and service fields. | Rules and Policies | CIS | Medium | Very important for rule hygiene. Any may be necessary but must then be justified and logged. |
| 29 | Sophos Central Reporting should be activated. | Sophos central | Recommended | Medium | Useful for reporting and longer evaluations. Not mandatory if Syslog/SIEM is properly operated. |
| 30 | The firewall should be registered for Sophos Central Management and Central Management activated. | Sophos central | Recommended | Medium | Practical for central management, backups, and reporting. Not every environment wants or needs cloud management. |
| 31 | An NTP server should be configured. | Time | CIS | Low | Basic requirement. Without correct time, logs, certificates, authentication, and troubleshooting suffer. |
Correctly Prioritise Findings
Not every finding has the same significance in every environment. A good review therefore sorts the entries not only by technical severity but also by exposure and operational risk.
This order has proven effective:
- Check internet-exposed management and portal accesses.
- Check MFA and login security for admins, VPN Portal, User Portal, and Remote Access.
- Clean up firewall rules with overly broad sources, destinations, or services.
- Control logging, backups, and hotfixes.
- Check protection functions per rule, such as IPS, web policy, application control, TLS inspection, or zero-day protection.
- Evaluate Central, reporting, or NDR findings based on whether the function is truly used and operated in the environment.
The order is pragmatic: first, the things that are directly visible on the internet or allow access to the firewall. Then rule hygiene and protection functions. Then operational and ecosystem topics.
Typical Findings and Appropriate Measures
WebAdmin, User Portal, or VPN Portal is Too Broadly Accessible
If administrative or user-related portals are accessible from too many zones, the risk from scans, brute-force attempts, and credential stuffing increases. The most important article on this is Secure Sophos Firewall Access: Configure Device Access Correctly.
For productive environments, you should check:
- Is WebAdmin really necessary from the WAN zone?
- Is there a Local Service ACL Exception Rule for management IP or admin network?
- Is SSH only allowed from trusted networks?
- Are User Portal and VPN Portal only accessible where needed?
MFA is Missing or Not Consistently Activated
MFA belongs at least on administrative accesses and Remote Access. If the Health Check shows MFA findings, you should not blindly switch for all users at once. Better is a controlled rollout with test user, fallback admin, and clean token process.
The practical guide is in Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.
Firewall Rules are Too Open
Very broad rules with Any for source, destination, or service are often historically grown. Not every broad rule is automatically wrong, but each should be justified.
For cleanup, these questions are helpful:
- Which zone is really allowed to access which zone?
- Can target networks or services be restricted?
- Is logging active so that hits are visible?
- Are there old test rules or temporary exceptions?
- Can the rule be split into several more understandable rules?
The basics are in Understand and Configure Sophos Firewall Rules Correctly. If it is unclear which rule applies, Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture helps.
Backups, Hotfixes, and Update Process are Missing
A Health Check can point to missing backups or update/hotfix topics. These points seem less spectacular than portal exposure, but are crucial in an emergency.
Before major changes, you should create a backup and know how a restore works. The procedure is described in Create or Restore Sophos Firewall Backup. For firmware topics, Sophos Firewall Firmware Update - Preparation and Best Practices is suitable.
Logging and Reporting are Incomplete
If logs are missing, the operation is blind. The Health Check can provide hints on logging or reporting topics, but the actual decision depends on the operational model.
For local analysis, Log Viewer, service logs, and Packet Capture are relevant. For longer retention, Central Firewall Reporting or Syslog/SIEM is needed. If not individual log events, but traffic flows, bandwidth peaks, or noticeable communication relationships are to be examined, sFlow Monitoring is additionally suitable. The local basics are in Sophos Firewall Troubleshooting: Services and Logs.
Protection Functions are Not Active in Rules
A common point is rules without IPS, web policy, application control, TLS inspection, or zero-day protection. Here, you should not activate everything indiscriminately, but understand the traffic path.
Examples:
- User web traffic needs different controls than server-to-server traffic.
- TLS Inspection must be introduced in a planned manner because it can disrupt applications.
- IPS and application control need logging and a review routine.
- NDR or threat feed functions only help if findings are later evaluated.
For TLS Inspection, Properly Introduce Sophos Firewall TLS Inspection is suitable. For threat feeds, Sophos Firewall Threat Feeds is suitable.
Document Overrides Consciously
Sophos Firewall allows the status of individual checks to be manually overridden. This can be sensible if a recommendation is consciously not implemented in your own environment.
However, overrides should not be misunderstood as a cleanup function. If a point is overridden, it should be documented:
- Why is the recommendation not suitable?
- Who approved the decision?
- Is the exception permanent or only temporary?
- When will it be reviewed again?
- Is there a compensating measure?
⚠️ An override is not a fix. It is a conscious risk acceptance or a documented exception. Without justification, the Health Check becomes less valuable.
Document the Result Cleanly
A Health Check review should produce a traceable result. Otherwise, you only briefly see a dashboard but later do not know which decision was made and which points are still open.
For small environments, a simple table is often sufficient:
| Field | Purpose |
|---|---|
| Date | When was the Health Check reviewed? |
| Firmware | On which SFOS version was it evaluated? |
| Finding | Which non-compliant point was reported? |
| Risk | Why is the point relevant or less relevant in this environment? |
| Measure | What will be changed, tested, or consciously accepted? |
| Responsible | Who clarifies the point professionally or technically? |
| Deadline | By when should the measure be completed or re-evaluated? |
| Evidence | Screenshot, ticket, change ID, or audit log reference |
For productive firewalls, the evidence should not only consist of a screenshot. If a configuration was changed, change ticket, audit trail, affected firewall rule, and result of the follow-up check belong together. For changes to rules, interfaces, hosts, and services, Check Sophos Firewall Audit Trail Logs is particularly useful.
Recheck After Changes
After a fix, you should reopen the Health Check and check whether the finding has really disappeared. Additionally, a technical functionality check is needed because a green status alone does not prove that the productive traffic continues to run correctly.
Examples:
- After a change to Device access, check whether admin access from the intended management network still works and is no longer accessible from unwanted networks.
- After MFA changes, log in with a test user and separately check the fallback admin.
- After rule changes, test Log Viewer, Policy Test, and affected applications.
- After logging or reporting changes, check whether new events are really visible locally, in Sophos Central, or in Syslog.
- After an override, set a reminder so that the exception is not permanently forgotten.
If multiple findings are addressed simultaneously, you should divide the changes into small blocks. Otherwise, in the event of a later problem, it is unclear whether Device Access, MFA, firewall rules, TLS Inspection, or another change was the cause.
Use Health Check as an Operational Process
The Health Check is strongest when it is performed regularly and after important changes.
Suitable times:
- after initial configuration or a go-live,
- before and after major rule changes,
- before firmware upgrades,
- after restore or hardware replacement,
- after migrations or major architectural changes,
- before audits,
- quarterly as a security review.
For changes themselves, the audit trail should also be used. The article Check Sophos Firewall Audit Trail Logs explains how to evaluate configuration-audit.log and trace configuration changes.
Practical Review Process
A pragmatic Health Check review proceeds as follows:
- Open Health Check in the Control Center.
- Sort non-compliant findings by severity.
- Check internet-exposed services and admin accesses first.
- Address MFA, password, and session topics.
- Identify broad firewall rules and validate with Log Viewer.
- Check backup, hotfixes, logging, and reporting.
- Evaluate protection functions per rule.
- Document justified exceptions instead of overriding without comment.
- Recheck after changes.
- Document the result with date, handler, and open points.
For recurring reviews, a simple table with finding, risk, measure, responsible person, status, and reminder is often sufficient. It is important that findings are not only viewed but processed or consciously accepted.
Limitations
The Health Check is helpful but has clear limitations.
- It does not know the complete business logic of the environment.
- It does not evaluate whether a rule is needed professionally.
- It does not replace network segmentation and a zone model.
- It does not automatically detect every risky special case.
- It does not replace an external audit and manual rule review.
- It does not say whether alerts will be processed later.
Therefore, the Health Check should be seen as a starting point. It makes visible deviations tangible, but the actual security quality arises from good architecture, clean processes, and consistent maintenance.
Operational Checklist
- Perform Health Check after go-live and major changes.
- Prioritise findings by severity and exposure.
- Check WAN accessibility of WebAdmin, SSH, User Portal, and VPN Portal.
- Activate MFA for admins, portals, and remote access.
- Clean up or justify broad firewall rules.
- Enable logging in important rules.
- Check backups and restore process.
- Document hotfix and firmware process.
- Set overrides only with justification.
- Regularly document Health Check results.