Sophos Server Protection: Check Windows and Linux Platform Support Before Rollout

In brief: Include a server in the next installation or update wave only if its specific operating system and agent meet current Sophos support requirements, the required features are available in your tenant, and a representative pilot remains healthy. A line in old release notes only establishes that components once existed for a platform—not that its operating system is supported today without restrictions. If reliable evidence is missing, keep the server out of the wave and ask Sophos Support to clarify its platform status.

This guide helps you make the approval decision before a new installation, operating system change, or agent update. The actual steps for Windows Server and Sophos Protection for Linux (SPL) are in their respective installation guides.

Check release versions and support status separately

As checked on September 24, 2026, the Sophos release notes list 2026.2.2.1 (September 2026) as the latest Windows Server Core Agent version, with separate component sections for Windows Server 2016 and later and for older legacy platforms. The current Windows Server Core Agent release notes are the reference for version and component changes. They also warn that software rollout can take several weeks after the notes are published. A historical or current component section is not approval for a particular Windows edition or build.

According to the Sophos Windows Server System Requirements (KBA-000003024, dated May 7, 2026), Windows Server 2016, 2019, 2022 and 2025 are fully supported server generations. Windows Server 2008 R2, 2012 and 2012 R2 are legacy platforms and require an Extended Support license; some features may be unavailable, unsupported or no longer updated there. Sensor Mode is not supported on legacy platforms. This dated overview is not blanket approval for every edition, architecture or build variant. Before the wave, record the exact edition, full OS build, architecture, agent version, intended protection mode and, for legacy hosts, actual Extended Support entitlement. Before approval, check the specific combination against the current Sophos Windows Server System Requirements, supported Windows variants and retirement calendar. If the Sophos support page is unreadable or does not provide a clear answer, suspend approval and consult Sophos Support. An agent that starts, or a release-notes entry alone, does not prove support entitlement.

Check resources by license and mode: As of May 7, 2026, Sophos Endpoint – Server requires at least 8 GB free disk space, 8 GB RAM and 2 cores. Sophos EDR, XDR and MDR – Server require at least 10 GB free disk space, 8 GB RAM and 2 cores; 10 GB free disk space, 16 GB RAM and 4 cores are recommended. These requirements apply to both Full Protection and Sensor Mode—the resource table does not override the prohibition on Sensor Mode on legacy platforms. Sophos strongly recommends an SSD for the boot drive. These figures are general guidelines, not a guarantee of adequate performance for every workload: CPU, RAM and disk usage may temporarily rise, especially during malware detection and cleanup. Check headroom and behavior in your own pilot.

For Linux, the SPL release notes list 2026.3 (September 2026) as the latest version on the same review date. Availability in your tenant may again follow publication of the notes. Under System requirements, the current minimums are 2.5 GB free disk space, 2 GB available memory, x86_64 or ARM64, a running systemd instance, Bash, and glibc 2.17 or later; ARM64 requires glibc 2.18 or later and kernel 5.3 or later. These figures are a dated basis for checking, not permanent approval for every Linux distribution or kernel.

The Sophos guidance on SPL distributions and kernels points to System requirements > Supported platforms in the release notes for the current platform list; it is not a second, independent approval matrix. Distribution, major and minor release, architecture, running kernel, and vendor support must all align. As of the review date, the tested list includes RHEL 8–10, Debian 11–13, and Ubuntu 22.04/24.04 LTS and 26.04, among others. There is also a separately identified legacy list, which does not confer automatic approval. Sophos tests the latest active minor releases or service packs; distribution-specific minimum kernel versions may apply on x86_64. Kernel 5.3 is therefore not a general x86_64 approval threshold. Even a kernel above a minimum can be problematic: the current notes identify a known ftrace bug affecting 5.10.133 through 5.10.142 that may hang the kernel. Do not approve that combination merely because setup appears successful; clarify the kernel and Sophos guidance first.

Separate exceptions before the pilot: If a Linux image is immutable, do not approve SPL for it here. Sophos says SPL is not designed for immutable distributions and points to the separate Sophos Linux Sensor (SLS) product for those platforms. SLS is not the SPL XDR Sensor; this guide does not cover SLS installation. Unlisted downstream distributions, custom or minimal kernels, and hardened systems do not automatically become tested platforms either: Sophos describes support on a best-effort basis and may require reproducing an issue on a supported platform or upgrading.

For an existing legacy Linux host, also check its actual Extended Support entitlement and both the installed software package and the package assigned through Update Management. On September 24, 2026, Sophos identifies LTS package 2026.1.0.35 as supported for legacy versions and recommends assigning it through Update Management. If problems arise with a newer package, returning to the supported package may be necessary for investigation. Before changing anything, check the then-current Sophos guidance and whether the specific package is available: the SPL 2026.3 heading is not an automatic target for a legacy host, and 2026.1.0.35 is neither a permanent commitment nor a general downgrade procedure.

Document approval for a specific rollout wave

A short verification record helps prevent a working installation from being mistaken for proof of support. Record the following separately for each server family—for example, Windows application servers and Linux database servers:

