Connect Sophos Firewall with Sophos Fusion

A Sophos Firewall does not necessarily need to be connected to Sophos Fusion. A single firewall can be fully managed locally via WebAdmin. However, connecting to Sophos Fusion is beneficial in many environments as it provides additional management, backup, reporting, and security features.

This article helps you decide when Sophos Fusion is useful and when local management suffices.

The current platform name is Sophos Fusion, formerly Sophos Central. The firewall menus, buttons, and registration alert may still use Sophos Central; follow those visible UI labels when working through the steps. A centrally managed firewall can also be integrated as a ZTNA gateway for access to internal resources. Registration alone does not configure that gateway or grant access to those resources; plan the ZTNA deployment and its access policy separately.

Quick Answer

If you are operating only a single Sophos Firewall locally and do not wish to use Central features, Sophos Fusion is not strictly necessary.

If you manage multiple firewalls, want to centrally analyze log data, store configuration backups in the cloud, or use other Sophos products like Sophos Endpoint, Sophos Fusion offers significant advantages.

The decision should not just be whether to connect. More importantly, you should decide which Central features should actually be activated. A firewall can be registered in Sophos Fusion without every management, reporting, or backup function being actively used.

Zero Touch: Deployment with a Configuration File

In addition to managing existing firewalls, Sophos Fusion also offers Zero Touch: new firewalls can be installed using a Zero Touch configuration file. This requires a Sophos Fusion account; the interface may still be called Sophos Central. This option is relevant when planning new site installations if deployment is to be prepared through Central. It is not the same as subsequent remote access to WebAdmin or distributing a group policy.

Before choosing a deployment method, clarify the intended tenant, the responsible administrators and their permissions, the device and serial number, licensing requirements, and internet connectivity. A working IPv4 connection remains necessary for subsequent Central management; the licensing requirements described in this article still apply. Zero Touch is not a prerequisite for local operation and is not a repair method for a firewall already in production.

Keep these tasks clearly separate:

• New installation with Zero Touch: The configuration file is used to deploy a new firewall. This overview describes the capability but does not provide complete instructions for creating or applying the file. Plan this approach before installation; do not infer a Zero Touch procedure from the OTP steps below.
• Local setup, ownership claim, and licensing: Set up Sophos Firewall, claim it, and activate licenses describes the basic local setup, assignment to the tenant through the ownership claim, and the separate activation or synchronization of licenses. These tasks must not be equated with management registration.
• Connect an existing firewall: The OTP workflow described further below requires a firewall that has been configured and claimed in the correct tenant. OTP registers it for Central Management but replaces neither the ownership claim nor subscription activation. Assigning the firewall to a customer as a partner does not replace the ownership claim either.
• Manage multiple firewalls together: Use Sophos Fusion Firewall Groups safely explains shared policies and the effects of Full Sync. Group management is a separate operational task, not the Zero Touch installation method.

Advantages of Connecting with Sophos Fusion

Central Overview

In Sophos Fusion, you can view registered firewalls centrally in one place. This is particularly helpful when managing multiple locations or appliances of the same organization.

Typical advantages:

• Status overview of the firewalls
• Serial numbers and license information
• Firmware and security status
• Central reports
• Quick switching between multiple firewalls

Management via Sophos Fusion

With Manage from Sophos Central, you can access firewall management through Sophos Fusion. This is often more secure than exposing the WebAdmin Console directly to the internet.

However, management access does not replace a sound administration strategy. Admin accounts, MFA, roles, Device Access, and ACL rules must still be configured deliberately. According to Sophos, Central Firewall Management also requires an active paid subscription other than Base Firewall or an active Sophos support license that includes this entitlement, such as Enhanced Support. The Base Firewall license alone is insufficient; not every support contract automatically provides this entitlement.

One technical point is often overlooked: Sophos Fusion can only manage firewalls if the firewall reaches the internet over IPv4. In IPv6-only or very strictly segmented environments, this path must be checked before activation.

If changes via Central do not arrive on the firewall as expected, you should also check the Sophos Fusion Firewall Management Task Queue. There you can see if group policies or API-based firewall tasks are pending, failed, or skipped.

Use Sophos Fusion Firewall Groups safely explains how multiple firewalls receive a shared policy and what Full Sync and Skip full sync actually do.

