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.

For the broader hardening context, use the hub Sophos Firewall Hardening: best practices for secure configuration.

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

How to Use This Guide

The Health Check provides a list, but not a decision. This guide therefore adds an Avanet assessment to every item:

• High priority: The finding concerns a fundamental security or operational control. Deviations should be fixed promptly or very well justified.
• Context-dependent: The recommendation is useful, but not equally appropriate for every rule, traffic path, or architecture.
• Covered differently: The security objective is valid but is already met by an equivalent third-party control or another operational process. A documented override can be appropriate in this case.
• Optional: The finding mainly evaluates a compliance function or an additional Sophos service. A red status does not automatically mean that the firewall is insecure.

This classification does not replace a risk assessment. It prevents a low Sophos severity from understating an important backup issue or a high severity on an optional integration from prematurely becoming a purchasing project.

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.

Evaluate Score and Status Correctly

The Health Check is helpful, but it is not a vendor-neutral security audit. In addition to general security basics, it checks whether additional Sophos functions such as Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds, or Synchronized Security are used. From Avanet’s perspective, this selection has a clear cross-selling component: a noncompliant finding may mean that a Sophos service is not used even though the underlying security objective is already covered by Microsoft Defender, another EDR/NDR, a SIEM, or a DNS security service.

That does not automatically make the recommendation poor. It does mean that Noncompliant can describe two very different situations: a real gap such as internet-exposed WebAdmin without MFA, or simply the decision not to use an optional Sophos service. The score must therefore never become an end in itself.

Avanet recommendation: Review every finding, but do not implement each one without question. A red finding for WebAdmin, MFA, unencrypted authentication, backups, or open rules deserves close attention. A red finding for an unlicensed Sophos service is initially an architecture and product decision, not an automatically proven security gap. The security objective, existing alternatives, and operating process determine whether enable, cover another way, or override with justification is the right response.

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.

For DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control, and Sophos Central Reporting, answer four questions: Which specific risk is reduced? Is an equivalent control already in place? Which licence and data transfer are required? Who handles alerts, exceptions, and false positives? If there is no good answer, a documented override is often more honest than an unused feature enabled only to improve the score.

Do not treat NDR Essentials and MDR as the same thing. NDR Essentials analyses selected firewall traffic and produces detections. Sophos MDR means Managed Detection and Response and is an additional paid service with analysts and incident processes. MDR threat feeds only make sense when that service is actually licensed and operationally integrated. An NDR finding therefore does not automatically mean that MDR must be purchased.

As a rule of thumb:

• Internet-exposed management access, MFA, automatic hotfixes, backups, password rules, and IPS are 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, Sophos Central, and Synchronized Security are possible solutions, not universal requirements. An existing effective alternative matters more than the Sophos logo on the control.
• Login disclaimer Usually more of a compliance/notice function than a technical protective measure. Only activate if it is really required or desired.

Quick decision: What should actually be implemented?

When opening the Health Check for the first time, sort the findings into four work queues:

• Review immediately and normally fix: 8, 9, 11, 13 to 20, 22, 25, 28, and 31. These cover hotfix status, login protection, admin passwords, MFA, encrypted authentication, SSH, WAN exposure, pattern updates, IPS, broad rules, and correct time.
• Very important even though Sophos rates them Low or Medium: 16 and 21. Backups require a tested restore. Alerts require a working path through email, monitoring, Central, or SIEM.
• Decide per traffic path and architecture: 3, 5, 10, and 23 to 27. X-Ops, Heartbeat, user password rules, Web Policy, Zero-Day Protection, Application Control, and TLS Inspection are not equally useful on every rule.
• Enable only with the appropriate Sophos ecosystem or a deliberate cloud-service decision: 1, 2, 4, 6, 12, 29, and 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection, and Central functions are not universal minimum requirements. Item 7, the Login disclaimer, is primarily a compliance decision.

This grouping is deliberately more direct than the Sophos severity. It evaluates what reduces risk first in the actual environment, not what Sophos can sell or technically integrate.

Open Health Check

The Health Check status appears in the Control center. The detailed view can also be found via the main menu:

