Sophos Fusion: Set up and verify Server Threat Protection safely

After installing a server agent, seeing a policy is not proof that protection is working. If installation and agent acceptance are still outstanding, follow the Windows Server installation and acceptance guide for Windows Server, or the separate SPL installation procedure for Linux servers. To establish a safe baseline in Sophos Fusion (formerly Sophos Central), first identify the actual server and its platform, then retain the recommended settings in a small pilot group, and finally check the server’s Policies, Status, and Events tabs to see what took effect. Windows and Linux servers share a policy interface, but not every protection feature.

Before making changes: record the platform and scope

Record the tenant, server name, operating system, installed agent, available licence or subscribed features, server role, and current policy. Compare a Windows and a Linux pilot server with the same production profile; database servers, domain controllers, and Linux container hosts need separate tests because their workloads and file-access patterns differ. Pilot-Windows-App and Pilot-Linux-App are example server group names you choose, not Sophos-defined values. Under My Products > Server > Servers, open the Server Groups tab and select Add Server Group. Create one group for each platform and assign individual servers. A server can belong to only one group: moving it into a pilot group removes it from its previous group and can also change other effective policies. First document each server’s former group, applied policies, and their order, assignments, and settings as a rollback baseline. Start with a few representative servers, not all of production.

The Base Policy protects servers when no higher-priority matching policy applies. Additional policies are suitable for targeted deviations. Sophos Fusion applies the first matching active policy from the top of the list for each policy type; settings from multiple Threat Protection policies are not combined. The policy fundamentals guide explains this shared selection model, but this pilot concerns Server policies and server groups, not endpoint computer groups. Put the specific pilot policy above a general policy and keep the remaining settings at the recommended baseline. Changes to a shared policy affect every server assigned to it: check assignments before selecting Save.

Configure Server Threat Protection in the pilot

Open My Products > Server > Policies and select Add Policy. If prompted to choose a type, select Threat Protection; to edit an existing policy, first open its policy type and then its name. Under Assigned to, assign the new policy to the small pilot group, and check Excluded from if shown. Do not inadvertently change the Base Policy for all servers.
Open Settings and leave the policy enabled. Under Show filters > Operating System, select Windows and click Apply; repeat with Linux and click Apply again. This filter displays settings available for each platform; it does not enable an agent feature. Recommended and Enabled/Disabled help reveal deviations.
Where possible, leave Live Protection, Deep Learning, and Real-time Scanning - Local Files and Network Shares at their recommended settings. Within Real-time Scanning - Local Files and Network Shares, Scan controls real-time scanning of local files and files accessed over the network; Local limits scanning to files on the device. Switching to Local requires a documented use case and a test of the affected shares.
Linux on-access protection is off by default. For a Linux pilot that requires protection on file access, install the SPL antivirus product or its AV plugin. In the effective Server Threat Protection policy, both Scan and Enable scan for Server Protection for Linux Agent must be enabled under Real-time Scanning - Local Files and Network Shares; the second option is off by default. Verify the installed AV component on the pilot server as described in the linked SPL installation guide. Without the component or either enabled option, do not accept the pilot as on-access protected: document the gap and stop expansion. A scheduled scan is no substitute for real-time scanning: it runs at set times, not on file access. Enable scheduled scan is available for both platforms; if needed, choose a low-load time window. The scheduled time follows the device’s local time. On Linux, scheduled scans use Live Protection regardless of the corresponding policy setting.
Keep Enable event journals on where possible. Turning it off leaves no journal data for later investigations during the disabled period; Threat Graphs and, if used, Server File Integrity Monitoring also stop working. Do not configure global journal sizes here. Save the change and verify the effective policy on the device before assigning more servers.

Do not equate platform capabilities: Internet real-time scanning, HTTPS decryption, CryptoGuard/exploit protection, AMSI, Adaptive Attack Protection, and Security Heartbeat are documented as Windows features in this policy. That does not imply equivalent protection on Linux. Linux runtime detections are a separate Linux feature requiring an appropriate licence; a visible option alone proves neither entitlement nor active runtime detection. Check the specific licence and agent/tenant status before planning to use it. The Linux options for real-time scanning and terminating associated malicious processes are likewise not equivalent to Windows runtime protection modules.

Add exclusions only for a demonstrated conflict

A scan exclusion reduces protection, even if other checks may still apply to the excluded object. For a suspected false positive, find the timestamp, detection, and affected path on the Events tab; compare them with the application version, vendor guidance, and a reproducible error. A database application can also suffer a measurable scanning impact from frequent file access without a detection event: compare runtime, load, and affected access patterns reproducibly before and after a time-limited test in the pilot group. A service being slow, without evidence linking it to scanning, does not justify an exclusion.