For multiple sites, Central can also orchestrate route-based VPN connections, XFRM interfaces, routes, and rules. Set up and verify a Sophos Fusion SD-WAN connection group explains planning, conflict resolution, and local validation.

Limits of Central Firewall Management

Central Firewall Management is an additional management path, but not a full replacement for local firewall administration, local logs, and tested emergency access. Especially with several admins, firewall groups, and HA clusters, admins should know the key limits so normal platform behavior is not mistaken for a configuration error.

Typical observations from operations:

• Two admins open the same firewall through Sophos Fusion: Only one Central Manager session per firewall can be active. If a second admin takes over, the first may see a loading or connection error.
• Read-only or helpdesk role does not see grouped firewalls: For firewalls in Central groups, read permissions can behave differently than expected. Test operational roles with a test account.
• HA pairs appear unexpectedly twice or on several pages in Central: This can be a display or pagination issue. For decisions, also check the local HA status on the firewall.
• Firewall rules cannot be moved at group level as they can locally: Not every local WebAdmin action is represented the same way in Central groups. Rule order and effect must be validated locally after group changes.
• Imported groups or WAF rules behave unexpectedly in Central: After a configuration import, full sync, or WAF rule import, check not only the Central view but also the target firewall and the Task Queue.

For production environments, this means that Sophos Fusion is the coordination point, but the firewall remains the place where critical effects are validated. After group changes, firmware tasks, WAF adjustments, or HA work, also check locally whether rules, services, HA status, logs, and affected connections are actually correct.

Configuration Backups in Sophos Fusion

The firewall can send configuration backups to Sophos Fusion. This is useful if an appliance needs to be replaced or restored and local backups are not available.

In Sophos Fusion, you can set up scheduled backups for registered firewalls. The intervals available are Daily, Weekly, and Monthly. This allows you to define, for example, that selected firewalls send a configuration backup to Sophos Fusion daily, weekly, or monthly.

The current Sophos backup documentation places scheduling under Global Settings > Products and Services > Firewall > Schedule Backup. If the Firewall Management > Backup path shown in the screenshot is absent from your interface, use this route.

Sophos Fusion doesn’t keep all automatic backups indefinitely. By default, the five most recent backups are retained and older ones are discarded. One backup can also be marked for permanent storage. In HA clusters, Primary and Auxiliary appear in the backup schedule, but according to Sophos, only the backup from the Primary device is generated.

For operations, two details matter: Sophos Fusion attempts to create a backup up to five times in total and generates an alert plus an email to the Sophos Fusion admin if it permanently fails. If a firewall is removed from Sophos Fusion management, Sophos Fusion deletes the related backup files. Cloud backups are therefore useful, but they don’t replace a dedicated backup and restore strategy.

Nevertheless, you should not rely on a single backup method. For production systems, regular local or external backups are still advisable. The backup password and Secure Storage Master Key are also important.

Central Firewall Reporting

With Central Firewall Reporting, the firewall sends log and report data to Sophos Fusion. This allows reports to be evaluated over longer periods and searched centrally.

In Sophos Fusion, dashboards, the Report Hub, the Report Generator, saved templates, and scheduled exports are available for this purpose. You can create reports for individual firewalls or multiple firewalls, filter time periods, search for specific events, and export results as PDF, CSV, or HTML. For regular evaluations, reports can also be scheduled and automatically provided.

According to Sophos, saved templates, scheduled exports, and downloads require a Central Firewall Reporting Advanced license. For reports across multiple firewalls, all selected firewalls must have the appropriate license.

Typical report templates include:

• Antivirus
• Bandwidth usage
• Cloud app risks and usage
• Firewall
• IPS
• Log viewer and search
• SD-WAN
• SD-WAN SLA trend
• SD-WAN bandwidth usage
• Security posture assessment
• Synchronize app
• Threat geo activity
• Threats and events blocked
• VPN usage
• Web usage
• Web user risks
• X-Ops
• Zero-day protection

The retention period depends on the license:

• Active Firewall Subscription: Up to 7 days for basic reports and short reviews
• Xstream Protection / Central Orchestration: Up to 30 days, depending on the bundle and permissions
• Central Firewall Reporting Advanced: Up to 365 days; 100 GB of additional storage per license