Current and target state: Server role, OS edition or distribution and minor version, full build or uname -r, architecture, installed agent and its components, and intended target release. For Windows, check the license type (Endpoint – Server or EDR/XDR/MDR – Server), Full Protection or Sensor Mode, free disk space, RAM, cores and boot drive. For Linux, also check image type (immutable or mutable), available RAM and space on the actual installation volume, running systemd, Bash, and glibc. For legacy Linux, record the installed and assigned software packages separately.
Evidence: Record the date and version of the Windows system requirements and the Windows or SPL release notes, current OS/kernel requirements, lifecycle/Extended Support and actual entitlement for legacy hosts, and the required license and tenant features. For Windows without unambiguous evidence for edition, build, architecture and protection mode, explicitly mark the status unresolved, not “compatible.” A release note announcing a new feature—for example, Linux as an Update Cache or Message Relay starting with SPL 2026.3—does not establish its actual availability in the tenant or replace its separate prerequisites.
Decision: Choose “approved for pilot,” “update OS/kernel first,” or “stop and clarify with Support.” Name the reviewer, change window, pilot devices, and stop criteria. The first option requires positive platform evidence; an untested downstream build is not equivalent to a tested combination. Keep immutable Linux out of the SPL wave. Proceed with legacy Linux only after confirming entitlement, suitable package assignment, and current support evidence.

On the Linux pilot, run these read-only commands on the target server as close to the change window as practicable and record the output:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

For free -m, compare the available column (not total) with the required 2 GB free memory. df -h -- /opt is useful for a default installation only if /opt is on the actual target volume; with a separate mount or --install-dir, instead use df -h -- <Pfad> on an existing path on the actual installation volume and verify 2.5 GB free. If that volume cannot yet be determined, do not approve the resources. ps and the /run/systemd/system directory check the running init system; Bash must be available, and the reported glibc version must meet the requirement for the architecture. Also establish whether the host is immutable from the image/OS type in the deployment inventory; os-release alone does not prove that a host is mutable. For Windows, save the full OS and agent details from the managed inventory and system properties, along with the resource values for the intended license and protection mode. Repeat the check whenever the OS, kernel, agent, license, or Sophos requirements change—do not rely on this article’s date alone.

Pilot, health, and the next wave

Start with one representative server per relevant platform combination: the same OS minor version, architecture, and kernel; a similar network/proxy path; and a comparable server role and workload. Before the pilot, verify the backup and recovery route, secure console or out-of-band access, and reserve a maintenance window that allows for a possible restart. A database with particular I/O peaks needs a matching load test; booting an idle test VM is not enough.

After installation or update, check My Products > Server > Servers in the correct tenant: the pilot should appear once, communicate recently, have the expected protection components and intended server group, and show no persistent health alert. Compare installed components and versions on the device and in Fusion; check the effective server policy on the host, not just its group assignment. On Linux, also check sudo systemctl status sophos-spl. Only if the antivirus plugin is installed, read sudo cat /opt/sophos-spl/plugins/av/VERSION.ini for the default installation path (adjust for a changed --install-dir) and compare its version with the Server Protection component, not the SPL base component, in Central. On an SPL XDR-only sensor without the AV plugin, instead check the components actually installed and their version/health status in Central; a missing AV file is not an error there. A healthy service alone confirms neither current malware protection nor effective policy enforcement. Only when AV protection is installed, and after checking that both Real-time scanning - Local files and network shares and Enable scan for Server Protection for Linux Agent are enabled in the effective Server Threat Protection Policy, perform a planned, safe on-access detection test as described in the Linux installation guide. An XDR-only sensor is not a suitable candidate for this test.

Then compare the business application, restart behavior, network connections, and normal workload with the baseline. For a new agent feature, first check whether it is actually offered to the pilot in the tenant. Begin the next, limited wave only after platform evidence, agent and policy status, health, and application testing have all passed. Release notes may precede deployment; if the version actually offered differs, investigate rather than force a download.

Stop and prepare a recovery path

Before the change, record the working OS/kernel and agent versions; for legacy Linux, also record the installed and assigned software packages, backup, maintenance window, protection mode, and responsible person. The presence of an older agent version in historical release notes does not by itself mean you can return to it. An OS or kernel rollback requires separate checks of bootability, data consistency, and support for the target version. Even if Sophos may request a return to a supported package when investigating legacy Linux support cases, Sophos software packages and update policies are not a universal downgrade switch; clarify the recovery path for the specific host with Sophos in advance.

If registration fails, health remains poor, protection coverage is wrong, unexpected restarts occur, or a server application is disrupted, stop distribution and automatic retries immediately, identify and scope the affected hosts; do not start another wave. First compare the tenant, connectivity, effective policy, offered agent version, and any OS/kernel discrepancy against the verification record. Limit any policy correction to the pilot and validate it again afterward; do not disable protection tenant-wide. If a return is necessary, use the previously defined and tested system recovery route and the Sophos Support procedure appropriate to the specific agent version. Do not remove components or drivers on a hunch. If platform support or a supported recovery path remains unclear, preserve logs and platform details and contact Sophos Support; keep the rollout wave on hold until then.