Under Settings > Exclusions > Add Exclusion, choose Exclusion Type and enter only the specific affected object. For File or folder, limit Active for to Real-time Scanning or Scheduled Scanning unless both are demonstrably affected. For confirmed Windows database load, first consider Process (Windows) with the application’s full path, following vendor guidance: this excludes files used by that process when it accesses them, rather than opening an entire directory tree to other processes. On Linux, File or folder (Linux) supports file and folder paths and the wildcards ? and *; the fully specified path /mnt/hgfs/excluded is a syntax example from Sophos documentation, not a general recommendation to exclude that directory. Replace it only with a verified path on the affected server. Do not treat Windows process or exploit exclusions as Linux equivalents. Do not use Detected Exploits or hashing exclusions as blanket scan workarounds; consult Sophos Support before using hashing exclusions. A policy exclusion applies only to servers to which that policy applies; a Global Exclusion, by contrast, applies tenant-wide. While reviewing an event, do not create a global detection exclusion with Don’t detect this again. The shared endpoint and server exclusions guide explains types, scope, and rollback; the choice here remains a server-policy decision. Document the detection event or reproducible performance data, vendor guidance, reason, owner, affected servers, test, and planned expiry date. After saving, verify the affected workflow and remove the exclusion once the root cause is fixed and the rollback has been tested.

Verify the effect on the actual server

Open My Products > Server > Servers, select the pilot server, and check:

Policies: Is the intended policy actually listed under Threat Protection? If not, check assignment, activation, and order. Clicking the policy opens its settings; changes there also affect other assigned servers.
Status: On newer Windows servers, Health status and ratings for Communication, Operations, Services, System, Threat, and Update can indicate problems. On Linux and older Windows servers, Security Health shows, among other things, the last contact with Sophos Fusion and running Sophos services; this is not the same detailed Windows rating. A green indicator alone does not prove tested attack protection.
Events: Check messages and successful updates for the relevant time window, and, if a detection already exists, inspect it via Details. The absence of a malware event is not a functional test. Do not deliberately trigger malware or exploit activity on a production server. The displayed Last active time may lag behind an event because it is updated roughly hourly.

For Linux, also check locally that the antivirus product/AV plugin is installed and that the policy has been applied (see the verification procedures in the SPL installation guide). Policies, Status, Events, and a green health indicator alone prove neither active on-access scanning nor its detection effectiveness. Only on an approved non-production system can a controlled functional test with the harmless EICAR test file, following Sophos instructions, verify the response on file access, the AV log entry, and the alert in Fusion; remove the test file and handle the test alert according to local procedure. Without such a test, detection effectiveness remains unconfirmed; do not run malware tests in production.

Account Health Check also flags Server Threat Protection policies that deviate from Sophos recommendations. If it raises a warning, open the named policy, inspect the settings marked red, and correct them selectively. Fix automatically resets all options in affected policies to recommended settings and can overwrite intentional pilot deviations; review affected servers and the scope of the change before confirming. Separately inspect warnings about risky Policy exclusions: this check detects only particularly unsafe exclusions, so a green status does not certify that every exclusion is safe. Do not apply an automatic fix there without reviewing the entire affected policy scope either; it may remove exclusions from all affected policies. The audit log records automatic changes. After any correction, recheck the pilot server’s policy, status, and events.

When the result does not match the configuration

Wrong policy or expected policy missing: Check the tenant, server group, enabled policy, and list priority. Read the actual name on the server’s Policies tab; do not infer the effective policy from the policy list alone.
Linux real-time scanning unclear: In the effective Linux-filtered policy, check Scan and Enable scan for Server Protection for Linux Agent under Real-time Scanning - Local Files and Network Shares, and check the local SPL AV plugin/antivirus product. If anything is missing or its effect remains unclear, do not claim on-access protection or expand the pilot; pass agent/licence details and diagnostics to Sophos Support.
Warning or red health rating: On Windows, open the specific Communication, Services, or Update rating; on Linux, compare last Fusion activity, running services, and alerts. Resolve communication or update problems first, then check again that the policy was received.
Application slow or file blocked: For a block, check the contemporaneous event and path; for a slowdown without an event, capture reproducible load and file-access comparisons along with vendor guidance. Do not exclude an entire directory tree or create a tenant-wide exclusion on suspicion. A narrow pilot exclusion is defensible only with an evidenced cause and a rollback path. If the discrepancy persists, document the finding, policy assignment, and agent status, and escalate.

Stop and roll back the pilot

Stop expansion if Linux on-access protection is missing, the wrong policy is effective, an agent remains unhealthy, blocks are unexplained, or a business-critical workload suffers a measurable disruption. Record affected servers and the discrepancy; coordinate rollback with workload owners during a change window. Return each moved server to its previous group, or remove it from the pilot group if it had no previous group. If pilot changes modified an existing policy, its priority, or its assignment, also restore the documented order, assignment, and settings; simply returning to the old group does not repair an edited policy. Withdraw pilot exclusions deliberately after checking the affected workload: first make sure the earlier block or performance problem will not recur; if necessary, establish the cause and document a narrowly scoped, time-limited residual need rather than removing an exclusion without control. Then check every affected server for group membership, effective policies, status/health, events, and the workflow that was previously disrupted. Until verification succeeds, keep the rollout stopped and escalate the incident.