The exact activation and log selection are described in detail in the article Activate Central Firewall Reporting.

Synchronized Security and Security Heartbeat

When Sophos Endpoint and Sophos Firewall are operated together via Sophos Fusion, Synchronized Security can be used. In this case, the firewall and endpoint exchange security information.

Examples:

• The firewall sees the Security Heartbeat of endpoints.
• Devices with a red heartbeat can be automatically restricted.
• Network and endpoint views are better connected.
• During incidents, you can quickly see which user or device is affected.

This is one of the greatest additional benefits when Sophos Endpoint, MDR, or XDR is used alongside the firewall.

Security Heartbeat can also send the Windows domain identity of a managed endpoint to the firewall. Set up Synchronized User ID Authentication explains the safe pilot, rule, and HA workflow.

Validate Security Heartbeat after Registration

A firewall visible in Sophos Fusion does not yet prove that Security Heartbeat is working for the endpoints. It requires a Sophos Fusion account, at least one Sophos Fusion-managed endpoint with a trial or full license, and a valid Network Protection subscription on the firewall. When the firewall is registered, SFOS automatically enables Security Heartbeat and Synchronized Application Control.

A single managed pilot endpoint is suitable for a controlled initial validation:

1. Under System > Sophos Central, check that the firewall is registered and Security Heartbeat is active.

2. In Sophos Fusion under My Products > Firewall Management > Firewalls, confirm the alert A new firewall has been successfully registered to Sophos Central. This alert proves registration, but not yet the effect of a rule.

3. For the pilot endpoint in Sophos Fusion, check the tenant, current health status, and events from the same period.

4. Under Control Center > User & device insights > Security Heartbeat, check whether the Connected counter is consistent with the expected pilot status. According to Sophos, the detailed view remains empty when all endpoints are green; it only lists red and yellow endpoints individually.

5. Check the firewall rule that actually matches and its settings under Configure Synchronized Security Heartbeat. Source and destination heartbeat conditions define the minimum required health status for each side separately; registration alone does not enforce either condition. Also review applicable Web > Exceptions: Sophos documents that web requests aren’t blocked when Block clients with no heartbeat is combined with an exception for policy checks. Verify the actual Rule ID and access result rather than assuming that a heartbeat condition guarantees isolation.

6. Only after establishing this baseline, enable a heartbeat condition in a narrowly scoped pilot rule, turn on logging, and test allowed traffic with a healthy endpoint.

Contradiction in the Sophos documentation: The Security Heartbeat overview for SFOS 22 and 23 states broadly in the VPN section that when an endpoint has a Missing status, all traffic from that endpoint is blocked by the firewall. The detailed Heartbeat description, however, makes the effect on access dependent on the rules and explicitly identifies an exception for policy checks under Web > Exceptions: web requests are not blocked despite Block clients with no heartbeat. These statements cannot be reconciled as a general guarantee of isolation. Safe acceptance testing therefore requires checking the rule that actually matches, the separate minimum requirements for Source heartbeat and Destination heartbeat, the applicable exceptions, and the actual access result. The Missing status alone is not proof of complete isolation.

A red status should not be created for this test by disabling or tampering with endpoint protection. If Central, Control Center, and the rule effect do not match, or Missing appears, systematically troubleshoot Missing Heartbeat alerts by zone, path, Rule ID, and logs.

For the broader Control Center > User & device insights view, see Evaluate User & Device Insights safely. It explains the Heartbeat and application counters, Zero-Day findings, UTQ, SSL/TLS errors, and firewall sessions, including their different time windows and the distinction between hiding an error and changing a decryption policy. These local signals are not the same as Central Reporting and do not prove that every endpoint or connection is protected.

Define Heartbeat monitoring scope and check the path

Under System > Sophos Central > Optional configurations > Missing heartbeat zones, select only zones in which managed Sophos endpoints are expected. Missing heartbeats are detected only in the selected zones; printers, guests, IoT devices, and clients with another EDR do not acquire a Sophos Heartbeat through registration. The zone list and the heartbeat conditions of the matching firewall rules must agree. Sophos documents a special case: if a heartbeat policy blocks a zone but no zone is added in this field, the Control Center widget can still show Missing. An empty list is therefore not proof that no policy is affecting traffic.