Monitor & analyze > 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.

Understand Status, Severity, and Override

The detailed view shows for each check whether the configuration is compliant, non-compliant, or manually overridden. For operations, these three states are more important than the percentage value alone.

• Compliant: The checked configuration fulfils the respective policy. After major changes, it should still be technically validated.
• Noncompliant: The checked configuration does not fulfil the policy. Risk, exposure, and feasibility must be assessed.
• Manual policy status override: The configuration does not fulfil the policy, but has been manually marked as compliant. This status should only be used with a reason, owner, and review date.

Severity helps with sorting, but it does not replace expert assessment. It is a static Sophos rating and does not know the exposure or compensating controls. High findings involving internet exposure, admin access, MFA, hotfixes, or firewall rules should be checked first. A Low finding for missing backups can still be operationally more urgent than a Medium finding for an unused Sophos service.

For an implausible finding, also check the firmware version and known issues. SFOS 22.0 MR1 corrected false Doesn't comply results for firewall rules and for NDR Essentials on virtual firewalls. An obviously incorrect status is therefore neither a reason for a risky configuration change nor for a premature override.

The search and sorting functions in the Health Check table help group findings by policy, module, standard, or severity. For larger firewalls, this is more practical than only looking at the dashboard tile.

Each Health Check Examination Assessed

The following list is based on the 31 examinations in the English Health Check view used for this review. Sophos can change the number, wording, standard, or severity with a firmware update. If the local firewall shows additional or differently named findings, its display is authoritative. The status is deliberately not listed because it varies per firewall. More important is which examination is meant and how it should be assessed.

Active Threat Response and Advanced Security

• 1. Synchronized Application Control should be enabled. Standard: Recommended, Severity: Medium. It identifies applications more accurately with data from Sophos Endpoint and requires Security Heartbeat; for first-time use, it must also be enabled in Sophos Central. Avanet assessment: optional. Enable it only when compatible Sophos endpoints are present and detected applications will later be classified and used through application filters. In environments using Microsoft Defender or another endpoint product, a justified override is more useful than an ineffective activation.
• 2. NDR Essentials should be enabled and monitor at least one interface. Standard: Recommended, Severity: Medium. The firewall analyses selected traffic through the Sophos NDR cloud service, detects IoCs, and logs them, but does not automatically block them. It supports selected interfaces in LAN, DMZ, and custom zones; WAN, Wi-Fi, and several interface types such as RED and XFRM are excluded. Active-active HA is not supported. Active Threat Response logging must also be enabled, and depending on the IoC type, firewall, DNS, IPS, or decryption checks must apply. Avanet assessment: context-dependent to optional. Enable it only when licensing, cloud analysis, privacy, suitable interfaces, and alert ownership are resolved. Do not replace an existing third-party NDR merely to make the Health Check green.
• 3. Sophos X-Ops should be enabled with Action Log and drop. Standard: CIS, Severity: High. SophosLabs threat intelligence can block known malicious IP addresses, domains, and URLs. Avanet assessment: context-dependent with high value when the required licence is available. Review logs and exceptions after activation. Another effective threat-intelligence process can meet the same objective even if the score does not recognise it.
• 4. MDR threat feeds should be enabled with Action Log and drop. Standard: Recommended, Severity: High. This requires Sophos MDR, Sophos Central registration, and qualifying firewall licences. MDR analysts can then push customer-specific threat intelligence to the firewall. Avanet assessment: optional. Existing Sophos MDR customers should use the integration consistently. Without an MDR contract, this is not a configuration gap but a product and service recommendation.
• 5. Synchronized Security Heartbeat should be used in a firewall rule. Standard: CIS, Severity: Medium. It allows endpoint health to influence access. Avanet assessment: context-dependent. Very useful in a well-operated Sophos Endpoint environment, but not applicable with Microsoft Defender or another EDR. A pilot is essential: devices that have never sent a heartbeat may still be allowed through, depending on the rule. The options Block clients with no heartbeat and Block request to destination with no heartbeat are required to enforce the intended behaviour for those devices.
• 6. Security Heartbeat should be enabled. Standard: CIS, Severity: High. It connects Sophos Firewall and Sophos Endpoint through Sophos Central. Avanet assessment: context-dependent. It is a useful control with Sophos Endpoint. Without Sophos Endpoint, a red finding is expected and does not prove that the firewall is insecure.
• 12. DNS Protection should be configured and active. Standard: Recommended, Severity: Medium. Sophos DNS Protection provides cloud-based DNS policies and reporting. An active status requires the appropriate licence, the DNS Protection resolvers on the firewall, and the firewall’s public IP address as a location in Sophos Central. Avanet assessment: optional. Enable it only when the service is deliberately operated as the DNS security layer and its logs are reviewed. Cisco Umbrella, Cloudflare Gateway, Microsoft, or other DNS filters can cover the same objective without the Sophos Health Check marking it compliant.