Before changing the scope or a pilot rule, record the original zone list, Rule ID, heartbeat options, and the pilot endpoint’s IP, MAC, and current status. Apply only the intended narrow change. Then compare the same endpoint in Central and Control Center, generate an approved healthy test flow, and verify the matching Rule ID and access result in the Log Viewer. If access changes unexpectedly, restore the recorded zone list and rule options, repeat the same flow, and investigate the path rather than weakening heartbeat requirements globally.

The documented Heartbeat channel uses encrypted TLS to 52.5.76.173 on TCP 8347. Central supplies certificates that let the firewall associate endpoints with the correct organization; an open port alone does not establish that trust. Check these topology limits before diagnosing a missing status:

• A VPN established before the heartbeat connection can divert that traffic away from the local firewall. For Sophos Connect IPsec, check Remote access VPN > IPsec > Advanced settings > Send Security Heartbeat through tunnel against the intended connection policy.
• Behind an intermediate router without NAT, an endpoint can still share health status, but the firewall cannot detect a missing heartbeat. Seeing a health status does not prove that Missing monitoring works on that path.
• Behind a NAT gateway, endpoints cannot share their health status with the firewall. This is a different limitation from the routed, non-NAT case.
• In TAP mode, at least one continuously connected LAN-zone interface must be reachable by the endpoints. Mirrored traffic alone is not enough: endpoints receive the LAN interface addresses through Central and try to send their heartbeat to one of them.

Interpret health status without assuming automatic isolation

Connected (green) is the endpoint’s reported healthy status, not a guarantee that every threat has been excluded. Warning (yellow) can indicate a PUA, inactive or cleaned-up malware, or signatures that have not updated for 24 hours. At risk (red) requires investigation, for example for active malware that could not be removed, malicious network traffic, or protection that is not working correctly. Missing (red) is different: the firewall sees traffic but receives no corresponding health status. Compare endpoint events before treating the two red labels as the same incident.

The red/yellow detail view provides hostname, IP, user, and time since the status changed. A Missing entry can remain in Control Center and reports after the endpoint leaves the network; it changes when the endpoint reconnects. Do not delete such an entry merely to make the dashboard green. The linked Missing Heartbeat guide explains evidence capture, timer trade-offs, supported Modern Standby behavior, and narrowly scoped cleanup. Endpoints send their heartbeat every 15 seconds; distribution of red/yellow endpoint lists every 30 seconds and the default 60-second Missing detection timeout are separate mechanisms. Longer detection or reporting delays can also delay real alerts.

Lateral movement protection is another separate control: other endpoints stop communicating with a red endpoint only when the corresponding Central endpoint policy applies. The firewall shares MAC addresses and health states as a Layer-2 proxy within the same broadcast domain. Do not assume that this isolates endpoints across routed networks or replaces heartbeat conditions on traffic passing through the firewall.

The SFOS 22 overview describes synchronized user identity with domain name, username, and Active Directory. The SFOS 23 overview additionally documents User Principal Name (UPN) and account validation against Active Directory or Microsoft Entra ID. Do not apply that SFOS 23 description to an SFOS 22 deployment or assume registration alone configures identity authentication; check the actual firmware and authentication-server configuration before using identity-based rules.

What Sophos Fusion Does Not Replace

Sophos Fusion is helpful but does not replace proper firewall configuration.

Central does not replace:

• Proper zone and interface planning
• Restrictive firewall rules
• Device Access Hardening
• MFA for admins and portals
• Local troubleshooting with Log Viewer and Packet Capture
• Documented backups and recovery tests
• An external Syslog system if compliance or long retention is required

Sophos Fusion is thus an additional management and reporting layer, but not a shortcut for a secure basic configuration.

Check Before Registration

Before connecting to Sophos Fusion, you should briefly clarify what you want to achieve with the registration. This prevents unclear responsibilities, duplicate tenants, or unnecessarily activated services later.

Important preliminary questions:

• In which Sophos Fusion tenant should the firewall be registered?
• Who has the required rights in the tenant for firewall management, reporting, backup, and licensing?
• Is the firewall already registered in another Central account?
• Does the firewall have an active paid subscription other than Base Firewall or an active Sophos support license that includes Central Firewall Management, such as Enhanced Support? Check the actual license, not just whether a support contract exists.
• Does the firewall have working IPv4 internet connectivity?
• Should Central be used only for a license overview and inventory, or also for management, reporting, and backups?
• Are firewall groups used, and have the roles for admin, helpdesk, and read-only access been tested in practice?
• May firewall logs be sent to Sophos Fusion from a data protection or compliance perspective?
• Is there a current local backup and a documented Secure Storage Master Key?
• Is it clear who checks alerts, reports, and failed tasks after registration?

If the firewall is already in the wrong account, first consult Transfer Sophos Firewall to another Sophos Fusion account. For an explanation of the different accounts and portals, see Sophos Portals: SophosID, Central, Support, and Firewall Access.

When You Don’t Need to Connect the Firewall

A connection to Sophos Fusion is not strictly necessary if:

• Only a single firewall is managed locally
• No Central reports are needed
• No Sophos Endpoint integration is planned
• Cloud management is not desired for organizational reasons
• Logs are already sent to your own SIEM or a Syslog server

In such cases, you can operate the firewall locally. It is then important to organize backups, firmware updates, monitoring, and logging properly elsewhere.

When Sophos Fusion is Recommended

Sophos Fusion is particularly recommended if:

• Multiple firewalls are managed
• Admins work from different locations
• Firewalls should not be directly accessible via WebAdmin from the internet
• Configuration backups should be stored centrally
• Firewall reporting is needed
• Sophos Endpoint, MDR, XDR, or other Sophos Fusion products are in use
• Security Heartbeat and Synchronized Security should be used

Activate Connection

The connection is set up on the firewall under System > Sophos Central.

The following workflows use English UI labels documented for SFOS 22 and SFOS 23; the local interface may still say Sophos Central. A local firewall administrator needs access to this menu. Central Firewall Management still requires an active paid subscription other than Base Firewall or an active Sophos support license that includes this entitlement, such as Enhanced Support. Base Firewall alone is insufficient, and the internet management path only works over IPv4.

Before generating an OTP: The firewall must already be configured and claimed in the intended Sophos Fusion tenant. If setup or claiming is still incomplete, first follow Set up Sophos Firewall, claim it, and activate licenses and verify the device and license assignment. The subsequent OTP registration connects the existing firewall for Central Management; it neither claims ownership nor activates subscriptions. Assigning the firewall to a customer as a partner does not replace claiming either.

There are two typical registration methods:

• OTP from Sophos Fusion: Useful when a partner, project team, or firewall admin shouldn’t work with Super Admin credentials for the Central tenant on the firewall. In Sophos Fusion, the existing firewall is added under My Products > Firewall Management > Firewalls > Add Firewall using the serial number, and an OTP is generated.
• Sophos Fusion credentials: Useful when registering directly on the firewall with a suitable Sophos Fusion admin account. Sophos refers to this as a Central Super Admin.

For HA pairs, work carefully. With OTP registration, both serial numbers are entered in Sophos Fusion; for new HA pairs, the OTP is used on the Primary device.

Generate an OTP in the correct tenant

For an already configured and claimed firewall, generate the OTP in Central before proceeding with the local registration steps:

1. Sign in to the intended tenant. A partner first assigns the firewall to the correct customer in Partner Dashboard and launches that customer’s Central Admin console. Customer assignment does not replace claiming.
2. Open My Products > Firewall Management > Firewalls > Add Firewall and choose Join a firewall that is configured or deployed.
3. In Enter Device Serial Number, enter the intended serial number and click Next. For HA, enter both serial numbers separated by a comma and verify them against the planned pair.
4. Leave Register using OTP selected and choose Copy OTP and Finish. The OTP is valid for 14 days. Share it only with the authorized firewall administrator through the approved secret-sharing channel; do not include the OTP, passwords, or unredacted credential screenshots in a support record.
5. On the firewall, choose Register > Use OTP, paste it into Enter OTP, and click Register. For a new HA pair, enter the OTP only on the primary device. Then enable the intended Central services and obtain the service approval described below.