Admin, Authentication, and Device Access

• 7. Login disclaimer should be enabled. Standard: CIS, Severity: Medium. Avanet assessment: optional or compliance-driven. A legally approved notice may be required in regulated environments. It does not technically protect the firewall and should not be enabled solely for a better score.
• 8. Hotfix setting should be enabled. Standard: CIS, Severity: High. Avanet assessment: high priority. Current SFOS 22 versions no longer show a separate Hotfix section under Backup & firmware > Firmware. Sophos installs hotfixes automatically by default; use system hotfix show in the Device Console if the status must be verified. A missing UI checkbox is not itself a finding.
• 9. Inactive sessions should be terminated and logins blocked after failed attempts. Standard: CIS, Severity: High. Avanet assessment: high priority. Session timeouts and login lockouts limit misuse of unattended sessions and automated login attempts. Choose values that protect without making administrator lockout too easy.
• 10. Password complexity for users should be configured. Standard: CIS, Severity: High. Avanet assessment: high priority for local accounts, otherwise context-dependent. With Entra ID, AD, or another IdP, its password, lockout, and MFA policies are primary. Local emergency and portal accounts still require separate review.
• 11. Password complexity for administrators should be configured. Standard: CIS, Severity: High. Avanet assessment: high priority. Personal admin accounts, MFA, restricted management networks, and removal of unused accounts matter even more than complexity alone.
• 13. MFA for Remote Access VPN logins should be enabled. Standard: CIS, Severity: High. Avanet assessment: high priority. MFA is a minimum safeguard for SSL VPN and IPsec Remote Access. The rollout needs test users, an emergency process, and verification of every authentication path in use.
• 14. MFA for WebAdmin Console and VPN Portal should be enabled. Standard: CIS, Severity: High. Avanet assessment: high priority. It is especially important for portals reachable from WAN or untrusted networks. MFA does not replace restrictions through Device Access and Local Service ACL.
• 15. Connections to authentication servers should be encrypted. Standard: CIS, Severity: Medium. Avanet assessment: high priority. LDAP without TLS and other unencrypted authentication methods can expose credentials and directory data. Test certificate validation and failure behaviour.
• 17. Public-key authentication for SSH should be enabled. Standard: Recommended, Severity: High. Avanet assessment: high priority when SSH is used. Also restrict SSH to trusted management networks and disable unused access.
• 18. User Portal should not be accessible from the WAN zone. Standard: Recommended, Severity: High. Avanet assessment: high priority with an exception review. If WAN access is required, minimise exposure, enforce MFA, and monitor login logs.
• 19. WebAdmin Console should not be accessible from the WAN zone. Standard: CIS, Severity: High. Avanet assessment: highest priority. Never expose WebAdmin broadly to the internet. Prefer VPN or ZTNA, a management network, and tightly scoped Local Service ACL Exception Rules.
• 20. MFA for the default admin should be configured. Standard: CIS, Severity: High. Avanet assessment: high priority. This account remains a sensitive emergency access path. Use personal admin accounts with appropriate roles for daily work.

Backup, Updates, Rules, and Inspection