If the OTP has expired or registration fails, first check the intended tenant, claiming, serial numbers, and IPv4 connectivity. Obtain a fresh OTP from the correct tenant when needed; do not repeatedly deregister or change ownership to work around the error. Registration is accepted only after the serial numbers and service status match in both views.

The alternative credential workflow requires a Central Super Admin. An administrator account belonging to a Central Enterprise sub-estate cannot be used for this registration. Keep the tenant account and local firewall administrator role distinct; OTP lets the local administrator register without receiving the tenant’s Super Admin password.

Typical procedure on the firewall:

1. Log in to the firewall.
2. Open System > Sophos Central.
3. Select Register.
4. Select Use OTP or Use email address.
5. Enter the OTP or Sophos Fusion credentials.
6. Complete the registration.
7. Turn on Sophos Central services.
8. Select the required services.

Depending on the need, these options can be activated:

• Use Sophos Central reporting / Send reports and logs to Sophos Central: Sends log and report data to Sophos Fusion.
• Use Sophos Central management / Manage from Sophos Central: Allows management access through Sophos Fusion.
• Send configuration backup to Sophos Central: Stores configuration backups in Sophos Fusion. In practice, this option is tied to the Central Management setup and must be approved in Sophos Fusion.

Only the functions that are actually used should be activated. In environments with data protection or compliance requirements, clarify beforehand which log data may be sent to Sophos Fusion.

After activating the services, an account with the Super admin role in the affected Sophos Fusion tenant must accept the services in Sophos Fusion:

1. Sign in to Sophos Fusion.
2. Open My Products > Firewall Management > Firewalls.
3. Find the firewall with Approval Pending.
4. Select accept-services.
5. On the firewall, check whether the status changes from Waiting for approval from Sophos Central to Managed or connected.

The status change can take a few minutes. If the display doesn’t change immediately, don’t register repeatedly. First check Central status, internet connectivity, DNS, and time.

If an egress filter is in front of the firewall, the matching outbound Sophos services and ports for Central, reporting, and backups must also be reachable.

Bring an HA pair under Central management

Distinguish two starting points before changing anything. Record both serial numbers, firmware versions, primary/auxiliary roles, local HA status, and Central service states. Keep current configuration backups, their passwords, the Secure Storage Master Key, and working local administration available. HA formation is a separate maintenance change, not a registration troubleshooting shortcut; Plan and operate Sophos Firewall HA variants covers configuration ownership, synchronization, and the recovery plan.

• Two standalone firewalls are already centrally managed: Prepare HA locally using the intended primary configuration. Both devices must run the same firmware version. Sophos documents both Active-Active and Active-Passive; after forming the pair, Central should display one HA pair, not two independent management targets. Follow the HA preparation workflow before allowing synchronization to replace the auxiliary configuration.
• An HA pair exists but is not centrally managed: Work on the primary. The HA-specific documentation calls the registration view Central synchronization and the action Register both HA devices. After registration, enable Central management and, beside the primary firewall in Central, select Approval Pending > accept-services using the authorized Super Admin. For the OTP route, use both serial numbers and the primary-only entry described above rather than registering each node independently.

Allow a few minutes, then confirm that Central shows one pair with an HA icon and the intended serial numbers. Verify the primary/auxiliary roles and synchronization locally, as well as management access and an approved production test flow. Central configuration changes apply to both firewalls; a single displayed object is not evidence that only the primary is affected.

If the display remains split or duplicated, compare the local HA state, both serial numbers, tenant, service approval, and Task Queue before changing registration. For a management-only rollback, restore the recorded Central service states and verify local access and HA health. Do not dissolve the HA pair, rerun the setup wizard, or force deregistration through the CLI as a display fix. Reversing HA formation requires the separately approved HA recovery plan; escalate unresolved registration or ambiguous node scope to Sophos Support with the captured state.

Safely narrow down a blocked registration

When the status is Approval Pending or Waiting for approval from Sophos Central, don’t register again or deregister prematurely. First check the correct tenant and serial number, approval by a Super admin in the affected tenant under My Products > Firewall Management > Firewalls, IPv4 internet access, DNS, time, and the required outbound services. For HA, both serial numbers must be entered in Central, and the OTP is entered on the primary. If the status remains stuck after correcting the prerequisites, capture screenshots of both status views, the time, serial numbers, and HA roles for Sophos Support.

Clear the Synchronized Security configuration only as an approved support operation. The Device Console documentation for SFOS 22 and 23 describes system synchronized-security central_registration deregister to remove the Synchronized Security configuration from Sophos Fusion or Sophos Central when it blocks registration or deregistration. The intended case here is an existing firewall whose registration remains blocked by Synchronized Security after the checks above, with Sophos Support confirming that cause. This is neither complete device deregistration through Deregister in the next section nor internal database cleanup using SQL. The command changes state; it is not a read-only diagnostic test or a general fix for Approval Pending.

Before any execution, record the intended and current tenant, device and serial number, exact SFOS version including build, registration status, active Central services, Security Heartbeat, Synchronized Application Control, and affected rules and their existing effect in the support case. For HA, include both serial numbers, primary/auxiliary roles, synchronization state, and the explicitly confirmed scope of affected nodes. Test and retain authorized local WebAdmin and console access independently of the Central management path. Keep a current local backup, its password, and the Secure Storage Master Key available.

Do not execute without build-specific approval. Sophos Support must first confirm that configuration clearing is appropriate for this case, the expected impact on registration, services, Heartbeat-dependent traffic and HA, and the recovery procedure, including any necessary registration and service approvals. Documented syntax alone guarantees neither unchanged services nor reversible restoration of the previous state; a backup alone does not establish that recovery path either. If impact, node scope or recovery remains unclear, withhold execution and keep the case with Support. Do not substitute SQL changes or forced complete deregistration.

After an explicitly approved operation, follow the Support plan to verify registration in the correct tenant and both status views, intended services, and independent local access. Also check Security Heartbeat with the managed pilot endpoint, application recognition where applicable, affected rule behavior, production traffic, logs and, for HA, roles and synchronization. A visible firewall alone is not proof of success. For unexpected results, capture the state and follow the approved recovery plan with Sophos Support rather than running the command again.

Change Central services or deregister

Turning off Security Heartbeat, Synchronized Application Control, or Sophos Central management does not deregister the firewall from Central. However, the services are not independent: turning off Security Heartbeat also disables Synchronized Application Control, and endpoints and the firewall stop exchanging health status information. A Heartbeat pause therefore affects more than a single service.

Before the change, record the previous on/off states of both Security Heartbeat and Synchronized Application Control, as well as the state of the affected service, under System > Sophos Central. Then disable the intended service, save, and check both the affected service states and that the firewall remains registered.

To roll back, restore the affected service and both recorded states, and have a Super admin in the affected tenant accept any renewed service approval in Central. Explicitly check Security Heartbeat and Synchronized Application Control separately rather than assuming that enabling Heartbeat alone restores both correctly. If Heartbeat was previously active, use a managed pilot endpoint to check the current health status and the corresponding Connected counter in Control Center as described above. If Synchronized Application Control was previously active, also verify application recognition under Applications > Synchronized Application Control with the pilot endpoint; Use Application Control in a targeted manner explains the relevant validation workflow.

Complete deregistration is a separate, planned lifecycle step:

1. Create a current local configuration backup and keep its password and the Secure Storage Master Key available. Record the tenant, serial numbers, enabled services, firewall groups, pending tasks, reporting, and Central backups. For HA, record both nodes and their roles.
2. Test local WebAdmin access with an authorized account. Complete pending Central tasks or record their state and choose a maintenance window. Don’t rely on Central backup files as the only rollback path because they are deleted when the firewall is removed from Central Management.
3. On the firewall, open System > Sophos Central and select Deregister. Don’t use undocumented Device Console or Advanced Shell commands as a shortcut.
4. Locally verify that the firewall is no longer shown as Central-managed. Under My Products > Firewall Management > Firewalls, check the device object’s state; don’t mistake a remaining object for a working registration. Then verify local access, production traffic, logging, and, for HA, cluster status.

To reverse the change, register the firewall again through the normal OTP or super-admin workflow, have a Super admin in the affected tenant accept the required services in Central, and repeat the service-specific acceptance tests. If Deregister isn’t available, deregistration remains stuck, or the affected scope is unclear for HA, don’t force it through the CLI. Provide the captured state to Sophos Support.