• 16. Backups should be scheduled on the firewall or in Sophos Central. Standard: CIS, Severity: Low. Avanet assessment: high operational priority. The low Sophos severity is a poor measure of the impact of a failed restore. Encrypt backups, store them externally, and test the documented recovery process.
• 21. Notification emails should be configured for system and security events. Standard: CIS, Severity: Low. Sophos Firewall can send notifications by email and SNMP; select the required events under System services > Notification list. Avanet assessment: context-dependent. What matters is a reliable and tested alert path. If Syslog, SIEM, monitoring, or Central Alerts are operated reliably, email is not necessarily the best additional control. A configured SMTP server without selected events and a delivery test is not yet an alerting process.
• 22. Automatic pattern updates should be enabled. Standard: CIS, Severity: High. Avanet assessment: high priority. Several protection functions lose effectiveness without current patterns. Pattern updates are enabled automatically by default, but the status and last successful update should still be checked. Firmware for access points and RED devices is only downloaded and installed separately because a restart is required. Air-gap environments need a documented manual pattern and licensing process instead.
• 23. A web policy should be selected in a firewall rule. Standard: Recommended, Severity: Medium. Avanet assessment: context-dependent. Often useful for user web traffic, but not automatically for server-to-server, update, or specialised traffic. First determine the traffic path and desired control.
• 24. Zero-day protection should be selected in a firewall rule. Standard: CIS, Severity: High. Avanet assessment: context-dependent with high value for suitable web and download paths. Licence, file types, privacy, delay, and false positives must fit the operating model.
• 25. IPS should be enabled and an IPS policy selected in a firewall rule. Standard: CIS, Severity: High. Avanet assessment: high priority on relevant traffic paths. Choose the policy for the client, server, or published service, enable logging, and handle false positives deliberately.
• 26. An Application Control policy should be selected in a firewall rule. Standard: CIS, Severity: Medium. Avanet assessment: context-dependent. Visibility and control are valuable for client internet rules. Observe critical or unknown traffic in log mode before blocking it.
• 27. An SSL/TLS inspection rule should use Action Decrypt. Standard: CIS, Severity: High. Avanet assessment: context-dependent; do not enable blindly. The security gain can be substantial, but CA distribution, privacy, certificate pinning, exceptions, a pilot, and a support process are prerequisites. A targeted rollout is better than a green score with unstable applications.
• 28. An allow rule should not use Any everywhere in network and service fields. Standard: CIS, Severity: Medium. Avanet assessment: high priority. Reduce broad rules by source, destination, and service using real log data. A necessary Any remains valid but should be justified, logged, and reviewed regularly.

Sophos Central and Time

• 29. Sophos Central Reporting should be enabled. Standard: Recommended, Severity: Medium. Avanet assessment: optional. It is convenient for centralised and longer-term reporting. A properly operated Syslog/SIEM can meet the same objective. A red finding does not then mean reporting has failed.
• 30. Sophos Central Management should be registered and enabled. Standard: Recommended, Severity: Medium. Avanet assessment: optional. Central management, backups, and reporting are convenient but introduce cloud dependency and additional permissions. Local, isolated, or air-gapped environments may deliberately opt out.
• 31. An NTP server should be configured. Standard: CIS, Severity: Low. Avanet assessment: high operational priority. Correct time is fundamental for logs, certificates, MFA, Kerberos, and troubleshooting. Verify at least two reliable time sources and reachability over the intended path.

Prioritise and Implement 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:

1. Check internet-exposed management and portal accesses.
2. Check MFA and login security for admins, VPN Portal, User Portal, and Remote Access.
3. Clean up firewall rules with overly broad sources, destinations, or services.
4. Control logging, backups, and hotfixes.
5. Check protection functions per rule, such as IPS, web policy, application control, TLS inspection, or zero-day protection.
6. 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 and Recheck the Review

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:

• 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:

1. Open Health Check in the Control Center.
2. Sort non-compliant findings by severity.
3. Check internet-exposed services and admin accesses first.
4. Address MFA, password, and session topics.
5. Identify broad firewall rules and validate with Log Viewer.
6. Check backup, hotfixes, logging, and reporting.
7. Evaluate protection functions per rule.
8. Document justified exceptions instead of overriding without comment.
9. Recheck after changes.
10. 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.

FAQ