Check After Connection

After registration, you should not only check whether the firewall is visible in Sophos Fusion. It is crucial to verify that the activated services really work and that responsibilities are clear.

Useful post-registration checks:

1. Check in Sophos Fusion whether the model, serial number, and license status are displayed correctly.
2. On the firewall under System > Sophos Central, check whether the desired services are active and connected.
3. If Manage from Sophos Central is used, open My Products > Firewall Management > Firewalls in Central and click the firewall name to open its WebAdmin console. Allow a few seconds and verify access with the intended administrator role; keep the working local administration path available while testing.
4. If reporting is active, check in the Log Viewer and in Sophos Fusion whether current events are arriving.
5. If cloud backups are active, configure the scheduled backup and document the last successful backup time.
6. Check alerts, roles, and responsibilities in Sophos Fusion.
7. If changes are distributed via Central, check the Central Firewall Management Task Queue.

Especially when managing multiple firewalls, document each registration internally: tenant, serial number, location, active Central services, reporting retention, backup interval, and responsible person.

Accept Central Services Separately

After registration, do not only check the global Central status. The individual services have different failure patterns and therefore need separate acceptance tests.

• Registration and inventory: The firewall appears in the correct tenant, and its serial number, model, license, and location are correct.
• Manage from Sophos Central: Access through Central works with the intended admin role, without WebAdmin unnecessarily remaining open from the WAN.
• Central Reporting: A deliberately triggered event appears in the Report Hub with the correct firewall, time, rule ID, or log type.
• Central Backups: A scheduled or manual backup completes successfully, and backup interval, password, and Secure Storage Master Key are documented.
• Backup retention: The five most recent Central backups and any permanently stored backup are known. For HA, it is clear that the Primary generates the backup.
• Backup alerting: Failed Central backups generate alerts and email notifications that are reviewed by a responsible person.
• Central Tasks: After a Central change, the Task Queue is checked until the task has completed successfully or is escalated cleanly.
• Security Heartbeat: Sophos Fusion shows the expected pilot status, and the corresponding counter in Control Center is consistent with it. Rule-based restrictions are only tested step by step after establishing this baseline.
• Alerts and responsibility: It is clear who regularly checks failed tasks, backup problems, reporting gaps, and license warnings.

This separation prevents a typical operational mistake: a firewall can be visible in Sophos Fusion while reporting, backups, or Central tasks are still not working correctly.

Common Mistakes

Firewall is Registered in the Wrong Central Account

This often happens with service provider changes, test accounts, or multiple historical SophosID accounts. In this case, do not simply attempt a second registration. First, clarify where the firewall currently resides, who has access to the tenant, and whether an account transfer is necessary.

Central Management is Confused with Local WebAdmin

Manage from Sophos Central is an additional access path. The local WebAdmin Console, local admin users, MFA, Device Access, and SSH remain independent security controls. It is especially important that WebAdmin does not remain accessible from the WAN just because Central Management has not yet been tested.

Central View is Not Validated Locally

For group policies, HA clusters, WAF rules, and firmware tasks, Central should not be treated as the only source of truth. Central can show that a change is planned, applied, or visible. What matters is whether the affected firewall has processed the change and whether the real traffic or service works afterwards.

In practice: after Central changes, check the Task Queue, local WebAdmin view, Log Viewer, and, if required, the Audit Trail. If the Central interface only keeps loading, an HA pair appears twice, or a group rule cannot be moved, that is not automatically a firewall rule problem.

Reporting is Activated, but No Usable Data Arrives

Then you should first check whether Send reports and logs to Sophos Central is active, whether the appropriate log types are enabled, and whether the firewall can reach Central. Then check the detailed points on log selection, retention, and reports in the article Activate Central Firewall Reporting.

Cloud Backup is Treated as the Only Backup

Central backups are convenient, but they do not replace a complete recovery plan. For critical locations, it should also be clear where local backups are located, who knows the backup password, whether the Secure Storage Master Key is documented, and how a restore or reimage would proceed.

No One Checks Central Tasks and Alerts

Central only helps if messages and failed tasks are also processed. Especially with group policies, firmware tasks, reporting, and backups, it should be clear who checks warnings and how errors are escalated internally.

Frequently Asked Questions